Тех. задание Call Центра - Азиатско

реклама
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по теме:
Разработка и внедрение Центра обработки вызовов
Благовещенск 2010
1
ОБЩИЕ СВЕДЕНИЯ
Полное наименование системы и ее условное обозначение
Центр обработки вызовов ОАО «Азиатско–Тихоокеанский Банк»
Реквизиты заказчика
Заказчик работ: ОАО «Азиатско–Тихоокеанский Банк».
Адрес: 675000, Россия, Амурская область, г. Благовещенск, ул. Амурская, 225
Назначение системы
Система предназначена для организации централизованного приема, регистрации и
обработки входящих вызовов первой линией поддержки пользователей.
Основание для проведения работ
Работа выполняется в рамках мероприятий по внедрению, технической и информационной
поддержке информационной системы.
Плановые сроки начала и окончания работ
Начало работ - с момента подписания контракта.
Окончание работ – в течение пятидесяти двух (52) рабочих дней с момента подписания
контракта.
Финансирование
Создание системы финансируется из средств бюджета Банка. Условия финансирования
определяются контрактом, заключаемым между Заказчиком и Поставщиком.
Порядок оформления и предъявления заказчику результатов работ
Результатами работ являются:
1. Обследование объекта автоматизации.
2. Разработка технического проекта системы.
3. Поставка оборудования по оснащению центра обработки вызовов в соответствии с настоящим
техническим заданием.
4. Работы по реализации центра обработки вызовов в соответствии с настоящим техническим
заданием и разработанным техническим проектом.
5. Комплект исполнительной и проектной документации на реализованное решение.
2
Требования к выполняемым работам
Общие требования к системе
Разрабатываемая система должна удовлетворять следующим основным требованиям:
 объединять информационные и вычислительные ресурсы, телекоммуникационные услуги,
прикладные, системные и интеллектуальные сервисы в единую автоматизированную систему;
 обеспечивать доступ пользователей к ресурсам центра обработки вызовов системы ОАО
«АЗИАТСКО–ТИХООКЕАНСКИЙ БАНК»;
 обеспечивать взаимодействие пользователей и информационных систем с ресурсами с
внутренних структурных подразделений Банка и сетями связи общего пользования (ССоП);
 обеспечивать приемлемый уровень отказоустойчивости и доступности сервиса на уровне всей
системы;
 дифференцировать сервис в системе в соответствии со стратегическими задачами системы;
 обеспечивать поддержку систем централизованного управления, анализа и контроля;
 обеспечивать функциональную совместимость всех элементов;
 обеспечивать интеграцию с уже использующимся оборудованием и технологиями.
Функциональные требования к системе
ЦОВ ОАО «АЗИАТСКО–ТИХООКЕАНСКИЙ БАНК» предназначен:
 Для регистрации заявок и распределения вызовов в рамках существующих групп компетенций;
 Для контроля над исполнением потока входящих заявок.
 Для автоматизации компаний исходящего обзвона.
 Для обработки вызовов электронной почты (Email).
 Для обработки вызовов с сайта Банка (Web-Chat).
 Для обработки факсимильных сообщений (Fax).
 Для организации голосовых меню самообслуживания (Self Service IVR).
В обработке потока заявок пользователей на первом этапе задействована группа
сотрудников Банка:
 Операторы центра обработки вызовов;
Единой точкой контакта в системе являются операторы ЦОВ осуществляющие первичную
регистрацию
и
обслуживание,
при
необходимости
перенаправление
вызова
на
специализированные группы сотрудников Банка. Контроль над исполнением заявок осуществляют
руководители
специализированных
групп
компетенций. Для специализированных групп
3
реализовать точки контакта с возможностью выбора персональных компетенций сотрудника.
Произвести телефонизацию групп пользователей и произвести интеграцию системы с телефонной
сетью общего пользования.
Требования к выполнению работ
К выполнению работ допускаются организации и специалисты, сертифицированные
компаниями производителями поставляемого программного и аппаратного обеспечения, и
специалисты компаний производителей.
Требования к составу работ
В рамках работ по разработке и внедрению системы Исполнитель должен выполнить
следующий состав работ:
 Произвести необходимые работы по монтажу системы в существующих шкафах заказчика и
коммутацию пассивной инфраструктуры к портам активного оборудования.
 Произвести установку программного обеспечения подсистем управления вызовами и
интеллектуальных сервисов на аппаратное обеспечение системы.
 Произвести разработку внутреннего номерного плана системы на основе четырехзначной
нумерации.
 Произвести интеграцию системы с телефонной сетью общего пользования с выходом в
городскую, междугороднюю и международную телефонную сеть к системам стационарной и
подвижной связи.
 Произвести разграничение внутренних абонентов системы на функциональные группы с
разграничением доступа к услугам сети (внутренние абоненты, экстренные службы,
информационные сервиса, мобильные, городские, междугородние и международные).
 Произвести разработку скрипов в подсистеме интеллектуальных сервисов в соответствии с
функциональными требованиями к системе и алгоритмом Заказчика.
 Произвести привязку внутренних номеров к абонентским терминалам.
 Произвести трансляцию внешних вызовов на внутренние телефонные номера.
 Произвести настройку и конфигурацию агентских мест пользователей для работы в ЦОВ.
 Произвести настройку активного сетевого оборудования системы в соответствии с
