Просмотр исходного текста страницы Менеджер голосовых задач

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



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

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



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

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

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



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



К таким задачам относятся задачи «с запросом подтверждения» и «с уведомлением». При благоприятных условиях активируется пул и у оператора появляется запрос подтверждения на дозвон. Существуют две разновидности задач с запросом: с простым запросом и с диалоговым сценарием запроса. 
* В случае простого запроса у оператора после его резервирования в задачу появляется форма с информацией об абоненте (все поля из списка, отмеченные при настройке как информационные), и возможностью подтвердить согласие оператора на осуществление звонка,  пропустить обработку (выставляется пауза для абонента и происходит переход к следующему) или отклонить абонента от дальнейшей обработки в задаче.  
* В случае с диалоговым сценарием у оператора по созданному и назначенному супервизором сценарию производится обработка данных, отображение соответствующих форм, веб-узлов, запуск приложений и т.п., результатом которых является принятие решения о согласии в совершении звонка, пропуске или отклонении с переходом к следующему абоненту и новой итерации сценария. В сценарии доступны поля из прикрепленной таблицы абонентов по выбранному задачей абоненту, а также все другие возможности и функции сценариев диалога, описанные в разделе [[Сценарии диалога|Call-центр. Сценарии. Сценарии диалога]]. Для анализа менеджером задач анализируется соответствующая служебная переменная сценария диалога. 

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

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

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

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

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

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

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

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



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



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

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

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

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

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


[[Файл:Extra_form_accept.png|center]]


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

[[Файл:Extra_form_choice2.png|center]]


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

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

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

<span style="color:red;">ВНИМАНИЕ! Стоит помнить, что операция перераспределения при редактировании задачи производит разбиение без учета перемещений, осуществленных супервизором. 

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

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

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

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



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



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

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

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

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

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

<span style="color:red;">При высокой приоритетности непосредственно процесса исходящего оповещения по сравнению с получаемой многоуровневой статистикой рекомендуется настраивать процесс таким образом, чтобы необходимая статистика формировалась по мере выполнения задачи, а неактуальные данные (например старше 1 дня, 1 недели, 1 месяца в зависимости от конкретной ситуации) в нерабочее время удалялись или переносились из основной базы данных во вспомогательные.

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

<span style="color:red;">ВНИМАНИЕ! При снижении скорости обработки информации в БД пул прогрессивного набора автоматически снижает производительность во избежание некорректных ситуаций, а также уведомляет администраторов и супервизоров задачи о необходимости принятия мер. По достижении порогового значения в скорости обработки пул производит автоматический перевод задачи в неактивное состояние.</span>

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