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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1: Блок-схема алгоритма работы процесса звонка.
Рис. 1: Блок-схема алгоритма работы процесса звонка.

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

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

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

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

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

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

Рисунок 2. Общая схема звонка клиенту с получением обратной связи.
Рисунок 2. Общая схема звонка клиенту с получением обратной связи.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3. Блок исходящего вызова
Рисунок 3. Блок исходящего вызова

Производит инициацию соединения по переданному номеру с передачей управления следующему блоку. В моем случае при ошибке соединения переводим на http-блок «Статус Недозвон», в случае успеха на следующий блок алгоритма.

Блок информирования «Инфоблок»

Нужен для произнесения стартового текста скрипта и дальнейшей передачи управления в вопрос. Так сделано для того, чтобы клиент при ответе не нарушил работу основного алгоритма распознавания, сформировав очередь ответов, например «Алло», «Да», «Привет». Содержит в себе текст и переменные, которые также затем заменяются на текст, который, в свою очередь произносит робот.

Блок вопрос

Содержит в себе достаточно сложную систему обработки ответов клиента. Его можно настроить на сбор ответов кнопками телефона или распознаванием голоса, рисунок 4.

Рисунок 4. Интерактивное меню, часть 1.
Рисунок 4. Интерактивное меню, часть 1.

В меню уже настроено определение ответов клиента, но для инициации действий со стороны абонента в поле текст, который будет проигрываться, внесен вопрос «Вы подтверждаете номер для заказа {{number_b}}?», где “number_b” — переменная с номером телефона клиента.

Рисунок 5. Интерактивное меню, часть 2.
Рисунок 5. Интерактивное меню, часть 2.

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

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

Кроме того, видно первый блок распознавания ответа, который обрабатывает ситуацию с запросом связи с оператором. В «случае успеха», а именно в случае, если алгоритм распознал запрос клиентом оператора, происходит перевод на блок связи с оператором.

Рисунок 6. Интерактивное меню, часть 3.
Рисунок 6. Интерактивное меню, часть 3.

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

Рисунок 7. Интерактивное меню, часть 4.
Рисунок 7. Интерактивное меню, часть 4.
Рисунок 8. Интерактивное меню, часть 5.
Рисунок 8. Интерактивное меню, часть 5.

Далее следует алгоритмы определения статусов (рис.7, рис.8):

  • «Некогда», когда неудобно говорить.

  • «Отказ», когда клиент отвечает на вопрос отрицательно, значит необходимо уйти на ветку замены номера.

  • «Сомнение», когда требуется разговор с оператором.

Рисунок 9. Интерактивное меню, часть 6.
Рисунок 9. Интерактивное меню, часть 6.

На рисунке 9 — завершение алгоритма со статусами ошибок. Скрипт тут обрабатывает ошибку распознавания голоса, не-ответ клиента или плохое качество связи, разрыв связи «переход в случае автоответчика или автоинформатора».

Блок невозможности распознавания ответов клиента

Рисунок 10. Обработка ошибок распознавания, блок уведомления.
Рисунок 10. Обработка ошибок распознавания, блок уведомления.

Эта часть собрана из уведомления о соединении с оператором и блоков перевода звонка и информирования. Она служит завершением работы алгоритмов распознавания речи при ошибке распознавания. В случае обрыва связи есть перевод на http-блок «Статус Недозвон», так как после выполнения алгоритма не выявлен ответ клиента. Если звонок продолжается, то вызывается оператор.

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

Производит подключение к текущему звонку number_a, который содержит федеральный номер колл-центра или вход в SIP-подключение АТС колл-центра. Тему перевода в АТС организации, возможно, рассмотрим вне рамок этой статьи, как отдельный механизм взаимодействия телефонии организации с VoiceBox.

Распознавание номера под диктовку клиента

Рисунок 11. Блок распознавания номера под диктовку.
Рисунок 11. Блок распознавания номера под диктовку.

Более легкий алгоритм блока может распознать до 20 символов, при этом я указал, что при распознавании ожидаются только цифры. Поэтому в переменную “number_new” будет записан номер телефона, который продиктует клиент. Все просто.

Алгоритм определяет успех распознавания и не успех. При отказе алгоритма я перевожу на блок оповещения о соединении с оператором. Так что в случае успеха мы уверены, что набор цифр в блоке определения номера сформирован и будет передан в CRM. В CRM я могу гарантированно поставить статус замены номера. Кроме того, я могу нормализовать на стороне CRM номер и проверить его корректность и вероятность существования по базам номеров и префиксов.

HTTP-блоки оповещения о результате работы алгоритма

Приведу пример некоторых блоков оповещения о статусе работы алгоритма для полного понимания происходящего в скрипте.

Рисунок 12. Блок http-оповещения о статусе подтверждения.
Рисунок 12. Блок http-оповещения о статусе подтверждения.

Блок http-оповещения о статусе подтверждения формирует JSON-запрос и отправляет его по указанному адресу. Блок http-оповещения можно использовать в любом месте алгоритма скрипта для передачи различных статусов в CRM. В данном случае, при передаче на указанный адрес, формируется статус JSON с пустым значением переменной “number_new” и статусом подтверждения “accept”.

Рисунок 13. Блок http-оповещения о статусе подтверждения, результат выполнения.
Рисунок 13. Блок http-оповещения о статусе подтверждения, результат выполнения.

На второй вкладке настройки блока http-оповещения можно указать переход на случай ошибки отработки этого блока и на случай успеха. Так как даже если у меня не получилось отправить ответ из МТТ в CRM, я все равно завершаю звонок. Поэтому финал работы блока всегда один: «Завершение» всего скрипта. На стороне CRM анализируется время ответа, и, если прошло 5 минут, а ответ не поступил, то операторам колл-центра поступает задача позвонить клиенту.

Рисунок 14. Блок http-оповещения о статусе замены номера.
Рисунок 14. Блок http-оповещения о статусе замены номера.

В случае, если клиент изменяет номер, а алгоритм распознал успешно данные номера, то я уведомляю CRM о смене номера передачей переменной “number_new”, которая сформировалась в блоке распознавания ответа клиента.

Ответ на «агрессию»

Приведу пример сообщения, которое формируется, если в блоке интерактивного меню появилось недовольство клиента.

Рисунок 15. Уведомление при недовольстве клиента.
Рисунок 15. Уведомление при недовольстве клиента.

Уведомление содержит текст, который призван успокоить клиента. После произнесения текста звонок завершается, и статус передается в предыдущем блоке настоящему блоку http-уведомления для того, чтобы при разрыве соединения информация все же поступила в CRM как можно оперативнее. Далее подключается оператор для корректной отработки возражений с таким клиентом.

Запросы, передаваемые между CRM и VoiceBox

Для начала работы в VoiceBox необходимо создать «Кампанию» исходящих звонков с инициацией по http-запросу.

Рисунок 16. Создание компании.
Рисунок 16. Создание компании.

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

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

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

Комментарии (2)


  1. Squoworode
    10.08.2022 08:52

    Здравствуйте! Я робот-помощник...

    Телефон сразу же откладывается на стол. Не могу троллить роботов - так хоть на линии подержу.

    Неудачное начало монолога для робота с осмысленным содержанием.


    1. Bessome Автор
      10.08.2022 10:18

      Доброго дня!
      Я программист 1С, отец, сын, покупатель, получатель посылки, etc
      В данном случае начало статьи должно показать содержимое. В реальных боевых условиях специалисты формулируют самые различные, более подходящие случаю вводные для произношения текста. Не думаю, что вопрос формулировок продающих фраз должен рассматриваться в техническом тексте.