рекомендациями лучшей практики производителя оборудования.
 Произвести интеграцию системы с корпоративной сетью Заказчика.
 Осуществить настройку записи разговоров всех агентов, подключённых к Системе.
 Произвести разработку продуктивного адресного плана системы.

При использовании ip-телефонов, произвести разработку плана деления на виртуальные сети
4
в системе. При проектировании обеспечить выделение в отдельные виртуальные сети
следующий набор сетей: сеть агентских мест пользователей, сеть ip-телефонов, сеть для
размещения систем управления ip-телефонии, сеть для размещения неиспользуемых портов в
системе.
 Произвести коммутацию рабочих мест пользователей к портам коммутаторов.
 Включить поддержку базовой безопасности на портах коммутатора.
Требования к исполнительной документации на систему
Проектная и исполнительная документация на систему должна содержать следующие
необходимые разделы:
-
Технический проект
 Пояснительную записку.
 Основной комплект чертежей.
 Спецификацию оборудования и материалов.
Пояснительная записка должна содержать основные организационно-технические решения
проекта, включающие решение следующих подзадач:
 описание архитектуры системы;
 описание соглашения по наименованию оборудования;
 описание решения по размещению системы;
 определять требования к электропитанию, размещению оборудования и точкам подключения
оборудования к существующей сети.
Основной комплект чертежей должен отражать графическую информацию, отражающую
все основные организационно-технические решения проекта. Комплект чертежей должен
включать следующий набор листов:
 структурную схему;
 схему электрических соединений;
 логическую схему;
 номерной план;
 обобщенную схему обработки входящих вызовов;
 обобщенную схему обработки исходящих вызовов;
 схему размещения оборудования в шкафах.
Требования к оборудованию
Все товары и комплектующие должны быть новыми – не бывшими в употреблении.
Все товары должны соответствовать или превышать требования технического задания.
5
Все предлагаемые товары должны функционировать при следующих условиях:
 параметры электропитания (220В +/- 20В, 50 Гц +/- 1 Гц);
 возможны резкие скачки напряжения;
 температура окружающей среды: от + 10C до +35C;
 относительная влажность от 10% до 80%.
Требования к совместимости
Все общесистемное программное обеспечение, поставляемое в комплекте с оборудованием,
должно быть совместимым с аппаратным обеспечением.
Требования к документации
Каждая единица программного и аппаратного обеспечения должна поставляться с
комплектом технической документации.
Требования к оборудованию сопряжения с сетью связи общего
пользования
Оборудование модуля сопряжения с ТфОП должно удовлетворять следующим
требованиям:
 Устройства должны поддерживать одновременную обработку, как голосового трафика, так и
трафика данных;
 Устройство должно поддерживать алгоритмы ITU G.711u, G.711a, G.723, G.726, G.728, GSM
EFR, GSM FR, G.729a, G.729b, G.729ab (c подавлением пауз и генерацией комфортного шума);
 Устройство
должно
поддерживать
возможность
транскодинга
голосового
трафика,
использующего кодек G.711, в голосовой трафик, использующий следующие кодеки: GSM
EFR, GSM FR, G.729a, G.729b, G.729ab;
 Устройство должно поддерживать возможность организации аудиоконференций между
участниками, использующими следующие кодеки: G.711u, G.711a, GSM EFR, GSM FR, G.729a,
G.729b, G.729ab;
 Устройство должно поддерживать возможность использования следующих аналоговых и
цифровых интерфейсов взаимодействия с традиционными телефонными сетями общего
пользования и офисными телефонными станциями: FXS, FXO, E&M, DID, ISDN BRI, E1MELCAS, E1-R2, E1 ISDN PRI. Аналоговые и цифровые порты должны поддерживаться на
устройстве одновременно;
 Устройство должно обеспечивать подключение к ТфОП при помощи стыка цифровых линий
связи E1 (ISDN PRI);
 Устройство должно поддерживать следующие стеки сигнальных протоколов: SIP, H.323,
MGCP;
6
 Устройство должно предоставлять информацию в реальном времени об установленных
голосовых вызовах;
 Устройство должно поддерживать MIB, с использованием которого можно было бы получать
