Привет! Я управляю подразделением VoIP в группе компаний Dyninno — международном холдинге, который предоставляет услуги и продукты в сфере туризма, финансов, развлечений и технологий в 50 странах. Важнейшей составляющей нашего бизнеса является продажа авиабилетов. Мы работаем по гибридной схеме: привлекаем клиентов онлайн, а тревел-агенты совершают продажи — созваниваются с клиентом, уточняют пожелания и формируют наиболее выгодное предложение от авиакомпаний. Сейчас у нас свыше 4200 тревел-агентов, и как раз-таки их работу и обеспечивает наш внутренний кол-центр. 

В этой статье я расскажу о разных сценариях работы территориально распределенного кол-центра на базе Asterisk, Kamailio и rtpengine. 

Как работает кол-центр 

Есть несколько сценариев взаимодействия с клиентами. Мы используем три типа автономного набора номера, или кампаний обзвона под каждую ситуацию:   

• Preview Dialer, когда мы резервируем агента для звонка и после его ответа начинаем звонить клиенту; 

• Predictive Dialer, когда система пытается спрогнозировать освобождение агентов и заранее начинает совершать следующие звонки клиентам для обеспечивания максимального КПД агента; 

• Power Dialer, когда мы можем регулировать интенсивностью обзвона (подстраивать количество вызывных линий на агента). 

Также у агентов существует возможность совершения звонка вручную, или из карточки клиента.

Рассмотрим применение Preview Dialer на примере тревел-бизнеса:  

1. Мы получаем лид — базовый запрос и контакты клиента — из нескольких каналов, например, с нашего сайта. Клиент выбирает, когда, куда, с кем он хочет полететь, и оставляет свои контакты: номер телефона, e-mail, имя.

2. Эти данные передаются в CRM-систему. 

3. Дальше уже CRM создает задачу для VoIP на звонок на этот номер.  

По параметрам нашей системы мы должны отзвонить клиенту в течение максимум 5 минут. В нашем случае есть одно отличие от классических систем Preview Dialer: агент не видит первичную информацию из запроса, пока его не начали соединять с клиентом. Делается это для того, чтобы зарезервировать агента в момент начала звонка и одновременно для оптимального распределения нагрузки на агентов.

Как это работает: у нас есть номер клиента и много тревел-агентов в очереди звонков (call queue) в разных странах и разных часовых поясах.  Мы используем самописную очередь звонков с кастомными стратегиями, так как “родная” очередь Asterisk не поддерживает кластеризацию серверов, а это именно наш случай, ведь кластер из Asterisk серверов легко и просто масштабируется. Наша система по заданной логике автоматически выбирает кого-то из свободных агентов и направляет ему звонок. Как только агент отвечает на звонок системы, она резервирует его и начинает дозваниваться на номер клиента.  

Если клиент отвечает – агент выполняет свою работу. Дополнительно, в бэкграунде, может происходить анализ звуковой дорожки и определение автоответчика. Если определяется как автоответчик, то есть возможность выполнить дополнительные действия со звонком; если же клиент не отвечает, то наша VoIP-система пробует перезвонить немного позже – согласно настроенному времени. В зависимости от рынка обычно совершается до пяти попыток дозвона. 

Для анализа автоответчиков мы используем приложение AMD (Asterisk Maсhine Detection), которое оценивает голосовую активность, количество слов в приветствии и другие подобные параметры. AMD работает вкупе с Early Media — в том числе для анализа аудиодорожки в фоне, даже если и агент, и клиент уже подключились. Кроме банального сбрасывания звонка мы используем AMD и для пометки звонков с тишиной. Далее, используя аналитику, проверяем, есть ли проблемы с определенным провайдером, или же это фрод (fraud). Так как мы используем популярные в Америке 800-ые номера (toll-free), то частенько получаем входящие фрод-звонки с тишиной (т.н. toll-free traffic pumping). Если аналитика определяет, что количество фрод-звонков превышает трешхолд, то на определенном номере, который затронут фродом, включаются дополнительные компоненты для защиты. Например, мы применяем IVR с рандомно генерируемыми выборками, либо же делаем дополнительные голосовые запросы с анализом аудио со стороны клиента. 

