Техническое задание ВТБ24 (ЗАО)
advertisement
ВТБ24 (ЗАО) Техническое задание Проект «развитие IVR» 1 Содержание 1 Введение 4 1.1 Назначение документа 4 1.2 Полное наименование и условное обозначение системы 4 1.3 Глоссарий 4 1.4 Цель проекта / задачи 6 1.5 Функциональный обзор 7 1.6 Требования к производительности и масштабируемости 7 1.7 Требования к надежности 7 1.8 Требования безопасности 8 1.9 Требования к версионности ПО 8 1.10 Требования к информационному обмену с внешними системами 9 1.11 Требования к администрированию 9 2 Архитектурное решение 10 2.1 Текущая архитектура решения 10 2.1 Описание БД 10 3 Ограничения реализации и дизайна (Подробное писание к интерфейсу IVR и статистике см.приложение Б.) 12 4 Функциональные требования 13 4.1 Общие требования 13 4.2 Функция проверки «звонок с мобильного» 25 4.3 Функция автоматического определения региона клиента 27 4.4 Функция проверки DNIS 28 4.5 Функция определения Grade 28 4.6 Функция определения наличия клиента в черном списке 30 4.7 Функция определения наличия клиента в белом списке 30 4.8 Функция проверки наличия PIN 31 4.9 Функция получения данных о просроченной задолженности 32 4.10 Функция автоматической идентификации/аутентификации 33 4.11 Функция ручной аутентификации 36 4.12 Функция ввода паспортных данных клиента 39 4.13 Функция приветствия клиента по времени суток (Главное меню IVR) 40 4.14 Функция получения статуса заявки 41 4.15 Функция формирования SMS из IVR 43 4.16 Функция выхода на оператора 45 4.17 Функция анализа признака «повторный звонок» 46 2 4.18 Функция повторного соединения с оператором 47 4.19 Функция «выхода на персонального финансового консультанта (ПФК)» 48 4.20 Функция повышения приоритета обращения клиента 51 4.21 Функция Управление пакетом SMS-нотификации (зарплатный) 51 4.22 Функция передачи информации в Siebel 52 4.23 Функция NBO в автоматическом режиме 53 4.24 Функция автоматической генерации УНК 53 4.25 Функция получения информации о наличии открытой сессии в Телебанке 54 4.26 Функция «отчетность в IVR» 55 4.27 Функция построения списка продуктов клиента 55 4.28 Функция «Получение сервисов по продуктам» 58 5 Принципы взаимодействия с внутренними системами банка 61 5.1 Принципы взаимодействия с Minerva 61 5.2 Принципы взаимодействия с WINGS 61 5.3 Принципы взаимодействия с MDM 61 5.4 Принципы взаимодействия с SONIC 61 6 Нефункциональные требования 62 6.1 Требования к информационной безопасности системы 62 6.2 Требования к масштабируемости 63 6.3 Требования к техническому обеспечению 63 6.4 Требования к документированию 63 6.5 Требования к резервированию и отказоустойчивости 64 7 Риски проекта 65 Приложение А Кейсы работы Системы 73 Приложение Б Требования к графическому пользовательскому интерфейсу 75 1 Описание интерфейса/программы. 75 1.1 Авторизация (опционально**) 75 1.2 Размеры окна программы и масштабируемость 76 1.3 Окна и диалоги 76 1.4 Многопользовательский режим 76 1.5 Применение изменений: 77 2 Обязательные функции программы. 77 2.1 Перезагрузка программы: 77 2.2 Журнал изменений 77 2.3 Возможность загрузки списков клиентов (черный/белый/спец.реестр и т.д.) 78 2.4 Статистика 78 2.5 Функция отправки SMS. 83 3 2.6 Хранилище звуковых сообщений. 83 2.7 Привязка звуковых сообщений. 83 2.8 «Черный/белый» список. 84 2.9 Функция «предобработки звонка». 86 3 Конфигурационные параметры. 87 3.1 Внешняя структура. 87 3.2 Первый уровень иерархии («DNIS/Сегмент»). 88 3.3 Второй уровень иерархии («регион»). 88 3.4 Третий уровень иерархии («Главное Меню»). 89 3.5 Четвёртый уровень и т.д. («пункт меню») 89 4 1 Введение 1.1 Назначение документа Назначением настоящего документа является описание общего архитектурного решения по проекту «Новое меню IVR», а также описание функциональных требований к новому динамическому IVR. 1.2 Полное наименование и условное обозначение системы Полное наименование системы: Автоматизированная система, реализующая функции динамического IVR для ОАО «ВТБ-24». Сокращенное наименование далее по тексту настоящего документа – Система. 1.3 Глоссарий Понятие Сокращение Определение понятия Банк, Заказчик ЗАО «ВТБ24» Исполнитель Разработчик Системы, определяемый в ходе конкурсных процедур на создание Системы Информационные системы банка ИС Банка Внутренне информационные системы банка хранящие в себе всю информацию о клиенте. Interactive Voice Response IVR Система интерактивного речевого взаимодействия, голосовое меню IVR Сервис Модель обслуживания Клиента в IVR Customer_IVR_ID Уникальный номер клиента, присваиваемый в IVR. База данных IVR БД IVR База данных IVR, которая должна быть создана в процессе реализации проекта и хранить в себе параметры необходимые для обработки звонка и сбора статистики. Клиент, Абонент Клиент или потенциальный клиент Банка, обратившийся по одному из номеров контактного центра Банка Клиент ДКО Клиент имеет «договор комплексного облуживания» и его номер занесен в системы банка и подтвержден самим клиентом 5 Понятие Сокращение Авторизация Определение понятия Предоставление доступа или прав на получение какой-либо информации после подтверждения определенных данных (номер телефона, УНК+пароль, Номер карты+пароль, Паспортные данные) Авторизация по номеру телефона Автоматическая авторизация Авторизация клиента в ИС банка, по номера телефона, с которого поступил вызов в контактный центр Авторизация по УНК+пароль УНК+пасс Авторизация клиента в ИС банка, после ввода УНК клиента и пароля Авторизация по номеру карты и паролю Карта+пасс Авторизация клиента в ИС банка, после ввода номера карты клиента и пароля Авторизация по Паспортным данным ПД (+ДР) Авторизация клиента в ИС банка, после ввода его паспортных данных (+даты рождения) Авторизационный центр АЦ Сервис Банка, осуществляющий процесс авторизации клиента в меню IVR Идентификация номера Определение принадлежности номера к сотовому оператору или к АТС (определение мобильности номера или принадлежности его к городскому типу) Идентификация кода региона Определение принадлежности номера к определенному региону по коду Контактный центр КЦ Контактный центр банка ВТБ24, занимающийся удаленной обработкой обращений клиентов (по телефону, по e-mail, по чату и т.д.) Уникальный номер клиента УНК Уникальный идентификатор клиента, необходимый для авторизации во внутренних системах банка. Центр обработки вызовов ЦОВ Центр обработки вызовов банка ВТБ24, занимающийся обработкой входящих/исходящих вызовов Calling Party Number CPN Номер вызывающего абонента Vector directory number VDN Добавочный номер на АТС, который переводит входящий вызов на заданный вектор DNIS Сервис, предоставляющий информацию о том, какой номер набирал вызывающий абонент DNIS_Group Группа DNIS, со схожими параметрами обработки но номинально разными входными точками. 6 Понятие Сокращение Определение понятия Телефонный номер КЦ Номер КЦ Пул номеров (пул DNIS), на которые маршрутизируются телефонные вызовы в приложение IVR (Систему) Ценность клиента Grade, Грейд Ценность Клиента, определенная Банком Контроль посылки вызова КПВ Акустический сигнал, который слышит Клиент после набора телефонного номера до ответа Системы Region Регион абонента (наименование региона, к которому относится номер вызывающего абонента) Avaya Программно-аппаратный комплекс, обеспечивающий техническое функционирование КЦ Банка Minerva Единый сервисный слой для доступа к различным банковским информационным системам Система мастер данных МДМ Система содержащая персональную информацию о клиенте (напрмер GRADE, наличие PIN и тд.) Гермес Система отвечающая за подключение СМС-нотификаций банка WINGS SMS портал Siebel CRM система Банка Телебанк Интернет-сервис дистанционного обслуживания Клиентов 1.4 Цель проекта / задачи Целью создания нового IVR является организация обработки входящих вызовов в автоматическом режиме с возможностью получения обратной связи от клиента. Бизнес-цели проекта представлены в таблице 1 Таблица 1 – Бизнес-цели проекта №. п. п. Бизнес-цель задачи 1 Сокращение времени ожидания ответа оператора путем повышения автоматизации в контактном центре 2 Повышение эффективности работы с клиентами банка, имеющими просроченную задолженность 7 Бизнес-цель задачи №. п. п. 3 Снижение затрат на обслуживание клиентов банка 4 Автоматизация процессов дистанционного обслуживания клиентов банка 5 Сбор статистической информации об обработке входящих вызовов в IVR 1.5 Функциональный обзор Требуется произвести разработку функциональности IVR, обеспечивающую: снижение затрат на телефонный трафик (уменьшение времени пребывания Клиента в IVR, сокращение длительности обслуживания вызовов операторами) за счет: оптимизации схемы маршрутизации звонков Клиентов Банка; создания «динамического IVR», обеспечивающего озвучивание клиенту только необходимой для него информации; создания более понятного для Клиента меню; уменьшения количества переходов для получения информации; повышение лояльности Клиентов Банка и востребованности ЦОВ, за счет улучшения качества сервиса самообслуживания Клиентов, которое достигается путем создания для Клиента Банка гибкой структуры меню, на основании персональных данных Клиента, выстраивания интуитивно понятной для Клиента схемы меню IVR; повышение эффективности работы с клиентами банка, имеющими просроченную задолженность, за счет разработки автоматической идентификации клиента по номеру телефона и разработки специализированного меню IVR для таких клиентов. 1.6 Требования к производительности и масштабируемости Время обработки запроса после момента передачи системе данных сервисом Банка не должно превышать 3 сек Система должна обеспечивать следующие нагрузочные характеристики: – средняя «штатная нагрузка» ~50000 звонков на IVR в сутки; – пиковая ~700000 в сутки, – пиковое одновременное подключение - 2000 входящих соединений 1.7 Требования к надежности Система должна работать в режиме 24/7/365 8 Система должна быть доступна 99,95 % времени (не более 1.1 часа недоступности системы в квартал при инцидентах) Должна быть реализована настройка timeout ожидания при обращении к внешним системам 1.8 Требования безопасности Система должна ограничивать несанкционированный доступ к персональным данным клиентов и сведениям, составляющим банковскую тайну, на основе карты ролей пользователей и в соответствии с политикой конфиденциальности Банка Пользователи банка, включая администратора прикладных систем не должны иметь административных прав на уровне системы и СУБД. Клиентская часть системы (АРМ пользователя) должна выполняться с правами, соответствующими правам непривилегированного пользователя в операционной системе и не требовать предоставления пользователю дополнительных прав в рамках операционной системы Система должна обеспечивать разграничения доступа внутренних пользователей на уровне ролей В Системе должна быть предусмотрена отдельная роль «Администратор безопасности», позволяющая проводить полный мониторинг действий клиентов и работников банка (с помощью механизма аудита) В целях обеспечения безопасности в Системе должен быть реализован следующий функционал: – – Защита от типовых уязвимостей DDoS и пр. Обеспечение защиты клиентских данных В системе должен быть реализован гибкий механизм аудита, включая полный аудит действий пользователя. Должны использоваться следующие инструменты аудита: журнал аудита, журналирование действий клиента (трекинг, формирование отчетов Необходимо протоколировать не только действия клиентов, но действия внутренних пользователей Банка, включая действия администратора, согласно списку событий, утвержденному ВТБ24 Система должна обеспечивать настройку полноты протоколирования Протоколы должны быть защищены от изменений Глубина хранения информации для целей аудита составляет 1 год 1.9 Требования к версионности ПО Система должна поддерживать возможность работы со своими версиями 9 Система должна вести архив всех своих версий, администратор должен иметь возможность просмотреть детали по каждой из версий В работе с версиями системы должна быть возможность возврата к предыдущим версиям, используя систему контроля версий Наличие встроенных возможностей по резервному копированию и восстановлению текущей конфигурации системы Система должна предоставлять возможность определения текущей версии 1.10 Требования к информационному обмену с внешними системами Система должна быть интегрирована с более чем одним сервисным слоем банка (HTTP SOAP либо JMS XML) 1.11 Требования к администрированию В системе должна быть предусмотрена возможность доступа к информации по показателям использования системы, оперативной отчетности системы В системе должно быть предусмотрено наличие средств мониторинга производительности и сбора метрик производительности KPI системы В системе должны присутствовать средства контроля работоспособности: В случае, если один из узлов вышел из строя, Система должна автоматически послать сообщение на электронный адрес в соответствии с настройками системы Система должна обеспечивать архивирование устаревших данных 10 2 Архитектурное решение 2.1 Текущая архитектура решения Текущая логическая архитектура используемых компонентов решения, в рамках функционирующего контактного центра, представлена на рисунке 1. Рисунок 1 – Текущая архитектура целевого контактного центра Исполнитель должен предложить и согласовать целевую архитектуру Системы с Заказчиком. Целевая архитектура должна быть разработана на этапе формирования ТЗ. 2.1 Описание БД В рамках реализации проекта и проработки целевой схемы, в архитектуре решения должна быть проработана БД, которая будет содержать в себе следующую информацию: 1. Данные полученные из внутренних ИС банка (алгоритм наполнения будет согласован дополнительно на этапе реализации проекта); 2. Данные полученные в процессе работы с IVR; 3. Данные необходимые для построения дерева IVR; 4. Данные необходимые для авторизации клиента как внутри IVR так и во внутренних ИС банка; 5. Статистические данные по работе клиента а также супервизоров системы (подробные требования описаны в GUI IVR см. Приложение Б) 11 Требования и схема к целевой архитектуре должны быть предоставлены на этапе формирования ТЗ. 2.1.1 Требования к БД Структура БД должна в максимальной степени соответствовать сценариям обслуживания IVR, в том числе – максимально быстрому поиску учетной записи по номеру телефона. В локальном хранилище должна быть следующая информация: – Уникальный идентификатор клиента, – Фамилия – Имя – Отчество – Дата рождения – Пол клиента – Серия и номер паспорта – Признак наличия ПИН-кода – телефоны и их типы (ДКО, СМС Нотификации). Информация о сегменте клиента – – Доходность и Признак привилегированного обслуживания; В качестве идентифицирующей информации на стороне IVR должен использоваться локальный ID учетной записи клиента в IVR (IvrClientID). Создание, обновление и удаление персональных клиентских данных в БД системы IVR должно обеспечиваться посредством публикации данных из системы МДМ. Т.е. IVR должна обеспечить реализацию программных сервисов создания, изменения и удаления учетных данных клиента в соответствии с рекомендациями УСБС в части интеграции с конечными системами. Режим работы программного сервиса IVR – синхронный вызов веб сервиса. Не допускается хранения на уровне локального хранилища системы IVR других ID, кроме IvrClientID. Система IVR должна реализовать сервис пакетного обновления информации в БД о наличии/отсутствии виртуального ПИН-а. Процесс обновления должен учитывать, что у клиента может быть несколько карт и соответственно по каждой карте может быть информация о ПИН-е. Сначала необходимо обновлять информацию об удалении ПИН-а (сброс признака в БД IVR), затем о наличии ПИН-а (установка признака в БД IVR). Признак Наличия NBO, признак Должник и информация о пакете нотификации не будет сохраняться в БД IVR, а будет получаться on-line сервисами Минервы. 12 3 Ограничения реализации и дизайна (Подробное писание к интерфейсу IVR и статистике см.приложение Б.) 1) Функциональность и принципы навигации IVR, не описанные в настоящем документе, остаются без изменений или не входят в рамки данного проекта. 2) По всему реализованному в IVR функционалу и пунктам меню должен быть обеспечен сбор соответствующей статистики. 3) Изменение параметров работы Системы и её функций производится путем изменения соответствующих параметров и настроек в модуле управления ПО IVR; все вносимые и корректируемые параметры и настройки ПО должны приниматься и применяться в работу без перезагрузки и недоступности сервисов Системы. 4) Все пункты нового меню IVR должны быть настраиваемыми на стороне Банка (включение / отключение функционала), настройка пунктов меню, необходимая Банку. 5) Для всех уровней меню, для каждого пункта в отдельности должна иметься возможность установки / замены / удаления отдельного звукового файла, этот параметр должен быть настраиваемым на стороне Банка. 6) Для всех уровней меню должна быть реализована возможность установки / замены / удаления рекламно-информационных сообщений до или после получения клиентом персональной информации. Данная возможность должна быть реализована в любом из пунктов меню на стороне банка. 7) Для всех уровней меню, для каждого пункта в отдельности должна быть возможность определения действия, которое будет предпринято, если Клиент не совершил никакого выбора в меню/выбрал несуществующий пункт меню/ввел некорректное значение (с возможностью настройки количества повторов информатора совершить выбор / действие в меню). 8) Для всех сервисов и функций, осуществляющих интеграцию (запросы во внешние системы либо двустороннее взаимодействие), Система должна обеспечивать логирование процесса интеграции. 9) Для всех уровней меню, для каждого пункта в отдельности должна быть возможность установки звуковых файлов на разных языках: русский и английский. 10) Тайм-ауты ожидания действия Клиента должны быть настраиваемыми на стороне Банка в пределах от Х до Y секунд. Значение по умолчанию 5 секунд. 11) Назначение клавиш: # - повтор, * - выход наверх, 0 – выход на оператора, возможность перехода в «главное меню» - 9 (с возможность редактирования назначения клавиш). 12) В системе должны быть предусмотрены настраиваемые параметры time-out для внутренних ИС банка. По истечении которых, должно проигрываться дефолтные сообщения. 13 4 Функциональные требования 4.1 Общие требования 4.1.1 Общие требования к функциональности системы 4.1.1.1 Система должна предоставлять визуальный интерфейс управления и конфигурирования меню IVR. 4.1.1.2 Система должна предоставлять пользователю управление через Webинтерфейс. 4.1.1.3 Графический интерфейс Системы должен предоставлять Заказчику следующие возможности: 4.1.1.3.1 Разработка / редактирование Сервисов IVR. 4.1.1.3.2 Разработка / редактирование пунктов меню IVR. 4.1.1.3.3 Размещение / прослушивание голосовых роликов. 4.1.1.3.4 Администрирование справочников, доступных в Системе. 4.1.1.3.5 Создание и редактирование шаблонов SMS для отправки из меню IVR. 4.1.1.3.6 Настройка модели обслуживания (настройка Критериальной модели) в зависимости от данных о Клиенте, полученных от Функций Системы; 4.1.1.3.7 Настройка принципов маршрутизации вызова(ов) в очередь к группе операторов зависимости от данных о Клиенте, полученных от Функций Системы. 4.1.1.4 Управление системой должно обеспечиваться пользователем с базовым уровнем подготовки – «Пользователь ПК». Все операции по созданию / изменению деревьев IVR, включение / отключение функционала должны производиться при помощи графического пользовательского интерфейса с учетом современных подходов к WEB дизайну и эргономики. 4.1.1.5 Требования к основным функциям и возможностям графического интерфейса представлены в Приложение Б. 4.1.1.6 Система должна реализовывать возможность одновременной работы нескольких деревьев IVR. 4.1.1.7 Для каждого дерева IVR Система должна предоставлять возможность: построения разветвленного голосового меню; перевода вызова на любой телефонный номер из любого пункта дерева IVR; перехода вызова из любого пункта на вышестоящий пункт, на любой другой пункт либо на начало главного меню дерева IVR. 4.1.1.8 Система должна обеспечивать вступление в силу всех изменений в деревьях IVR без необходимости перекомпиляции или перезапуска каких-либо сервисов. 14 4.1.1.9 Перед активацией версии дерева IVR Система должна обеспечивать возможность проверки этого дерева IVR на тестовых вызовах. 4.1.1.10 Система должна иметь возможность проверки нарушения логики построения меню IVR: 4.1.1.10.1 При возникновении логических ошибок при построении меню IVR Система должна сообщать пользователю об ошибке. 4.1.1.10.1.1 Перечень логических ошибок и критериев проверки должны быть описаны при формировании технического задания. 4.1.1.10.2 Проверка меню IVR на логические ошибки должна осуществляться Системой при редактировании IVR в момент сохранения изменений. 4.1.1.11 Система должна предоставлять возможность обработки ошибок ввода или бездействия клиента для каждого меню выбора в IVR. 4.1.1.11.1 При выборе несуществующего пункта меню Система должна озвучивать сообщение об ошибке ввода и повторно озвучивать меню для выбора. 4.1.1.11.2 Система должна предоставлять возможность настройки количества ошибок выбора пункта меню для каждого меню выбора в IVR. 4.1.1.11.3 Система должна предоставлять возможность настройки тайм-аута ожидания выбора клиента для каждого меню выбора в IVR. 4.1.1.11.4 Система должна предоставлять возможность настройки логики обработки вызовов с допущенными ошибками ввода и/или тайм-аутами ожидания ввода. 4.1.1.12 Для всех пунктов меню IVR, в которых озвучивается персональная информация или производятся действия с персональной информацией, после озвучивания такой информации или успешной операции с персональной информацией, Система должна позволять настраивать дальнейший сценарий обработки вызова: возврат в последнее меню, в котором Клиенту предлагался выбор, принудительное завершение вызова, маршрутизация на группу Операторов, отправка СМС сообщения и т.д. 4.1.1.13 Во всех пунктах меню Система должна предоставлять возможность озвучивать звуковое рекламное и/или информационное сообщение. 4.1.1.13.1 Данная возможность (её параметры и логика использования) должна быть настраиваема в каждом конкретном пункте в отдельности с помощью настроек через графический пользовательский интерфейс. 4.1.1.13.2 Система должна иметь возможность добавления рекламного и/или информационного сообщения для любого пункта меню IVR. 4.1.1.14 Система должна реализовывать следующие функции (Таблица 2): 15 Таблица 2 – Функции Системы № п. п. 1 Группа функций Определение параметров Клиента Наименование Функции Системы Функция проверки «звонок с мобильного» Функция автоматического определения региона клиента Функция проверки DNIS Функция определения Grade Функция определения наличия клиента в 16 № п. п. Группа функций Наименование Функции Системы Функция определения наличия клиента в белом списке 4.1.2 Общее описание 4.1.2.1 Функция определения наличия клиента в белом списке предназначена для предоставления клиенту специальной модели обслуживания. 4.1.2.2 Функция определения наличия клиента в белом списке должна иметь возможность включения Клиента в белый список. 4.1.2.2.1 Система должна предоставлять возможность настройки сценариев обслуживания в зависимости от наличия Клиента в белом списке. 4.1.2.3 Система должна проверять наличие клиента (номера) на вхождение в белый список в процессе предварительной обработки вызова. 4.1.2.4 Функция определения наличия клиента в б списке должна позволять использовать информацию о наличии Клиента в одном из специальных списков всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.1.2.5 В один момент времени клиент может находиться только в одном списке (белом или черном). 4.1.3 Требования к входным данным 4.1.3.1 Входные данные для Функции определения наличия клиента в белом списке – CPN. 4.1.4 Конфигурация функции 4.1.4.1 Данный параметров раздел описывает 17 № п. п. Группа функций Наименование Функции Системы Error! Reference source not found. Error! Reference source not found. 18 № п. п. Группа функций Наименование Функции Системы Функция «выхода на персонального финансового консультанта (ПФК)» 4.2.5 Общее описание 4.2.5.1 Данная функция предназначена для обслуживания VIP клиентов за которыми закреплен ПФК. 4.2.5.2 Информация о том, имеет ли Клиент персонального финансового консультанта (ПФК) должна храниться в БД IVR. 4.2.5.2.1 Система должна хранить два параметра по которым возможно определить необходимость специального обслуживания Клиента, а также наличие у данного Клиента ПФК (Таблица 5): Таблица 5 – Параметры для определения ПФК Клиента Наименование параметра Описание параметра «Привелегия_NEW» Параметр, определяющий предоставления специального Принимает значения «1» / «0» (и Признак (значение) PFK Параметр, хранящий внутренни оператора в системе Avaya In ПФК Клиента 4.2.5.3 Система должна осуществлять поиск параметров Функции «Выход на ПФК» для только при попытке соединения с оператором. 4.2.5.4 Реализация функции должна быть дополнительно проработана на этапе формирования ТЗ. 4.2.6 Ограничения функции Наличие у клиента пакета 19 № п. п. Группа функций Наименование Функции Системы Функция получения информации о наличии открытой сессии в Телебанке Функция анализа признака «повторный звонок» 2 Идентификация и авторизация Клиента Функция автоматической идентификации *После прохождения процедуры автоматической идентификации клиента, система должна аутентифицировать клиента в ИС банка, данный алгоритм должен иметь возможность включения/выключения на стороне IVR. Если алгоритм включен система делает это в фоном режиме во время построения меню IVR. Если алгоритм выключен система аутентифицирует клиента только в момент выбора пункта меню требующего обращения к ИС банка. Функция ручной Функция ввода паспортных данных клиента 3 Персональное приветствие Функция приветствия клиента по времени суток (Главное меню IVR) 5 Маршрутизация на операторов Функция повторного соединения с оператором Функция соединения с ПФК 6 Предоставление сервисов в IVR Функция получения статуса заявки Функция формирования SMS из IVR Функция Управление пакетом SMS-нотификации Функция NBO в автоматическом режиме Функция автоматической генерации УНК Error! Reference source not found. Функция построения списка продуктов клиента Функция «Получение сервисов по продуктам» 7 Сохранение статистики и передача параметров во внешние системы Функция передачи информации в Siebel Функция «отчетность в IVR» 20 4.2.7.1 Система должна иметь возможность передачи информации о результатах работы функции («выходные» параметры функции) в Операторское приложение (siebel), если иное не указано в описании соответствующей функции. 4.2.7.1.1 Список параметров, необходимых для передачи из Системы в Операторское Операторское приложение, представлен в Таблице 3: №. п. п. Название Описание Пример передаваемого значения 1 ivr_history Узел IVR, из которого переведено обращение BKO_Oper 2 acd_split Телефонный номер Hunt-группы 07510 3 IVR_ID Уникальный номер клиента присвоенный в IVR (только для однозначно определенных клиентов) 123456ivr 4 client_contract_number Номер последнего CIM-объекта, по которому была озвучена информация 4483460548249252 5 client_number Идентификатор клиента (телефонный номер) 559356 6 client_system_id Идентификатор системы 4GCIF 7 error_message Текст сообщения об ошибке Таймаут ввода 8 сard_number Номер карты клиента 1111222233334444 9 personal_data Персональная информация о клиенте (ПД+ДР) 1111 222222 ddmmyyyy 4.2.7.1.2 Список параметров может быть уточнен Банком в процессе формирования технического задания. 4.2.7.2 Система должна иметь возможность настройки порядка и необходимости запуска Функций, перечисленных в п. 4.1.1.14, в общей модели обслуживания Клиента в IVR. 4.2.7.2.1 Порядок запуска функций и сервисов должен настраиваться через графический интерфейс Системы по принципу «конструктора», т.е. каждая функция должна являться блоком, порядок исполнения которого может быть определен путем перемещения этого в соответствующей модели обслуживания (в любую точку/узел схемы IVR). 21 4.2.7.3 Система должна поддерживать несколько уровней (настраивается Банком) авторизации Клиента в IVR. 4.2.7.3.1 По умолчанию Система должна поддерживать следующие типы авторизации для Клиента (подробное описание авторизации см. Функция Авторизации): Анонимный клиент – информации о номере с которого обращается клиент, нет ни в одной из систем банка; Серый клиент – условно авторизованный клиент имеющий доступ к узкому списку функций с персональной информаций; Белый клиент – однозначно авторизованный (например по УНК+Пароль или номер ДКО) клиент имеющий полный доступ к персональной информации; 4.2.7.3.2 Система должна позволять предоставлять различную персональную информацию в IVR в зависимости от типа авторизации. 4.2.7.3.3 Параметры для авторизации Клиента описаны в п. 4.11, п. 0. 4.2.7.3.4 Система должна предоставлять возможность выбора схемы наследования прав предоставления информации для типа авторизации. Например, если Клиент авторизован с типом авторизации «Белый клиент», он должен иметь возможность получения любых сервисов «Серого клиента» без необходимости дополнительной процедуры авторизации. 4.2.7.4 Система должна иметь возможность выбора схемы авторизации каждого пункта IVR, предоставляющего персональную информацию: 4.2.7.4.1 Система должна предоставлять для выбора одну из следующих схем авторизации: схема автоматической авторизации (требования указаны в п. 4.11); одна из схем авторизации, созданная в п. 0. 4.2.7.4.2 Клиент должен получать персональную информацию в IVR только успешно успешно выполнив процедуру авторизации в предложенной схеме. 4.2.7.4.3 Система должна иметь возможность назначения альтернативной схемы авторизации для блока с персональной информацией. Например: Предоставление Клиенту информации об остатке по его счету возможно как после успешного ввода УНК+Пароль, так и после успешного ввода Номера карты+Пароль. 4.2.7.5 Система должна предоставлять Клиенту персональную информацию в IVR только после обязательной проверки возможности получения персональной информации в IVR. 4.2.7.5.1 Проверка должна производиться Функцией определения возможности получения персональной информации – подробнее описание функции представлено в п. 4.8. 22 4.2.7.6 При любой обработки данных клиента, где требуется ввод номера карты (НК), система должна производить проверку корректности ввода карты не только на количество символов (=16), но и по стандарту «Luna». Для минимизации ошибочных запросов в системы банка. 4.2.8 Общее описание прохождения вызова через IVR 4.2.8.1 Данный раздел описывает общий процесс работы Нового меню IVR при поступлении входящего вызова по телефонным номерам КЦ Банка для получения справочной или персональной информации клиентом или потенциальным клиентом Банка. 4.2.8.2 Общий процесс обслуживания Клиента должен состоять из следующего набора логических блоков: – В момент поступления звонка система должна проверять номер на соответствие требуемому формату («маскам»). Например: звонок поступающий из России может иметь вид типа «+7(916)746 12 34», где: +7 – код страны; 916 – код оператора; 746 12 34 – номер клиента. Система должна обеспечивать преобразование номера к международнопринятым форматам. определение параметров Клиента в том числе автоматическая авторизация); запрос карточки Клиента (в процессе приветственного сообщения); построение IVR на основе полученной информации; предоставление сервисов, предложенных Клиенту в рамках предоставленного персонального IVR. 4.2.8.3 Каждый входящий вызов на телефонный номер КЦ Банка должен быть обслужен в соответствии со следующей логической схемой (рисунок 2 - Рисунок 4). 23 Предобработка звонка white Enter/dnis region Начало предобработки Определение DNIS Определение “white” Опред елен? нет Добавление Attach_data: “white=0” БД white да Добавление Attach_data: “white=1” Добавление Attach_data: “DNIS=XX” Переход в этап определение region. Опред елен? да Определение Моб./Фикс. REGION Добавление Attach_data: “region=not_rus” Переход в этап определение mob./fix. Возможные исходы: 1. “white” = 1/0 2. “DNIS” = XX 3. “Region” = 1~99 4.”mob” = 1/0 5. “GRADE” = 1~8 6.”trust” = 0~3 да(fix) да(mob) grade trust Определение GRADE Определение уровня доверия Добавление Attach_data: “GRADE=XX” Добавление Attach_data: “TRUST=XX” нет да (not_rus) Добавление Attach_data: “region=XX” БД DEF/ABC Опред елен? нет Добавление Attach_data: “region=unknown” Добавление Attach_data: “mob=1” Переход в этап определение grade Этап Переход в этап определение region. БД DNIS Определение региона абонента mob./fix. Только для абонентов имеющих признак «Mob=1» и «Reg=XX»; Остальные звонки идут на этап «END» Рисунок 2 – Пример алгоритма предварительной обработки звонка. Добавление Attach_data: “mob=0” Переход в этап определение trust Зав пред 24 Вход Grade := Null CPN определен? да Использование таблицы «GRADE» вкл.? нет DNIS? да Запрос GRADE В таблице «GRADE» нет GRADE Определен? да Grade := null Grade := Gradegrade Grade := Graddnis Вход Рисунок 3 – Пример алгоритма определения Grade 25 БД1 Вход/начало функции Проверка номера на принадлежность к «ДКО» (система MDM) да Номер ДКО? да «1» Номер есть в Гермесе нет «0» Пакет нотификации «Зарплатный»? да «3» Выход/завершение функции Виды приоритета: «1» - Однозначно определен в MDM; «3» - Нет в MDM + Пакет нотификации =«зарплатный»; либо Пакет != «зарплатный», но номер привязан к нескольким счетам; «2» - Нет в MDM + Пакет нотификации !=«зарплатный»; «0» - Номера нет в системах банка; нет Проверка номера на наличии «SMSнотификации» (система Гермес) БД2 да Номер уникальный да нет «2» Рисунок 4 – Пример алгоритма определения уровня доверия 26 4.2.8.4 Блок определения параметров Клиента в процессе КПВ должен включать в себя выполнение ряда Функций Системы. Данная информация формируется только на основание CPN клиента и не затрагивает персонализированную информацию. По результатам исполнения данного блока Система получать следующую информацию о Клиенте (Таблица 3). На основании этих данных система может строить первый уровень дерева IVR, который может быть доступен всем клиентам (дефолтное). Таблица 3 – Параметры Клиента, полученные при предварительной обработке звонка Параметр № п. п. 1 Наличие в специальных реестрах Функция-источник информации Функция ЧС и БС (черный; белый списки) 2 DNIS, DNIS-Group Функция проверки DNIS 3 Регион / Страна Функция автоматического определения региона клиента 4 Язык Функция автоматического определения региона клиента 5 Тип абонента Функция проверки «звонок с мобильного» (мобильный; стационарный) 6 Grade Функция определения Grade 27 4.2.8.5 После формирования дефолтного дерева (п.4.1.2.4) и одновременно с озвучиванием приветствия система обращается к внутренней БД, для формирования персонифицированной структуры IVR. Набор параметров, которые система может получить на данном этапе, приведен в таблице 4. Данная информация служит для построения более детального меню IVR. Таблица 4 – Параметры карточки Клиента Параметр № п. п. Функция-источник информации 1 IVR_ID Функция автоматической идентификации 2 Запрет получения персональной информации Error! Reference source not found. 3 Наличие VIP пакета + логин ПФК Функция «Соединение с ПФК» (внутренняя БД) 4 Уровень авторизации Функция автоматической идентификации 5 NBO Функция NBO в автоматическом режиме 6 PIN Функция «безбумажный PIN» Комментарий Уникальный идентификатор Клиента во всех банковских Системах. Заполняется при идентификации Клиента: либо однозначной автоматической, либо посредством ручной авторизации Информация о специальных предложениях, которые должны быть предложены Клиенту (по имеющимся данным, полученным о Клиенте при КПВ) 4.2.8.5.1 Список параметров может быть уточнен/дополнен Банком в процессе формирования технического задания. 28 4.2.8.6 После завершения предыдущего этапа (4.1.2.5) система начинает процесс автоматической аутентификации (по номеру телефона) клиента и в случае успешности достраивает максимально персональное меню для данного клиента. Пример набора параметров полученных в процессе обработки этапа 4.1.2.6 приведен в таблице 5 № п. п. Параметр Функция-источник информации 1 Список продуктов банка Функция построения списка продуктов клиента 2 Открытая сессия в ТБ Функция получения информации о наличии открытой сессии в Телебанке 3 Наличие в списке должников Функция получения данных о просроченной задолженности 4 Запрос баланса (для аутентификации по номеру нотификации) Функция получение сервисов по продуктам 4.2.8.6.1 Параметры карточки Клиента могут быть заполнены не полностью, в зависимости от информации, полученной от Функций Системы. 4.2.8.6.2 Параметры карточки Клиента могут дополняться в процессе предоставления Клиенту запрошенных сервисов (в случае выбора пункта меню, в котором потребуется ручная авторизация). 4.2.8.6.3 В случае если автоматическая аутентификация для данного клиента не выполнена, система достраивает дополнительную ветку которая будет позволять пройти «ручную идентификацию» 4.2.8.7 В случае если запрос карточки Клиента и Построения персонального меню IVR по общей длительности превышает длительность озвучиваемого приветствия, Система должна предоставить схему обслуживания «по умолчанию» для региона, полученного в блоке определения параметров в процессе КПВ. 4.3 Функция проверки «звонок с мобильного» 4.3.1 Общее описание 4.3.1.1 Функция проверки «звонок с мобильного» предназначена для определения типа телефонного номера Клиента, обратившегося в КЦ Банка. 4.3.1.2 В рамках реализации функции проверки «звонок с мобильного» должен быть разработан алгоритм, который будет идентифицировать входящий номер по признаку городской / мобильный. 29 4.3.1.3 Функция проверки «звонок с мобильного» должна позволять использовать информацию о типе номера (городской / мобильный) всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.3.1.4 В случае невозможности определения типа номера (городской / мобильный) Система выставляет такому клиенту статус «unknown_type» и виртуальный код региона (например «777»). 4.3.2 Требования к входным данным 4.3.2.1 Входные данные для Функции проверки «звонок с мобильного» – CPN. 4.3.3 Конфигурация параметров функции 4.3.3.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.3.3.1.1 Включение / отключение мобильный / городской номер. идентификации номера по признаку 4.3.4 Описание работы функции 4.3.4.1 Работа функции должна состоять из следующих логических действий: 4.3.4.1.1 Система проверяет, включен или отключен функционал проверки «звонок с мобильного». 4.3.4.1.1.1 Если функционал отключен, работа Функции завершается, и процесс прохождения Клиента в IVR продолжается согласно общей схеме прохождения вызовов в IVR. 4.3.4.1.2 Система идентифицирует CPN (входящий номер абонента) по типу городской / мобильный. 4.3.4.1.3 При успешном завершении работы Функции проверки «звонок с мобильного», Система имеет следующие данные о телефонном обращении: тип телефонного номера Клиента: городской или мобильный. 30 4.4 Функция автоматического определения региона клиента 4.4.1 Общее описание 4.4.1.1 Функция автоматического определения региона клиента предназначена для определения региона обращения на Телефонные номера КЦ в целях построения меню IVR разработанное для данного региона. 4.4.1.2 Функция автоматического определения региона клиента должна определять регион при поступлении обращения на Телефонные номера КЦ как с мобильного телефона, так и со стационарного телефона. 4.4.1.3 Функция автоматического определения региона клиента должна иметь возможность определения страны: «звонок из России», «Звонок из СНГ» или «звонок не из России». Каждая из этих подгрупп должна иметь возможность настраиваться на стороне IVR. 4.4.1.4 Функция автоматического определения региона клиента должна определять язык предоставления информации для Клиента в IVR (русский или английский). 4.4.1.5 На основании данных полученных от данной функции, клиенту должна быть предоставлена возможность производить смену языка в меню IVR. 4.4.1.6 Функция автоматического определения региона клиента должна позволять использовать информацию о регионе и типе номера (городской / мобильный), языке предоставления информации всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.4.1.7 В случае невозможности определения региона Система должна выставлять такому клиенту статус «unknown_reg» и виртуальный код региона (например «777»). 4.4.2 Ограничения функции 4.4.2.1 Функция автоматического определения региона клиента должна определять на основании ABC, DEF-кода CPN Клиента. 4.4.2.2 Для определения региона, в Системе должен быть реализован справочник, содержащий коды (DEF, ABC) в привязке к региону. 4.4.2.3 Для определения кода страны, должен быть реализован справочник. 4.4.2.3.1 Редактирование справочника должно осуществляться администратором Системы. 4.4.2.3.2 Должна быть предусмотрена возможность импорта кодов (DEF, ABC) в Систему, в формате, определенным в соответствии с информацией с сайта Россвязи или других аналогов (Пример: http://www.rossvyaz.ru/activity/num_resurs/registerNum/). 4.4.2.3.3 Импорт справочника должен осуществляться Т.е. администратор Системы должен предварительно скачивать информацию о соответствии кодов региону с сайти Россвязи (в виде структурированного файла) и далее, производить обновление справочника в Системе, указывая путь к актуальному структурированному файлу. 31 4.4.2.4 Для определения языка предоставления информации в IVR, в Системе должен быть реализован справочник, содержащий коды (DEF, ABC), для которых IVR должен быть англоязычным. 4.4.2.4.1 Редактирование справочника должно осуществляться администратором Системы. 4.4.3 Требования к входным данным 4.4.3.1 Входные данные для Функции автоматического определения региона клиента – CPN. 4.5 Функция проверки DNIS 4.5.1 Общее описание 4.5.1.1 Функция проверки DNIS предназначена для определения номера, который набирал Клиент. 4.5.1.2 Функция определения DNIS должна определять телефонный номер КЦ Банка, набранный Клиентом. 4.5.1.3 Функция определения DNIS должна позволять использовать информацию о набранном номере всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.5.1.4 Система должна иметь возможность агрегировать номера DNIS в DNIS-Group. 4.5.1.4.1 Администрирование Администратору Системы DNIS-Group должно быть доступно только 4.5.2 Ограничения функции 4.5.2.1 Функция проверки DNIS должна быть реализована средствами оборудования Avaya. 4.6 Функция определения Grade 4.6.1 Общее описание 4.6.1.1 Функция определения Grade предназначена для определения статуса Клиента в целях предоставления необходимой модели обслуживания. 32 4.6.1.2 Функция определения Grade должна хранить данные о грэйде каждого Клиента Банка в справочнике (БД IVR) Системы. 4.6.1.2.1 Периодичность автоматического обновления справочника GRADE должна настраиваться Банком (по умолчанию это 1 месяц). 4.6.1.2.2 Функция определения Grade должна иметь возможность выполнять синхронизацию по запросу администратора системы (т.е. «вручную»). 4.6.1.3 Полученное значение грэйда клиента, должно использоваться всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.6.2 Требования к входным данным 4.6.2.1 Входные данные для Функции определения Grade – CPN. 4.6.3 Конфигурация параметров функции 4.6.3.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.6.3.1.1 Включение / отключение Функции определения Grade. 4.6.3.1.2 Настройки параметров обновления таблицы GRADE из внутренних ИС банка. 4.6.4 Описание работы функции 4.6.4.1 Работа функции должна состоять из следующих логических действий: 4.6.4.1.1 Система проверяет, включен или отключен функционал определения Grade. Если функционал отключен, работа Функции завершается и процесс прохождения Клиента в IVR продолжается согласно общей схеме прохождения вызовов в IVR. 4.6.4.2 Система запрашивает во внутренней БД банка GRADE клиента. 4.6.4.3 Система определяет регион Клиента. 4.6.4.4 Если запрос информации из БД не доступен: возник сбой / тайм-аут – работа Функции определения Grade завершается, и процесс прохождения Клиента в IVR продолжается согласно общей схеме прохождения вызовов в IVR. 4.6.4.5 При успешном завершении работы Функции определения Grade, Система имеет следующие данные о телефонном обращении: GRADE Клиента . 33 4.7 Функция определения наличия клиента в черном списке 4.7.1 Общее описание 4.7.1.1 Функция определения наличия клиента в черном списке предназначена для ограничения возможности выхода на оператора. 4.7.1.2 Функция определения наличия клиента в черном списке должна иметь возможность включения Клиента в один черный список. 4.7.1.2.1 Система должна предоставлять возможность настройки обслуживания в зависимости от наличия Клиента в черном списке. сценариев 4.7.1.3 Система должна проверять наличие клиента на вхождение в черный список только при попытке соединения с оператором. 4.7.1.4 Функция определения наличия клиента в черном списке должна позволять использовать информацию о наличии Клиента в одном из специальных списков всеми функциями Системы в рамках одной сессии (самообслуживание в IVR). 4.7.1.5 В один момент времени клиент может находиться только в одном списке (белом или черном). 4.7.2 Требования к входным данным 4.7.2.1 Входные данные для Функции определения наличия клиента в черном списке – CPN. 4.7.3 Конфигурация параметров функции 4.7.3.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.7.3.1.1 Включение / отключение функционала определения наличия Клиента в черном списке. 4.7.3.1.2 Справочник со списком клиентов. 4.8 Функция определения наличия клиента в белом списке 4.8.1 Общее описание 4.8.1.1 Функция определения наличия клиента в белом списке предназначена для предоставления клиенту специальной модели обслуживания. 4.8.1.2 Функция определения наличия клиента в белом списке должна иметь возможность включения Клиента в белый список. 34 4.8.1.2.1 Система должна предоставлять возможность обслуживания в зависимости от наличия Клиента в белом списке. настройки сценариев 4.8.1.3 Система должна проверять наличие клиента (номера) на вхождение в белый список в процессе предварительной обработки вызова. 4.8.1.4 Функция определения наличия клиента в б списке должна позволять использовать информацию о наличии Клиента в одном из специальных списков всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.8.1.5 В один момент времени клиент может находиться только в одном списке (белом или черном). 4.8.2 Требования к входным данным 4.8.2.1 Входные данные для Функции определения наличия клиента в белом списке – CPN. 4.8.3 Конфигурация параметров функции 4.8.3.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.8.3.1.1 Включение / отключение функционала определения наличия Клиента в белом списке. 4.8.3.1.2 Справочник со списком клиентов. 4.9 Функция проверки наличия PIN 4.9.1 Общие описание 4.9.1.1 Функция проверки наличие PIN предназначена для предоставления клиенту в автоматическом режиме нового PIN кода для его карты. 4.9.1.2 Функция проверки наличия PIN должна хранить данные о наличии PIN в БД IVR. 4.9.1.3 Функция проверки наличия PIN должна фиксировать факт озвучивания информации по PIN клиенту. 4.9.2 Требования к входным данным 4.9.2.1 CPN клиента. 35 4.9.3 Ограничения функции 4.9.3.1 В случае если PIN код карты уже был озвучен клиенту ранее, система не должна давать возможность запрашивать его еще раз. 4.9.4 Описание работы функции 4.9.4.1 Клиент звонит в IVR ВТБ24. 4.9.4.2 Система идентифицирует клиента. 4.9.4.3 Система проверяет наличие у клиента признака «наличие PIN». 4.9.4.4 Если признак у клиента присутствует, система строит для данного клиента дополнительную ветку IVR. 4.9.4.5 Если клиент выдирает данный пункт меню система отправляет запрос во внутренние системы банка с целью аутентификации клиента и получения информации о «виртуальном PIN» (помимо передачи номера телефона, как основного идентификатора, необходимо предусмотреть возможность донабора доп.параметров). 4.9.4.6 Система получает ответ от ИС банка с PINом клиента и озвучивает его. 4.9.4.7 Система снимает пометку в БД, для данного клиента, о наличии PIN. 4.10 Функция получения данных о просроченной задолженности 4.10.1 Общее описание 4.10.1.1 Функция получения данных о просроченной задолженности предназначена информирования клиента о его кредитных задолженностях перед банком. 4.10.1.2 Система должна иметь возможность настройки специального сценария обслуживания (например, перевод на отдел по работе с просроченной задолженностью) в случае обнаружения Клиента в списке должников. 4.10.2 Требования к входным данным 4.10.2.1 Входные задолженности – CPN. данные для Функции получения данных о просроченной 36 4.10.3 Конфигурация параметров функции 4.10.3.1 Включение / отключение функционала определения наличия Клиента в должников. 4.11 Функция автоматической идентификации/аутентификации 4.11.1 Общее описание 4.11.1.1 Функция автоматической идентификации Клиента предназначена для идентификации Клиента по номеру телефону (CPN). 4.11.1.2 Функция автоматической идентификации должна позволять идентифицировать Клиента, обратившегося в КЦ Банка с мобильного телефона, который был внесен в ИС Банка, как валидный номер 4.11.1.2.1 Возможны несколько вариантов валидности: Номер уникальный (ДКО) Номер уникальный (Гермес) нотификация зарплатная; Номер уникальный (Гермес) нотификация коммерческая; Номер не уникальный (Гермес) нотификация зарплатная; 4.11.1.2.2 Информация для автоматической идентификации Клиента содержится в БД IVR, но аутентификация должна производиться во внутренних ИС банка. 4.11.1.3 Функция автоматической идентификации должна выполнять запрос в БД IVR с целью поиска клиента по CPN (Определение ID клиента) и определения уровня идентификации. 4.11.1.4 Алгоритм определения уровня автоматической идентификации / аутентификации: 1. Данный алгоритм реализует процесс автоматической идентификации клиента путем сопоставления полученного из IVR CPN со следующим категориями мобильных телефонов в ИС Банка: Номерами ДКО Номерами «СМС Нотификации» 1.1. В случае отсутствия совпадения, проставить по ANI признак – «Анонимный клиент» - признак 0 1.2. В случае если найдено одно совпадение 1.2.1. Считать клиента однозначно идентифицированным; 1.2.2. Сопоставить CPN и определенный ID клиента; 1.2.3. Присвоить ANI признак уровня доверия (от 1 до 3, где 1 максимальный уровень доверия) идентификации: 1.2.3.1. CPN совпал с номером ДКО – признак 1 37 1.2.3.2. CPN совпал с номером «СМС Нотификации» (любой пакет кроме «Зарплатного» - признак 2 1.2.3.3. ANI совпал с номером «СМС Нотификации» (пакет «Зарплатный») - признак 3 1.3. В случае если найдено совпадений одного CPN с несколькими ID клиента (нотификаий), считать клиента анонимным . 1.4. В случае если найдено совпадение одного CPN с несколькими ID клиента (один из которых ДКО, а остальные нотификационные) считать такого клиента как однозначно идентифицированного по ДКО. 4.11.1.4.1 Проверка должна проводиться только для CPN с признаком «мобильный». Для городских телефонов Функция автоматической идентификации по умолчанию возвращает значение «анонимный Клиент». 4.11.1.4.2 В случае успешной идентификации, система должна произвести автоматическую аутентификацию во внутренних системах банка без ввода дополнительных данных со стороны клиента. 4.11.1.4.3 В случае успешной аутентификации, Клиент должен иметь возможность получения ряда сервисов Банка (пример): Уникальный клиент ДКО + Смс нотификации Клиенту предоставляется баланс карты по которой он запросил информацию; NBO Уникальный клиент ДКО Клиента информируют о наличие "Маркетингового предложения"; Построение списка продуктов Уникальный клиент ДКО Клиенту предоставляется информация по всем продуктам которые есть у него в кабинете: - Карты; - Счета; - Кредиты; и т.д. Получение баланса по карте Детальное описание сервисов будет сформировано на этапе проработке проекта. 4.11.1.5 Функция автоматической идентификации должна позволять использовать информацию об уровне авторизации Клиента всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.11.2 Ограничения функции 4.11.2.1 Функция автоматической идентификации должна производить идентификацию клиента на уровне IVR, а аутентификацию во внутренних ИС банка. 4.11.2.2 Функция автоматической идентификации должна иметь возможность установки статуса «по умолчанию» для следующих случаев: 38 4.11.2.2.1 Уровень авторизации Клиента невозможно определить. 4.11.2.2.2 Превышение тайм-аута ответа от ИС банка. 4.11.2.2.3 Функция автоматической идентификации должна записывать в лог-файл информацию об ошибках определения уровня авторизации (п. 4.11.2.2.1 – п. Error! Reference source not found.). 4.11.3 Требования к входным данным 4.11.3.1 Входные данные для Функции автоматической идентификации – CPN. 4.11.4 Конфигурация параметров функции 4.11.4.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.11.4.1.1 Включение / отключение функционала автоматической идентификации Клиента в IVR. В случае отключения данной функции клиенту строится дефолтное дерево IVR. 4.11.4.1.2 Тайм-аут ожидания от ИС банка. 4.11.4.1.3 Значение «по умолчанию» для Функции автоматической идентификации. 4.11.5 Описание работы функции 4.11.5.1 Работа функции должна состоять из следующих логических действий: 4.11.5.1.1 Предусловия: Клиент позвонил в КЦ Банка с мобильного телефона (Система подтвердила); Система определила CPN Клиента. 4.11.5.1.2 Система проверяет, включен или отключен функционал Автоматической идентификации. 4.11.5.1.2.1 Если функционал отключен, работа Функции завершается; Клиенту присваивается статус «анонимный клиент» и процесс прохождения Клиента в IVR продолжается согласно общей схеме прохождения вызовов в IVR (дефолтное дерево IVR). 4.11.5.1.3 При успешном завершении работы идентификации, Система имеет следующие данные Клиенте: Функции автоматической IVR_ID Уровень авторизации Клиента. *После прохождения процедуры автоматической идентификации клиента, система должна аутентифицировать клиента в ИС банка, данный алгоритм должен иметь 39 возможность включения/выключения на стороне IVR. Если алгоритм включен система делает это в фоном режиме во время построения меню IVR. Если алгоритм выключен система аутентифицирует клиента только в момент выбора пункта меню требующего обращения к ИС банка. 4.12 Функция ручной аутентификации 4.12.1 Общее описание 4.12.1.1 Функция ручной аутентификации Клиента предназначена для идентификации Клиента посредством ввода уникальных авторизационных данных. 4.12.1.2 Функция ручной аутентификации должна позволять Клиенту вводить авторизационные параметры посредством DTMF-команд. 4.12.1.2.1 Завершение ввода авторизационного параметра должно подтверждаться Клиентом с помощью нажатия клавиши # (настраиваемо). 4.12.1.3 Функция ручной аутентификации должна предоставлять возможность администратору Системы создавать схемы авторизации: 4.12.1.3.1 Схема авторизации должна иметь два обязательных поля для заполнения (два авторизационных параметра). 4.12.1.3.2 Администратор Системы должен иметь возможность настройки формата и логики заполнения авторизационных параметров (наименование, количество символов, ограничения на диапазон введенного значения). 4.12.1.3.3 Администратор Системы должен иметь возможность настройки Типа авторизации, который будет доступен Клиенту после успешного прохождения процесса авторизации. 4.12.1.3.4 По умолчанию, в Системе должны быть настроены следующие схемы авторизации: УНК+Пароль; Номер карты+Пароль; УНК+ последние 4 цифры номера карты. ПД (+ДР) (подробное описание смотри п.4.11); 4.12.1.3.5 Функция ручной идентификации должна иметь возможность сообщения о неверном/не корректном вводе авторизационных параметров. 4.12.1.3.6 В случае успешной авторизации, Система считает Клиента авторизованным с уровнем авторизации, указанным в настройках схемы авторизации и система считает клиента авторизованным на протяжении одной сессии (без дополнительных запросов) до завершения звонка. 40 4.12.1.4 Функция ручной идентификации должна позволять использовать информацию об уровне авторизации Клиента всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.12.2 Ограничения функции 4.12.2.1 Функция ручной идентификации должна производить аутентификацию Клиента путем запроса к ИС банка. 4.12.2.1.1 Система должна формировать запрос на подтверждение аутентификации с введенными авторизационными параметрами. ИС банка должна возвращать статус: верные/не верные авторизационные параметры. 4.12.2.2 Функция ручной идентификации должна иметь возможность установки статуса «по умолчанию» для следующих случаев: 4.12.2.2.1 Уровень авторизации Клиента невозможно определить. 4.12.2.2.2 Превышение тайм-аута ответа от ИС банка. 4.12.2.2.3 Для подтверждённой аутентификации, полученного от ИС Банка (Minerva), в Системе не создана соответствующая модель обслуживания. 4.12.2.2.4 Функция ручной идентификации должна записывать в лог-файл информацию об ошибках определения уровня авторизации (п. 4.12.2.2.1 – п. 4.12.4.1.3). 4.12.3 Требования к входным данным 4.12.3.1 Входные данные для Функции автоматической авторизационные параметры, введенные Клиентом в IVR. идентификации – 4.12.4 Конфигурация параметров функции 4.12.4.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.12.4.1.1 Включение / отключение функционала ручной авторизации Клиента в IVR. 4.12.4.1.2 Тайм-аут ожидания от ИС Банка. 4.12.4.1.3 Значение «по умолчанию» для Функции ручной авторизации. 4.12.4.1.4 Создание / редактирование / удаление схем авторизации. 4.12.4.1.5 Количество повторных попыток авторизации. 4.12.4.1.6 Сервис для формирования запроса в ИС Банка. 41 4.12.5 Описание работы функции 4.12.5.1 Работа функции должна состоять из следующих логических действий: 4.12.5.1.1 Предусловия: Клиент выбрал пункт меню IVR, предоставляющий персональную информацию. 4.12.5.1.2 Система авторизации. проверяет, включен или отключен функционал ручной 4.12.5.1.2.1 Если функционал отключен, работа Функции завершается; Клиенту озвучивается звуковое сообщение о невозможности предоставления данного сервиса. 4.12.5.1.3 Система проверяет, какой Тип авторизации необходимо запрашивать для предоставления данного сервиса. 4.12.5.1.3.1 Если Клиент, в рамках данной сессии, авторизован Системой с необходимым Типом авторизации (или по приоритету выше требуемого), то Система предоставляет Клиенту запрошенный сервис. 4.12.5.1.4 Система предлагает Клиенту ввести необходимые авторизационные параметры. 4.12.5.1.4.1 В случае ошибочного ввода одного из параметров, либо если превышен тайм аут ожидания ввода, Система повторно предлагает Клиенту повторный ввод. 4.12.5.1.5 Система формирует запрос в ИС Банка с целью валидации авторизационных параметров. 4.12.5.1.6 В случае если ИС Банка подтверждает корректность введенных параметров, то Система считает Клиента авторизованным с тем уровнем авторизации, который был задан в схеме авторизации. 4.12.5.1.6.1 Если ИС Банка сообщает о том, что параметры были введены неверно, то Система озвучивает Клиенту информацию об ошибке авторизации и предлагает повторную процедуру авторизацию. 4.12.5.1.6.2 В случае превышения попыток авторизации (более Х), Система должна предложить соединить данного клиента с оператором. 4.12.5.1.7 Если запрос информации из ИС Банка не доступен: возник сбой/таймаут/недоступность сервиса интеграции – работа Функции ручной авторизации завершается; Клиенту озвучивается звуковое сообщение о невозможности предоставления данного сервиса. 4.12.5.1.8 При успешном завершении работы Функции ручной авторизации, Система имеет следующие данные Клиенте: 42 Уровень авторизации Клиента. 4.13 Функция ввода паспортных данных клиента 4.13.1 Общее описание 4.13.1.1 Функция ввода паспортных данных клиента предназначена для идентификации Клиента в целях возможности предоставления ряда информационных сервисов. 4.13.1.2 Функция ввода паспортных данных клиента должна позволять Клиенту вводить авторизационные параметры посредством DTMF-команд. 4.13.1.2.1 Завершение ввода авторизационного параметра должно подтверждаться Клиентом с помощью нажатия клавиши # (настраиваемо). 4.13.1.3 Функция ввода паспортных данных клиента должна реализовывать процесс авторизации Клиента по вводу цифровых значений паспортных данных: Серия паспорта; Номер паспорта; Дата рождения в формате ДДММГГГГ. 4.13.1.4 Функция ввода паспортных данных клиента должна предоставлять возможность настройки порядка ввода цифровых значений паспортных данных и их комбинацию. 4.13.1.5 Функция ввода паспортных данных клиента должна иметь возможность сообщения о вводе неверных/некорректных паспортных данных (проверка количества введенных символов). 4.13.1.6 В случае успешной идентификации по паспортным данным, Клиент должен иметь возможность получения следующих сервисов Системы: Получение статуса заявки. 4.13.1.7 Функция ввода паспортных данных клиента должна позволять использовать информацию об уровне авторизации Клиента всеми функциями Системы в рамках одной сессии (самообслуживание в IVR, обслуживание оператором). 4.13.2 Ограничения функции 4.13.2.1.1 Функция ввода паспортных данных клиента должна передавать введенные Клиентом паспортные данные в соответствующие Функции Системы (п. 4.13.1.6). 43 4.13.3 Требования к входным данным 4.13.3.1 Входные данные для Функции ввода паспортных данных клиента – паспортные данные, введенные Клиентом в IVR. 4.13.4 Конфигурация параметров функции 4.13.4.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.13.4.1.1 Порядок ввода цифровых значений паспортных данных. 4.13.5 Описание работы функции 4.13.5.1 Работа функции должна состоять из следующих логических действий: 4.13.5.1.1 Предусловия: Клиент выбрал пункт меню IVR, в настройках которого выбрана опция запроса паспортных данных. 4.13.5.1.2 Система проверяет Тип авторизации Клиента. 4.13.5.1.2.1 Если Клиент авторизован с Типом авторизации, приоритет которого выше, чем ввод паспортных данных, то Система предоставляет Клиенту запрошенный сервис без ввода дополнительной информации. 4.13.5.1.3 Система предлагает Клиенту ввести цифровые значения паспортных данных. 4.13.5.1.3.1 В случае нарушения логики ввода запрашиваемых параметров, Система предлагает повторный ввод (количество повторных запросов настраивается Банком). 4.13.5.1.4 Функция ввода паспортных данных клиента параметры соответствующей Функции Системы (п. 4.13.1.6). передает введенные 4.14 Функция приветствия клиента по времени суток (Главное меню IVR) 4.14.1 Общее описание 4.14.1.1 Функция приветствия клиента по времени суток должна озвучивать приветственное сообщение исходя из часового пояса клиента. Например – «Добрый день», «добрый вечер» и т.д. 44 4.14.2 Ограничения функции 4.14.2.1 Функция приветствия клиента по времени суток должна иметь возможность редактирования временных интервалов для озвучивания приветственного сообщения. 4.14.2.2 Функция приветствия клиента по времени суток, строит приветственную фразу исходя из DEF/ABC кода клиента, при этом если клиент находится в роуминге, данная функция не будет этого учитывать. 4.14.2.3 Функция приветствия клиента по времени суток должна определять часовой пояс клиента по данным его региона (Функция автоматического определения региона клиента). 4.14.3 Требования к входным данным 4.14.3.1 Входные данные для Функции персонального приветствия – CPN. 4.14.3.2 Регион клиента + привязка к GMT клиента. - CPN 4.14.4 Конфигурация параметров функции 4.14.4.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.14.4.1.1 Включение / отключение функционала персонального приветствия. 4.14.5 Описание работы функции Клиент обратился в КЦ; Система делает запрос в БД IVR для определения «региона клиента»; На основании полученных данных системы текущий часовой пояс данного региона; После получения часового пояса системы выбирает один из видов приветствия, пример: o 7:01~11:00 – «Доброе утро! Вас приветствует Банк ВТБ24» o 11:01~19:00 – «Добрый день! …» o 19:01~22:00 – «Добрый вечер! …» o 22:01~07:00 – «Доброй ночи! …» 45 4.15 Функция получения статуса заявки 4.15.1 Общее описание 4.15.1.1 Функция получения статуса заявки предназначена для получения и предоставления информации об имеющихся у Клиента активных заявках на продукты КН (Кредиты наличными) и КК (Кредитные Карты). 4.15.1.2 Функция получения статуса заявки должна иметь возможность запрашивать данные о статусе заявки в Minerva. 4.15.1.3 Функция получения статуса заявки должна иметь возможность озвучивать Клиенту статус его заявки. 4.15.1.4 Функция получения статуса заявки должна запрашивать и предоставлять информацию только по заявкам, имеющим статус «активная». 4.15.1.5 Функция получения статуса заявки должна предоставлять данный сервис как уже существующим Клиентам банка, так и новым Клиентам, которых еще нет в Банковских системах. 4.15.1.6 Функция получения статуса заявки должна позволять использовать информацию о статусе заявок Клиента всеми функциями Системы, в рамках одной сессии (в частности, информация должна быть доступна для функции, реализующей отправку смс). 4.15.2 Ограничения функции 4.15.2.1 При наличии у Клиента нескольких активных заявок, Функция получения статуса заявки должна последовательно предоставлять информацию по каждой из заявок. 4.15.3 Требования к входным данным 4.15.3.1 Входными данными для функции должны быть цифровые значения паспортных данных либо ID Клиента (в случае однозначно определенного Клиента). 4.15.4 Конфигурация параметров функции 4.15.4.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.15.4.1.1 Тайм-аут ожидания от Minerva. 4.15.4.1.2 Уровень авторизации Клиента, необходимый для получения сервиса. 4.15.4.1.3 Возможность отправки информации по смс. 46 4.15.5 Описание работы функции 4.15.5.1 Работа функции должна состоять из следующих логических действий: 4.15.5.1.1 Предусловия: Клиент прошел автоматическую Клиент выбрал в IVR пункт меню с информацией о статусе заявки. 4.15.5.1.2 Система проверяет уровень авторизации Клиента: 4.15.5.1.2.1 Для однозначно определенного Клиента сервис предоставляется без дополнительных авторизационных запросов. 4.15.5.1.2.2 Для анонимного клиента либо неоднозначно определенного клиента, Система вызывает Функцию ввода паспортных данных клиента. 4.15.5.1.3 Система формирует запрос в Minerva с целью определения статуса заявок Клиента. 4.15.5.1.4 Система озвучивает данные о статусе заявок Клиента с использованием технологии синтеза речи. 4.16 Функция формирования SMS из IVR 4.16.1 Общее описание 4.16.1.1 Функция формирования SMS из IVR предназначена для формирования смс с данными информационных блоков либо данными блоков, предоставляющих персональную финансовую информацию, с целью дальнейшей передачи в сервис, реализующий отправку смс. 4.16.1.2 Функция формирования SMS из IVR должна передавать во внутренни ИС банка (wings) данные, необходимые для отправки смс (параметризованная ссылка, содержащая номер телефона и текст). 4.16.1.3 Функция формирования SMS из IVR должна иметь возможность диалогового подтверждения отправки смс. Например, после озвучивания информационного блока, Система запрашивает клиента: Если Вы хотите получить информацию в виде смс, нажмите «1». 4.16.1.4 Функция формирования SMS из IVR должна иметь возможность принудительной отправки смс (без подтверждения Клиентом). 4.16.1.5 Функция формирования SMS из IVR должна иметь возможность создания шаблонов смс через графический пользовательский интерфейс (GUI). 47 4.16.1.5.1 Система должна иметь возможность указания шаблона смс для каждого блока IVR (Функции или информационному сервису), информация из которой может быть отправлена в виде смс. 4.16.1.5.2 Шаблоны должны иметь возможность использования переменных для формирования смс. 4.16.1.5.3 Переменными должны быть результаты работы Функции Системы. 4.16.2 Ограничения функции 4.16.2.1 Функция формирования SMS из IVR должна формировать смс для Клиента, обратившегося с мобильного телефона. 4.16.2.2 Функция формирования SMS из IVR доступна только в рамках определенного блока IVR, для которого выбран соответствующий шаблон смс. 4.16.3 Требования к входным данным 4.16.3.1 Тип CPN клиента – Мобильный; 4.16.3.2 Входные данные для Функции формирования SMS из IVR – шаблон смс, переменные, переданные соответствующей Функцией. 4.16.4 Конфигурация параметров функции 4.16.4.1 Данный раздел описывает параметры, настраиваемые через графический пользовательский интерфейс: 4.16.4.1.1 Шаблоны смс. 4.16.4.1.2 Запрос на отправку смс / принудительная отправка. 4.16.4.1.3 Включение / отключение возможности отправки смс для блока IVR (или Функции Системы). 4.16.5 Описание работы функции 4.16.5.1 Работа функции должна состоять из следующих логических действий: 4.16.5.1.1 Предусловия: Клиент обратился в КЦ Банка с мобильного телефона; Система определила CPN Клиента; Клиент выбрал пункт меню IVR, в котором доступен функционал отправки смс с запросом на отправку смс. 4.16.5.1.2 Система озвучивает предложение об отправке озвученной информации (в пункте меню IVR) в виде смс. 48 4.16.5.1.3 При согласии Клиента, Система подготавливает сообщение на основе шаблона. 4.16.5.1.4 Система передает в ИС Банка (Wings) параметризованную ссылку, содержащую текст сообщения и номер телефона, на который необходимо отправить данное сообщение. 4.17 Функция выхода на оператора 4.17.1 Общее описание 4.17.1.1 Функция выхода на оператора предназначена для возможности перевода Клиента из меню IVR в очередь к группе Операторов. 4.17.1.2 Переход на начало функции должен осуществляться в одном из следующих случаев: выбор Клиентом кнопки «0» (настраиваемо) в пункте, где это предусмотрено; возникновение тайм-аута; исчерпание лимита попыток выбора пункта меню (если настройки пункта меню не предполагают иной модели обслуживания). 4.17.1.3 Функция выхода на оператора должна переводить Клиента на группу Операторов в зависимости от анализа прикрепленных данных во время предобработки звонка. 4.17.1.4 Функция выхода на оператора должна сохранять информацию в течение заданного времени о Клиенте, операторе, который его обслуживал, и времени окончания обслуживания. 4.17.1.4.1 Данная информация должна храниться в БД Системы. 4.17.2 Ограничения функции 4.17.2.1 Функция выхода на оператора должна иметь возможность настройки группы Операторов/приоритета вызова/ТО ожидания/расширения группы поиска (и др. параметров*) для каждой схемы обслуживания Клиента в IVR. 4.17.2.2 Функция выхода на оператора должна иметь возможность передачи в Банковские системы информацию о ветке IVR, из которой произошел выход на оператора *набор параметров будет уточнен на этапе проработки проекта. 4.17.3 Описание работы функции 4.17.3.1 Предусловия: 49 Клиент перешел на начало Функции выхода на оператора (одним из способов в п. 4.17.1.2). 4.17.3.2 Система определяет группу операторов(скиловой набор), название виртуальной очереди, приоритет маршрутизации вызова и т.д.. 4.17.3.3 Система осуществляет перевод вызова в очередь к операторам. 4.17.3.4 По факту завершения обслуживания Клиента, Система сохраняет информацию о Клиенте, Операторе и времени завершения обслуживания. Пример №1: Звонок из Москвы (reg=77); Тип абонента = мобильный; Уровень доверия = 1; Grade = VIP Открыта сессия в ТБ; Исход для такого звонка: Группа операторов поддержки ТБ; Приоритет выше среднего; Пример №2: Звонок из Москвы (reg=77); Тип абонента = мобильный; Уровень доверия = 1 (однозначно идентифицированный клиент ДКО); Grade = низкодоходный Открыта сессия в ТБ; Исход для такого звонка: Группа операторов первой лини; приоритет низкий. 4.18 Функция анализа признака «повторный звонок» 4.18.1 Общее описание 4.18.1.1 Функция анализа признака «повторный звонок» предназначена для сбора оперативной информации о повторных звонках Клиентов с целью предоставления специальной модели обслуживания. 4.18.1.2 Функция анализа признака «повторный звонок» должна подсчитывать количество повторных звонков (счетчик повторных звонков), совершенных с одного уникального номера телефона (CPN). 4.18.1.2.1 Данная информация должна храниться в БД Системы. 4.18.1.2.2 Глубина хранения информации – не менее 24 часов. 50 4.18.1.3 Функция анализа признака «повторный звонок» должна иметь возможность настройки периода, в течение которого звонок считается повторным. 4.18.1.4 Логика работы Функции анализа признака «повторный звонок» представлена на рисунке 5. Рисунок 5 – Алгоритм работы Функции анализа признака «повторный звонок» 4.18.1.5 По результатам работы Функция анализа признака «повторный звонок» передает в Систему информацию о количестве повторных вызовов Клиента (счетчик повторных звонков). 4.18.2 Ограничения функции 4.18.2.1 Функция анализа признака «повторный звонок» должна быть доступна только для однозначно определенных Клиентов. 4.19 Функция повторного соединения с оператором 4.19.1 Общее описание 4.19.1.1 Функция повторного соединения с оператором предназначена для соединения с оператором, осуществлявшим обслуживание Клиента. 51 4.19.1.2 Функция повторного соединения с оператором должна соединять Клиента, повторно обратившегося в КЦ Банка. 4.19.1.2.1 Функция повторного соединения с оператором должна получать информацию о повторном звонке от Функции анализа признака «повторный звонок». 4.19.2 Ограничения функции 4.19.2.1 Функция повторного соединения с оператором должна быть доступна только для однозначно определенных Клиентов. 4.19.3 Описание работы функции 4.19.3.1 Предусловия: Клиент совершает повторный вызов, попадающий в интервал времени, указанный в Функции повторного соединения; Клиент прошел процедуру автоматической идентификации и является однозначно определенным Клиентом. 4.19.3.2 Система запрашивает данные о предыдущем обращении Клиента. 4.19.3.3 В случае если предыдущее обращение удовлетворяет условиям Функции для повторного соединения, Функция повторного соединения с оператором проверяет статус необходимого оператора. 4.19.3.3.1 Если оператор находится в статусе «свободен», то Система соединяет Клиента с данным оператором. 4.19.3.3.2 Если оператор находится в статусе, отличенном от «свободен» - Система переводит Клиента в очередь (в соответствующую skill-группа) с максимальным приоритетом. 4.20 Функция «выхода на персонального финансового консультанта (ПФК)» 4.20.1 Общее описание 4.20.1.1 Данная функция предназначена для обслуживания VIP клиентов за которыми закреплен ПФК. 4.20.1.2 Информация о том, имеет ли Клиент персонального финансового консультанта (ПФК) должна храниться в БД IVR. 52 4.20.1.2.1 Система должна хранить два параметра по которым возможно определить необходимость специального обслуживания Клиента, а также наличие у данного Клиента ПФК (Таблица 5): Таблица 5 – Параметры для определения ПФК Клиента Наименование параметра Описание параметра «Привелегия_NEW» Параметр, определяющий необходимость предоставления специального обслуживания. Принимает значения «1» / «0» (или true / false) Признак (значение) PFK Параметр, хранящий внутренний номер (номер оператора в системе Avaya Interaction Center) ПФК Клиента 4.20.1.3 Система должна осуществлять поиск параметров Функции «Выход на ПФК» для только при попытке соединения с оператором. 4.20.1.4 Реализация функции должна быть дополнительно проработана на этапе формирования ТЗ. 4.20.2 Ограничения функции Наличие у клиента пакета привилегированного обслуживания Наличие закрепленного ПФК; 4.20.3 Описание работы функции Клиент звонит в IVR ВТБ24 (88001002424 или др. аналоги); IVR проверяет наличие для данного номера прикрепленных двух параметров: Пакет «Привилегия_NEW» = 1; Признак «PFK» = XXXXXX; где «XXXXXX» логин сотрудника либо в Siebel, либо в AVAYA*; Если признак «PFK» у данного клиента отсутствует или имеет пустое значение, маршрутизация производиться согласно текущим настройкам. Если признак «PFK» содержит какое-то значение, то распределение на оператора происходит по следующему условию: 53 Телефония пытается распределить звонок на ПФК, указанного в данном поле. Если соединение с ПФК прошло успешно** (работа алгоритма прекращается); Если соединение с ПФК не происходит (необходимо предусмотреть два сценария, основной и резервный, которые можно переключать между друг другом): (Основной) Клиента информируют «Ваш ПФК в настоящий момент не доступен, ваш звонок будет переведен на замещающего его ПФК». Далее происходит соединение с группой ПФК УЦ с повышенным приоритетом (VDN:XXXXXX); (Резервный) Клиента информируют «Ваш ПФК в настоящий момент не доступен, чтобы оставить заявку для соединения со своим ПФК нажмите «1», или оставайтесь на линии для соединения с замещающего его сотрудником»; Если клиент нажимает «1»; звонок распределяется на линию «ТБ» (VDN:YYYYYY) и сотрудник этой линии оформляет заявку в Siebel для конкретного ПМ; Если клиент ни чего не нажимает, вызов распределяется на общую линию ПФК УЦ (VDN:XXXXXX); *Данный критерий должны определить архитекторы на этапе экспертизы; ** В случае если ПФК доступен, но не берет трубку обеспечит переход то переходим к следующему пункту Пример алгоритма функции «соединение с ПФК»: 54 Начало обработки 88001002424 И др.аналоги. Признак «Привилегия_NEW» = 1; Признак «ПМ» = ХХХХХХ; IVR Выход на оператора Выход на ПМ (Time_out = Х сек.) Распределение на ПФК да ПФК доступен? нет_1 Распределение на другого ПФК (VDN:XXXXXX) Информационное сообщение_1 нет_2 Информационное сообщение_2 1 2 Распределение на группу ТБ (VDN:YYYYYY) Распределение на другого ПФК (VDN:XXXXXX) 4.21 Функция повышения приоритета обращения клиента 4.21.1 Общее описание 4.21.1.1 Функция повышения приоритета обращения клиента предназначена для виртуального увеличения приоритета звонка в очереди к оператору. 4.21.1.2 Функция повышения приоритета обращения клиента должна действовать в рамках одной сессии без дополнительной записи об увеличении приоритета в какие-либо системы. 4.21.1.3 Функция повышения Grade клиента должна иметь возможность настройки условий повышения приоритета в зависимости от данных других Функций. Например, повышать приоритет, если Функция анализа признака «повторный звонок» сообщила, что счетчик повторных звонков для данного Клиента больше нуля. 55 4.22 Функция Управление пакетом SMS-нотификации (зарплатный) 4.22.1 Общее описание 4.22.1.1 Функция Управление пакетом SMS-нотификации предназначена предоставления Клиенту сервиса подключения зарплатного пакета нотификации в меню IVR. 4.22.1.2 Функция Управление пакетом SMS-нотификации должна иметь возможность проверки статуса смс-нотификации у Клиента (нотификация включена/отключена). 4.22.1.2.1 Если у Клиента включен любой из пакетов смс-нотификации, Функция Управление пакетом SMS-нотификации, функция ничего не делает. 4.22.1.2.2 Если у Клиента отключен пакет нотификации и он является зарплатным клиентом, Функция Управление пакетом SMS-нотификации должна предлагать Клиенту подключение пакета нотификации «Зарплатный» (только на тот номер, с которого клиент обращается). 4.22.1.3 Функция Управление пакетом SMS-нотификации должна иметь возможность озвучивания Клиенту информации о стоимости и условиях пакета нотификации в виде звукового сообщения (предзаписанный файл). 4.22.1.4 Функция Управление пакетом SMS-нотификации должна иметь возможность подключения услуги только для CPN Клиента. 4.22.1.5 Для подключения пакета нотификации, Функция Управления пакетом SMSнотификации должна формировать запрос в ИС Банка. 4.22.2 Входные параметры Тип CPN клиента – мобильный; Тип клиента – зарплатный; Подключенные пакеты нотификации – отсутствуют для данного клиента. 4.22.3 Ограничения функции 4.22.3.1 Функция Управление пакетом SMS-нотификации должна предоставлять только авторизованному Клиенту. 4.22.3.1.1 Уровень авторизации должен задаваться администратором Системы. 4.22.3.2 Для подключения доступны только следующие пакеты смс-нотификации: Зарплатный 56 4.23 Функция передачи информации в Siebel 4.23.1 Общее описание 4.23.1.1 Функция передачи информации в Siebel предназначена для передачи в приложение Оператора информации, полученной о Клиенте в IVR. 4.23.1.2 Функция передачи информации в Siebel должна открывать карточку в системе Siebel при соединении Клиента с Оператором. 4.23.1.3 Функция передачи информации в Siebel должна передавать информацию для предзаполнения карточки в системе Siebel данными, полученными о Клиенте в IVR. 4.23.1.4 Функция передачи информации в Siebel должна передавать следующую информацию в систему Siebel: 4.23.1.4.1 Только номер карты – для неавторизованного клиента, который ввел информацию в IVR. 4.23.1.4.2 ID клиента – для однозначно идентифицированного клиента по CPN. 4.23.1.4.3 ID клиента с признаком «Авторизован» – для однозначно идентифицированного клиента, авторизовавшегося в IVR. 4.23.2 Ограничения функции 4.23.2.1 Система должна вызывать Функцию передачи информации в Siebel в случае, если Клиент попадает в очередь к группе Операторов. 4.23.2.2 Способы и формат передачи информации в Siebel должны быть описаны на этапе формирования технического задания. 4.24 Функция NBO в автоматическом режиме 4.24.1 Общее описание 4.24.1.1 Функция NBO в автоматическом режиме предназначена для предоставления Клиенту информации по имеющимся у Банка предложениям (кредиты/автокредиты/кк/депозиты/ипотека/счета и услуги), а также по индивидуальным предложениям. 4.24.1.2 Функция NBO в автоматическом режиме должна проверять наличие специальных предложений при авторизации Клиента. 4.24.1.2.1 Сервис должен быть доступен Клиентам, авторизованным по схемам авторизации: УНК+Пароль, Номер карты+Пароль, УНК+4 посл. Цифры, Белый однозначно авторизованный клиент (Функция автоматической идентификации). 4.24.1.2.2 Функция NBO в автоматическом режиме должна предоставлять возможность изменения уровня авторизации и схемы авторизации. 57 4.24.1.3 Функция NBO в автоматическом режиме должна получать информацию о специальных предложениях из Minerva. 4.24.2 Ограничения функции 4.24.2.1 При наличии актуальных предложений Система должна озвучивать данную информацию отдельным пунктом меню IVR. 4.25 Функция автоматической генерации УНК 4.25.1 Общее описание 4.25.1.1 Функция автоматической генерации УНК предназначена для возможности получения Клиентом (сотрудник министерства обороны) числовых значений УНК и пароля в автоматическом режиме (без участия оператора). 4.25.1.2 Функция автоматической генерации УНК должна использовать существующую процедуру генерации УНК (и пароля) через дистанционный канал IVR. 4.25.2 Ограничения функции 4.25.2.1 Для получения сервиса генерации УНК Клиент должен быть авторизован по вводу числовых значений серии и номера паспорта (Функция ввода паспортных данных клиента). 4.25.3 Описание работы функции 4.25.3.1 Клиент входит в «пункт генерация УНК»; 4.25.3.2 Система предлагает клиенту ввести номер банковской карты; 4.25.3.3 После ввода карты система запрашивает во внутренних ИС Банка принадлежность данной карты к проекту обслуживания МО; 4.25.3.4 Если введенная карта не принадлежит «МО», данный звонок переводиться на оператора с обязательной передачей в Siebel информацией о карте клиента (номер карты) работа алгоритма прекращается; 4.25.3.5 Если введенная карта принадлежит «МО», система просит доввести информацию о клиенте (ПД+ДР); 4.25.3.6 Если данные введенные в п.4.25.3.5 валидны и соответствуют тем что находятся в системах банка, данному клиенту генерируется новый УНК(существующий механизм) и озвучивается. После озвучивания работа алгоритма прекращается. 4.25.3.7 Если в процессе ввода данных паспорта происходит ошибка, вызов маршрутизируется на оператора. 58 4.26 Функция получения информации о наличии открытой сессии в Телебанке 4.26.1 Общее описание 4.26.1.1 Функция получения информации о наличии открытой сессии в Телебанке предназначена для передачи в Систему информации о том, что Клиент залогинен в интернет сервисе Телебанка при осуществлении обращения в КЦ Банка. 4.26.1.2 Получение Системой информации о наличии открытой сессии предназначено для осуществления особой модели обслуживания Клиента в IVR (и маршрутизации на группу Операторов). 4.26.1.3 В результате работы Функция получения информации о наличии открытой сессии в Телебанке должна получать следующую информацию о Клиенте: наличие / отсутствие открытой сессии в Телебанке. 4.26.2 Ограничения функции 4.26.2.1 Функция получения информации о наличии открытой сессии в Телебанке должна получать информацию об открытой (активной) сессии в Телебанке из BC банка(Minerva). 4.26.2.2 Функция получения информации о наличии открытой сессии в Телебанке должна быть доступна только для однозначно определенного Клиента. 4.27 Функция «отчетность в IVR» 4.27.1 Общее описание (подробное описание функции см. Приложение Б) 4.27.1.1 Функция «отчетность в IVR» предназначена для сбора и отображения статистики в Системе. 4.27.1.2 Детализированные требования к перечню отчетов должны быть составлены при формировании технического задания. 4.28 Функция построения списка продуктов клиента 4.28.1 Общее описание 4.28.1.1 Функция построения списка продуктов клиента предназначена формирования персонального меню на основе имеющегося набора продуктов Клиента. для 59 4.28.1.2 Функция построения списка продуктов клиента должна реализовывать функции динамического IVR, а именно: 4.28.1.2.1 Функция построения списка продуктов клиента должна иметь возможность построения дерева IVR в зависимости от параметров, полученных в карточке Клиента. 4.28.1.2.2 Функция построения списка продуктов клиента должна иметь возможность передавать данные для обеспечения приоритета маршрутизации при попадании Клиента в очередь к Операторам. 4.28.1.3 Пример логики настройки динамического IVR представлен на рисунке 6. 60 ВХОД (прошла проверка: Должник / Белый / черный да DNIS = Prime DNIS =Affl да Главное меню Главное меню Аварийный / Проигрывается фрагмент в зависимости от Информацион региона (настраивается в Системе). ный фрагмент Проигрывается приветствие для сегмента (настраивается в Системе) Оператор Проигрывается приветствие для сегмента (настраивается в Системе) Ценность=High Проигрывается фрагмент в зависимости от Аварийный / региона (настраивается в Системе). Может Информацион содержать предложение перейти в пункт ный фрагмент меню 1 Счет Персональная информация по Счетам и заявкам в банке: автоматическа / ручная авторизация 2 Динамика NBO / Заявка в банк / Продукты и услуги 3 Геолокация Поиск банкомата и отделения да Главное меню Проигрывается приветствие для сегмента (настраивается в Системе) Проигрывается фрагмент в зависимости от Аварийный / региона (настраивается в Системе). Может Информацион содержать предложение перейти в пункт ный фрагмент меню Да 0 Оператор 1 Счет Персональная информация по Счетам и заявкам в банке: автоматическа / ручная авторизация 2 Динамика NBO / Заявка в банк / Продукты и услуги 3 Геолокация Поиск банкомата и отделения 0 Оператор да CPN Определен? да CPN=Mass DNIS =Mass Главное меню СТРУКТУРА IVR «Потенциальн ый клиент» Структура IVR «Юр. Лица» Да CPN=Prime Да CPN=Affl Легенда Prime – Клиенты пакета «Прайм Affl – Клиенты пакета «Привилегия/приоритет. Состоятельный сегмент Mass – Массовый сегмент NBO – Специальное предложение (Next Best Offer) Проигрывается приветствие для сегмента (настраивается в Системе) Проигрывается фрагмент в зависимости от Аварийный / региона (настраивается в Системе). Может Информацион содержать предложение перейти в пункт ный фрагмент меню Персональная информация по Счетам и 1 Счет заявкам в банке: автоматическа / ручная авторизация 2 Динамика NBO / Заявка в банк / Продукты и услуги 3 Геолокация Поиск банкомата и отделения 4 Компании группы ВТБ Реквизиты банка, адреса офисов и банкоматов - нажмите 6 Рисунок 6 – Пример логики построения динамического IVR 0 Оператор 61 4.28.1.4 Функция построения списка продуктов клиента должна получать список имеющихся продуктов Клиента в Minerva. 4.28.1.4.1 Список продуктов доступных для Клиента представлен в таблице 6. Таблица 6 - Список продуктов, доступных для Клиента Список продуктов и сервисов Информация «на выходе» функции Результат работы функции Банковская карта Тип карты (VISA/Master) Тип карты Master/Visa Сценарий обслуживания клиента для типов карты Visa/Master Активирована/Не активирована Активирована/Не активирована Предложение получить ПИН-код Статус блокировки (тип блокировки) Статус блокировки (тип блокировки) Сценарий обслуживания Период погашения (для кредитных карт) Период погашения Сценарий обслуживания Признак «Наличие просрочки» Признак «Наличие просрочки» Сценарий обслуживания Кредит наличными/Автокредит Дата очередного платежа по кредиту Дата очередного платежа по кредиту Сценарий обслуживания Признак «Наличие просрочки» Признак «Наличие просрочки» Сценарий обслуживания Наличие досрочных погашений в прошлом расчетном периоде Наличие досрочных погашений в прошлом расчетном периоде Сценарий обслуживания Признак ЧДП Признак ЧДП Сценарий обслуживания Депозит Дата окончания Сумма депозита Процентная ставка Начисленные проценты за выбранный период Дата окончания за последний Сценарий обслуживания период 62 Список продуктов и сервисов Информация «на выходе» функции Результат работы функции Ипотека Дата очередного платежа по кредиту Дата очередного платежа по кредиту Сценарий обслуживания Телебанк Активная заявка на КН/КК Активная заявка на КН/КК Сценарий обслуживания 4.28.1.4.2 Список продуктов может дополняться и изменяться (на стороне Банка). 4.29 Функция «Получение сервисов по продуктам» 4.29.1 Общее описание 4.29.1.1 Функция «получение сервисов по продуктам» предназначена для предоставления автоматизированных сервисов, предоставляющих информацию по продуктам Клиента. 4.29.1.2 Функция «получение сервисов по продуктам» должна предоставлять Клиентам возможность получения следующих сервисов (Таблица 7). Таблица 7 – Автоматизированные сервисы, доступные в системе Сервис Результат работы сервиса Информация по Банковской карте: 1. Остаток по карте Предоставляется информация по остатку на карточном счете на момент обращения к сервису 2. Сумма просроченной задолженности на текущую дату, если имеется Предоставляется информация о задолженности при получении остатка по карте (информация на момент обращения к сервису) 3. Сумма к погашению на льготных условиях, если имеются Предоставляется информация о сумме погашения на льготных условиях при получении остатка по карте (информация на момент обращения к сервису) 4. сумма к погашению Предоставляется информация о минимальной сумме к погашению и дате при получении остатка по карте (информация на момент обращения к сервису) 63 5. Полная сумма задолженности на текущую дату Предоставляется информация о полной сумме задолженности по карте на момент обращения к сервису 6. Размер и дата 5-ти последних транзакций по карте Предоставляется информация о дате и суммах последних 5ти транзакций по карте. Информация может быть озвучена голосом или направлена клиенту в виде СМС (опция предлагает только при проверке, что обращение поступило с мобильного телефона) Информация по кредитам наличными/автокредитам/Ипотечным кредитам: 1. Полная сумма задолженности на текущую дату Клиенту предоставляется полная сумма задолженности в валюте кредита актуальная на момент обращения. Возможна отправка в виде СМС 2. Размер и дата очередного платежа Клиенту предоставляется информация о дате и размере ОП на момент обращения к сервису 3. Сумма просроченной задолженности, в случае если у клиента она есть Пункт динамический, озвучивается при авторизации! Клиенту предоставляется о просрочке при получении информации по кредиту на момент обращения к сервису 4. Сумма для полного досрочного закрытия кредита на текущую дату При выборе данного пункта в меню по кредитам голосом или отправкой смс, по выбору клиента на момент обращения к сервису Информация по депозитам: 1. Информация по вкладу Клиент может получить следующую информацию: - Сумма депозита - Процентная ставка, возможность пополнения с условиями, условия автопролонгации и досрочного растрожения; - Информация по 5-ти последним приходно-расходным операциям по депозиту; - Дата завершения вклада; - Начисленные на момент обращения проценты Информация по текущим счетам: 1. Остаток по счету на текущую дату Клиенту предоставляется об остатке по счету на текущую дату по выбранному счету 2. Пять последних транзакций по счету Информация зачитывается: Сумма, валюта, дата, тип операции Информация по ипотечному кредиту: 64 1. Размер и дата очередного платежа Клиенту предоставляется размере очередного платежа, просроченной задолженности если имеется и платежном периоде (погашение с __ по ___ ) 2. ОСЗ на текущую дату Клиенту предоставляется информация по общей сумме задолженности на момент обращения клиента 3. Срок кредита на текущую дату Клиенту предоставляется информация по сроку действия кредита на момент обращения клиента 4. Текущая процентная ставка по кредиту Клиенту предоставляется информация по текущей процентной ставке (текущая процентная ставка по кредиту (должно учитываться значение переменной %, понижение % при оформлении права собственности на новостройку и надбавка при непродлении страхования) по кредиту на момент обращения клиента 4.29.1.3 Для каждого сервиса должна быть возможность назначения требуемого типа авторизации. 4.29.1.4 Функция «получение сервисов по продуктам» должна иметь возможность формировать запрос для получения информации и получать информацию из Minerva. 4.29.1.5 Система должна иметь возможность построения различных сценариев получения информации по продуктам: 4.29.1.5.1 В зависимости от набора продуктов Клиента (либо иных данных, полученных от Функций Системы), Система должна предоставлять возможность настройки логики предоставления сервисов. 4.29.1.5.2 Система должна иметь возможность установки признака продукта, информация по которому обязательна для предоставления Клиенту. Такие продукты должны иметь признак «Реклама». 65 5 Принципы взаимодействия с внутренними системами банка Детальная информация по взаимодействию с ИС банка будет предоставлена на этапе реализации проекта. 5.1 Принципы взаимодействия с Minerva Взаимодействие с системой Minerva должно производиться через Сервисный слой Minerva, реализованный с помощью технологии Microsoft .NET WCF и использующей протоколы HTTP SOAP. Описание интерфейсов и интерфейсных методов должны быть разработаны на этапе формирования технического задания. 5.2 Принципы взаимодействия с WINGS Взаимодействие с системой Wings происходит посредством HTTP GET запроса на заданный URL. 5.3 Принципы взаимодействия с MDM Требования будут уточнены на этапе проработки проекта 5.4 Принципы взаимодействия с SONIC Sonic – интеграционная шина, обеспечивающая взаимодействие систем Банка посредством использования стандарта Java Message Service. 66 6 Нефункциональные требования 6.1 Требования к информационной безопасности системы 6.1.1 Общие требования к безопасности 6.1.1.1 Система должна обеспечивать защиту от несанкционированного доступа (НСД) к функциям и данным Системы сторонних лиц. 6.1.1.2 Компоненты защиты Системы от НСД должны обеспечивать: установление и подтверждение пользователя; защиту от подбора и идентификации пароля; выдачу полномочий пользователю при начале сеанса работы; управление правами доступа; протоколирование инцидентов нарушения безопасности. 6.1.2 Требования к установлению и подтверждению пользователя 6.1.2.1 Авторизация пользователя в Системе должна производиться путем ввода логина (идентификатора) и пароля. 6.1.2.2 Система должна иметь возможность взаимодействия со службой каталогов банка (AD), для обеспечения доменной авторизации. 6.1.3 Требования к защите от подбора и идентификации пароля. 6.1.3.1 Проверка введенной информации (идентификатор, пароль) должна осуществляться только после полного ее ввода. 6.1.3.2 В случае обнаружения ошибки Система не должна уточнять, какие именно данные введены неправильно. 6.1.3.3 Пароль не должен отображаться при вводе. 6.1.3.4 Доступ к Системе должен предоставляться после успешного прохождения процесса аутентификации пользователя. 6.1.3.5 Запрещается сохранять пароль в открытом виде в системе, исполняемых файлах, скриптах, базах данных, на серверах и т.п. 6.1.4 Требования к протоколированию инцидентов нарушения безопасности 6.1.4.1 Должна осуществляться регистрация входа/выхода в систему/из системы. 6.1.4.2 Модификация журнала пользователем системы должна быть невозможна. 67 6.1.4.3 Должно производиться протоколирование изменений прав пользователей (в журнал должна включаться информация о том, какой пользователь системы, в какую дату и время вносил какие изменения). 6.1.5 Требования к управлению правами доступа 6.1.5.1 В системе должна быть гибкая система настройки прав для работы с Системой. 6.1.5.2 В системе должна быть назначена роль, которая имеет возможность назначать права для пользователей, контролировать список пользователей системы (в том числе подключенных в настоящее время) и их прав. 6.2 Требования к масштабируемости Система должна быть масштабируемой и соответствовать требованиям бизнеса в части производительности. А именно, обеспечивать производительность, достаточную для обслуживания в штатные дни до 50 000 звонков на IVR в сутки; В пиковые до 700 000 звонков на IVR в сутки; 6.3 Требования к техническому обеспечению Система должна поддерживать работу со следующими редакциями СУБД: Microsoft SQL Server 2008 и выше. Система должна иметь возможность поддержки виртуализации (установка на виртуальных серверах). Приложение IVR должно работать по SIP. Требований по интеграции с AIC: 6.3.1. 1) Вызов регистрируется в AIC непосредственно перед выходом на оператора, после чего происходит запись в AIC всей необходимой информации из IVR, которая должна быть передана вместе со звонком. 2) При новом звонке генерации EDU и чтения данных из AIC не происходит. 3) Чтение данных из AIC происходит при трансфере вызова на приложение IVR оператором. 6.4 Требования к документированию Документация к проекту обязательно должна сожержать: Техническое задание (ТЗ); 68 Руководство пользователя IVR_GUI; Руководство администратора (ИТ) Дополнительные требования к документированию будут уточнены на этапе реализации проекта. 6.5 Требования к резервированию и отказоустойчивости 6.5.1 Резервирование подсистемы Voice Portal 6.5.1.1 Детальные требования к резервированию будут проработаны на этапе разработки ТЗ. 6.5.2 Резервирование подсистемы сбора и хранения статистики 6.5.2.1 Подсистема сбора и хранения статистики должна состоять из следующих компонентов: 1. Компоненты сбора статистики. 2. Компоненты хранения статистики (сервера БД статистики). 6.5.2.2 Компоненты хранения статистики должны быть зарезервированы таким образом, чтобы обеспечить режим функционирования 24 часа в сутки, 7 дней в неделю, 365 дней в году, за исключением плановых отключений компонентов (режим технического обслуживания). 6.5.2.3 Детальные требования к резервированию будут проработаны на этапе разработки ТЗ. 69 7 Риски проекта В данном разделе представлены основные риски проекта, связанные с описанными функциональными требованиями Банка. Риски представлены в таблице 8: 70 Таблица 8 – Риски проекта построения нового IVR в соответствии с функциональными требованиями Банка № п. п. 1 Риск Кейс/Описание проблемы Недостаточное время отклика от Минерва и/или других внешних систем - В связи с тем, что большое количество сервисов должно получать информацию из внешних банковских систем, существует риск того, что такие запросы могут занимать больше времени, чем комфортное ожидание Клиентом информации. Возможные последствия риска Для Клиента: • Невозможность заполнения карточки Клиента за время приветственного сообщения в IVR. • Отсутствие необходимых данных для построения персонального IVR, как следствие получение стандартного меню. • Длительное ожидание получения персональных сервисов, как следствие неудовлетворенность Клиентов обслуживанием и понижение лояльности к дистанционным сервисам в IVR. Для Банка: • Доработка сервисного слоя Минерва. • Реинжиниринг процессов в Минерва. • Частичный отказ от сервисов, получающих информацию от внешних систем. • Как следствие, недостижение целей проекта. Для Исполнителя: • Сдвиг сроков проекта. Способы минимизации риска • Тестирование быстродействия отклика от Минерва. • Тестирование отклика от Минерва при прогнозируемой нагрузке на КЦ. • Определение максимального времени ожидания отклика от Минерва (либо другого банковского сервиса, предоставляющего информацию) со стороны IVR для каждой функции Договоренности по управлению, при срабатывании риска Банк полностью принимает данный риск и берет на себя ответственность при его срабатывании 71 № п. п. 2 Риск Недостаточное быстродействие внутренних сервисов Системы вследствие больших размеров внутренних БД Кейс/Описание проблемы Многие функции и сервисе Системы предполагают хранение большого количества оперативной и/или исторической информации полученной от внешних, для себя, систем. Вследствие чего, существует риск нестабильной работы Системы. Возможные последствия риска Для Клиента: • Отсутствие необходимых данных для построения персонального IVR, как следствие получение стандартного меню. • Длительное ожидание получения любых сервисов Системы, как следствие повышение неудовлетворенности Клиента. Для Банка: • Частичный отказ от сервисов Системы. • Изменение требований к глубине хранения информации и объемам БД в Системе. • Недостижение целей проекта. Для Исполнителя: • Большое количество доработок • Проблемы ввода Системы в промышленную эксплуатацию. Способы минимизации риска • Точное определение объемов данных, хранящихся на стороне Системы. • Точное определение глубины хранения данных, хранящихся на стороне Системы. • Нагрузочное тестирование на проектируемую Систему и выдача рекомендаций по оптимизации и/или способам хранения данных в Системе. Договоренности по управлению, при срабатывании риска 72 № п. п. 3 Риск Кейс/Описание проблемы Сложность логических выражений Критериальной модели Системы В связи с тем, что в целевом описании функциональных требований к Системе, логика построения меню IVR, для различных типов Клиентов, достаточно сложная и зависит от большого количества факторов, то существуют риски корректной настройки таких логических выражений. Возможные последствия риска Для Клиента: • Неверное определение и предоставление необходимых для Клиента сервисов. Для Банка: • Трудоемкость разработки логики обслуживания Клиентов. • Наличие высококвалифицированного персонала для управления Системой. • Неэффективное использование возможностей Системы, как следствие необоснованное удорожание проекта. Для исполнителя: • Высокая трудоемкость реализации, как следствие высокая стоимость проекта и сроки его реализации. Способы минимизации риска • Разработка этапности реализации сервисов и функций Системы. • Определение приоритетных сервисов и динамических моделей обслуживания Клиентов. • Проведение исследований (среди Клиентов Банка) на предмет потенциальной удовлетворенности от динамически предоставляемой информации и сервисов. • Тестирование функционала Системы на выделенной группе Клиентов Банка, в целях определения удовлетворенности Клиентов сервисами Банка. Договоренности по управлению, при срабатывании риска 73 № п. п. 4 Риск Кейс/Описание проблемы Неверное определение критериев при настройке Критериальной модели Системы Как следствие риска сложности логических выражений: При построении логики обслуживания Клиента, Администратор Системы может выбрать неверные критерии. При этом, формально построенная логика может не быть противоречивой, однако, ожидаемого эффекта Банк не достигнет Возможные последствия риска Для Клиента: • Неверное определение и предоставление необходимых для Клиента сервисов. Для Банка: • Трудоемкость сопровождения и тестирования Системы. • Недостижение поставленных целей Для Исполнителя: • Большое количество запросов в службу поддержки. Способы минимизации риска • Разработка этапности реализации сервисов и функций Системы. • Определение приоритетных сервисов и динамических моделей обслуживания Клиентов. • Определение минимально необходимого набора критериев Критериальной модели (в соответствии с определенными этапами разработки и внедрения Системы). Договоренности по управлению, при срабатывании риска 74 № п. п. 5 6 Риск Неудовлетворенность пользователя системы Отсутствие гарантий/полной информации по реализации части требований со стороны банка Кейс/Описание проблемы Возможные последствия риска При построении сложной, многофакторной логики обслуживания, может сложиться ситуация, когда одному и тому же клиенту при каждом последующем звонке будут строиться разные меню. Существует риск, что большому пласту Клиентов такая динамика будет неудобна. Для Клиента: В связи с тем, что реализация сервисов в IVR напрямую зависит от функций в сервисном слое Минерва, которые на настоящий момент не реализованы, существует риск сдвига сроков проекта до окончания реализации функционала на стороне Банка Для Банка, для Исполнителя: • Неверное определение и предоставление необходимых для Клиента сервисов. Для Банка: • Неудовлетворенность Клиентов. • Недостижение поставленных целей • Сдвиг сроков проекта Способы минимизации риска • Проведение исследований (среди Клиентов Банка) на предмет потенциальной удовлетворенности от динамически предоставляемой информации и сервисов. • Тестирование функционала Системы на выделенной группе Клиентов Банка, в целях определения удовлетворенности Клиентов сервисами Банка. • Разработка календарных планов реализации сервисов в Минерва. • Контроль соблюдения плана. • Передача информации о сроках разработки Исполнителю Договоренности по управлению, при срабатывании риска 75 № п. п. 7 Риск Кейс/Описание проблемы Риск качества синтеза речи В связи с потребностями Банка в использовании технологий синтеза речи (как аналога предзаписанным сообщениям) существует риск некачественного синтеза речи, с использованием технологий TTS (text to speech) Возможные последствия риска Для Клиента: • Недовольство предоставляемыми сервисами Для Банка: • Неудовлетворенность Клиентов. • Недостижение поставленных целей Необходимость смены архитектуры КЦ в части выноса VP «во фронт» В связи с логикой целевого предложения, а также руководствуясь рекомендациями вендора, Разработчик предлагает запланировать архитектурное изменение решения. • Тестирование технологий синтеза речи. • Отказ, в части сервисов от синтеза речи и переход на предзаписанные сообщения. Для Банка и Исполнителя: • Трудозатраты по тюнингу синтеза речи. • 8 Способы минимизации риска Сдвиг сроков проекта Для Банка и Исполнителя: Изменение стоимости и сроков проекта. Отсутствие консолидированной статистики в существующих системах отчётности по вызовам которые завершились в IVR без перевода на оператора. Утверждение концепции изменений в архитектуре КЦ и согласование ТЗ на разработку проекта. Описание бизнес процессов на которые может повлиять изменение архитектуры решения. Предварительное согласование изменений с бизнес подразделениями. Договоренности по управлению, при срабатывании риска 76 № п. п. 9 10 Риск Кейс/Описание проблемы Возможные последствия риска Отказ или несогласие Банка предоставлении тестовых ресурсов банка Для полнофункционального тестирования, а также для ускорения процесса разработки и отладки системы, необходимы тестовые ресурсы банка, повторяющие целевую конфигурацию решения. Для Банка и Исполнителя: Общий риск по возможному появлению факторов, влияющих на трудозатраты проекта На этапе формирования ЧТЗ для каждого этапа, существуют риск того, что будут появляться факторы/требования, которые невозможно было оценить заранее, но влияющие на изменение трудозатрат. Для Банка и Исполнителя: Изменение стоимости и сроков проекта. Изменение стоимости и сроков проекта. Способы минимизации риска Сторонам заранее договориться о тестовой среде и всех нюансах, связанных с ее использованием Пересмотр рамок/оценок этапа по факту подписания ЧТЗ на соответствующий этап Договоренности по управлению, при срабатывании риска 77 Приложение А Кейсы работы Системы 1) В Банк обращается действующий клиент, который имеет задолженность по какому-либо продукту. В данном случае вызов должен быть маршрутизирован: Коллекторам; Выделенная схема обслуживания в IVR. Схема работы по кейсу: а) б) в) г) звонок клиента; проверка номера – есть в БД Банка; проверка задолженности по всем продуктам банка – имеется просроченный платеж; перевод клиента на выделенное обслуживание (вариант обслуживания настраиваемый на стороне банка – либо перевод на коллектора, либо озвучивание информации о просрочке и вариантах погашения задолженности). 2) В Банк поступает обращение клиента, внесенного в Черный. Вызов данного клиента должен быть завершен после озвучивания причин «сброса». Схема работы по кейсу: а) б) в) г) звонок клиента; проверка номера – есть в БД банка; проверка наличия номера в ЧС банка – номер внесен в Черный список; клиенту озвучивается информация – Уважаемый клиент, в связи с некорректными обращениями в Банк, ваш вызов не может быть осуществлен (или любая другая информация от Банка); д) вызов завершается. 3) В Банк обращается клиент из «Белого списка». Клиенты из данного списка должны напрямую попадать к оператору, минуя весь IVR (возможно настройка на выделенную skill группу – настройки соединения с оператором и вариантов обслуживания клиента в IVR на стороне Банка). Схема работы по кейсу: а) б) в) г) звонок клиента; проверка номера – есть в БД банка; проверка наличия номера в Белом списке банка – номер внесен в Белый список; маршрутизация вызова на … (либо на оператора, либо на выделенную группу, либо озвучивание персонального меню – варианты настройки на стороне банка). 4) В Банк обращается клиент сегмента «низкодоходный клиент». В данном случае применяется схема прохождения вызова в IVR с «затрудненной» схемой выхода на оператора. Схема работы по кейсу: а) звонок клиента; 78 б) проверка номера – есть в БД Банка; в) проверка статуса клиента – клиент сегмента «низкодоходный»; г) применение схемы прохождения вызова в IVR для «низкодоходных клиентов» (схема, где выход на оператора вынесен «за пределы» главного меню – находится в сервисных ветках или информационных ветках – варианты настроек выхода на оператора на стороне Банка). 5) В Банк обращается клиент, который за установленный интервал времени уже несколько раз обращался в Банк (порог по количеству повторных обращений устанавливается на стороне Банка) и все диалоги клиента с сотрудником Банка завершались регистрацией обращения как «Получение информации по балансу карты». В данном случае при повторном обращении в КЦ Клиент в IVR должен первым пунктом слышать информацию с предложением прослушать «Баланс карты». Схема работы по кейсу: а) звонок клиента; б) проверка номера – есть в БД Банка; в) проверка информации по предыдущим звонкам клиента в КЦ за заданный интервал времени – клиент обращается повторно; г) проверка количества повторных обращений – клиент обращался Х раз; д) получение информации по зарегистрированным тематикам обращений Клиента – все обращения отмечены как «Баланс карты»; е) в IVR применяется схема, в которой первым пунктом для клиента озвучивается информация – Узнать баланс карты. 6) В КЦ обращается клиент, который имеет кредитную карту. Карта активирована и период обращения клиента в КЦ совпадает с периодом погашения кредита. В данном случае клиенту в IVR должна быть озвучена информация по кредитным картам первым пунктом (о способах погашения кредита, сумме погашения и т.д.). Вариант настройки маршрутизации вызова должен быть реализован на стороне Банка. Схема работы по кейсу: а) б) в) г) д) звонок клиента; проверка номера – есть в БД Банка; проверка продуктов клиента – клиент имеет кредитную карту; проверка статуса карты – карта активна; проверка периода погашения кредита – период погашения кредита=периоду обращения клиента; е) клиенту озвучивается информация о: способах погашения кредита, сумме погашения и т.д. 79 Приложение Б Требования к графическому пользовательскому интерфейсу 1 Описание интерфейса/программы. Данный интерфейс/программа (далее – «IVR_UI») должна быть предназначена для просмотра и изменения конфигурации системы «IVR». Она должна представляет собой web-приложение, работающее под управлением браузера Internet Explorer версии ХХ или выше. IVR_UI должен обеспечивать просмотр и изменение следующих настроек: сегменты (DNIS_Group); регионы; пункты меню; звуковые файлы; шаблоны смс сообщений, отправляемые из IVR; интеграцию с автоматизированными банковскими системами; использование «черного списка» абонентов контактного центра; использование «специальный реестр» абонентов контактного центра; использование функции «отчеты по статистике IVR»; и другие настройки системы. 1.1 Авторизация (опционально**) Для авторизации в программе должны быть использованы доменные учетные записи банка. Для входа в программу должны быть использованы средства AD (Active Directory) c разграниченными правами доступа. Проверка Login/pass так же будет использоваться из систем AD банка. После успешного подключения, программа должна проверить, подключены ли в настоящий момент к программе другие пользователи и проинформировать* об этом как текущего пользователя, так и всех остальных кто на текущий момент уже авторизован в программе. Необходимо предусмотреть как минимум 4 типа пользователей с разными правами: Название роли Описание Параметры доступа IVR_admin Администратор системы Полный доступ IVR_Supervisor Супервизор системы Практически дублирует список функций роли Admin. С возможность изменения структуры/контента и т.д. IVR_User Пользователь системы Доступны права только на чтение, с возможность просмотра большинства контента и функций. Права на изменения отсутствуют. IVR_Guest Гость системы Доступны права только на просмотр основного дерева IVR и прослушивания контента. Доступ ко всем вспомогательным функциям отсутствует. 80 *Если подключено более одного пользователя, то необходимо координировать работу таким образом, чтобы не возникало конфликтов при сохранении информации. **Возможно рассмотреть вариант создания локальной БД содержащей логины/пароли 1.2 Размеры окна программы и масштабируемость Внешний вид окна программы должен обеспечивать просмотр всех элементов. В связи с тем, что IVR_UI будет работает в среде браузера, размер окна программы зависит от размера окна браузера. В случае если окно браузера будет иметь недостаточный размер для отображения всех элементов окна программы и часть элементов будет скрыта, должно быть предусмотрено отображение соответствующих полос прокрутки содержимого окна, как по горизонтали, так и по вертикали. 1.3 Окна и диалоги Для завершения работы с программой IVR_UI необходимо либо закрыть окно браузера, либо нажать соответствующую клавишу. При этом должно быть отображено окно с сообщением о подтверждении закрытия. Изменения конфигурации системы «IVR» автоматически не должно сохраняются на сервере IVR. Для того чтобы сделанные в программе изменения конфигурации вступили в силу, необходимо предусмотреть функцию сохранения конфигурации соответствующей клавишей. К изменениям конфигурации относятся все изменения, сделанные в программе «IVR_UI», включая: создание новых объектов (пунктов меню, регионов и др.), изменение конфигурации объектов, привязка звуковых файлов, создание SMS-шаблонов и т.д. 1.4 Многопользовательский режим Программа IVR_UI должна обеспечивать возможность работы в многопользовательском режиме. Работа в программе (изменения конфигурации) несколькими пользователями одновременно должна учитывать правила многопользовательского режима и имеет ряд ограничений. Например не возможность редактирования одного и того же пункта меню двумя пользователями, о чем второй и каждый последующий пользователь должны быть оповещены путем всплывающего сообщения. При завершении работы с программой одного из пользователей, все блокировки, ставшие следствием несохраненных изменений, будут удалены. 1.4.1 Ограничения «многопользовательского режима» Многопользовательский режим работы должен обеспечивать блокировку объекта, с которым сейчас работает конкретный пользователь. Объект становится заблокированным, если изменяются* какие-либо его параметры, либо он удаляется, либо меняется привязка звукового файла и т.д. *просмотр пунктов меню и прослушивание контента не является ограничением для блокировки Каждое изменение конфигурации конкретным пользователем должна создавать блокировки для всех других пользователей, уже подключенных к программе (без исключений). 81 Блокировка** должна устанавливаться как непосредственно на модифицируемый объект, запрещая его изменение для других пользователей программы. Так и на объекты, зависимые от изменяемого (например, вложенные пункты меню). При попытке изменить заблокированный объект должно выводиться сообщение об ошибке включающее в себе следующие параметры: название объекта; имя пользователя, действия которого привели к блокировке указанного объекта; дата и время начала блокировки объекта; **Необходимо планировать организацию работы нескольких пользователей с программой IVR_UI таким образом, чтобы исключить одновременное изменение/создание близких или зависимых объектов конфигурации. 1.5 Применение изменений: При проведении каких-либо изменений в структуре программы и последующее ее сохранение ни в коем случае не должно приводить к следующим действиям со стороны программы: «Выкидыванию» других пользователей из программы; «Отваливанию» абонентов, которые сейчас находятся в данном пункте; «Падению» всего IVR в целом. 2 Обязательные функции программы. 2.1 Перезагрузка программы: В случае если какие-то изменения не применяются/сохраняются по какой-либо причине, в системе должна быть предусмотрена функция принудительной перезагрузки для конкретного пользователя, с обязательным обновлением до актуальной структуры 2.2 Журнал изменений В системе должна присутствовать функция «журнал изменений», в которой бы отражались абсолютно все изменения, которые были произведены в IVR. Журнал должен содержать следующую информацию: Дата и время изменения; Логин пользователя сделавшего изменение; Событие (изменение структуры; загрузка звукового файла и т.д.); Пункт меню; Отдельно должны отображаться системные сообщение – остановки/запуска, разного рода технические ошибки и т.д. перезагрузка; Хранение данных в журнале должно обеспечиваться минимум на 3 месяца*. *Возможность ручной очистки истории необходимо полностью исключить! время 82 Просмотр событий в журнале должен обеспечиваться в среде браузера. Данные должны выводиться в хронологическом порядке, но при желании пользователь мог отсортировать их по любому из полей приведенных выше. Должна быть предусмотрена возможность выгрузки журнала как всего, так и за определенный период. Формат выгрузки предпочтительно «*.xls» 2.3 Возможность загрузки списков клиентов (черный/белый/спец.реестр и т.д.) Приложение должно обеспечивать возможность работы с наборами списков клиентов, для разных реестров. Например «черный список» - это клиенты, которые при попытке соединения с оператором, должны получать информационное сообщение об отказе: Варианты реестров: Черный список; Белый список; Для работы с реестрами должны быть предусмотрены возможности загрузки как целыми списками (например в формате «*.xls»; «*.csv») либо в ручную, по одному номеру. Работа со списками должна обеспечивать ручное редактирование уже внесенных списков: Поиск; Изменение; Удаление; Выгрузка; 2.4 Статистика Приложение IVR должно обеспечивать сбор исторической статистики. Выгрузка исторической статистики должна производиться прямо из приложения, посредством запуска определенной функции. 2.4.1 Примеры отчетов: 2.4.1.1 Отчет «Общая информация по звонкам Параметр отчета Общее количество поступивших вызовов*. Описание параметра Общее количество поступивших вызовов на IVR, за определенный промежуток времени. Комментарий Значение должны быть представлены в двух вариантах: Количество вызовов Общее количество звонков ушедших на оператора, абсолютное (количество звонков) относительное (процентное отношение, относительно материнского меню.) 83 переведенных на оператора* за определенный времени. промежуток Количество обращений к автоматизированным банковским системам * Общее количество звонков которые обратились к автоматизированным банковским системам, за определенный промежуток времени. Количество автоматических идентификаций Количество автоматических идентификаций клиента, без ввода дополнительных параметров Количество ручных идентификаций (успешных) Количество успешных идентификаций клиентов (все виды) Количество ручных идентификаций (не успешных) Количество не успешных идентификаций клиентов (все виды) «Количество отправленных SMS» Общее количество отправленных SMS шаблонов из IVR. *Данные должны представлять собой иерархическую модель, и при необходимости детализировать информацию по каждому заведенному DNIS отдельно. DNIS, в свою очередь, должен детализировать информацию еще на один шаг глубже. 84 2.4.1.2 Отчет «Время в IVR» Параметр отчета Описание параметра Название DNIS Название DNIS, по которому строится текущий отчет, за определенный промежуток времени. Время Среднее время нахождения в текущем DNIS (сек.) Комментарий Детализация подменю должна быть до 1 уровня вниз. 2.4.1.3 Детальная информация по звонкам Параметр отчета Описание параметра Комментарий «Количество уникальных посещений» Параметр содержит значение посещений меню в рамках одной сессии (звонка) по одному уникальному номеру. Если клиент, прослушав пункт меню, перемещается по IVR, а затем возвращается в данный пункт, значение счетчика = 1 «Количество посещений» Параметр содержит значение посещений меню в рамках одной сессии (звонка), без привязки к номеру телефона. Если клиент, прослушав пункт меню, перемещается по IVR, а затем возвращается в данный пункт, значение счетчика = 2 «Относительно материнского меню (%)» Количество посещения данного пункта меню, относительно пункта являющегося материнским для данного (в процентах). «Завершено клиентом» Параметр содержит значение звонков завершенных клиентом в данном меню «Завершено IVR» Параметр содержит значение звонков завершенных системой «Переведено оператора» на «IVR_Gross» Пример формы отчета: IVR_report (пример шаблона).xls Например, дефолтное разъединение по не активности клиента Параметр содержит значение звонков переведенных на оператора из данного меню. Количество звонков завершенных в системе (в процентах). «звонки которые не ушли на оператора»/«общее количество уникальных звонков» 85 2.4.1.4 Детальная статистика по звонку: Параметр отчета «EDUID» Описание параметра Комментарий Уникальный идентификатор звонка «CPN» № Абонента «Дата и время звонка» Дата и время конкретного звонка «IVR_Tree_ID» Ветка IVR из которой клиент вышел на оператора «SMS» Наличие признака заказа информационного сообщения «SURVEY» Наличие признака перевода на IVR по качеству обслуживания «ANSW1» Ответ на первый вопрос Значение в формате «0/1», где «0» - клиент не переходил в данный раздел; «1» клиент явно поступил в данный раздел; Значение в формате «1-5» Ответ на второй вопрос Значение в формате «1-2» Ответ на третий вопрос Значение в формате «1-2» 1/0 анкеты «ANSW2» анкеты «ANSW3» анкеты «ANSW4» Ответ вопрос анкеты «ANSW5» на четвертый Значение в формате «1-5» Ответ на пятый вопрос Значение в формате «1-5» Ответ на шестой вопрос Значение в формате «1-5» анкеты «ANSW6» анкеты 2.4.2 Ограничения: В функции должна быть предусмотрена возможность остановки/возобновления сбора статистики, для минимизации нагрузки на сервер. Перед формирование отчета должно выводиться сообщение с возможностью выбора следующих ограничений/фильтров: Название ограничения Описание Период (дата) Возможность задания определенного интервала в формате дд.мм.гггг (от и до) Период (время) Возможность задания определенного интервала в Комментарий 86 формате чч:мм (от и до) Сегмент (DNIS) Возможность выбора определенного DNIS или нескольких DNIS по которым необходима выгрузка Общий/динамический возможность выгрузку статистики как за выбранный период целиком, так и в динамике* за несколько дней При формирование динамического отчета, детальная статистика будет отсутствовать Система должно обладать достаточными ресурсными, что бы обеспечивать хранение статистики до 3 месяцев для отчетов 2.4.1.1., 2.4.1.2. и 2.4.1.3. Для отчета 2.4.1.4 - до 45 дней. 87 2.5 Функция отправки SMS. Система должна обеспечивать возможность создания и отправки SMS прямо в структуре IVR. Для этого должен быть проработан дополнительное окно/поле в котором пользователь системы сможет его вводить. Ввод символов должен содержать как русские (а-я; А-Я) так и латинские (a-z; A-Z) символы, а так же цифры (0-9) и специальные символы (!@#$%^&* и т.д.). Ограничение на ввод знаков должно составлять не менее 1200 символов. 2.6 Хранилище звуковых сообщений. В системе должно быть предусмотрена возможность хранения звуковых фрагментов необходимых для привязки к конкретному пункту пеню. Все привязки звуковых файлов должны обеспечиваться только из него. Т.е. для того что бы привязать звуковой файл к конкретному пункту пеню необходимо сначала залить его на сервер, а затем через дополнительный интерфейс привязать его к тому или иному пункту. В случае если будет происходить удаление звуковых файлов с сервера (через интерфейс), система должна проверить не привязан ли он к какому-нибудь пункту меню, и если такая привязка существует, отменить операцию удаления и выдать сотруднику соответствующее оповещение. Для того что бы можно было поддерживать актуальность звуковых фрагментов, в интерфейсе хранилища должно быть предусмотрено отображение информации об дате заливки конкретного звукового фрагмента на сервер и дате последнего использования/привязки. 2.7 Привязка звуковых сообщений. Основная функция системы, которая позволяет привязать звуковой контент к конкретному пункту меню. При выборе звукового файла, должен открываться интерфейс хранилища звуковых файлов (п.2.6), и уже из которого и будет сделан выбор. В настройках (а в дальнейшем и свойствах выбранного пункта меню) должен выставляться параметр «прерываемый»/«непрерываемый» звуковой элемент*. *В случае если клиент прослушивает звуковой контент с пометкой «непрерываемый», он не сможет перемещаться дальше по меню, до тех пор, пока не дослушает звуковой файл до конца. 2.7.1 Типы звуковых сообщений: Каждый пункт меню может содержать несколько типов звуковых сообщений, которые будут проигрываться во время того или иного действия клиента: «Приветствие*» – первое звуковое сообщение, которые слышит клиент банка, при попадании в меню IVR. (Настраивается на уровне Сегмента); «Основной» - основное звуковое сообщение, который будет проигран клиенту; «Доп.Непрерываемый» - дополнительное звуковое сообщение, которое может стоять в данном пункте меню (до основного звукового контента), и не может быть прерван клиентом во время прослушивания (Настраивается на уровне Региона и ниже); 88 «Ошибка выбора» - звуковое сообщении, которое проигрывается клиенту в случае ошибочного выбора пункта меню(Настраивается на уровне Региона и ниже). «Прощание» - звуковое сообщение, которое проигрывается клиенту перед разъединением с IVR (Настраивается на уровне пунктов меню и ниже). «Прощание_Default» - звуковое сообщение, которое проигрывается клиенту в случае его не активности (Настраивается на уровне пунктов меню и ниже). «Навигация» - звуковое сообщение, которое проигрывается клиенту, с описание возможности перемещения по меню (Настраивается на уровне пунктов меню и ниже). «Перевод» - звуковое сообщение, которое проигрывается клиенту перед переводом звонка на оператора. *Приветствие должно меняться в зависимости от часового пояса абонентов поэтому, поэтому необходимо предусмотреть возможность загрузки как минимум 4 различных файлов, для каждого из которых должны выставляться разные часовые интервалы, например: Приветствие №1 «Доброе утро, вас приветствует ВТБ24», интервал проигрывания с 06:00 по 09:59 местного времени абонента (либо GMT+X) Приветствие №2 «Доброе день, вас приветствует ВТБ24», интервал проигрывания с 10:00 по 19:59 местного времени абонента (либо GMT+X) И т.д. 2.8 «Черный/белый» список. 2.8.1 «Черный список» (ЧС) – Функция системы которая позволяет ограничивать выход на оператора для конкретного абонента. В системе должен быть разработан интерфейс который бы позволял вносить абонента в «черный» список. Данный интерфейс должен содержать следующую информацию: «Номер» - Номер клиента компании, который внесли в ЧС; «Время добавления» - дата и время внесения данного абонента в ЧС; «Время разблокировки» - дата и время разблокировки данного абонента; «Сотрудник» - логин сотрудника, который вносил данного абонента в ЧС; «причина внесения» - Комментарий сотрудника. 2.8.1.1 Автозаполнение По умолчанию поля «время добавления», «время разблокировки» и «сотрудник», должны заполняться автоматически «Время добавления» - текущая дата и время; «Время разблокировки» - текущая дата и время +24 часа; «Сотрудник» - логин сотрудника который внес данный номер в реестр; При необходимости сотрудник должен иметь возможность корректировать данные поля. Интерфейс для ввода данных, должен быть представлен в удобоваримом виде (например, календарь) и должен осуществлять ряд минимальных проверок на релевантность данных, например: нельзя ввести дату и время ранее текущей даты. 89 Нельзя внести номер абонента содержащий менее 10 цифр. И т.д. Поле логин сотрудника закрыто для редактирования. 2.8.1.2 Просмотр и выгрузка Интерфейс функции должен обеспечивать возможность просмотра клиентов, которые сейчас находятся в ЧС, а так же клиентов которые ранее были внесены. При необходимости сотрудник должен иметь возможность выгрузить реестр внесенных номеров. (формат выгрузки EXCEL) 2.8.1.3 Поиск Интерфейс функции должен обеспечивать возможность осуществлять поиск по*: По сотруднику; По номеру телефона (с возможность задания масок); По дате добавления или разблокировки; По параметру действующий или архивный (или оба); *Должна быть возможность комбинирования нескольких фитров. 2.8.1.4 Досрочное удаление из ЧС В случае необходимости Администратор IVR может удалить абонента из ЧС. Для этого должна быть предусмотрена соответствующая кнопка при просмотре реестра. 2.8.1.5 Ограничения Занесение и удаление номеров в ЧС должно осуществляться только сотрудниками системы; Досрочное удаление номера из ЧС не должно приводить к удалению записи из реестра архива; Занесение номеров в ЧС должно осуществляться без дополнительной перезагрузки приложения IVR; Доступ к ЧС, должен предоставляться только ролям Supervisor и выше. Система должна обеспечивать хранение данных в архиве не менее 3 месяцев+15 дней. 2.8.2 «Белый список» - функция системы которая позволят обеспечивать отдельному реестру номеров быстрый доступ к сотрудникам КЦ. В системе должен быть разработан интерфейс позволяющий вносить определенные номера в «белый список». Данный интерфейс должен содержать следующую информацию: «Номер» - номер клиента, который был добавлен в реестр; «Время добавления» - дата и время добавления в реестр; «Сотрудник» - логин сотрудника, который добавил запись; 90 2.8.2.1 Поиск Интерфейс функции должен обеспечивать возможность осуществлять поиск по*: По номеру телефона (с возможность задания масок); 2.8.2.2 Удаление Интерфейс системы должен обеспечивать возможность удаления номеров из данного реестра. 2.8.2.3 Хранение и выгрузка: Система должна обеспечивать хранение данных о номерах, на постоянной основе до момента удаления их из реестра. При необходимости администратор системы должен иметь возможность выгрузить реестр номеров «белого списка», в отдельный файл (EXCEL). 2.9 Функция «предобработки звонка». В системе должен быть предусмотрен интерфейс позволяющий маршрутизировать –звонок в тот или иной сервис в зависимости информации пришедший со звонком и полученной от ИС банка. Данный интерфейс должен включать в себя все параметры звонка и от определенного их набора предлагать выбрать один из уже созданных сегментов IVR или завести новый. Например: DNIS – «VTB24»; Region – «77»; Grade – «Prime»; Etk… То для такого набора параметров звонок необходимо поместить в ветку (сегмент) IVR – «Hight». Функция «предобработки звонка» должно позволять отключать проверку того или иного параметра, для этапа предобработки. Интерфейс функции, должен представлен в виде отдельного окна/формы, в который должны содержатся все наборы типовых предобработок. Помимо ввода конкретных названий того или иного параметра, должна быть предусмотрена возможность ввода «макро подстановок»: Любое значение (пустое/непустое); Любое не пустое значение; 91 Любое пустое значение; Любое значение кроме Х; 2.9.1 Ограничения Система должна проверять наличие одинаковых наборов параметров. В случае их дублирования выдавать соответствующие сообщение. Если требуется разделить звонки с практически одинаковыми наборами параметров (отличие одном из них). Необходимо предусмотреть систему приоритезации одного правила над другим. Например: Сегмент DNIS Region GRADE Prioritet MASS MASS ANY ANY 2 PRIME MASS 77 ANY 1 Это означает* что звонки с набором параметров: «Region – 77»; «Grade – любой»; «DNIS Mass»; идут в сегмент «PRIME»; в то время как остальные регионы, в сегмент «MASS». *Если бы приоритет был расставлен по другому, то сначала бы была проверка по первому набору параметров и звонки 77 региона пошли бы в сегмент «Mass» как и все остальные. Второе правило уже бы не проверялось. 3 Конфигурационные параметры. 3.1 Внешняя структура. Внешняя структура основного дерева IVR, должна представлять собой структурированную последовательность с выраженной иерархической зависимостью: «VTB24» Уровень 2 Уровень 3 Уровень 4 Уровень 5 Уровень Х Сегмент 1 (DNIS) Регион 1 (Region) Главное меню (GM) Пункт 1 Пункт 1.1 Пункт 1.1.Х Регион 2 (Region) Главное меню (GM) Пункт 2 Пункт 1.2 Пункт 1.2.Х Регион 3 (Region) Главное меню (GM) Пункт 3 Пункт 1.3 Пункт 1.3.Х Регион Х (Region) Главное меню (GM) Пункт Х Пункт 1.Х Пункт 1.X.Х Этап Уровень 1 При выборе каждого элемента дерева IVR, в интерфейсе программы должны отображаться: Свойства конкретного элемента; Параметры звукового файла (свойства/название/прослушка и т.д.); Элементы управления/модификации конкретного пункта меню; 92 Элементы управления выходом на конкретный VDN, для распределения на группу операторов; Элементы управления ввода «непрерываемого звукового фрагмента» (п.2.7.); В приложении должна быть предусмотрена возможность копирования всего дерева IVR (во всеми внутренними привязками файлов, структуры и т.д.) или его части, для дальнейшей вставки. 3.2 Первый уровень иерархии («DNIS/Сегмент»). Для каждого набора параметров звонка (п.2.8.) должен соответствовать определенный «Сегмент» IVR. Который(/ые) является верхним уровнем каждого дерева IVR, со своим набором параметров и звуковых файлов. Каждый сегмент должен обладать уникальным набором параметров. При попадание в сегмент, клиенту проигрывается приветственное сообщение которые залито для конкретного сегмента. 3.3 Второй уровень иерархии («регион»). После прохождения главного меню, клиент попадает в ветку принадлежащую к своему региону обслуживания, для этого должны быть реализовано поле в котором этот параметр будет прописан. Если для какого-то региона нет четко прописанной ветки с регионом, клиент попадает в ветку с признаком «ХХ», где меню будет унифицировано для всех клиентов. 3.3.1 Ограничения В системе не должно быть двух регионов с разными названиями, но одинаковыми кодами регионов. Если пользователь пытается сохранить такой регион или структуру, ему должно быть выведено соответствующее сообщение об ошибке. 3.3.2 Настройки В настройках данного уровня, должны задаваться основные параметры, которые будут применимы к звонку во время его дальнейшего хождения по IVR: Название региона; Код региона (из списка Автокодов); Доп.Неприрываемый – настройка включения/отключения пункта дополнительного сообщения (перед основным.); Диапазон – интервал времени в течении которого проигрывается доп.фрагмент (при выключенном параметре доп.фрагмент проигрывается постоянно); Звуковой файл – название основного звукового файла, который проигрывается при попадании в данный пункт меню; VDN – точка перевода на оператора; Default – действие по умолчанию, используется для случаев если клиент не выбирает; 93 3.4 Третий уровень иерархии («Главное Меню»). Главное меню представляет собой звуковой файл, который привязан к уровню 2, для текущего уровня настройка дополнительных параметров не требуется. 3.5 Четвёртый уровень и т.д. («пункт меню») Конкретный пункт меню IVR, который может быть как промежуточным звеном в рамках текущего дерева, так и оконечной точкой меню в которой со звонком производят какое-либо действие. Например – «перевод на оператора»; «отправка SMS» и т.д. 3.5.1 Настройки В настройках данного уровня, должны задаваться основные параметры, которые будут применимы к звонку во время его дальнейшего хождения по IVR: Доп.Неприрываемый – настройка включения/отключения пункта дополнительного сообщения (перед основным.); Диапазон – интервал времени в течении которого проигрывается доп.фрагмент (при выключенном параметре доп.фрагмент проигрывается постоянно); Звуковой файл – название основного звукового файла, который проигрывается при попадании в данный пункт меню; VDN – точка перевода на оператора; Default – действие по умолчанию, используется для случаев если клиент не выбирает; N – параметр который будет определять, сколько раз будет проигран звуковой фрагмент после срабатывания действия «Default»; DTMF – dtmf-код меню, при нажатие на который в меню на уровень выше, клиент попадает в текущее; SMS – Шаблон SMS-текста который будет отправлен клиенту, после прослушивания звукового файла; Пиритизация вызова – параметр, который максимально увеличивает приоритет звонка при выходе его из данного меню на оператора; Ссылка – параметр, который выполняет перевод звонка в другой пункт меню (в рамках одного сегмента/региона); Параметр который завершает вызов (без перевода на оператора), после прослушивания звукового файла; Перевод – параметр который позволяет отправить звонок на внешний номер телефона; GM – параметр который переводит звонок в главное меню (текущего сегмента/региона), после прослушивания звукового фрагмента.