статистику по работе голосовых портов по протоколу SNMP.
Оборудование
должно
иметь
модульную
конструкцию.
Оборудование
должно
поддерживать не менее 3 одновременно подключаемых голосовых потоков ISDN E1.
Требование к подсистеме управления вызовами
Подсистема управления вызовами должна поддерживать одновременную регистрацию 1000
абонентских устройств. Решение должно быть масштабируемым с возможностью объединения в
кластер.
Подсистема управления должна обеспечивать ведение базы данных для хранения
номерного плана, правил трансляции номеров, конфигурационной информации компонент
телефонной системы, включая телефонные номера, названия устройств, информацию о
дополнительных видах обслуживания вызовов, библиотеки программного обеспечения телефонов.
Подсистема управления должна предоставлять возможность дистанционной настройки и
мониторинга.
Подсистема
управления
должна
обладать
следующими
функциями
настройки
и
мониторинга:
Доступ к административному интерфейсу должен осуществляться через WEB посредством
протокола HTTPS. Должны поддерживаться следующие HTTP-клиенты: Microsoft Internet Explorer
версии 5 или 6; Netscape Communicator 4.X;
Должен обеспечиваться контролируемый доступ к административному интерфейсу
управления. Для идентификации пользователей сервер управления должен использовать службу
каталогов, обращение к которой осуществляется посредством протокола LDAP. Сервер
управления должен обеспечивать формирование групп пользователей и присвоение этим группам
разных уровней доступа к ресурсам системы. Как минимум, должны быть предусмотрены виды
доступа «только чтение», «доступ запрещён», «полный доступ на чтение и запись». Должно
контролироваться обращение к следующим ресурсам: настройкам телефонных аппаратов;
настройкам плана нумерации; общесистемным настройкам сервера управления; настройкам
голосовых шлюзов. Действия пользователей, совершаемые при доступе к ресурсам, должны
протоколироваться в файле журнала.
Сервер управления должен поддерживать развитые средства отладки, включающие
возможность отладки стыковки с внешними системами посредством шлюзов, контролируемых
сервером управления, должно обеспечиваться полное сохранение информационного обмена в
сигнальном канале при использовании протоколов Q.931 или Q.SIG. Сервер управления должен
7
содержать встроенное средство мониторинга в реальном времени. Должен поддерживаться
мониторинг числа активных соединений, числа зарегистрированных устройств. Доступ к средству
мониторинга
должен
осуществляться
через
WEB-интерфейс
(используется
специальное
программное обеспечение, входящее в комплект поставки).
Сервер управления должен сохранять информацию об установленных соединениях.
Должно поддерживаться сохранение информации в реляционной базе данных или в текстовом
файле. В дополнение к информации о времени вызова, абонентах, виде соединения, времени
разговора и причине завершения, должна сохраняться информация о качестве телефонного
разговора, получаемая с телефонных аппаратов системы, сразу после завершения вызова. Сервер
управления должен содержать встроенное средство анализа информации об установленных
соединениях, способное генерировать отчеты об установленных соединениях за заданный
промежуток времени, их количестве и общей продолжительности, по отдельным пользователям
системы, подразделениям компании. Информация о пользователях системы и подразделениях, а
также телефонных аппаратах, соответствующих пользователям, должна извлекаться из
корпоративной службы каталогов, доступной по протоколу LDAP.
Сервер управления должен предоставлять инструментарий для выполнения пакетного
добавления устройств и абонентов, модификации параметров существующих устройств или их
удаления. Информация об устройствах должна предоставляться в текстовом формате, например в
виде полей разделенных запятыми (Comma Separated Value).
Сервер управления должен предоставлять программный интерфейс для манипуляции базой
данных устройств, получения информации о зарегистрированных устройствах и их адресах.
Должны поддерживаться операции добавления новых устройств, изменения параметров
существующих устройств, удаления устройств, изменения плана нумерации, установления
ограничений по выполнению соединений.
Сервер управления должен поддерживать автоматическую маршрутизацию звонков и
автоматический выбора маршрута (Automatic Alternate Routing и Automatic Route Selection). При
сбое голосового шлюза или нехватке полосы пропускания для установления соединения, сервер
управления должен автоматически выбирать запасной маршрут или шлюз.
Сервер управления должен обеспечивать следующие пользовательские функции:
 Индикация вызова на экране телефонного аппарата. Должна быть предусмотрена возможность
отключения звуковой индикации;
 Возможность автоматического ответа на звонок при поступлении звонка;
 Отображение номера вызывающего абонента (Automatic Number Identification, ANI). Номер
должен передаваться в управляющих сообщениях Q.931 или H.225 при установлении
соединения;
8
 Перенаправление вызова. Должна поддерживаться возможность безусловного перенаправления
всех вызовов, перенаправления при занятости номера абонента, при отсутствии ответа в
течение установленного интервала времени или в случае, когда абонент не зарегистрирован в
системе в данный момент времени;
 Парковка
вызова.
Сервер
управления
должен
обеспечивать
возможность
парковки
установленного соединения на определенный номер, для его последующего продолжения с
другого телефонного аппарата;
 Перехват вызовов и групповой перехват вызовов. Сервер управления должен обеспечивать
возможность перехвата вызовов, поступающих на телефонные аппараты группы, с телефонного
аппарата, принадлежащего этой группе. Сервер управления также должен обеспечивать
возможность перехвата вызовов, принадлежащих другой группе. Для этого абонент должен при
перехвате вызова указать номер группы;
 Ждущий вызов. Сервер управления должен поддерживать режим ждущего вызова. При
поступлении второго звонка на занятую абонентскую линию, должна обеспечиваться
индикация на экране телефона и раздаваться звуковой сигнал. Абонент должен иметь
возможность удержать текущее соединение и переключиться на поступивший звонок;
 Идентификация номера звонящего абонента (Calling Line Identification, CLID). Сервер
управления должен предоставлять информацию о номере звонящего абонента;
 Идентификация имени звонящего абонента (Calling Name Identification, CNID). Сервер
