Predictive Dialer или как живет трудяга «Номеронабиратель»

Перенесено со старого сайта. Автор — Дмитрий Инцин.

Предисловие:

Дата написания статьи — октябрь 2010 года. В связи с чем, большая часть изложенного в ней — изрядное старье. Сейчас модуль автоматического обзвона устроен совсем иначе: архитектура изменена на кластерную, благодаря чему нагрузка перераспределяется и балансируется (максимум нагрузки, который мы видели от клиентов, использующих наш автодозвон, — четверть миллиона звонков в день при 290 операторах в одной очереди), для соединения с оператором используется технология webRTC без телефонов и SIP и многое другое (кое о чем можно прочитать в этом блоге по тегу «Автонабор (дайлер)»).

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

Однако мы решили ничего не менять в тексте, а вместо этого написать новый, тем более что, по прошествии пяти лет, нам есть, о чем рассказать. А базовые представления, изложенные в этой статье, не устарели.


Autodialer или, как его называют на просторах СНГ, «номеронабиратель» (callcenterguru.ru) — модуль автоматических телефонных звонков, одна из важнейших функций колл-центра. Он необходим для эффективного выполнения целого ряда задач: телефонных продаж, работы с должниками, опросов, голосовых оповещений и т.п. И естественно, что автодайлером стараются обзавестись все аутсорсинговые колл-центры и те из ин-хауз колл-центров, кто работает с исходящими звонками.

В то же время стоимость этого компонента программного обеспечения колл-центра обычно сравнима со стоимостью всего базового комплекта ПО, рекламируется и продаётся он часто отдельно, как дополнительная опция или даже как самостоятельный продукт. Цена при этом может складываться из многих факторов (таких, как выгоды от его применения или платежеспособность покупателя), среди которых сложность продукта занимает далеко не первое место. И это делает его доступным не для всех, кому он необходим.

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

ОПРЕДЕЛЕНИЯ

Но вернемся к самому «номеронабирателю». Его задача состоит в звонке абоненту в назначенное время и соединении его с оператором или модулем IVR. Эта задача может выполняться несколькими способами, и в зависимости от используемого в специальной литературе дайлеры принято делить на predictive, progressive, preview. Определения у разных авторов могут отличаться в деталях, но общим является следующее:

  • preview dialer — способ, при котором выбор номера и принятие решения о звонке осуществляется оператором. Это, по сути, обычный звонок, за тем исключением, что оператор не нажимает кнопок на телефоне и не снимает трубку до того момента, как абонент ответит на звонок;
  • progressive dialer — такой способ работы дайлера, при котором он стремится занять звонками максимальное количество доступных коммуникационных каналов вне зависимости от прочих условий. Это подходит для автоматических извещений;
  • predictive dialer — самый, пожалуй, противоречивый способ с точки зрения определения у разных авторов. Он, предназначен для максимального сокращения времени ожидания оператором звонка при минимальных потерях успешных звонков. Т.е. дайлер должен совершать такое количество звонков, чтобы все операторы были постоянно заняты и все ответившие абоненты были соединены с операторами. Для достижения этого используются алгоритмы, «предсказывающие» необходимое количество звонков в следующий момент на основании данных о количестве операторов, которые будут доступны на момент соединения, о средней длительности разговора, о проценте успешных соединений и т.д. Большинство авторов склоняются к тому, что предиктивный дайлер становится эффективным только при больших количествах операторов и звонков, когда статистики достаточно для прогнозирования.
  • Ну, вот и вся лирика. А теперь о том, что работает, а что не очень.

    НЕОБХОДИМЫЙ РЕКВИЗИТ

    Про первые два дайлера писать особенно нечего. Они простые, особенно preview, который к тому же является базовой функцией любого колл-центра, не имеют «обратной связи». Работают и все. Потому все, что будет говориться дальше, касается в основном predictive-дайлера. Кроме того, все это основано на собственном понимании этого неоднозначного термина, субъективном опыте его создания и использования и личных представлениях, что есть жизненно важно, а от чего можно спокойно отказаться.

    Для построения дайлера нужно выполнить несколько условий: для начала иметь API очереди операторов в проекте, обзавестись крепкой коммуникационной платформой, ну и запастись достаточным количеством коммуникационных каналов. Про API очереди: должен быть контроль статусов операторов (занят/свободен) с возможностью определять освобождение оператора не по завершении разговора, а решению оператора (иначе у оператора не будет времени на обработку данных после звонка — Wrap up time или Post Call Processing).

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

    Про каналы: целесообразно использовать VoIP, поскольку увеличивать количество каналов почти мгновенно и почти без вложений можно только так.

    ОСНОВНЫЕ ПОКАЗАТЕЛИ И ИХ РОЛЬ ДЛЯ PD

    Предиктивному дайлеру (PD) для работы требуются несколько ключевых показателей.

    ASR (average seizure ratio) — доля успешных соединений среди всех совершенных попыток. Параметр определяет, сколько звонков одновременно нужно сделать дайлеру, чтобы занять оператора в кратчайший срок. ASR зависит от актуальности базы телефонов, сезона, дня недели, погоды, солнечных бурь и т.д. и т.п. Но в простейшем случае достаточно учитывать ASR за последние 10—20 минут. Этот параметр не должен превышать количество каналов, выделенных на проект.

    Тонкий момент №1. GSM-шлюзы, столь любимые публикой, оказываются непригодными для работы с PD, так как имеют мало каналов при высокой цене, да и содержание в достаточном количестве безлимитных карточек накладно. А если работа не постоянная, то и подавно. Решение: делайте первый звонок через оператора связи и, если пришел Alerting, то завершайте звонок и делайте новый, но уже через шлюз. У абонента даже не зазвенит телефон, хотя номер высветится. Таким образом, и деньги целы и шлюзы полны результативных звонков. Мы назвали это Predial feature. Кстати, этот же подход позволяет получить более точные данные о причине неудачной попытки звонка, поскольку обычно шлюзы скупо или искаженно сообщают ошибки соединения.

    Тонкий момент №2. Запустив предиктивный дайлер на массовый обзвон, а особенно с использованием Predial и тем более с низким ASR-ом, вы наверняка окажетесь отключенными от связи вашим оператором «до выяснения». Такой вал звонков, да еще с низким уровнем дозвона будет замечен и очень быстро. Решение: предупреждайте операторов связи о таких работах заранее.

    Тонкий момент №3. Бывают базы с настолько низким ASR-ом, что никаких каналов не хватит для загрузки операторов. Решение: если это связано с большим количеством «неправильных» номеров, звоните в два приема. Первый — без участия операторов, обрывая звонки после прихода alerting’а. Второй — уже в обычном режиме.

    ACD (Average Call Duration) позволяет рассчитать, когда начинать набор нового номера, если вы хотите начинать его до завершения оператором предыдущего разговора. Использование такого подхода возможно только при наличии годной статистики.

    Тонкий момент. Статистика есть статистика, и когда закончится конкретный разговор, она не знает. Это влечет обрывы звонков, что не всегда приемлемо. Решение №1: используйте этот подход при наличии свободного оператора, на которого можно перенаправить звонок, если предсказание «не сбылось». Решение №2: откажитесь от этого. Те секунды, за которые дайлер совершит звонки после окончания оператором разговора, превращаются в доллары только на очень больших объемах.

    AAD (Average Answer Delay) среднее время, между тем, как абоненту придет звонок, и его ответом на него. Этот параметр нужно учитывать, если вы хотите начинать набор нового номера до завершения оператором предыдущего разговора. Далее см. ACD.

    Количество свободных операторов — полезная величина, вместе с ASR-ом дающая количество каналов, необходимых в каждый момент времени для того, чтобы занять всех операторов в кратчайшие сроки.

    Первая версия предиктивного дайлера была нами создана «по книжкам» для собственных нужд. Этот дайлер учитывал все перечисленные параметры. Затем пришлось добавить и день недели, и время совершения звонка (обед, пробки на дорогах, понедельничные планерки), и темперамент оператора, и что-то там еще. Оказалось, что создать рабочую модель предиктивного дайлера чрезвычайно сложно, но еще сложнее собрать для нее достаточное для работы количество достоверных данных. И это в постоянно меняющихся условиях: сегодня звоним пенсионерам, завтра — пионерам.

    Словом, игры не стоила свечей. Выход был найден до смешного простой, хотя в последствии мы его несколько усложнили.

    КАК PD РАБОТАЕТ У НАС

    Наш предиктивный дайлер работает так: софтсвитч имеет трид, который проверяет наличие очередей PD. Если они есть и активны в этом расписании, то другой трид — очереди — инициирует звонки на операторов. Оператор должен надеть гарнитуру и принять звонок — с этого момента он ждет соединения с клиентом.

    Параллельно трид очереди проверяет батчи очереди (см. ниже) и, если они должны быть активны, то запускает нити батчей. Если есть операторы, каналы и номер, удовлетворяющий расписанию, то нить батча создает отдельную нить звонка, которая пытается позвонить клиенту. Если соединение успешно, то звонок отправляется на оператора. Перед соединением оператора и клиента трид звонка дает звуковой сигнал оператору о том, что клиент «на линии». Если свободные операторы закончились, то трид звонка сообщает всем тридам батча этой очереди, что операторов, готовых принять звонок нет (это функциональность софтсвитча), и они завершают начатые попытки соединения.

    Мы учитываем только ASR и количество свободных операторов и этого хватает, чтобы оперативно занимать освободившихся и не делать «лишних» звонков.

    Мы использовали Predial feature до тех пор, пока не отказались от шлюзов полностью, заменив их включением в операторов связи.

    У нас есть разделение на домашние, мобильные и рабочие номера с отдельным расписанием звонков для каждой группы. Каждая из групп может иметь несколько телефонов.

    Мы создали так называемые батчи — независимые друг от друга списки контактов, которые нужно обзвонить в очереди проекта, таким образом, облегчив разделение контактов по очередности и характеру действий с ними. Батчи имеют настройки количества попыток, таймаута для занятых номеров и номеров без ответа, количество линий для батча, а также Predial feature.

    При работе с PD наши операторы сначала устанавливают звонок с сервером, а затем ждут подключения абонента. Это позволяет исключить завершение звонка абонентом, если оператор недостаточно быстро взял трубку. Asterisk тоже имеет такую функциональность.

    Мы работаем с коммуникационным сервером украинской разработки Лирой (liraart.com). Как это часто бывает, у него имеются трудности с документацией, но зато нет проблем с поддержкой и надежностью. Работает наш PD с нагрузкой более 200 одновременных звонков месяцами без рестартов и падений.

    Вот и все основы.

    • Автонабор (дайлер), статьи со старого сайта, основы

    Эта статья связана с возможностями