Журнал «Расчеты и операционная работа в коммерческом банке» № 3/2018
Термины «диджитализация» и «омниканальность» не только закрепились в лексике, но и стали обязательными элементами стратегии развития банков. При этом стратегия омниканальности подразумевает бесшовное взаимодействие клиента и банка во всех каналах одновременно без потери скорости обработки запросов и без дополнительной нагрузки как на специалистов контактного центра, так и на потребителя. Однако возможно ли добиться столь идиллической картины? Насколько сложно банку реализовать омниканальность и какие шаги требуется предпринять?
Рассмотрим более детально сложности, с которыми сталкивается большинство банков, идущих по пути диджитализации и омниканальности. Разберем вопросы, которые возникают у специалистов, отвечающих за реализацию диджитал-стратегии.
С какого канала начать?
Начните с наиболее релевантного для вашей аудитории канала, развивайте его, а затем по мере необходимости добавляйте новые. Чат в интернет-банке или мобильном приложении — хороший инструмент для старта и проверки идей. Фокусируясь на поиске возможностей, испытайте доступные в этих каналах инструменты. Кроме того, такой выбор позволит решить вопрос с идентификацией клиентов и избежать сложностей, возникающих при адаптации существующего инструментария для ведения диалогов в мессенджерах и социальных сетях.
Начиная поиск релевантного канала, опишите вашу целевую аудиторию и профилируйте клиентов. Оцените их покупательную способность, сегментируйте их по демографическим признакам, сформированности потребностей и другим параметрам. На основании полученной аналитики определите стратегию коммуникации и приступите к выявлению наиболее подходящего канала.
Критериями оценки могут быть ответы на вопросы: «Решает ли выбранный канал поставленные задачи?» и «Какова стоимость или окупаемость данного канала?». Выявите все существующие каналы, которые используют ваши клиенты; разделите их на обязательные и второстепенные на основе выводов по предыдущему этапу исследования; примите решение об этапах запуска.
Какие инструменты необходимо адаптировать, а какие банк получит вместе с новыми каналами?
Спецификой неголосовых каналов являются асинхронность и множественная итерационность. Именно поэтому наиболее востребованными инструментами при массовом обслуживании становятся роутинг и организация единой очереди. Применяйте инструменты, которые это учитывают. Для добавления к голосовым каналам цифровых используйте готовую интеграцию или API.
Плюсом в реализации стратегии омниканальности становится высокая доступность текстовых диалогов: можно применить их для обучения чат-бота и автоматизировать клиентский сервис. Тем не менее нужно учитывать, что не любая нейронная сеть может работать с банковской спецификой. В открытом доступе можно найти множество уже обученных нейронных сетей, например на базе Википедии. Используя такую сеть, мы получим результат, при котором слова банковской терминологии «кредит», «вклад», «заем» будут равнозначны по смыслу.
Необходима специфическая методология нейронной сети: ей требуется учитывать два аспекта — отраслевую специфику и канал взаимодействия. Например, корпус данных, сформированных на базе коммуникации контактного центра банка, оказывающего поддержку по электронной почте, дает неточную модель для построения диалогов в чатах. Под отраслевой спецификой мы подразумеваем невозможность использования полностью универсального готового продукта «из коробки». Практика показывает, что в данном случае невозможен прямой перенос специфики решения от клиента одной отрасли в другую. Опыт разработчика и понимание особенностей конкретной отрасли играют важную роль.
Есть ли отличия в параметрах голосовой и неголосовой коммуникации?
Наиболее серьезное заблуждение, с которым мы столкнулись, — измерение эффективности цифровых каналов по метрикам голосовых коммуникаций. Как мы уже упоминали, для каналов, где могут использоваться чат-боты, существует своя специфика:
- необходимая скорость реакции на обращение может обеспечиваться без участия оператора контактного центра. Опытным путем мы выяснили, что использование простого робота в чате позволяет гарантировать среднее время ответа (Time to Answer) в пределах минуты даже при пиковых нагрузках на контактный центр;
- больше нет пропущенных обращений. Abandon Rate всегда будет равен нулю благодаря чат-ботам. Любое входящее сообщение будет принято банком, обработано и задокументировано системой. Клиент получит ответ, даже если в контактном центре произошла чрезвычайная ситуация;
- при обслуживании в чатах и мессенджерах нет аналога одного из важнейших KPI кол-центра — Call Handling Time. Время диалога как параметр расходной статьи кол-центра неприменимо. При неголосовой коммуникации длительность контакта, то есть срок, в течение которого клиент остается на связи с вашим оператором с момента первого обращения до закрытия вопроса, может не оказывать никакого влияния на стоимость обработки запроса;
- один сотрудник одновременно ведет работу с несколькими клиентами. На примере реальных диалогов мы убедились, что довольно большой процент клиентов обращается в чаты в промежутках между делами. В связи с этим диалог может прерываться и возобновляться клиентом многократно. На практике один оператор может комфортно для клиентов вести до шести диалогов одновременно, получая позитивную реакцию в каждом из них. Зачастую от оператора не ожидают и не требуют мгновенного решения. Со стороны банка достаточно адекватной реакции в разумный срок.
Таким образом, внедряя цифровые каналы, необходимо пересмотреть подход к измерениям (что является темой для отдельной статьи).
Оправдает ли надежды чат-бот?
Рассматривая коммуникацию с клиентом, можно прийти к выводу, что большая часть запросов стандартны. Они решаются довольно просто, и возникает желание добавить чат-бот в процесс обслуживания. Однако, как показывает практика, есть причины, по которым такой подход, помимо сокращения запросов на живого оператора и желаемой экономии, может привести к снижению клиентского сервиса. Поэтому, приступая к задаче автоматизации, разбейте ее на несколько этапов:
1) описание кейсов для автоматизации;
2) определение бизнес-метрик;
3) сбор и обработка данных для обучения чат-бота;
4) описание бизнес-логики поведения чат-бота;
5) запуск тестовых кейсов для проверки.
При подобном этапном подходе чат-бот, безусловно, оправдает ожидания и окажется незаменимым инструментом клиентского сервиса.
Как настроить бота?
Начальный этап — определить, какие кейсы можно автоматизировать и реализовать при помощи чат-бота. Основной принцип — понимание того, с какой потребностью/болью/вопросом клиент к вам приходит и какой результат он ожидает получить. Зачастую банк понимает, что никаких сложных ботов создавать не требуется. Достаточно реализовать схему в диалоговом формате, то есть создать скриптового бота. Такой подход очень хорошо работает, если необходимо выполнить строгую фиксированную последовательность шагов, например оформить заявление. Применять здесь распознавание естественного языка не требуется.
Главное ограничение скриптового бота — он позволяет легко получить позитивный результат при минимальных вложениях, но может быть использован не более чем для 20 % обращений клиентов. Качественное решение остальных 80 % кейсов требует понимания контекста обращения и обработки естественного языка.
Важным этапом формирования требований и оценки качественной работы является определение бизнес-метрик. Предварительно должны быть сформированы критерии, по которым будет оцениваться успешность реализованного чат-бота. Это могут быть как качественные показатели, например точность ответа бота на вопросы из заранее подготовленной выборки, так и количественные показатели — процент обращений клиентов, решаемых ботом без перевода на операторов.
Главный этап — сбор и обработка данных для обучения чат-бота. Первое правило обучения — необходимы данные. Без этого хорошо сделать чат-бота очень сложно. Требуется получить информацию о том, как именно клиенты (в конкретном случае, в определенной тематике, в определенном контексте) задают вопросы по той или иной теме. Чем больше такой информации и ее вариантов, тем лучше будет бот. Очень важно: выбирая диалоги, проверяйте, что вместе с ответом не добавляется дополнительной информации, например уточнений или прощаний. Это усложнит обработку. Для обучения лучшим образом подходят реальные диалоги сотрудников с клиентами. Обязательным атрибутом сообщений в диалогах является наличие информации о том, кто отправил конкретное сообщение — специалист службы поддержки или клиент. Немаловажно и то, какова связь сообщений между собой, чтобы было однозначно понятно, являются ли они одним разговором.
Если диалогов для обучения чат-бота нет, то позаботьтесь о накоплении данных уже сейчас. Вы можете использовать решение с открытым API, выбрав инструмент, который поможет работать с большим объемом неструктурированных данных.
Настройки, определяющие общение с ботом подобно общению с человеком, следующие:
- приветствие (элементарный этикет);
- управление диалогом — необходимо определить, как работать с диалогами — при каких условиях бот может считать, что разговор окончен; может ли он закрыть диалог в системе; считать ли обработанные ботом, но переданные сотруднику диалоги переведенным обращением, или это два разных диалога;
- управление уточняющими вопросами — как вести себя боту, если клиент не отвечает; через какое время задавать вопрос;
- если в диалоге могут упоминаться тарифы, ставки, значения которых находятся в сторонней системе, то для их корректного отображения требуется установить связь с данными в сторонней системе.
Последний этап — определение тестовых кейсов для чат-бота.
Как и для любой задачи, для создания чат-бота требуется подготовка тестовых кейсов. Очень часто мы сталкиваемся с подходом «мы хотим получить магию». В результате на старте работы банки не обращают внимания на требования к бизнес-логике и на то, как они в итоге будут тестировать готового бота. Это может привести к тому, что на этапе тестирования, которое состоит из двух блоков: качество распознавания вопросов и соблюдение бизнес-логики, выясняются новые требования, и работу приходится возобновлять практически с самого начала.
Наш опыт показывает, что подготовительные работы в итоге могут занять не менее 14 дней, но результат того стоит.
Пример простого бота — бот, выполняющий функции митер-гритер в офисе. Он встречает клиента, выясняет его первичную потребность, направляет к нужному сотруднику или подсказывает, как можно провести операцию самостоятельно. Бот позволяет сократить скорость первой реакции на обращение клиента. При этом в зависимости от контекста он может выполнять следующие задачи:
- приветствие — сокращает время реакции на обращение клиента;
- прощание — оптимизирует время сотрудника;
- выявление потребности — сокращает время сотрудника на выяснение потребности клиента, сотрудник не тратит время на это и получает запрос уже со сформулированной потребностью;
- ответы на простые вопросы — фокусировка сотрудников только на сложных вопросах клиента, которые требуют комплексного решения;
- замена для дефолтных FAQ — получение информации в разговорном формате более естественно, чем поиск по статьям.
Усиливаем преимущества
На рынке представлены решения, которые позволяют в кратчайшие сроки начать реализацию стратегии омниканальности и работу в цифровых каналах. По нашему опыту, операционная деятельность — процесс, который лежит вне клиентской коммуникации, —медленнее адаптируется к изменениям клиентского сервиса. Например, мы видим, что ограничения ПО вынуждают сотрудников банка, отвечающих за развитие клиентского сервиса, тратить 95 % времени на настройку и отладку процессов.
Выходом может стать кастомизируемая платформа с максимальным числом каналов, которая легко встраивается в инфраструктуру и окружение банка. Ее использование позволяет уделить 5 минут изучению и отладке необходимого инструментария и сразу же приступить к реализации главной задачи — заботе о клиентах, исследованию их поведения и потребностей.
Мы ожидаем, что тенденция к увеличению каналов будет продолжать расти. Взаимное проникновение «голоса», ботов и технологий неголосового обслуживания будет усиливаться. Интернет вещей уже становится более доступным: подумайте о том, что вскоре в ваш контактный центр сможет обращаться не реальный живой человек, а устройство. Программное обеспечение должно поспевать за этой трансформацией, предлагать новые инструменты, интеграционные решения или расширенный API.
Используете ли вы программное обеспечение, готовое к предоставлению лучшего клиентского сервиса в новых условиях?
