«Здравствуйте! Я робот-помощник <службы доставки>. Звоню Вам для подтверждения заказа, который оформлен на номер <number>. Он же будет контактным для курьера. Вы подтверждаете номер для заказа <number>?».
Меня зовут Дмитрий Лупонос. Я программист 1С, который любит интеграции со сторонними сервисами (да, я существую). Я веду задачи, которые иногда касаются управления голосовым роботом. И да, это не спам, а совершенно добровольное согласие пользователя, который самостоятельно ставит галочку в поле «Звонки от робота».
С начала пандемии число пользователей доставки выросло лавинообразно. «По-старинке» через колл-центр работать становится неэффективно и затратно, поэтому бизнес ищет новые решения. Одно из таких – первичный звонок после заказа голосовым роботом, который проговаривает данные заказа и уточняет некоторые детали.
После предыдущей статьи, предлагаю отойти от 1С, и посвятить время анализу достаточно сложного сценария звонка, описание которого находится под катом.
Постановка задачи
В организации есть база, в которой появляется заказ. В течение 10 минут, пока склад начинает собирать его, необходимо убедиться, что получатель заказа знает о его создании, подтверждает свой номер телефона для контакта курьера организации, или меняет номер телефона без привлечения операторов. Если происходит замена номера, то склад при упаковке и вручении курьеру должен уже распечатать лист заказа с корректным номером.
На стороне МТТ с использованием voicebox.mtt.ru у меня есть доступ к настройкам скриптов и кампаний обзвона. Номера могут быть различных регионов, в зависимости от региона скрипт должен позвонить клиенту с подходящего номера. Этот вопрос решается в CRM-системе на стороне СУБД, а скрипт МТТ получает при инициации необходимые данные.
Во время звонка могут произойти события, которые робот должен обработать с помощью распознавания голоса клиента:
Прием звонка и подтверждение номера телефона.
Прием звонка и замена номера телефона.
Прием звонка, но отказ от разговора в связи с занятостью.
Прием звонка и отбой до завершения отработки скрипта.
Отказ от приема – нет соединения или не ответ.
Возможно, клиент не согласен общаться с роботом, поэтому необходимо соединять с оператором.
В результате звонка обновляется статус документа, в том числе о том, что номер изменился, на стороне CRM. Звонок совершается один раз. Я предполагаю, что ранее номер клиента верифицировали, поэтому нормализация номера телефона из базы данных клиентов не нужна.
На рисунке 1 укрупненная блок-схема постановки задачи в работу и обработка ответа от МТТ:
Настройка скрипта в интерфейсе VoiceBox МТТ
В интерфейсе VoiceBox МТТ (далее Voicebox) есть инструменты для настройки скриптов обзвона и извлечения отчетов с детализацией звонков, план нумерации.
Для решения поставленной задачи необходимо создать сценарий, привязать его к кампании, для чего также воспользуюсь одним из номеров из плана нумерации.
Создание сценария
Создаю сценарий с названием «Звонок-подтверждение покупателем». Все элементы взаимодействия представлены в виде блоков, в которых необходимо задать настройки и параметры.
На рисунке 2 полная схема звонка с обратной связью от клиента:
Основные блоки инициации, в которых выполняются все необходимые операции, расположены вверху:
Блок исходящего звонка клиенту.
блок информирования, в котором отключены все определения ответов.
Блок вопрос, в котором реализован весь механизм вопросов и ответов клиента.
Вторая линия блоков:
Блок уведомления о несостоявшемся звонке.
Обработка невозможности распознавания ответа клиента.
Блок определения замены номера под диктовку клиента.
Блок перевода на оператора.
Третья линия блоков:
Блоки уведомления нашей CRM о статусе звонка.
Блоки голосового оповещения клиента.
Завершение звонка.
Производит инициацию соединения по переданному номеру с передачей управления следующему блоку. В моем случае при ошибке соединения переводим на http-блок «Статус Недозвон», в случае успеха на следующий блок алгоритма.
Блок информирования «Инфоблок»
Нужен для произнесения стартового текста скрипта и дальнейшей передачи управления в вопрос. Так сделано для того, чтобы клиент при ответе не нарушил работу основного алгоритма распознавания, сформировав очередь ответов, например «Алло», «Да», «Привет». Содержит в себе текст и переменные, которые также затем заменяются на текст, который, в свою очередь произносит робот.
Блок вопрос
Содержит в себе достаточно сложную систему обработки ответов клиента. Его можно настроить на сбор ответов кнопками телефона или распознаванием голоса, рисунок 4.
В меню уже настроено определение ответов клиента, но для инициации действий со стороны абонента в поле текст, который будет проигрываться, внесен вопрос «Вы подтверждаете номер для заказа {{number_b}}?», где “number_b” — переменная с номером телефона клиента.
Следует пояснить, что ниже вопроса идут настройки и варианты ответов для распознавания. Вариантов обработки существенно больше, чем представлено в текущем алгоритме. Ожидание ответа клиента в секундах определяет время, до окончания которого должен быть произнесен ответ. Если этого не произошло, то алгоритм вновь произносит текст.
Поле «Запускать распознавание сразу после входа в состояние» подразумевает, что во время проигрывания текста клиент может начать отвечать и алгоритм уйдет на обработку результата распознавания сразу после фиксации всей фразы.
Кроме того, видно первый блок распознавания ответа, который обрабатывает ситуацию с запросом связи с оператором. В «случае успеха», а именно в случае, если алгоритм распознал запрос клиентом оператора, происходит перевод на блок связи с оператором.
Содержит в себе блоки распознавания ответов абонента. Остановлюсь на ситуации «Агрессия», когда алгоритм выявляет признаки недовольства клиента и должен сформировать соответствующий статус переходом «В случае успеха» на блок «Клиент недоволен».
Далее следует алгоритмы определения статусов (рис.7, рис.8):
«Некогда», когда неудобно говорить.
«Отказ», когда клиент отвечает на вопрос отрицательно, значит необходимо уйти на ветку замены номера.
«Сомнение», когда требуется разговор с оператором.
На рисунке 9 — завершение алгоритма со статусами ошибок. Скрипт тут обрабатывает ошибку распознавания голоса, не-ответ клиента или плохое качество связи, разрыв связи «переход в случае автоответчика или автоинформатора».
Блок невозможности распознавания ответов клиента
Эта часть собрана из уведомления о соединении с оператором и блоков перевода звонка и информирования. Она служит завершением работы алгоритмов распознавания речи при ошибке распознавания. В случае обрыва связи есть перевод на http-блок «Статус Недозвон», так как после выполнения алгоритма не выявлен ответ клиента. Если звонок продолжается, то вызывается оператор.
Блок перевода на оператора
Производит подключение к текущему звонку number_a, который содержит федеральный номер колл-центра или вход в SIP-подключение АТС колл-центра. Тему перевода в АТС организации, возможно, рассмотрим вне рамок этой статьи, как отдельный механизм взаимодействия телефонии организации с VoiceBox.
Распознавание номера под диктовку клиента
Более легкий алгоритм блока может распознать до 20 символов, при этом я указал, что при распознавании ожидаются только цифры. Поэтому в переменную “number_new” будет записан номер телефона, который продиктует клиент. Все просто.
Алгоритм определяет успех распознавания и не успех. При отказе алгоритма я перевожу на блок оповещения о соединении с оператором. Так что в случае успеха мы уверены, что набор цифр в блоке определения номера сформирован и будет передан в CRM. В CRM я могу гарантированно поставить статус замены номера. Кроме того, я могу нормализовать на стороне CRM номер и проверить его корректность и вероятность существования по базам номеров и префиксов.
HTTP-блоки оповещения о результате работы алгоритма
Приведу пример некоторых блоков оповещения о статусе работы алгоритма для полного понимания происходящего в скрипте.
Блок http-оповещения о статусе подтверждения формирует JSON-запрос и отправляет его по указанному адресу. Блок http-оповещения можно использовать в любом месте алгоритма скрипта для передачи различных статусов в CRM. В данном случае, при передаче на указанный адрес, формируется статус JSON с пустым значением переменной “number_new” и статусом подтверждения “accept”.
На второй вкладке настройки блока http-оповещения можно указать переход на случай ошибки отработки этого блока и на случай успеха. Так как даже если у меня не получилось отправить ответ из МТТ в CRM, я все равно завершаю звонок. Поэтому финал работы блока всегда один: «Завершение» всего скрипта. На стороне CRM анализируется время ответа, и, если прошло 5 минут, а ответ не поступил, то операторам колл-центра поступает задача позвонить клиенту.
В случае, если клиент изменяет номер, а алгоритм распознал успешно данные номера, то я уведомляю CRM о смене номера передачей переменной “number_new”, которая сформировалась в блоке распознавания ответа клиента.
Ответ на «агрессию»
Приведу пример сообщения, которое формируется, если в блоке интерактивного меню появилось недовольство клиента.
Уведомление содержит текст, который призван успокоить клиента. После произнесения текста звонок завершается, и статус передается в предыдущем блоке настоящему блоку http-уведомления для того, чтобы при разрыве соединения информация все же поступила в CRM как можно оперативнее. Далее подключается оператор для корректной отработки возражений с таким клиентом.
Запросы, передаваемые между CRM и VoiceBox
Для начала работы в VoiceBox необходимо создать «Кампанию» исходящих звонков с инициацией по http-запросу.
В результате создания система сгенерирует логин, пароль для подключения к URL API VoiceBox, сам запрос, где будет указан метод, которым эту кампанию можно вызвать, и выдаст структуру запроса.
Со стороны CRM требуется сформировать запрос с данными и передать его по URL API следующей формы:
{
"method": "тут имя метода",
"data": {
"number_a": "номер оператора",
"number_b": "номер клиента",
"delivery": "название службы доставки"
}
}В результате этого запроса VoiceBox вместе с ответом 200ОК вернет call_id, обернутый в JSON. Его необходимо сохранить и привязать к заказу так, чтобы при поступлении post запроса из VoiceBox был возможен поиск заказа по call_id.
Post-запрос о результатах работы скрипта поступает вида:
{"call_id": "{call_id}",
"status": "статус работы скрипта",
"number_new": "{{number_new}}" //пустой или заполненный номер для внесения изменений
}
Заключение
В статье изложил настройки VoiceBox МТТ, которые привел на рабочем примере скрипта определения доступности номера телефона клиента, вероятной замены номера телефона, с которым требуется созвониться курьеру.
Всю нагрузку по формированию статусов звонка удалось реализовать на стороне МТТ. Это позволило разгрузить CRM от лишних проверок и контроля системы связи с клиентом. Кроме того, настройка скрипта позволила на практике исключить операторов из общения с клиентом по рутинной задаче и передать все управление роботу МТТ.
Со стороны компании МТТ, уже привычно, оказана необходимая поддержка.
Всем спасибо за прочтение статьи, прошу все вопросы задавать в комментариях.
