Материал: Организация локальной сети для call-центра

Для второго звонка соединение устанавливается со вторым IP-телефоном 1112. А когда поступает третий звонок, то телефонная станция, «обнаружив», что оба IP-телефона, записанные в таблице маршрутизации, уже заняты, дает команду голосовому шлюзу (GW) отбить звонок.

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

непрогнозируемые и неконтролируемые потери звонков;

отсутствие CTI-интеграции;

неконтролируемая работа операторов: чтобы не принимать звонки, оператор может просто положить трубку на стол;

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

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

Теперь рассмотрим второй вариант, когда в контакт центре используется оборудование Cisco IPCC для приема телефонных звонков. Будем рассматривать все те же три одновременных звонка, но теперь на схеме добавлены элементы, относящиеся к оборудованию Cisco IPCC (выделены фоном): ICM, IVR, CTI, DBReport.

Обратите внимание, что в таблице маршрутизации для многоканального номера теперь указан «номер» ICM - подсистемы интеллектуальной маршрутизации вызова. При поступлении первого звонка из ТфОП на номер 961-14-10 голосовой шлюз (GW) по протоколу сигнализации запрашивает у телефонной станции (IP PBX): «Что делать со звонком?» IP PBX, в свою очередь, запрашивает у ICM: «Что делать со звонком?» ICM запускает сценарий маршрутизации звонка, который в соответствии с алгоритмом выбирает свободного оператора, и выполняет два действия: сообщает IP PBX номер IP-телефона оператора и параллельно сообщает CTI имя оператора, на которого будет переключен вызов. IP PBX, получив от ICM номер IP-телефона, переключает на него вызов (аналогично тому, как это делается в первом варианте). А CTI, получив информацию от

Рисунок 13 - Схема прохождения вызова

ICM об имени оператора, запускает на экране монитора оператора механизм CTI-интеграции и обеспечивает всплытие окна CRM-системы.

Второй вызов по той же самой схеме переключается на оператора 1112 (Рисунок 13), у которого также всплывает окно CRM-системы. При поступлении третьего вызова в силу того, что свободных операторов нет, в соответствии со сценарием маршрутизации вызова ICM возвращает IP PBX не номер IP-телефона оператора, а номер подсистемы IVR. Получив команду, IP PBX переключает вызов на IVR (в очередь), где запускается IVR-приложение - музыкальный автоинформатор или интерактивное голосовое меню. Как только появляется свободный оператор, ICM дает команду IP PBX о переключении вызова с IVR (из очереди) на IP-телефон освободившегося оператора и параллельно передает CTI имя оператора. Далее все происходит аналогично тому, как описано для первого и второго вызова.

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

На схеме это не обозначено явно, но, если это необходимо и предусмотрено бизнес-требованиями, то ICM при принятии решения о маршрутизации вызова также обращается к CRM-системе для получения дополнительной информации о звонящем клиенте. Полученные данные непосредственно влияют на принятие решения о дальнейшей маршрутизации вызова. Аналогично и при нахождении вызова на IVR (например, в очереди) алгоритм IVR-приложения может предусматривать запрос в базу данных компании, например, для проверки пароля клиента или получения информации о балансе его счета. Данные, введенные клиентом на IVR, становятся CTI-данными контакт центра и, соответственно, доступны на рабочем месте оператора и могут быть использованы во всплывающей CRM-форме.

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

Важным отличием от первого рассмотренного варианта является то, что маршрутизация звонка в этом варианте происходит не на основе записей таблицы маршрутизации IP PBX, а в результате выполнения сценария маршрутизации вызова на ICM. Вторым отличием является то, что в случае отсутствия свободного оператора вызов не теряется, а ставится в очередь. ICM продолжает следить за вызовом в очереди и контролирует, чтобы при освобождении оператора на него сразу же был переведен вызов из очереди. Третьей особенностью является то, что параллельно с поступлением звонка на рабочем месте оператора всплывает окно CRM-системы. И последнее - очень важное - собирается полная статистика обслуживания вызовов, что позволяет менеджменту контакт центра точно знать, как обслуживаются вызовы: сколько вызовов обслужено, как они обслужены, сколько потеряно и по какой причине, чем были заняты операторы в течение рабочего дня.

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

Рисунок 14 - Схема прохождения вызова

Каждый поступивший интернет-вызов независимо от его вида (e-mail, chat, Web и т. д.) маршрутизируется в сценарии ICM и дальше переводится на оператора (Рисунок 14). На экране компьютера оператора используется окно, соответствующее виду поступившего вызова. Окно содержит весь необходимый инструментарий и всю необходимую информацию для того, чтобы оператор мог обслужить вызов. Параллельно с маршрутизацией ICM сохраняет статистику обо всех поступивших и обслуженных интернет-вызовах. Если при поступлении вызова типа сhat или Web нет свободного оператора, ICM, аналогично телефонному вызову, ставит интернет-вызов в очередь - на экран «звонящего» выводится html-страничка, сообщающая о том, что вызов находится в очереди. Перевод вызова из очереди на свободного оператора происходит аналогично тому, как это было описано для голосового вызова, за исключением того, что не используется IVR.

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

ЗАКЛЮЧЕНИЕ

Основные результаты дипломной работы состоят в следующем:

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

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