Приложение к Порядку проведения конкурса на предоставление услуг интегратора первой очереди Единого Распределенного Контактного Центра (ЕРКЦ) Сбербанка России базе оборудования Avaya. |
Подробные технические требования к оборудованию ЕРКЦ:
Назначение и цели создания системы
Основные цели создания ЕЦОВ Сбербанка РФ на базе оборудования Avaya:
· Прием, обработка и регистрация входящих обращений клиентов и потенциальных клиентов Сбербанка.
· Осуществление исходящих телефонных обзвонов, проведение рассылок.
· Создание инструмента сбора, хранения и анализа статистической информации, поступающей через обращения клиентов и потенциальных клиентов Банка.
Обслуживаемые каналы доступа в ЕРКЦ:
· Телефонные вызовы.
· e-mail-сообщения.
· Факсимильные сообщения.
· Запросы с web-сайта.
Требования к технической документации
Перед началом работ должно быть разработано техническое задание на проект ЕРКЦ в г. Воронеж (Москва). В ТЗ должно быть отражено:
· требования к алгоритмам маршрутизации вызовов ЕРКЦ;
· требования к разработке структуры Voice Portal (IVR);
· требования к настройкам систем ЕКРЦ;
· требования к интеграции систем ЕКРЦ;
· требования к настройке и интеграции ЕРКЦ;
· разработка программы испытаний и проведение испытаний ЕРКЦ;
· разработка технической и пользовательской документации ЕРКЦ.
Разработка всех документов предполагает и их согласование с уполномоченными сотрудниками Банка.
Общие требования
ЕРКЦ должна включать в себя следующие подсистемы:
1) Подсистема маршрутизации вызовов (УАТС)
2) Подсистема конвертора
3) Подсистема интерактивного речевого взаимодействия Voice Portal (IVR)
4) Подсистема SES (работа с протоколом SIP)
5) Подсистема AES (компьютерно –телефонная интеграция)
6) Подсистема AIC (Автоматизация АРМ операторов при входящих вызовах).
7) Подсистема анализа и записи информации, полученной через контакт с клиентом (NICE)
8) Подсистема факс-сервер
9) Подсистема исходящего обзвона (PDS)
10) Подсистемы управления и отчетности на базе CMS и ОА
11) Подсистема учета обращений (АРМ Оператора)
12) Подсистема контроля качества работы ЦОВ (АРМ Супервизора)
Количественные характеристики ЕРКЦ
· УАТС: версия Communication Manager Enterprise Edition, 180 лицензий CC Elite, дублирование ISPI, дублирование блоков питания в S8730 и G650.
· Подсистема СMS: 46 администраторов (6 из них для WallBoard) и 180 операторов.
· NICE: горячее резервирование, функция Customer Feedback (возможность клиента оставлять отзыв) 180 лицензий.
· PDS: Версия, 10 операторов + 1 супервизор.
· Voice Portal (IVR): Voice Portal на 450 портов с TTS (450 портов) и ASR (6 портов). Дублирование N+1 MPP, дополнительный VPMS (всего 6 серверов). В серверах дублируются блоки питания.
· Конвертор протоколов на 20 потоков Е1.
· AIC: на 160 операторов (20 multimedia\140 voice), включая модули обработки E-mail и связи с web-Server. Модули Content Analysis, Avaya Agent, VoIP Chat.
· FAX Server: RightFax на 30 каналов, дублированный. Модуль управления рассылками.
Требования к надежности разрабатываемой системы
Должно быть предусмотрено резервирование основных компонент Системы следующим методами. Дополнительно, системы, расположенные в Москве, должны быть территориально разнесены для обеспечения катастрофоустойчивости.
Компонент | Метод резервирования | |
УАТС | Процессор S8730 | Горячее |
Блок питания шлюза G650 | Горячее и Холодное | |
Плата IPSI TN2312 (плата сетевого управления шлюза G650 от процессора) | Горячее и Холодное | |
Плата голосовых объявлений TN2501 | Горячее | |
Плата потока E1 TN2464 | Холодное | |
Плата цифровых абонентов TN2214 | Холодное | |
AES | Жесткие диски | Горячее (RAID 1 и 5) |
Сервер | Холодное | |
Voice Portal (IVR) | Сервер MPP | Горячее |
Жесткие диски | Горячее (RAID 1) | |
Серверы VPMS и APP | Холодное | |
SES Сервер | Сервер | Горячее |
Nice | Сервер VoiP Logger | Холодное |
Жесткие диски | Горячее (RAID 1 и 5) | |
Серверы | Холодное | |
AIC | Жесткие диски | Горячее (RAID 1 и 5) |
Серверы | Холодное | |
Серверы интеграции | Жесткие диски | Горячее (RAID 1) |
Блоки питания серверов | Горячее | |
Серверы | Холодное | |
Сервер CMS | Жесткие диски сервера с данными | Горячее (Mirroring) |
Конвертор | Конвертор | Горячее |
Требования по подключению к оператору связи
Для подключения каждой площадки в Москве к оператору связи должны использоваться 15 потоков Е1 с сигнализациями ISDN-PRI или ОКС-7 (суммарно 30 потоков Е1). В состав оборудования ЕРКЦ должно входить оборудование для обеспечения работы с использованием вышеуказанных сигнализаций. Вышеуказанное оборудование должно допускать балансировку нагрузки и быть дублировано по схеме 1+1.
Для подключения площадки в Воронеже к площадке в Москве должен использоваться протокол SIP. Дополнительно площадка в Воронеже должна иметь возможность принять 2 потока Е1 от оператора связи с сигнализациями R1, R2 или ISDN-PRI.
Требования к каналам связи между площадками в Москве и Воронеже выдает интегратор.
Требования к системе электропитания
Для обеспечения электроснабжения поставляемого оборудования, при отключении основного и резервного вводов внешнего энергоснабжения, в состав ЕРКЦ должны входить источники бесперебойного питания (ИБП) с комплектом аккумуляторных батарей (АКБ). Время работы ИБП от АКБ должно обеспечить бесперебойную работу оборудования всех компонентов ЕРКЦ на время срабатывания АВР и запуск ДГУ, но не менее 10 мин. Необходимо реализовать уровень резервирования ИБП по схеме не менее N+1.
Требования к оборудованию рабочего места оператора и супервизора
Рабочее место оператора должно соответствовать следующим требованиям:
· программно-аппаратная часть рабочего места оператора должна состоять из следующих компонентов:
o персональный компьютер, подключенный к корпоративной сети;
o цифровой телефон;
o телефонная гарнитура (с двумя наушниками и микрофоном с шумоподавлением);
o Количество гарнитур - 300.
o фиксированные кнопки телефона: «Конференция», «Перевод вызова», «Отбой», «Удержание», «Отключение микрофона»;
o регулятор громкости звонка и речевого сигнала.
· управление телефонными вызовами должно осуществлять с телефонного аппарата и через программный интерфейс;
· режимы работы операторов («Свободен», «Обслуживает вызов», «Поствызывная работа», Перерыв») с кодами (до 9) причин перехода в нерабочее состояние;
· возможность осуществления исходящих вызовов по различным направлениям (внутренний, местный, междугородний, международный, в зависимости от прав доступа), которые отслеживаются системой отчетности;
· возможность ввода специальных кодов, описывающих вид каждого вызова.
Технические требования к подсистемам
Требования к подсистеме маршрутизации вызовов (УАТС)
1) Тип станции – модульная цифровая конвергентная УАТС Avaya S8730.
2) Система должна реализовывать следующие требования к производительности, масштабируемости и функциональному развитию УАТС:
· Производительность процессора должна быть не менее 500 000 обслуживаемых вызовов в ЧНН;
· УАТС должна обеспечивать поддержку до 250 удалённых отказоустойчивых выносов;
· Удаленный вынос должен иметь возможность установки встроенного локального процессора с производительностью не менее 50000 обслуживаемых вызовов в ЧНН;
· УАТС должна иметь возможность расширения до 36000 абонентов и до 8000 соединительных линий.
3) Требования к исполнению УАТС:
· Исполнение УАТС – стоечное, должна устанавливаться в стандартную 19-дюймовую телекоммуникационную стойку;
· Все критические компоненты УАТС (процессоры и платы интерфейсов между процессорами и шлюзами) должны быть дублированы.
· УАТС должна иметь дублированные встроенные блоки питания с возможностью распределения нагрузки.
Требования к подсистеме конвертора
1) Конвертор должен принять от оператора связи потоки Е1 с сигнализацией SS7 или ISDN-PRI и преобразовать их в протоколы SIP или H.323.
2) Система должна поддерживать следующие функции:
· Терминация SS7 трафика;
· Одновременная поддержка протоколов SS7, ISDN и SIP;
· Поддержка до 24х потоков Е1 в одном устройстве;
· Объединение до 12-х шлюзов в единый кластер с общим числом потоков 200 x E1
· Перекодировка «на лету» кодеков из различных сетей - G.711, G.723.1, G.729A/B, GSM;
· Поддержка всех расширений протокола SIP, включая SIP-T и SIP-I;
· Доступ к заголовкам сигнальных пакетов;
· Поддержка возможности создания географически распределенных резервированных решений.
Требования к подсистеме SES
1) Подсистема SES выполняет роль SIP Proxy сервера и выполняет функции отказоустойчивости, балансировки нагрузки и и перенаправления трафика, согласно заложенным алгоритмам. SES принимает SIP трафик от конверторов и перенаправляет трафик в подсистемы Voice Portal (IVR) и УАТС.
2) Подсистема SES должна быть реализована на серверах стандартной архитектуры.
3) Подсистема SES должна поддерживать отказоустойчивость по схеме 1+1.
Требования к подсистеме интерактивного речевого взаимодействия Voice Portal (IVR)
1) Предоставляемая информация должна быть четко структурирована и представлена в виде дерева. Должна обеспечиваться возможность формирования нескольких уровней дерева (пунктов голосового меню).
2) Предоставление запрошенной клиентом информации должно производиться в речевом виде. Проигрываются информационные сообщения, записанные заранее.
3) Подсистема Voice Portal (IVR) должна предоставлять функционал синтеза речи.
4) Подсистема Voice Portal (IVR) должна предоставлять функционал распознавания голоса.
5) Информационные сообщения могут быть как непрерываемые, так и прерываемые нажатием любой кнопки телефона.
6) Должна обеспечиваться возможность возврата в предыдущее меню и в главное меню.
7) Должна предоставляться возможность повторного прослушивания пункта меню.
8) Система должна обеспечивать возможность соединения абонента с Оператором из Voice Portal (IVR) с постановкой в очередь с соответствующим приоритетом (количество приоритетов: 4).
9) Клиенты, не имеющие возможность переключить телефон в тоновый режим, должны переводиться на Оператора.
10) Ввод информации клиентом должен осуществляться в тоновом режиме телефона.
11) Система должна предоставлять высокоуровневый интерфейс настройки информационных пунктов меню силами Супервизора, без необходимости перекомпиляции приложения Voice Portal (IVR).
Требования к подсистеме AES
1) Подсистема AES должна обеспечивать возможность интеграции подсистемы УАТС с подсистемами Voice Portal (IVR), Nice, AIC.
Требования к подсистеме AIC
1) Система мультимедийной обработки вызовов должна обеспечивать:
· мультимедийную обработку вызовов в реальном масштабе времени;
· одинаковый стандарт для приложения оператора вне зависимости от его месторасположения;
· Настраиваемые сценарии обработки данных;
· Возможность адаптации под необходимые задачи заказчика и открытые инструменты и стандарты интеграции с другими приложениями и СУБД, доступные для специалистов заказчика.
2) Система должна маршрутизировать обращения и управлять обработкой обращений по разнообразным коммуникационным каналам, включая голос, IP-телефонию, системы интерактивного речевого взаимодействия Voice Portal (IVR), факсимильную связь, электронную почту, web, позволяющим регистрировать и учитывать все взаимодействия независимо от того, какой канал связи выбрал клиент.
3) Маршрутизация каждого мультимедийного вызова должна производиться на основе индивидуальных данных о звонке, месте вызова, номеру телефона, обратившемся абоненте и прочих сопутствующих оперативной ситуации данных.
4) Для идентификации клиента должны использоваться такие методы, как АОН для телефонных вызовов, введенные цифры для Voice Portal (IVR), «cookie» для Web, поля «От» ("From") или «Тема» ("Subject") для e-mail. На основе полученных данных подсистема маршрутизации направляет вызов на определенную группу операторов, принимая при этом во внимание квалификацию операторов, возможные намерения абонента.
5) Сразу при получении сообщения система должна иметь возможность направить автоматическое уведомление адресату о прочтении его письма и принятия его в работу, и действительно немедленно начать его обработку.
6) Система должна ставить мультимедийное сообщение в очередь на получение ответа от оператора. Оператору, к которому поступил запрос от клиента, выдается на экран список возможных стандартных ответов, сформированный системой на основании анализа содержимого письма, что значительно облегчает и ускоряет обслуживание запроса. Вся электронная почта, поступающая в компанию, может обрабатываться с учетом желаемых уровней обслуживания, критериев маршрутизации.
Требования к подсистеме анализа и записи информации, полученной через контакт с клиентом (NICE)
1) Должна быть реализована запись всех переговоров и экранов Операторов ЦОВ (без возможности несанкционированного отключения, модификации и удаления). Запись вызовов должна производиться в режиме Total Recording (Запись всех звонков).
2) Запись каждого контакта Оператора начинается автоматически при ответе на вызов этим Оператором.
3) Должны быть обеспечены следующие требования защиты информации от НСД:
· вызовы хранятся в зашифрованном виде;
· доступ к записям осуществляется только через ядро системы;
· модификация записанных вызовов невозможна;
· выгрузка архивов происходит в зашифрованном виде.
4) Должна обеспечиваться возможность поиска в базе данных записанных вызовов по любому из критериев, присутствующему в базе (Nice query), в том числе:
· по дате/времени регистрации вызова, периоду времени;
· по номеру телефона, полученному от АОН;
· по номеру Оператора;
· по внутреннему номеру телефона;
· по идентификатору Оператора;
· по причине обращения выбранной оператором в АРМ Оператора;
· а также по совокупности вышеуказанных параметров.
5) Доступ к прослушиванию любых записей вызовов (в т. ч. архивных) должен осуществляться только с АРМ Супервизора.
6) Должна быть возможность извлечь сохраненный системой записи вызов в виде звукового файла по меньшей мере одного из «де факто» стандартных форматов (формат *.wav). Данная функциональность должна быть доступна только с АРМ Супервизора.
7) Должна быть предусмотрена возможность дискретной по правам настройки разграничения доступа к функциям для Супервизора, Контролера (доступ ко всем Операторским группам, доступ к конкретным Операторским группам). Управление настройками по ограничению доступа должен осуществлять администратор ЦОВ.
8) Должна быть предусмотрена возможность прослушивания в режиме on-line (Nice monitor) с АРМ Супервизора.
9) Должна быть возможность анализа качества работы операторов и ЦОВ в целом, используя модуль «Анализ качества работы», предоставляющий Супервизорам ЦОВ следующие штатные возможности:
· Создание оценочных форм.
· Оценка по количественным/качественным показателям.
· Анализ экранных действий.
· Формирование отчетности на основе оценок качества работы.
10) Архивирование информации должно осуществляться на внутренние и внешние носители. Минимальный период архивирования – 1 день. Срок хранения архива на внутреннем носителе – не менее 15 дней. Планируемый срок хранения информации на внешнем носителе – не менее 1 года. Данные требования должны быть учтены на этапе технического проектирования и реализованы на 1-м этапе проекта.
11) Должна быть обеспечена возможность оперативного поиска информации в архивах, без необходимости остановки/изменения используемой системы записи.
Требования к подсистеме факс-сервер
1) Подсистема факс-сервер должна интегрироваться с Почтовым сервером, предоставляемым Банком.
2) Водящие факсы должны рассылаться на соответствующие входящим телефонным номерам почтовые ящики.
3) При отсылке электронных писем на почтовые ящики подсистемы факс-сервера, данные письма или текстовые файлы должны быть отосланы в виде факсов на телефонные номера, соответствующие данным почтовым ящикам.
4) Должна предоставляться возможность массовых рассылок факсимильных сообщений.
Подсистема исходящего обзвона (PDS)
1) Система должна использоваться для автоматизации массовых исходящих телефонных обзвонов. Осуществление обработки звонков должно производиться в соответствии с задаваемой бизнес-логикой:
· Автоматический набор телефонного номера.
· Фиксирование результата попытки дозвона и результата звонка.
· Осуществление обзвона с нескольких линий.
· Осуществление обзвона Системой по нескольким заданиям.
2) В системе должен быть реализован механизм распределения контактов по временным зонам. Данный атрибут контакта может быть включен в файл импорта или присваиваться системой автоматически.
3) В системе должен быть реализован механизм сохранения результатов звонка и добавления агентом новой информации в рамках обработки звонка.
4) Система Proactive Contact совершает исходящие вызовы в соответствии с заданной стратегией обзвона. Стратегия обзвона должна задавать:
· С какого номера телефона в записи начинается дозвон Клиенту.
· Число посылок вызова, при котором Система считает вызов неотвеченным.
· Временной интервал, по истечении которого Система повторит вызов для данной записи, если вызов был не отвечен, телефонный номер абонента был занят, во время набора номера произошло разъединение и т. п.
· Число попыток дозвона по заданному телефонному номеру Клиента, если соединения не произошло.
· Следующий номер телефона в записи Клиента, по которому необходимо продолжит дозвон, если число попыток дозвона по текущему телефонному номеру исчерпано
· Какие отвеченные вызовы Система будет переводить на оператора (живая речь, автоответчик и т. п.).
5) Системой должны быть предусмотрены следующие режимы осуществления звонков:
· Preview: в режиме предварительного просмотра данных о клиенте (контакта) перед началом набора номера. Данный режим позволит работать с персонализированными контактами, которые в соответствии с бизнес-процессами, которые требуют «предвызывной» обработки. Примеры использования данного режима: информирование клиентов о результатах рассмотрения письменного заявления/ претензии и т п.
· Predictive: система должна предварительно совершить исходящий звонок, и при ответе абонента она должна гарантировать подключение агента к абоненту, клиентская запись поступает агенту в момент его подключения к абоненту.
6) Должна быть реализована возможность отсекания непродуктивных событий:
· Некорректный номер
· Отсутствие ответа станции
· Сброс линии после набора номера
· Линия занята
· На линии факс или модем
· Автоответчик
· Нет ответа
· Клиент разъединился, ожидая освобождения оператора
· Перехват вызова оператором связи
· Отсутствие свободных каналов
· Перегрузка в сети связи
· Неполадки на линии
7) В системе должна быть реализована возможность автоматического регулирования интенсивности совершения исходящих звонков системой в процессе проведения кампании.
8) Должны быть настроены кампании исходящего обзвона (jobs).
9) АРМ Оператора исходящего обзвона должен быть реализован на базе стандартных возможностей приложения Avaya PDS Agent.
10) Должны быть созданы форматы файлов обмена для загрузки листов обзвона в Систему и выгрузки результатов обзвона из Системы.
11) Должны быть созданы стандартные экранные формы в Avaya PDS Agent, содержащие набор полей из файлов обмена с данными о кампании исходящего обзвона.
Подсистемы управления и отчетности на базе CMS и ОА
1) Предусмотрены следующие виды отчетов (по всем мультимедийным каналам):
· Отчеты реального времени.
· Хронологические отчеты.
· Интегрированные отчеты.
· Пользовательские отчеты.
· Отчеты о недопустимых событиях.
· Отчеты-прогнозы.
2) Система должна предоставлять возможность управления составом групп операторов
3) Система должна предоставлять возможность получения детальных данных о мультимедийных обращениях, входящих в ЦОВ.
Требования к АРМ Оператора
4) АРМ Оператора должен предоставлять оператору функционал для обслуживания следующих типов обращений:
· Голосовые обращения;
· E-mail-сообщения;
· Факсимильные обращения;
· Сообщения, поступающие через формы на web-сайтах Банка. (Данные форм должны поступать в EЦОВ в виде e-mail сообщений)
· Web-чат (практическая реализация на данном этапе не требуется).
5) АРМ Оператора должен поддерживать персонифицированные логины и пароли пользователей и позволять вход в АРМ только после авторизации пользователя путем ввода логина и пароля.
6) Управление телефонными вызовами как с помощью телефонного аппарата, так и через интерфейс АРМ Оператора:
· прием прямых входящих вызовов и осуществления исходящих вызовов;
· отключение от соединения;
· постановка вызова на удержание;
· снятие вызова с удержания;
· переадресация вызова;
· ответ на вызов во время разговора по другой линии (при этом вызов на другой линии ставится на удержание);
· организация конференции, максимум из 5-ти участников.
7) Оператор должен иметь возможность в АРМ Оператора управлять своим статусом подключения: готов, не готов, перерыв.
8) Отображение информации о поступившем к оператору вызове: дата и время поступления, входящий номер, принадлежность Территориальному Банку (Центральному аппарату) (в случае, если получен АОН).
9) АРМ оператора должен предоставлять Оператору механизм регистрации тематики обращения (причины, побудившей клиента или потенциального клиента обратиться в ЦОВ) при обслуживании телефонного вызова либо во время постобработки. У Оператора должна быть возможность для каждого обслуживаемого телефонного обращения зафиксировать следующие атрибуты:
· Контактные данные клиента.
· Причина обращения (выбирается из соответствующего справочника «Причины обращений»).
· Источник получения клиентом информации (выбор из справочника «Источники информации»).
· Содержание вопроса и ответа (текстовый комментарий Оператора).
· Тип обратившегося (выбор из справочника «Тип обратившегося»).
· Статус обращения (выбирается из справочника «Статус обращения»).
10) В АРМ Оператора при поступлении вызова должна появляться информация о предыдущих обращениях с данного телефонного номера последние 3 месяца. Отображаемая информация:
· Дата и время регистрации обращения.
· Идентификатор Оператора, зарегистрировавшего обращение.
· Причина обращения.
· Содержание обращения (текстовый комментарий Оператора).
· Номер телефона, с которого поступил вызов.
11) В случае, если Оператор, находящийся в статусе готовности к приему вызова, не отвечает на вызов (после 25 секунд), Система должна автоматически заблокировать Оператора и поставить вызов обратно в очередь с наивысшим приоритетом.
Требования к АРМ Супервизора
1) Система должна предоставлять возможность формирования хронологических отчетов по системе: время ожидания в очереди, количество не дозвонившихся, среднее время в очереди за период и т. д. в рамках штатных возможностей системы CMS.
2) Система должна предоставлять возможность формирования отчетов реального времени, отчетов по недопустимым событиям в рамках штатных возможностей подсистем CMS и ОА.
3) Система должна предоставлять Супервизору возможность поиска и прослушивания записей телефонных переговоров и экранов операторов средствами подсистемы Nice.
4) Система должна предоставлять Супервизору возможность использования функционала оценки качества работы операторов.
5) Супервизор должен иметь возможность в АРМ Супервизора формировать отчеты на основании данных, регистрируемых операторами в приложении АРМ Оператора:
· Статистика обращений по причинам обращений.
· Средняя длительность обработки обращений (в разрезе причин обращений, в разрезе операторов).
· Статистика обращений по источнику информации.
· Статистика обращений по типам обратившихся.
· Статистика обращений по статусу обращения.
6) Супервизор должен иметь возможность в АРМ Супервизора управлять справочниками, используемыми операторами в АРМ Оператора.
