Менеджер голосовых задач

Общие принципы

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

• Пока пользователь назначен в задачу, он считается зарезервированным. Время резерва также включает в себя предвызывную и поствызывную обработку.
• При переключении звонка на другого оператора системы резервирование также переходит к нему. Переходит в этом случае и текущая форма сценария диалога.
• При переключении абонента на сценарий IVR резервирование с оператора снимается. Продолжать выполнение задачи начинает сервис IVR, который при необходимости может повторно переключить на того или иного оператора или пользователя, либо самостоятельно определить результат звонка. В нетривиальных входящих кампаниях довольно часто возможны случаи, когда после обработки в задаче фронт-офиса необходимо переключить звонок на другую задачу с другим набором ответственных операторов. Это становится возможным при переключении абонента на сценарий IVR с одновременным выходом из текущей задачи (необходима соответствующая настройка задачи на вкладке «Дополнительно» модуля «Call-центр. Голосовые задачи»).
• В исходящих задачах список абонентов и их номеров обновляется в соответствии с настройками синхронизации, а также каждый раз при завершении цикла прохода по списку, но не чаще чем раз в минуту.
• Обработка каждого звонка по задаче в сценариях всех типов может непосредственно использовать информацию из таблицы абонентов в строке, соответствующей абоненту, звонок которому находится в обработке.
• В качестве таблиц абонентов может быть использована любая таблица БД и даже запрос. Доступ к полям прикрепленной таблицы возможен, если таблица абонентов локальная, либо внешняя с явно указанной базовой таблицей БД. Однако отсутствие базовой таблицы не исключает возможность использования запроса для формирования списка абонентов для совершения исходящих звонков.
• При использовании больших таблиц абонентов, а также в случае работы большого количества задач со средними размерами таблиц, работу с ними во избежание переполнения памяти необходимо производить в режиме прямого доступа к БД. Переключение в этот режим не производится автоматически и является свойством задачи. В этом режиме в памяти сервера не создается кэш-образ таблицы, содержащий коды и номера телефонов, однако при значительной масштабности проекта существенно увеличивается плотность обращений к серверу баз данных. При использовании ограниченных версий MS SQL SERVER (MSDE и Personal edition) это может повлечь переполнение числа доступных пулов подключений и как следствие торможение работы всего комплекса в местах обращения к БД. В этом случае необходимо использовать разграничение доступа к БД; максимальное количество выделяемых подключений настраивается в модуле общих настроек в разделе «Управление сервером».
• Запрос в таблице абонентов может возвращать любые наборы данных, в которых есть идентификатор клиента и по крайней мере одно поле с телефонами. Телефоны могут быть как в разных полях, так и в одном поле через разделители (любые символы, кроме «*#123456789-()»). Телефоны могут содержаться даже в разных записях, имеющих один идентификатор. Поле идентификатора – целочисленное. При внесении через стоп-форму дополнительных номеров абонента, они заносятся через запятую в первое, обозначенное типом «Телефон», поле таблицы. Это возможно в случае, если соответствующее поле имеет достаточно большую емкость символов, а также если указана базовая таблица БД.
• После установки соединения с абонентом обратный дозвон до оператора будет производиться без учета правил переадресации.
• После дозвона до абонента и до поднятия трубки оператором абоненту воспроизводится мелодия ожидания соединения с оператором (общая, либо установленная задаче).
• Оператор, будучи зарезервированным на выполнение звонка по задаче, может снять трубку на телефоне и вместо привычного тона АТС услышит мелодию ожидания соединения с абонентом. При дозвоне до абонента в трубку телефона оператора воспроизводится щелчок и мгновенно следует коммутация. Такую же мелодию ожидания оператор слышит в трубке телефона в любой другой момент, находясь в зарезервированном задачей состоянии.
• При поступлении звонка по входящей задаче и отсутствии свободных операторов может быть задействована очередь ожидания. Первый снявший трубку оператор получит на обработку первый звонок из очереди. Очередь ожидания задачи задействуется только в случае, если разрешено ее использование соответствующей настройкой задачи (вкладка «Дополнительно») и свойством «Очередь» компонента «Вход в задачу» . Если одно из свойств отключено, будет осуществлен возврат в сценарий голосового меню. Вход в задачу осуществляется из сценария IVR и может получить отказ по нескольким веткам, соответствующим разным неподходящим состояниям задачи.
• Входящая задача может в своем распоряжении иметь таблицу абонентов. Это может быть использовано для маршрутизации, VIP-обслуживания, а также для создания анкетных таблиц в соответствии с задачами кампании.
• Время нахождения абонента в очереди может быть ограничено настройками задачи. В этом случае происходит возврат управления в обрабатывающий входящий звонок сценарий IVR по ветке «Время ожидания в очереди истекло».
• При постановке в очередь задачи учитывается текущий приоритет звонка, выставленный в сценарии.
• Использование очереди абонентов в задаче можно отключить. Это будет влиять как на входящие задачи, так и на исходящие задачи с прогрессивным и/или предиктивным набором.
• Личная очередь оператора анализируется не при опускании трубки, а после поствызывной обработки звонка по задаче.
• При отсутствии прикрепленного к задаче сценария диалога, а также в случае, если сценарий не был завершен, по завершении звонка появляется форма запроса успешности звонка (и необходимости перезвонить позднее с указанием времени). Если Вы используете собственные обработчики диалогов, и/или если Вам требуется особое ее поведение – пользуйтесь свойством «отображать стоп-карту» компонента «Стоп», а также служебными переменными сценария. Подробно в разделе «Сценарии диалога. Стоп-форма».
• В случае использования прогрессивного, предиктивного или их совмещенного наборов операторы резервируются в пул без привязки к конкретным абонентам. При уменьшении числа операторов мгновенной реакции не следует, однако эта информация используется при появлении возможности совершить очередной звонок. При выходе последнего оператора все звонки прекращаются, очередь абонентов обрывается, и соответствующая запись заносится в информацию о результате звонка.
• Обзвон с резервированием операторов наиболее лояльный к абонентам, но наименее продуктивный. Прогрессивный набор номеров менее лояльный, но существенно более эффективный, особенно при числе операторов > 2 и числе линий, существенно превышающем число операторов (эффективная зависимость нелинейна). На лояльность прогрессивного набора достаточно сильно влияют параметры задачи. Предиктивный дозвон лоялен только при малой дисперсии длительности разговора, а достаточно эффективен при качественной абонентской базе. Наиболее гибко работает совмещенный прогрессивно-предиктивный механизм на задаче из более двух операторов, однако найти точку оптимальности для параметров, зависящую от числа линий, операторов и качества абонентской базы достаточно трудно.
• Вся информация по звонкам, состояниям операторов и очередей моментально кладется в статистическую пространственную БД Oktell и становится доступна для построителей статистики.
• Состояние перерыва, выставляемое оператором внутри call-центра, позволяет ему вести личные разговоры. По завершении подобных разговоров статус перерыва не пропадает.
• Вход в режим «call-центр» мгновенно вводит оператора в перечень ресурсов и менеджер задач при дальнейшей обработке использует его наравне с другими ресурсами. Выход из режима «call-центр» прерывает текущий разговор оператора, завершает выполнение итерации задачи с занесением соответствующей информации в статистику.

Исходящее оповещение

Исходящее оповещение может производиться несколькими вариантами в соответствиями с настройками задачи. Одновременно менеджер задач производит работу со всеми активными задачами. Рекомендуется оптимально распределять ресурсы в случае, если необходимо производить работу одновременно нескольким задачам. В противном случае возможна ситуация, когда все ресурсы захватываются для работы одной задачей, а все остальные стоят без движения. Это становится возможным, если на задачи назначены одни и те же операторы и линии, а также при относительно большом списке абонентов в доминирующей задаче.

Для решения проблемы распределения общих ресурсов по разным задачам, одновременно производящим работу, пользуйтесь настройкой менеджера задач «Общие настройки. Менеджер задач. Приоритет исходящих задач».

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

Задачи с резервированием оператора и общим списком

К таким задачам относятся задачи «с запросом подтверждения» и «с уведомлением». При благоприятных условиях активируется пул и у оператора появляется запрос подтверждения на дозвон. Существуют две разновидности задач с запросом: с простым запросом и с диалоговым сценарием запроса.

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

· В случае с диалоговым сценарием у оператора по созданному и назначенному супервизором сценарию производится обработка данных, отображение соответствующих форм, веб-узлов, запуск приложений и т.п., результатом которых является принятие решения о согласии в совершении звонка, пропуске или отклонении с переходом к следующему абоненту и новой итерации сценария. В сценарии доступны поля из прикрепленной таблицы абонентов по выбранному задачей абоненту, а также все другие возможности и функции сценариев диалога, описанные в разделе «Call-центр. Сценарии. Сценарии диалога». Для анализа менеджером задач анализируется соответствующая служебная переменная сценария диалога.

В случае отказа от звонка по той или иной причине производится завершение обработки текущего абонента, прерывается резервирование ресурсов и производится повторный анализ ситуации.

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

Задачи с резервированием без запроса не требуют подтверждения начала осуществления звонка оператором, что позволяет сэкономить некоторое время, которое уходит у оператора на предвызывную обработку.

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

ВНИМАНИЕ! В задачах с запросом подтверждения существуют два возможных варианта проведения резервирования линии: до запроса и после получения положительного ответа от оператора. Настройка существует глобально в системе в модуле общих настроек в разделе call-центра, а также дублируется в свойствах задачи для установления индивидуальных параметров.

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

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

Необходимо аккуратно анализировать и применять это свойство.

Задачи с распределенным списком и ручным выбором абонентов

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

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

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

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

Окно запроса, появляющееся у оператора предоставляет информацию о последнем звонке, предлагая осуществить дозвон до следующего абонента или же на один из номеров предыдущего абонента.

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

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

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

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

ВНИМАНИЕ! Стоит помнить, что операция перераспределения при редактировании задачи производит разбиение без учета перемещений, осуществленных супервизором.

ВНИМАНИЕ! В задачах с запросом подтверждения существуют два возможных варианта проведения резервирования линии: до запроса и после получения положительного ответа от оператора. Настройка существует глобально в системе в модуле общих настроек в разделе call-центра, а также дублируется в свойствах задачи для установления индивидуальных параметров.

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

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

Необходимо аккуратно анализировать и применять это свойство.

Задачи с прогрессивным набором

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

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

Прогрессивный дозвон имеет больший смысл, если число линий, выделенных для задачи больше числа операторов, единовременно обрабатывающих задачу. Разумно настроенная прогрессивная схема – крайне эффективный инструмент. В качестве примера можно привести следующий результат в самых крайних условиях: Оповещение одним оператором по двум линиям списка из 10 абонентов, где у каждого абонента от 1 до 5 телефонных номеров и ситуация усугубляется тем, что половина номеров в итоге не отвечает. Для оператора наличие «битых» номеров остается незаметным до самого конца, когда на обеих линиях остаются только абоненты, не имеющие ни одного нормального номера. При увеличении числа линий и числа операторов качество заметно повышается. Более эффективно и менее лояльно прогрессивный дозвон можно настраивать, если число операторов достаточно велико, а время обработки одного звонка достаточно мало.

В схемах, где число линий и операторов, назначенных в задачу, практически одинаково и значительно (20, 30, 40, 50, ...) прогрессивный дозвон экономит время поствызывной обработки и набора номера, производя работу в параллельном режиме, что в некоторых случаях приводит практически к тем же результатам что и в случае с числом линий, превышающим число операторов, а также имеет преимущество, делая невозможным рост очереди абонентов.

ВНИМАНИЕ! Прогрессивный набор при больших объемах таблиц абонентов и использовании большого числа линий и операторов производит серьезную нагрузку на БД. При организации длительных и массовых исходящих кампаний необходимо периодически производить обслуживание баз данных: чистку, переиндексацию, дефрагментацию, сжатие и т.д.

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

ВНИМАНИЕ! Выбор сервера, обслуживающего БД MS SQL Server, необходимо производить в соответствии с предстоящими кампаниями. Большое значение имеет количество и скорость жестких дисков и объем оперативной памяти. Базу рекомендуется разделить по файловым группам, находящимся на разных жестких дисках для ускорения обработки информации. 

ВНИМАНИЕ! При снижении скорости обработки информации в БД пул прогрессивного набора автоматически снижает производительность во избежание некорректных ситуаций, а также уведомляет администраторов и супервизоров задачи о необходимости принятия мер. По достижении порогового значения в скорости обработки пул производит автоматический перевод задачи в неактивное состояние.

Задачи с прогрессивным набором очень эффективное средство, дающее наибольшую производительность при рационально назначенных количественных и ресурсных свойствах. Занятость операторов в зависимости от длительности разговора, соотношения операторы / линии и качества телефонной базы может достигать 90% и более.

Задачи с предиктивным набором

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

ВНИМАНИЕ! При использовании в задаче большого числа операторов предиктивный набор теряет смысл и в чистом виде существенно уступает прогрессивному.

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