Соединение с внешними КЦ и перелив вызовов

На сервере 172.16.90.26 настроен интерфейс 95.161.236.158/30. Через этот интерфейс сервер взаимодействует с четырьмя АКЦ: Gran, Newcontact, Astrapage, Komus.

Для них настроена отдельная маршрутизация в файле /etc/sysconfig/network-scripts/route-eth1.

В IVR используется функция, которая читает callparam outsource_call_center и выбирает из него номер для перенаправления вызова. Назначение callparam настраивается в интерфейсе PMS в разрезе проекта (в блоке «настройки проекта»). Строка в callparam должна иметь формат <номер телефона>: <процент перенаправляемых вызовов>[; <номер телефона>: <процент>[; <номер телефона>]], например: 8110001:33; 6965001:17; 6960001.

Такая запись означает, что 33% вызовов будут перенаправляться на номер 8110001, 17% на номер 6965001, а все остальные на номер 6960001.

 

Рис 5. Схема взаимодействия IVR NCC с АКЦ и проектами NCC

 

IVR-скрипт отправляет в сокет UDP на порт 3929 строку вида corebolg80bho0000kj2d3iuv188rijk|8110001:33; 6965001:17; 6960001. В ответ из сокета читает номер телефона, на который нужно перенаправить вызов. На порту 3929 находится сервис calldistributor, который занимается сбором статистики по «переливам» и вычислением, на какой номер телефона передать следующий вызов.

calldistributor - приложение, написанное на C++ с использованием boost, статически слинкованное. Конфигурации не требует, зависимостей не имеет. Запускаться может с ключом -p (порт UDP). Его запуском занимается naucore.

Если в UDP-сокет на порт 3929 отправить строку “dump”, то в ответ calldistributor вышлет текущую статистику по распределению вызовов.

Функция IVR getTransferNumber описана в /opt/naumen/nauphone/spool/naubuddy/ivr/client/custom_sm3/base.py.

Для таких “переливов” настроены правила маршрутизации (рис.6).

Рис 6. Правила маршрутизации

Вызовы в АКЦ "Newcontact"
Вызовы в АКЦ "Gran"
Вызовы в АКЦ "Astrapage"
Вызовы в АКЦ "Komus-contact"

 

Для контроля сделан “Отчёт по переливам”.

 

Smart Routing

Звонки клиентов, обращающихся в КЦ повторно, маршрутизируются исходя из категории их предыдущих обращений. Категория обращения выбирается оператором на форме анкеты в флекс атрибуте с кодом «cdisp» типа «Элемент справочника». Обычно используется глобальный справочник «Call Disposition», но возможно использование и других справочников.

Система анализирует последние x категорий обращения (по коду элемента справочника) для определившегося автоматически номера телефона и в случае совпадения y из x кодов завершения, маршрутизирует звонок в соответствии с таблицей маршрутизации.

Таблица 2. Таблица маршрутизации

Условие (код завершения)	Маршрутизация	DNIS
Order	Проект 01_Заказ	6434
Order:msk	Проект 01_Заказ_МСК	4511
Order:spb	IVR_SPB_Zakaz	6460
Consultation	..	..
Consultation:msk	..	..
Consultation:spb	..	..

 

Таблица маршрутизации настраивается в справочнике «Интеллектуальная маршрутизация». Код элемента соответствует коду категории обращения. Допускается указывать коды в формате <код категории>:<citycall>. Название элемента – либо DNIS, либо uuid очереди. В случае DNIS будет совершено перенаправление на указанный номер, в случае uuid очереди – разблокировка вызова в соответствующей очереди (через CHANGECALLPROJECT).

Существует возможность изменения значений размера выборки x и значения совпадений y в конфигурационном файле сервиса Enquiry Data Store (EDS).

*ограничение: значения x и y одинаковы для всех пар «код завершения» - «маршрутизация».

В IVR в умной маршрутизации участвуют блоки Magic Routing и Smart Routing. Блоки бывают двух типов: простые и комплексные. Простые не содержат внутри других блоков, выполняют код на языке Python. Комплексные блоки, к которым относятся Magic Routing и Smart Routing, содержат внутри другие блоки, как простые, так и комплексные.

Блок Magic Routing в качестве параметра принимает номер звонящего (CALLER_ID) и таймаут выполнения HTTP-запроса (TIMEOUT). Выполняет запрос GET /magic_routing к сервису EDS, адрес сервиса блок получает из параметра IVR-скрипта eds_url (/opt/naumen/nauphone/spool/naubuddy/ivr/client/custom_sm3/params.xml). В качестве параметра citycall в GET-запрос подставляется параметр вызова citycall, который установлен на момент выполнения блока. Атрибут data из ответа сервиса сохраняется в self.magic_routing.

