Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, меня зовут Алексей, я руковожу цифровыми продажами одного из крупнейших региональных банков нашей страны. Специфика моей работы заключается в том, что под моим крылом сконцентрирован и бизнес, и IT. Поэтому сегодня я расскажу, как при помощи технических решений мы решали базовые потребности бизнеса, а точнее, как мы сделали систему мониторинга и навигации звонков на бесплатном движке, увеличили конверсию и при этом сократили расходы.
Алексей Аверин
Директор по развитию цифровых каналов в Банке Синара. Поделился с Нетологией опытом работы
Зачем нам понадобилась своя система
Когда-то давно банк, в котором я работаю, использовал только один внутренний кол-центр. Так как в те времена доля клиентов, которые приходили через цифровые каналы, была маленькой, для обслуживания текущей клиентской базы такого центра хватало.
Но время шло, появлялись новые продукты. При росте количества заявок на кредиты в банке решили не расширять внутренний кол-центр, а подключить внешние на аутсорсе (далее — ВКЦ) для обработки заявок. Для своего центра требовались затраты на наём, обучение, оборудование рабочего места, телефонию и штат.
Интеграция с внешним исполнителем была в 2,5 раза дешевле.
Так что мы подключили сначала два кол-центра, а после ещё два. Мы интегрировали ВКЦ путём обмена звонками через телефонию Avaya, которая уже была установлена в банке. Внутренний центр работал со старой базой клиентов, так как у них был доступ ко всем персональным данным. А ВКЦ работали с новыми клиентами.
Клиент заполнял заявку на нашем сайте или лендинге партнёра, после этого заявка попадала к нам в CRM. В большинстве случаев банку не хватало данных для решения о сотрудничестве, то есть клиентскую анкету требовалось дозаполнить. Для этого — связаться с клиентом и запросить у него недостающую информацию. На первоначальном этапе всё это отслеживали вручную и уже по факту: заявка пришла во столько-то, результат получили во столько-то, а промежуточные статусы не мониторили. Единой статусной базы по заявкам на тот момент не было. Примерно через 4 месяца использования системы количество заявок снова выросло в три раза, ВКЦ увеличили количество операторов.
По выгрузкам из Avaya все поняли, что реализация неэффективна, а все показатели можно существенно улучшить.
Основные проблемы, с которыми мы столкнулись:
Одну заявку на кредит мог забирать только один кол-центр из четырёх. Он совершал по ней в течение 3–5 дней в среднем до четырёх попыток дозвона, после чего возвращал банку результат.
ВКЦ сам переносил звонки внутри своей системы и определял время перезвона клиенту. Из-за этого случались сбои: часовой пояс клиента никто не определял, поэтому операторы могли позвонить в неудобное время.
Как правило, с клиентом работал только один оператор.
Конкретный ВКЦ брал в работу заявку и работал с ней «от и до». Из-за этого случались провалы. Допустим, первый кол-центр взял заявку, начал заполнять данные, но звонок сорвался. И так как у этого ВКЦ все операторы заняты, заявка встаёт в очередь, звонок откладывается. В других КЦ операторы могут быть свободны, но принять эту работу они не могут. Или заявку заполнили полностью, кредит одобрен, но нужно, чтобы клиент подтвердил доход, принес справку. Клиент опять же встаёт в очередь в этот ВКЦ, а у другого могут быть ресурсы, но они не задействованы.
Иногда дополнительно общаться с клиентом было не нужно — когда он заполнил заявку сам. Но ВКЦ не знали об этом и продолжали звонить.
ВКЦ брал в работу заявку на кредит и мог позвонить клиенту 10 раз, а мог — один раз. Мы же видели, что происходит в самом центре, и не могли контролировать качество работы: как операторы звонят, сколько разговаривают и так далее.
Что мы хотели получить
По результатам выявленных проблем мы решили реализовать микросервис, который бы позволил нам управлять всеми звонками между кол-центрами: делать правильную маршрутизацию, получать полную аналитику, управлять очередью.
Вторая задача микросервиса — произвести полную интеграцию с кол-центрами по АПИ. Мы хотели видеть полную статистику, получать результаты звонков в онлайне, вести аналитику работы каждого оператора и кол-центра.
Как мы создали и реализовали микросервис
Все ВКЦ в работе используют Naumen. Для микросервиса мы собрали команду из аналитиков и бизнес-аналитиков, разработчиков Java, Python, и тестировщиков — всего 14 человек.
Микросервис разрабатывали на Java с использованием Spring Boot. В качестве движка для обработки бизнес-процессов, разработанных на bpmn, применяли Camunda. Интеграции выполнили путём реализации REST API. Документацию сделали с помощью Swagger.
Использование Camunda позволило нам добиться существенного снижения временны́х затрат на внесение модификаций в бизнес-процесс — мы ускорились в три раза.
Раньше всё это реализовывалось в коде и проходило все три стадии: аналитика, разработка, тестирование. Теперь сами аналитики получили инструментарий для внесения правок — Camunda Modeler. С его помощью для большинства задач, хоть и не для всех, пропала необходимость в привлечении разработчиков.
Почему Camunda:
Она бесплатная.
У неё большое и развитое сообщество, так что можно легко получить или найти ответы на вопросы.
Наличие GUI, в котором можно видеть, как пошагово прошёл процесс.
Поддержка Postgre в качестве БД.
В дополнение к этому мы зафиксировали общее снижение количества ошибок в системе. Баги появлялись на этапе, связанном с переносом бизнес-процесса в код. Этот этап просто исчез, а сам процесс стал реализовываться в bpmn нотации, исполняемой Camunda. Мы снабдили бизнес-аналитиков знаниями о переменных в контексте выполнения камундовского движка, чтобы, условно, они понимали, в каких переменных хранятся какие значения. В итоге мы смогли замкнуть весь процесс на бизнес-аналитиках, убрав из него системных аналитиков и разработчиков, привлекая последних только в тех случаях, когда требуется добавить в контекст недостающие значения.
Что мы, собственно, по итогу сделали: начали применять DMN внутри уже существующих bpmn-процессов, выполняемых Camunda, и camunda-engine-dmn внутри сервисов, для которых подтягивание всей Camunda было бы избыточно.
В качестве приятного бонуса такого решения — возможность внесения правок в процесс без необходимости пересборки приложений и их остановки. Вы можете, используя rest api Camunda, заливать новые схемы прямо в онлайне.
На реализацию ушло три месяца. Микросервис в итоге учитывал следующие параметры:
количество свободных операторов на стороне ВКЦ,
количество звонков в очереди и загруженность ВКЦ,
часовой пояс клиента,
онлайн-обмен статусами между банком и всеми ВКЦ.
Какой результат мы получили и что захотели потом
Мы закрыли все основные первоначальные боли. Вот что получилось:
По одной заявке клиента банк генерирует необходимое количество звонков и помещает их в общую очередь. Разные ВКЦ забирают звонки в работу и по каждому совершенному звонку возвращают результат.
Банк планирует звонки в нужное время, чётко определяет часовой пояс клиента, исключает кейсы недопустимых по времени звонков.
Звонок попадает в работу разным операторам, не создаётся длинной очереди.
Появилась возможность регулировать типы звонков на конкретный ВКЦ. Когда-то нужно заполнить анкету с нуля, когда-то уточнить некоторые сведения, а иногда вообще не нужно ничего заполнять, требуется только подтверждение.
При отмене необходимости дальнейшего дозвона уже ненужные звонки исчезают из очереди, клиентам никто не надоедает.
Банк по каждому звонку пишет четыре временных параметра: время забора звонка в работу, начало совершения вызова, окончание вызова, выдача банку результата звонка.
Но работая над всеми этими данными, мы поняли, что для увеличения эффективности можем оперировать гораздо большим количеством параметров. На основе анализа ретроданных после полугода работы мы обнаружили, что не все ВКЦ работают с трафиком одинаково. У нас есть более 30 разных источников заявок и 4 контакт-центра, которые их обрабатывают. Все эти 30 источников трафика дают неравномерный поток заявок: какие-то более сложные, какие-то менее продуктивные и хуже конвертируются.
Поэтому мы решили улучшить свой микросервис и добавить больше переменных в распределение звонков.
Мы построили зависимости от типа партнёра по трафику, социально-демографических показателей клиента, места его проживания и так далее. Всего использовали более 30 параметров. На основании этих данных уже распределяли звонки на конкретных операторов, которые наиболее эффективно отрабатывают именно эти типы звонков.
Для этого был реализован модуль на python, который в моменте вычислял все эти данные, а микросервис распределял звонки. Для раскатки модели использовался наш сервер MLOps. Основная проблема, с которой мы столкнулись, — сохранить точность модели при онлайн-работе приложения. Для каждого оператора выделили кластер с определёнными параметрами, обеспечивающий наибольшую эффективность. Далее были разработаны простые модели кластеризации, не требующие больших затрат ресурсов при работе.
Таким образом, мы закрыли не только первоначальные боли, ради которых задумывался проект, но и существенно улучшили его.
Что нам это дало в цифрах:
Показатели успешного дозвона были 49%, после реализации проекта 82%.
Конверсия в заполненную заявку увеличилась в 2 раза.
Сокращение расходов на услуги ВКЦ на 21%.