управления должен предоставлять информацию об имени звонящего абонента. Сервер
управления должен корректно обрабатывать имена, содержащие русские символы в одной из
распространённых кодировок (например, windows-1251).
Система управления вызовами должна поддерживать возможность предоставления
информации о текущем статусе абонента (свободен, занят или не зарегистрирован) и возможность
отображения её в каталоге абонентов, списках пропущенных, совершённых и полученных вызовов
на экране IP телефонов.
Сервер управления должен обеспечивать возможность разделения планов нумерации, и
определения классов ограничений при выполнении вызовов между абонентами системы. Сервер
управления должен обеспечивать приём и отправку набранного номера (Dialed Number
Identification Service, DNIS) и номера, с которого осуществлялось перенаправление (Redirected
Dialed Number Identification Service, RDNIS).
Сервер управления должен поддерживать функцию удержания вызова и снятия с
удержания. В моменты, когда звонок находится на удержании, абонент системы должен слышать
музыку на удержании. Должен обеспечиваться режим генерации потоков музыки на удержании в
режиме многоадресной рассылки (IP Multicast).
9
Сервер управления должен поддерживать режимы набора телефонного номера, когда
трубка снята или лежит на телефонном аппарате.
Сервер управления должен поддерживать режим автоматической установки соединения
при поднятии трубки (Private Line Automatic Ringdown, PLAR).
Сервер
управления
должен
поддерживать
перевод
вызовов
(Transfer).
Должен
поддерживаться безусловный перевод звонка и перевод с консультацией.
Сервер управления должен поддерживать трансляцию набранных номеров или полученных
цифр.
Сервер управления должен быть оснащен достаточным количеством оперативной памяти.
Сервер
управления
должен
обеспечивать
пользовательский
для
WEB-интерфейс
индивидуальной настройки параметров для телефонного аппарата абонента. Пользователь должен
иметь возможность установки номера безусловного перенаправления вызовов для принадлежащих
ему телефонных аппаратов, возможность настройки кнопок быстрого набора. Пользовательский
интерфейс управления также должен включать средство поиска пользователей в корпоративном
справочнике. Должен поддерживаться режим, при котором набор телефонного номера с
телефонного аппарата пользователя инициируется непосредственно из телефонного справочника
абонентов, через web-интерфейс.
Сервер управления должен поддерживать создание конференций. Конференция может быть
организована подключением абонентов одним из участников в процессе телефонного разговора.
Требования к подсистеме интеллектуальных сервисов
Подсистема интеллектуальных сервисов должна удовлетворять следующим требованиям:
Количество сотрудников Call центра:
Период
I
3 месяца
6 месяцев
12 месяцев
9
15
30
50
супервизор
1
1
2
4
Web, Email агентов
1
2
3
5
этап
Общее
число
сотрудников
10
 Организация круглосуточной работы 55 рабочих мест операторов и 4 рабочих мест
супервизоров ЦОВ; На первом этапе кол-во операторов 9, кол-во супервизоров 1.
В части маршрутизации входящих вызовов.
Возможность объединения операторов в группы, обслуживающие определенные типы вызовов, и организацию очередей. Каждой такой группе должен присваиваться собственный внутренний и/или соответствовать внешний телефонный номер. Механизм маршрутизации вызовов
должен быть настраиваемый и иметь возможность изменения без участия программистов. Маршрутизация вызовов должна осуществляется как на основании квалификации операторов, так и на
основе алгоритмов распределения вызовов установленных супервизором или администратором
ЦОВ. Также ПО ЦОВ должно обеспечивать следующие алгоритмы маршрутизации:
 Линейное распределение на операторов (Hunt group);
 выбор «наиболее свободного оператора» в зависимости от времени, в течение которого
операторы оставались свободными (longest available agent);
 выбор оператора с самым низким средним временем обслуживания вызовов (Shortest average
call handle time);
 выбор оператора, обслуживающего в среднем наибольшее количество вызовов (Highest
average calls handled)
 функция прямого вызова. В данном случае абонент при желании может направить вызов
непосредственно к интересующему его оператору. Такие вызовы будут обладать более
высоким приоритетом, чем вызовы, поступающие в операторскую группу;
 при отсутствии свободных операторов предполагается, что вызовы внутри операторской
группы будут распределяться так же, как и с учетом квалификации сотрудников. Как только
оператор освобождается, к нему поступает самый ранний вызов, имеющий самый высокий
приоритет и ожидающий при этом оператора с самым высоким уровнем профессиональных
знаний.
 Переадресация вызова в случае не ответа оператора на вызов – система должна выполнять
следующие действия:
 переводить рабочее место оператора в состояние «Не готов» (чтобы на данное место не
поступали следующие вызовы);
 уведомлять о данном происшествии супервизора (т. к. данное событие является
11
нарушением дисциплины со стороны оператора);
 переводить вызов на другого свободного оператора или возвращать вызов в очередь, но с
более
высоким
приоритетом
(чтобы
вызов
был
обслужен
следующим
же
освободившимся агентом);
 маршрутизация вызовов на основе расчетного времени ожидания. Данная функция должна
позволять сообщать абоненту, сколько времени ему предстоит ждать в очереди. В зависимости
от того, сколько времени вызов стоит в очереди, выбирается наилучший маршрут.
 приоритетность обслуживания.
 Входящие вызовы в зависимости от линий должны делиться по приоритетам от 0
(низший) до 10 (наивысший). Изменение уровня приоритета линии должно быть
доступно администратору, для оперативного управления очередями.
 Так же должна быть возможность назначать приоритет входящих вызовов в зависимости
от категории клиента.
 Возможность организации централизованной системы интерактивных голосовых меню
автоинформатора (IVR); В частности автоинформатор должен обладать следующими
возможностями:
Используя синтезированную или заранее записанную речь и доступ к корпоративным
базам данных, ПО должно:
 Ответить на входящий вызов;
 Запросить у абонента дополнительные данные, необходимые для обслуживания его