Если дозвониться не получилось, то далее мы переходим к использованию Predictive Dialer. В этом случае система уже не занимает свободное время агента, а сначала дозванивается до клиента. Если он отвечает и AMD подтверждает, что это не автоответ, то вызов отправляется в очередь звонков, и система соединяет клиента с первым свободным агентом — опять же, согласно настроенной логике. Если система определяет, что ответ автоматический, мы помечаем этот номер, но будем еще раз пробовать дозвониться до ответа человека.  

Predictive Dialer на основе статистики конкретной кампании и времени суток пытается предугадать загруженность агентов и делать обзвон в соответствии с этим показателем, чтобы клиентам не приходилось долго ждать в очереди. Мы анализируем уровень ответа клиентов в определенное время суток и в определенные дни недели, среднее время дозвона, а также среднее время обслуживания клиента агентом. Важным показателем является именно время обслуживания, то есть время, через которое агент будет готов принять следующий звонок. Точность показателя позволяет минимизировать потенциальное ожидание агентами следующего звонка. 

Power Dialer используется для обзвона большого количества клиентов, когда уже известно, что статистика ответов (answer rate) будет очень мала — путем динамической настройки количества вызывных линий на одного агента, учитывая статистику ответов в конкретное время. Например, если уровень ответа 10%, то на одного агента будут вызываться 10 номеров. Конечно, не всегда ровно 10% будет отвечать — система подстраивает количество вызовов, и в случае с большим числом агентов эта стратегия будет эффективнее, соответственно, цена ошибки алгоритма будет меньше. 

Что внутри?  

Наша платформа кол-центра построена на базе open source решений. На границе сети, как условный SBC (Session Border Controller), используется Kamailio в паре с RTPengine. В основе уровня приложения — Asterisk. Вокруг этих решений собственными силами были разработаны менеджмент-интерфейс, аналитика, статистика и отчеты, инструменты для настройки логик звонков (call flow), роутинга, система прав, система менеджмента кластера серверов, анти-фрод система, различные интеграции с другими сервисами и т.д.  

Сейчас мы также внедряем софтфон на базе технологии WebRTC. Он работает через браузер и встроен в CRM — агенту достаточно авторизоваться в CRM-системе, и можно сразу начинать работать: получать входящие и совершать исходящие звонки из любой точки мира без установки или настройки дополнительного программного обеспечения. 

Конкретно в нашей имплементации софтфон разработан на базе библиотеки SIP.JS и имеет интеграции с системами аутентификации, выполняет автоматические получение временных креденшлов и регистрацию к серверу, а также является мульти-оконным — пользователь может иметь N количество окон/вкладок CRM, и при этом софтфон будет иметь одно соединение, одну регистрацию, и пользователь может контролировать звонок в любой из вкладок. Совершая или получая звонок и начиная разговор, аудио с микрофона пользователя будет обрабатываться в одной из вкладок, но при закрытии этой вкладки захват аудио перейдет на любую другую вкладку, что никак не повлияет на звонок.  

Наш софтфон имеет весь стандартный функционал: удержание звонка, перевод звонка (трансфер), конференции, историю звонков, и т.д. Так как это внутренняя разработка, она интегрирована с нашей системой телефонии. Таким образом напрямую с софтфона возможно получить список пользователей, на которых можно перевести звонок — со статусами и детальной информацией. Также имеются возможности персонализации аудио-устройства, перемещения окна софтфона по всей страничке, автоответ с возможностью настройки определенных типов звонков, выбора рингтонов, и т.д. 

Вся персональная информация о клиентах (например, их номера) маскируется, и агент не видит ее ни в интерфейсе, ни в Developer Tools. Звонки из CRM или call history реализуются с помощью API и уникальных идентификаторов клиентов, которые впоследствии превращаются в номер клиента на стороне системы телефонии. 

Используя WebRTC, мы имеем шифрование звонков из коробки. Тут не нужен VPN, и решение работает через WSS. Агенту необходимо лишь авторизоваться в системе, и он может сразу начинать работать без необходимости подготовки инфраструктуры. 

Заключение 

Отлаженная работа кол-центра — основа и гарантия успеха нашего бизнеса. Поэтому важно, чтобы все системы работали стабильно и надежно, были комфортны для наших агентов, отвечая при этом требованиям местного законодательства в более чем 20 странах. А в ближайшее время перед нами будет стоять амбициозная задача по разделению нашей монолитной системы на сервисы, миграции на сервисные компоненты без простоя, а также по масштабированию всех систем как минимум в два раза — согласно прогнозам развития бизнеса. 

Автор:
Алексей Григорьев
Руководитель VoIP отдела
LinkedIn