Голосовой помощник для колцентра интернет-провайдера: опыт команды Ziax

Система автоматически обрабатывает до 85% входящих звонков.

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

Руководители провайдера вышли на нас с целью провести тестирование нашего решения на первой линии технической поддержки. Перед нами также стояла своя локальная задача — доработать Ziax для обработки входящих вызовов.

Изначально наша команда занималась разработкой систем IP-ATC для контакт-центров, основная задача которых состояла в сборе данных о работе операторов по итогам дня, недели или месяца, необходимых руководителям для подсчёта заработной платы.

В процессе работы возник резонный вопрос: «Зачем нам собирать столько отчётов? Если будут роботы, то столько отчётов не нужно». Нам повезло, ведь именно в то время появились голосовые сервисы у «Яндекса» и Google. Так появился Ziax.

После нескольких пилотных проектов и успешных внедрений продукта на исходящие вызовы, мы решили сфокусироваться на обработке входящих. Уже на тот момент на рынке стали появляться сервисы автообзвонщиков с якобы «искуственным интеллектом» и с использованием «псевдонейронной сети».

Но в таком ПО «под капотом» была классическая блочная система и скриптовая логика работы бота. Изучив подробно функционал конкурентов, мы поняли, что слабые места всех их сервисов — обработка входящих вызовов.

Заказчики для нового направления появились практически сразу, и одним из них стал крымский интернет-провайдер, которому требовалась именно обработка входящих звонков, включающая такие операции по решению следующих вопросов пользователей:

баланс на лицевом счете;
номер лицевого счета по SMS;
обещанный платеж;
приостановка обслуживания;
активация услуги после приостановки;

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

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

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

АОН клиента (телефонный номер, с которого звонит клиент);
имя клиента (если есть).

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

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

Мы обучили систему на извлечение параметра «номер договора» и сейчас проблем с извлечением не возникает.

Для извлечения параметров мы используем машинное обучение. Благодаря тому, что Ziax отслеживает контекст диалога и корректно понимает намерения собеседника (интенты), данные извлекаются корректно. У нас был кейс, где из одной фразы извлекалось сразу пять параметров, но и это не предел.

Далее необходимо было собрать модель для обучения. Мы проанализировали записи предыдущих звонков колцентра и составили лингвистическую модель. После этого начали заполнять агента в своей системе. Расписали все интенты и объединили их контекстами.

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

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

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

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

Безусловно, в первый месяц мы периодически обучали агента, исходя из постоянно получаемой обратной связи. Сейчас робот обрабатывает без ошибок 75-85% всех звонков. Лучший показатель у этого клиента — 87%. В среднем робот обслуживает 500–1000 входящих звонков в сутки. Клиент доволен и заказывает новые тематики, а робот постоянно расширяет свою базу знаний. Наша цель — чтобы робот без ошибок обрабатывал не менее 90% всех звонков.

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

Вот как наш робот из описанного выше примера общается с клиентами: