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

Я решил написать статью на Хабр для обмена опытом обработки call-листов с использованием SQL и получения обратной связи от читателей с критикой и рекомендациям по усовершенствованию моих алгоритмов.

Предыстория

В 2021 году по статистике для имеющихся у нас среднего размера баз данных с телефонами для проведения различных рекламных и иных обзвонов начался существенный дрейф в сторону ухудшения контактности. При дозвоне увеличилась доля телефонов с автоответчиками, голосовой почтой, голосовым меню и различными роботизированными сообщениями от телефонных операторов, которые недостаточно хорошо блокировались автоматическим анализатором ответов и непроизводительно загружали операторов Call-центра. Многочисленные попытки квалифицированных пользователей системы и привлеченных специалистов адаптироваться к новой обстановке в рамках ПО предыдущего поколения не увенчались существенным успехом.

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

Такое положение дел в конечном итоге и стимулировало к переходу на другое ПО последнего поколения. После начала работы на новом ПО конечным управляющим пользователям системы (супервизорам в терминах ПО), проверяющим параметры списков обзвона, загружающим их в аппаратно-программную систему и контролирующим скорость и качество прозвона контактных листов стали доступны новые возможности по фильтрации, сортировке и динамическому (в реальном времени) формированию списков телефонов непосредственно во время работы системы по уже загруженным и прозваниваемым спискам телефонов с помощью SQL запросов.

Замечу, что по стандартной схеме распределения привилегий у супервизоров (это конечные пользователи системы, а не системные администраторы) существенно ограниченны права по стандартной манипуляции Call-листами через меню ПО. А вот через SQL, при сохранении должной безопасности в режиме "Экcперт", появились интересные возможности.

Проблемы обработки call-листов без применения сортировки и фильтрации телефонных списков

Предположим, в распоряжении некоторой фирмы имеется список телефонов с атрибутами объемом в 1 миллион записей или строк. Предположим, что Сall-центр этой фирмы способен прозванивать 100 тысяч телефонов за 1 рабочую смену. Если не применять никаких сортировок к исходному листу, то каждый день будут прозваниваться одни и те же телефоны примерно в одно и тоже время. Получится, что 900 тысяч телефонов никогда не будут прозвонены.

Очевидно, что это плохо с точки зрения бизнеса, так как списки телефонов имеют значительную стоимость и если делать, как в выше приведенном примере, деньги, уплаченные за 900 тысяч номеров телефонов в базе, не смогут окупиться.

Как из интуитивных представлений, так и из общих положений теории вероятности и психологии получается, что тактика прозвона одних и тех же телефонов примерно в одно и тоже время - одна из самых неудачных, как и тактика звонков на рабочие стационарные телефоны в нерабочее время и в обеденные перерывы. Неудачны и звонки слишком рано и слишком поздно на домашние и/или стационарные телефоны.

В настоящее время считается, что тактика с различными случайными и алгоритмическими перемешиваниями времени звонков с учетом локального поясного времени дает большую эффективность. Таким образом, целью использования сортировок и фильтраций call-листов является повышение эффективности работы Call-центров.

Подготовка call-листа для обработки фильтрами

Пригодный для обработки встроенным SQL call-лист должен представлять из себя массив строк (raw). Часто в строке имеются стандартные поля, например, такие: номер строки, номер телефона, идентификатор владельца телефона, может быть и его ФИО, район проживания и/или часовой в месте проживания, дата последнего звонка, результат звонка, общее число звонков объекту и т.д. При обработке в ПО некоторые поля в строках call-листов могут меняться системой автоматически в реальном времени в зависимости от результатов попытки дозвониться до объекта. Стандартно, это - количество попыток дозвона, время дозвона, результат соединения, иногда известны некоторые атрибуты телефона (мобильный, стационарный, рабочий, домашний) и другие.

Улучшение эффективность прозвона с помощью фильтрации и сортировки

На вход фильтра (Dialing filter) подается исходный call-лист. ПО набирает номера по списку строк на выходе фильтра. С помощью простого фильтра, например, можно сделать так, чтобы по одному телефону звонили только один раз. Для этого в фильтре выбираем Число_попыток = 0. Сразу после попытки дозвона это число (значение в соответствующем поле строки call-листа) увеличится на единицу, перестанет удовлетворять условию фильтра, пропадет из списка на выходе фильтра и больше звонков на этот номер не будет. Однако в исходном (до фильтра) call-листе измененное поле сохранится и будет доступно из других фильтров и в случае отключения этого фильтра.

На мой взгляд, с помощью стандартного фильтра затруднительно, например, не звонить по рабочим телефонам в обеденный перерыв с учетом часового пояса (т.е. по локальному или местному времени, не по московскому времени).

CAST(Datediff(s,'1970-01-01',DateAdd(hh,(tz_dbid-135),GETDATE())) AS BIGINT) < CAST(Datediff(s, '1970-01-01', DATETIMEFROMPARTS(year(GETDATE()),month(GETDATE()),day(GETDATE()),19,0,0,0)) AS BIGINT)INT)

Данный пример кода упрощенный, и правило "не звонить после определенного локального времени" возможно реализовать и без использования SQL, на настройках через меню ПО. Но вот множественные интервалы тишины мне удалось наиболее просто реализовать без администраторских прав в системе через SQL в экспертном режиме.

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

Смысл такой сортировки в том, чтобы при прозвоне большого call-листа в рабочую смену Call-центра прозванивались попеременно и самые, например, новые объекты и самые старые или с самым высоким рейтингом попеременно с самым низким рейтингом.

Дело в том, что длительный непрерывный прозвон только "плохих" или с низким рейтингом телефонов быстро и сильно утомляет операторов Call-центра (снижает производительность труда) ввиду большого процента неконструктивных диалогов с объектами с низким рейтингом. Полностью отказаться от прозвона объектов с низкой вероятностью достижения положительного результата иногда бывает экономически невыгодно. В примере кода ниже применяется активное использование замечательных возможностей SQL, таких как конструкции case when .. then .. else .. end, оконные функции row_number(), count() over( partition .. order by ..)

    case when 
       row_number() OVER(partition by Некоторое_поле ORDER BY Рейтинг DESC) > (0.5*count(*) OVER(partition by Некоторое_поле ) ) and (row_number() OVER(partition by Некоторое_поле ORDER BY Рейтинг DESC)) < (count(*) OVER(partition by Некоторое_поле ))+1 then (count(*) OVER(partition by Некоторое_поле )) - (row_number() OVER(partition by Некоторое_поле ORDER BY Рейтинг DESC)) + 0.5 else (row_number() OVER(partition by Некоторое_поле ORDER BY Рейтинг  DESC))SC))
     end

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

Результат применения фильтра из примера выше (таблица приведена в качестве дополнительного пояснения и на практике выглядит по-другому и немного сложнее)

Выводы

Примеры кода в этой статье на встроенном в ПО SQL работают в реальном времени, удовлетворительно решают проблему повышения эффективности прозвона call-листов и не требуют прав администратора в системе.

В настоящее время продолжаем изучать открывшиеся возможности экспертного режима ("Expert mode") SQL фильтрации и сортировки call-листов в реальном времени в обновленном ПО.