вызова;
 Предоставить абоненту нужную информацию или вид услуг на основе полученных от
него
данных. Например, автоматическое информирование клиента о сумме остатка
денежных средств на личном счёте, при его авторизации в системе при помощи номера
лицевого счета и пароля. Система должна не только воспроизводить, но и воспринимать
человеческую речь, помимо цифровой навигации в меню (DTMF).
 В системе отчетности в части интерактивного речевого взаимодействия, необходимо
получать весь набор данных, характерных для операторов: уровень загруженности,
процент обслуженных и потерянных вызовов и т.д. Должна быть возможность
просматривания наиболее востребованных и менее востребованных ветвей меню, с
каких ветвей абоненты чаще всего запрашивают помощь оператора. Возможность
преобразования или удаления неудачных ветвей меню. ПО должно позволять
вызывающим абонентам более эффективно использовать время ожидания в очереди.
Когда освобождается оператор, линия связи с системой немедленно разрывается, и
вызывающий абонент соединяется
с
12
освободившимся
оператором.
При этом передается вся информация, связанная с этим абонентом.

Система распознавания речи
Система должна обеспечивать поддержку языков распознавания: русского, английского и китайского, а также наличие встроенных грамматик распознавания дат, цифр,
да/нет, времени и аббревиатур.
Грамматики системы должны соответствовать спецификации SRGS.
Доступ к системе распознавания речи должен быть по протоколу MRCPv1/v2 через
единый ASR/TTS Speech Server.

Система генерации речи
Система должна обеспечивать поддержку языков генерации речи: русской, английской и китайской. Система должна обладать встроенными шаблонами фонем и интонаций
для произнесения дат, времени, погоды, адреса и электронной почты.
Система должна иметь возможность обработки текста в UNIPA/SAMPA формате,
для более повышения качества генерации речи.
Доступ к системе генерации речи должен быть по протоколу MRCPv1/v2 через единый ASR/TTS Speech Server.

Обработка факсов
Предполагается передача факсов по протоколу T.38 (FoIP). Система должна иметь возмож-
ность интеграции в рабочее место оператора, организации очередей факсов, обеспечивать подтвержденную доставку факсов, обеспечивать авто-доставку факсов документов пользователей, доставлять факсы в виде email сообщений пользователям системы.
 Наличие графического интерфейса для администрирования ЦОВ и создания сценариев
обработки вызовов;
 Cбор оперативно-статистических данных по нагрузке и показателям работы операторов,
выдача их на печать и / или средства отображения.
 Возможность гибкого распределения вызовов между операторами по следующим параметрам:
текущее время дня; день недели; длина очереди; номер вызывающего абонента; набранный
абонентом номер; введенные абонентом дополнительные цифры; количество свободных
операторов;
расчетное
время
ожидания
обслуживания;
квалификационные
признаки
операторов.
 Система организации кампаний исходящих вызовов
 Система должна поддерживать работу кампаний в режимах Preview, Progressive,
Predictive и их производных.
 Должны
поддерживаться
режимы
исходящего
13
обзвона
как
с
переключением
установленных соединений на операторов так и с переключением на порты IVR
(автоинформатор).
 Система должна иметь интерфейсы интеграции с внешними информационными
системами для автоматической загрузки контактов и управления работой кампаний
 Система должна поддерживать следующие атрибуты контактов для обзвона:
o Идентификатор контакта
o Несколько типов телефонных номеров (домашний, рабочий, мобильный)
o Локальный часовой пояс контакта
o Пользовательские атрибуты контакта
 Система должна содержать инструменты гибкой настройки расписания работы кампаний
с учетом локального часового пояса каждого конечного клиента. Расписание работы
должно задаваться как на уровне кампании так и на уровне типов телефонных номеров
контакта.
 У оператора должна быть возможность классифицировать исходящий вызов из ПО
рабочего места в случае попадания вызова на Fax или автоответчик.
 система должна входить в состав ПО ЦОВ и обладать единой статистикой, позволяющей
строить отчёты производительность ЦОВ.
 Система должна обладать функцией персональных обратных вызовов (callback), которая
позволяет оператору перенести вызов клиента, по его просьбе, на более удобное время.
Обратные вызовы могут быть настроены таким образом, что при повторном вызове
звонок будет направлен любому оператору (обычный обратный звонок) или тому
оператору, который зарезервировал обратный звонок (персональный обратный звонок).
 В режиме автоинформатора система должна иметь средства контроля доступности
свободных портов IVR для обработки вызовов и отслеживания длительности соединения
с установкой соответствующего статуса обработки контакта, если клиент не дослушал до
конца голосовое объявление автоинформатора.
 Система управления.
 Система управления ЦОВ должна иметь возможность по администрированию и
конфигурированию в режиме реального времени. Такие параметры как, состав
операторских групп, уровни обслуживания, коды причин изменения статуса операторов,
параметры маршрутизации вызовов и многое другое могут вноситься без остановки
работы ЦОВ.
 Задание пороговых значений производительности. Каждый супервизор системы может
самостоятельно задавать пороговые значения производительности, изменяя значения
соответствующих настроек меню
ПО своего рабочего места. Должна
14
быть предусмотрена возможность установки как минимум двух пороговых уровней
(thresholds): предупредительный (желтый) и критический (красный). Супервизор может
минимизировать окна ПО рабочего места и работать с другими приложениями до тех
пор, пока не возникнет предупреждение системы с желтой или красной индикацией,
означающая,
что
необходимо
обратить
внимание,
либо
вмешаться
в
работу
операторского центра. Кроме этого, при возникновении экстраординарных событий,
должен выдаваться звуковой сигнал.
 Система отчетности.