Блок Smart Routing проверяет параметр вызова smart_routing: если параметр уже установлен, для предотвращения повторного срабатывания срабатывает выход FAIL, при этом параметру присваивается значение loop. Далее анализируется атрибут smart_routing.projectid в JSON, сохраненном в self.magic_routing: если он отсутствует или пуст, срабатывает выход FAIL, параметру smart_routing присваивается значение false, иначе ему присваивается значение true; если smart_routing.projectid содержит uuid проекта (проверяется по наличию префикса corebo), выполняется команда CHANGECALLPROJECT, срабатывает выход QUEUE; иначе совершается попытка трансфера на номер, полученный в параметре smart_routing.projectid, если попытка трансфера не успешна, срабатывает выход FAIL.

В IVR существуют блоки, которые обращаются к спискам VIP, VIP2, SList, EList, BlackList для того, чтобы звонок мог правильно маршрутизироваться. Списки VIP, VIP2, SList, EList – включают в себя вип – клиентов, BlackList – чёрный список. Данные списки обновляются вручную через полное удаление клиент – каталога и загрузки нового файла в формате .xls или .xslx с обновлёнными данными. Номер телефона должен быть в следующем формате – 11 цифр, начинающихся с восьмёрки.

 

3. Описание настройки проектов

Общее описание

В Системе присутствуют проекты следующих типов: входящие, исходящие, автоинформаторы, по обработке Webchat, E - mail обращений и SMS – обращений (таблица 3).

Обращения по Webchat поступают с двух сайтов: http://new.beta.kluatr.ru/ (бета - версия) и http://petrovich.ru/. Сообщения, поступающие с бета – сайта приходят в Naumen Contact Center через шлюз [email protected]. Сообщения, поступающие с главного сайта, приходят в мобильное приложение Webim.

Для проекта по обработке входящих SMS – сообщений в Системе используется шлюз smpp.smsc.ru, для отправки SMS с формы анкеты используется шлюз smpp.qtelecom.ru.

Все SMS – сообщения поступают в формате 7-ххх-ххх-хх-хх (ограничение SMS провайдера). Для автоматического определения клиента по номеру телефона реализована функция, которая заменяет 7 на 8, и клиент определяется автоматически (так как формат номера клиентов в клиент – каталоге 8-ххх-ххх-хх-хх). Эта функция находится в скрипте petrovich.js, который располагается в /opt/naumen/naucrm/server/webapps/UserFiles/js:

self.data.caller =phoneControllerService.caller;

if (self.data.caller.match(/^(7|\+7)?[0-9]{10}$/g)) self.data.caller =

('8' + self.data.caller.slice(-10))

Таблица 3. Типы проектов

	Голосовой	Автоинформатор	E-mail	Web - chat	SMS
Входящий	✔	✔	✔	✔	✔
Исходящий	✔

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

Таблица 4. Основной функционал анкет

	Описание функциональности	Какими средствами достигается
1.	Автоматическое определение клиента по номеру телефона, изменение контактных данных, поиск по клиент-каталогу, а также возможность создания нового клиента. Идентификатором клиента является его мобильный телефон	Стандартный виджет анкеты «Информация о клиенте»
2.	Возможность отправки E – mail и SMS с формы анкеты	Стандартный виджет анкеты «Отправить SMS» и «Отправить письмо»
3.	Просмотр истории обращений по всем каналам связи	Стандартный виджет анкеты «История контактов»
4.	Отображение истории заказов из 1С	Интеграционная прослойка между 1С и бизнес – системой (п. 3.2.3)
5.	Выбор контрагента по клиенту	Интеграционная прослойка между 1С и бизнес – системой (п. 3.2.3)
6.	Открытие 1С для создания заказа посредством нажатия кнопки на форме анкеты	Функция для создания предзаполненного заказа в 1С (п. 3.3)
7.	Автоматическое определение города клиента	Правила маршрутизации, описанными в п. 1.2 (таблица 4)
8.	Указание категории обращения с последующей интеллектуальной маршрутизацией по коду завершения вызова	Флекс - атрибут анкеты «Категория обращения» (п. 2.3)
9.	Передача комментария из АКЦ, если звонок перевели из АКЦ	Флекс – атрибут «Комментарий из АКЦ» (п. 3.2.2)
10.	Передача комментария при перенаправлении вызова другому оператору	Флекс – атрибут «Комментарий к звонку» с одинаковым идентификатором call_comment
11.	Возможность оставить комментарий к клиенту для последующего его отображения в контактных данных	Стандартная настройка классов объектов по объекту «клиент – физическое лицо» путём добавления нового пользовательского атрибута «Комментарий»

 

Одновременно оператор может обрабатывать один звонок, одно e-mail обращение, одно sms-обращение и несколько Webchat сессий (количество сессий гибко настраивается).

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

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

⇐ Предыдущая123456Следующая ⇒

Поделиться: