«Здравствуйте! Я робот-помощник <службы доставки>. Звоню Вам для подтверждения заказа, который оформлен на номер <number>. Он же будет контактным для курьера. Вы подтверждаете номер для заказа <number>?».

Меня зовут Дмитрий Лупонос. Я программист 1С, который любит интеграции со сторонними сервисами (да, я существую). Я веду задачи, которые иногда касаются управления голосовым роботом. И да, это не спам, а совершенно добровольное согласие пользователя, который самостоятельно ставит галочку в поле «Звонки от робота».

С начала пандемии число пользователей доставки выросло лавинообразно. «По-старинке» через колл-центр работать становится неэффективно и затратно, поэтому бизнес ищет новые решения. Одно из таких – первичный звонок после заказа голосовым роботом, который проговаривает данные заказа и уточняет некоторые детали.

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

Постановка задачи

В организации есть база, в которой появляется заказ. В течение 10 минут, пока склад начинает собирать его, необходимо убедиться, что получатель заказа знает о его создании, подтверждает свой номер телефона для контакта курьера организации, или меняет номер телефона без привлечения операторов. Если происходит замена номера, то склад при упаковке и вручении курьеру  должен уже распечатать лист заказа с корректным номером.

На стороне МТТ с использованием voicebox.mtt.ru у меня есть доступ к настройкам скриптов и кампаний обзвона. Номера могут быть различных регионов, в зависимости от региона скрипт должен позвонить клиенту с подходящего номера. Этот вопрос решается в CRM-системе на стороне СУБД, а скрипт МТТ получает при инициации необходимые данные.

Во время звонка могут произойти события, которые робот должен обработать с помощью распознавания голоса клиента:

1. Прием звонка и подтверждение номера телефона.

2. Прием звонка и замена номера телефона.

3. Прием звонка, но отказ от разговора в связи с занятостью.

4. Прием звонка и отбой до завершения отработки скрипта.

5. Отказ от приема – нет соединения или не ответ.

6. Возможно, клиент не согласен общаться с роботом, поэтому необходимо соединять с оператором.

В результате звонка обновляется статус документа, в том числе о том, что номер изменился, на стороне CRM. Звонок совершается один раз. Я предполагаю, что ранее номер клиента верифицировали, поэтому нормализация номера телефона из базы данных клиентов не нужна.

На рисунке 1 укрупненная блок-схема постановки задачи в работу и обработка ответа от МТТ:

Настройка скрипта в интерфейсе VoiceBox МТТ

В интерфейсе VoiceBox МТТ (далее Voicebox) есть инструменты для настройки скриптов обзвона и извлечения отчетов с детализацией звонков, план нумерации.

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

Создание сценария

Создаю сценарий с названием «Звонок-подтверждение покупателем». Все элементы взаимодействия представлены в виде блоков, в которых необходимо задать настройки и параметры.

На рисунке 2 полная схема звонка с обратной связью от клиента:

Основные блоки инициации, в которых выполняются все необходимые операции, расположены вверху:

1. Блок исходящего звонка клиенту.

2. блок информирования, в котором отключены все определения ответов.

3. Блок вопрос, в котором реализован весь механизм вопросов и ответов клиента.

Вторая линия блоков:

1. Блок уведомления о несостоявшемся звонке.

2. Обработка невозможности распознавания ответа клиента.

3. Блок определения замены номера под диктовку клиента.

4. Блок перевода на оператора.

Третья линия блоков:

1. Блоки уведомления нашей CRM о статусе звонка.

2. Блоки голосового оповещения клиента.

3. Завершение звонка.

Производит инициацию соединения по переданному номеру с передачей управления следующему блоку. В моем случае при ошибке соединения переводим на 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 от лишних проверок и контроля системы связи с клиентом. Кроме того, настройка скрипта позволила на практике исключить операторов из общения с клиентом по рутинной задаче и передать все управление роботу МТТ.

Со стороны компании МТТ, уже привычно, оказана необходимая поддержка.

Всем спасибо за прочтение статьи, прошу все вопросы задавать в комментариях.