Должны быть предусмотрены следующие виды отчетов:
 Отчеты реального времени. Данные отчеты должны обновляться каждые 3 секунды. С их помощью управляющий персонал может принимать оперативные решения
по управлению ЦОВ. С помощью отчетов реального времени можно отслеживать
следующую информацию:
-
число вызовов в очереди;
-
время, которое ожидает в очереди самый ранний вызов;
-
средняя продолжительность разговора;
-
расчетное время ожидания в очереди;
-
процент вызовов, обслуженных в течение заданного интервала времени;
-
среднее время, в течение которого абонент вешает трубку, не дождавшись ответа;
-
число свободных операторов;
-
причины отсутствия операторов на рабочем месте и т.д.
 Исторические отчеты. Исторические отчеты могут обновляться каждые 15 секунд,
данные можно суммировать по интервалам, дням, неделям и месяцам. Отчеты в хронологическом виде должны представлять следующую информацию:
-
Суммарные данные о производительности операторских групп в течение заданного периода времени: общее число обслуженных вызовов; общее число
вызовов, когда абоненты повесили трубку, не дождавшись ответа; процент
вызовов, обслуженных с заданных уровнем сервиса; средняя скорость ответа;
максимальная задержка при ответе на вызовы и т.д.;
-
Распределение вызовов (как обслуженных, так и не получивших ответа) по
временным интервалам. Например, можно будет определить, сколько вызовов
было обслужено в течение 10-15 секунд после постановки в очередь, сколько
вызовов было обслужено в течение следующих 10 секунд и т.д.
-
Подробные данные о производительности каждого оператора (по всем груп15
пам, в которые он входит);
-
Характеристики загруженности соединительных линий и т.д.
 Интегрированные отчеты. В основе интегрированных отчетов лежит комбинация
данных, полученных из отчетов реального времени и хронологических отчетов.
Данный вид отчетов позволит одновременно видеть ситуацию настоящего и прошлого времени работы ЦОВ, решать долговременные стратегические задачи.
 Пользовательские отчеты. Подразумеваются отчеты, как реального времени, так и
хронологические - в виде графиков, таблиц, текстов или их комбинации. В эти отчеты можно включить только те данные и в том порядке, которые необходимы нам.
 Отчеты о недопустимых событиях. Необходимо предусмотреть возможность создания специальных отчетов (реального времени и хронологических), содержащих
информацию о различных экстраординарных событиях. Например, если оператор не
ответил на поступивший вызов, система должна сформировать отчет (реального
времени и исторические) с указанием времени и имени оператора, не ответившего
на вызов. Под экстраординарным событием подразумевается – это превышение оператором времени, отведенного на перерыв, одновременное нахождение в очереди
трех (пять, десяти и т.д.) вызовов, принудительное отклонение вызовов и т.д. Пороговые значения, определяющие выход события за рамки допустимого, устанавливаются на уровне отдельных операторов, операторских групп, групп соединительных
линий. При возникновении экстраординарного события управляющий персонал (супервизор) должен получить звуковое уведомление на своем персональном компьютере, что позволит немедленно отреагировать на изменение оперативной ситуации в
ЦОВ
 Отчеты-прогнозы. Необходимо предусмотреть возможность составления специальных отчетов, позволяющих спрогнозировать будущие характеристики трафика,
загрузки операторов и соединительных линий на основе данных хронологических
отчетов. Отчеты-прогнозы предполагают возможность сначала смоделировать ту
или иную ситуацию, а потом уже принимать решение, например, о расширении штата операторов или подключении соединительных линий.
Отчеты должны экспортироваться в формат Exel, HTML и pdf.
Система отчетности должна иметь разграничение доступа к отчетности.
ПО рабочего места оператора:
 позволять оператору подключаться к системе с любого рабочего места, с сохранением всех
параметров;
 уметь фиксировать причину перехода оператора в не рабочее состояние - когда оператор
16
переходит в нерабочее состояние (выходит из системы либо уходит на перерыв), он должен
указать причину, по которой он перешел в нерабочий режим («обед», «туалет», «вызов
руководителя», «обучение» и т.д.)
 ПО рабочего места оператора должно обладать следующим функционалом
 Автоответ - данная функция дает возможность оператору начать обработку вызова, не
поднимая телефонной трубки и не нажимая кнопок на телефоне/компьютере. Вызов,
поступивший к агенту, сразу переключается в его гарнитуру после короткого
предупредительного сигнала.
 Обращение за помощью к супервизору – в процессе обработки вызова агенту может
потребоваться помощь для решения некоторых вопросов, которые данный агент не
может или не уполномочен решать. Путем нажатия кнопки агент запрашивает помощь со
стороны начальника группы (супервизора), получает консультацию, после чего
возвращается к обработке вызова.
 Функция интерактивной переписки позволяет посылать мгновенные сообщения другим
операторам в командах и другим супервизорам.
 Возможность обработки электронных сообщений (Email) операторами. Операторы
контакт-центра назначенные для обработки электронных сообщений и голосовых
вызовов могут обслуживать голосовые и электронные поступающие контакты.
 Запись разговоров по требованию - Если это разрешено администратором, оператор
может записывать любой вызов. Администратор настраивает на панели инструментов
две кнопки задач: одну кнопку для начала записи, а другую для ее остановки. Также
предусмотрен режим записи всех разговоров без вмешательства оператора.
 Отчётность – У каждого оператора есть возможность просмотра собственной статистики
работы и полученных вызов, которая включает 7 журналов. В том числе Журнал вызовов
(число вызовов, стоящих в очереди…)
Журнал состояний оператора
Личная статистика оператора (текущая и историческая активность) и другие.
 Встроенный браузер, который позволяет просматривать веб-страницы во внутренней и
внешней сети из рабочего места оператора, а также позволяет поднимать всплывающие
формы при входящих или исходящих вызовах с информацией по клиенту.
ПО рабочего места супервизора:
 Супервизор имеет возможность активировать встроенное рабочее место оператора на
своём PC и принимать участие в обработке входящих контактов как оператор.
 Контроль за работой агентов – супервизор имеет возможность контролировать работу
операторов подопечной групп/ы
[team group].
17
 Статистика реального времени – супервизор имеет права на просмотр статистики
реального времени (real-time).
 Горячие клавиши - для навигации по интерфейсу рабочего места доступны клавиши
быстрого вызова (shortcut).
 Изменение состояния оператора - в ряде случаев супервизор может целенаправленно
менять состояние агента со своего рабочего места, например в случаях, когда оператор
слишком долго задерживается в состояниях поствызывной обработки.
 супервизор должен имеет возможность помогать оператору, отправляя веб-страницы во
встроенный браузер ПО рабочего места этого оператора
 супервизор должен иметь возможность бесшумно прослушивать разговоры оператора по
телефону, а также в случае необходимости вторгаться в разговор оператора, если в
процессе прослушивания он понимает, что вмешательство необходимо
 супервизор должен иметь возможность исключить агента из разговора и полностью
перевести обслуживание данного вызова на себя.
В качестве абонентских терминалов операторов ЦОВ рекомендуется использование
программных IP-коммуникаторов.
требования к системе в части мультимедийной обработки вызовов
1) Единые база знаний/настройки маршрутизации/настройки операторов для обработки писем
(Email) и Web-чатов
2) В системе должно вестись протоколирование всех обращений, т.е. каждому обращению
присваивается уникальный номер. В рамках этого номера сохраняется вся история переписки и все данные, передаваемые с письмом.
3) Система должна анализировать входящие обращения по адресу отправителя/получателя,
ключевым словам в теме или теле письма, дате и времени отправки и т.д.
В результате анализа система должна определить «тип» письма, его приоритет и
идентифицировать клиента.
Письмо помимо атрибута «тип» (автоматически определяемого системой) должно
иметь атрибут «статус». Условия присвоения статусов:

Новое – письмо зарегистрировано в системе, определен его тип, но письмо не открыто
и не принято в обработку ни одним пользователем системы

В обработке – пользователь системы принял письмо в работу. Статус сохраняется до
отправки ответного письма, либо до ручного изменения статуса на «Требует ответа
специалиста/сделан уточняющий запрос».

Требует ответа специалиста/сделан уточняющий запрос – статус может проставляться
18
вручную пользователем системы в случае, если для ответа на вопрос клиента требуется
дополнительное время для детального анализа ситуации, либо необходимо отправлять
запрос в другие подразделения.

Отправлен ответ – статус проставляется автоматически при отправке ответного письма
Клиенту. В ответном письме должна быть реализована возможность подтверждения о
получении ответного письма Клиентом.

Подтверждено Клиентом – статус проставляется автоматически при получении подтверждения ответа от Клиента.
4) В системе должен существовать механизм контроля над качеством обслуживания. Если положенный срок обработки обращения истек, то должна быть реализована эскалация обращений на другого пользователя системы или супервизора.
5) У операторов должна быть возможность при ответе на письмо от клиента использовать типовые шаблоны. Помимо этого, система должна предоставить оператору несколько вариантов шаблона, которые наилучшим образом подходят для ответа на данное сообщение.
6) Ответное письмо от оператора должно попадать на сервер, где в результате обработки к
письму подгружаются персональные предложения (в случае, если клиент был идентифицирован системой, либо оператором вручную) или общие предложения в случае, если клиент
не был идентифицирован.
В системе должны быть реализованы две функциональные роли с различными
полномочиями:
 Оператор
 Супервизор
Оператор
Пользователь с ролью Оператор должен производить в системе обработку писем и обладать
следующими полномочиями:
 Принимать обращения, поступающие из общей очереди обращений заданного типа
 Видеть очередь обращений (назначенных на него, либо на группу операторов обрабатывающих один тип обращений), видеть приоритет писем, служебную информацию
 Отвечать на письма клиента
 Получать напоминания об истечении установленного срока ответа на письмо.
 Отвечать на обращения с использованием типизированных шаблонов ответа
 Менять вручную тип обращения, определенный системой
 Менять вручную статус письма «В обработке» на статус «Требует ответа специали19
ста/сделан уточняющий запрос»
 Перенаправлять обращение на другого пользователя системы
 Идентифицировать клиента вручную; менять идентификатор клиента (EAN), определенный
системой
Супервизор
Пользователь с ролью Супервизор должен обладать следующими полномочиями:
 Добавление/удаление пользователей системы
 Настройка параметров анализа входящего обращения
 Настройка параметров автоответчика: текст ответа, возможность включения/отключения
подгрузки предложений для обращений различных типов, возможность настройки логики
подгрузки предложений в автоответ (например: для писем, по которым клиент идентифицирован – подгружаем в автоответ персональные предложения; если клиент не идентифицирован – подгружаем общие предложения; если по данному e-mail адресу в базе обнаружено несколько клиентов – подгружаем общие предложения)
 Управление очередями писем: задание правил маршрутизации для каждого типа обращений
(назначение обработки на пользователя/группу пользователей)
 Настройка правил, определяющих приоритет входящего обращения
 Ручное изменение приоритета любого письма
 Установка максимального времени нахождения письма в каждом статусе
 Настройка правил маршрутизации обращений с превышенным лимитом времени нахождения в одном статусе.
 Просмотр списка писем, для которых истек установленный срок ответа
 Настройка, редактирование, добавление и удаление типовых шаблонов, используемых при
ответе на обращения
 Просматривать текущую и историческую статистику по поступающим обращениям, очередям обращений, обработке e-mail и эффективности работы пользователей системы.
Требования к системе регистрации телефонных переговоров
Система записи (регистрации) вызовов и управления качеством
Необходимо предусмотреть возможность записи и хранения вызовов. Система записи
должна иметь следующие режимы:
 тотальная запись (внешних соединительных линий и внутренних номеров);
 выборочная запись:
 для записи отдельных вызовов в соответствии с информацией о вызове, поступающей по
20
каналу. Например, записывать только входящие вызовы; только входящие вызовы с
определенными номерами; только исходящие вызовы; только исходящие вызовы на
заданные номера и т.д.
 для записи отдельных операторов в соответствии с заданными критериями. Например,
можно записывать вызовы, поступающие к конкретным операторам или группам
операторов и т.д.;
 запись по требованию – запись инициируется по требованию оператора;
 Необходимо также записывать не только аудио-информацию, относящуюся к вызову, но и
различные сопутствующие вызову данные, в том числе все компьютерные экраны, которые
оператор открывал на дисплее во время обслуживания вызова. Совместимая запись голоса
и данных позволят организовать многокритериальный поиск и запись.
 Система должна поддерживать возможность резервирования серверов записи аудиоинформации для записи IP телефонов по схеме N+N (“один к одному”) и N+M (“один к
нескольким”).
 Необходимо обеспечить возможность записи как IP-телефонов, так и аналоговых аппаратов
и транков Е1 в рамках одной системы записи с единым интерфейсом для поиска и
воспроизведения вызовов.
 Система записи должна обеспечивать сжатие вызовов, записанных в кодеке g.711, с
помощью кодека g.723.
 Система записи должна интегрироваться с оборудованием контакт-центра и IT
инфраструктурой для обеспечения идентификации конкретного оператора, работающего в
определённый момент времени за произвольным рабочим местом путём анализа
сообщений от IP-PBX и специализированного клиентского ПО на рабочей станции
оператора.
 Система записи вызовов должна автоматически группировать различные сегменты с
одинаковым идентификатором вызова для непрерывного воспроизведения. Должна быть
предусмотрена возможность осуществлять выбор сегмента для прослушивания.
 Система записи вызовов должна иметь собственную подсистему отчётности для
построения хронологических отчётов по статистике записанных вызовов и статистике по
результатам проверок подсистемы управления качеством.
 Подсистема управления качеством должна позволять производить оценку работы
оператора по конкретному обращению в контакт-центр путём заполнения специалистом
формы оценки в процессе прослушивания записанного вызова, автоматического подсчёта
баллов и привязки результата к конкретному записанному вызову. Формы оценки должны
21
быть редактируемыми и составляться в соответствие регламентам работы контакт-центра.
 Подсистема управления качеством должна позволять производить оценку мнения клиентов
о работе компании в целом путём заполнения специалистом формы оценки в процессе
прослушивания записанного вызова, автоматического подсчёта баллов и привязки
результата к конкретному записанному вызову. Для оценки должны использоваться
редактируемые формы, выделенные в отдельную функциональную группу.
 Система должна поддерживать возможность создания меток для прикрепления к
выполненным оценкам. Система должна поддерживать возможность быстрой выборки
помеченных оценок за текущий период или поиска оценок по стандартной форме с учётом
наличия прикреплённых меток.
22
Этапы работ и результаты выполнения
Работы по настоящему техническому заданию выполняются в один этап в сроки
определенные контрактом. Содержание и результаты выполняемых работ представлены в
следующей таблице.
Таблица 1
№
Содержание выполняемых
№
работ
1
.
приемки ТП
Поставка оборудования и
Акт сдачи-приемки оборудования и ПО
Настройка системы и запуск в
эксплуатацию
4
.
Технический проект (ТП). Акт сдачи-
программного обеспечения (ПО)
3
.
Отчетные документы
Техническое проектирование
системы
2
.
Результаты,
Корректно функционирующая система
ЦОВ. Акт сдачи-приемки работ
Разработка исполнительной
документация на систему
Исполнительная документация. Акт
сдачи-приемки работ
Порядок контроля и приемки работ
Контроль работ осуществляется Заказчиком в соответствии с контрактом. Приемка работ
производится в сроки, установленные контрактом. По результатам работ оформляется акт приемосдаточных испытаний.
23
Скачать