«Здравствуйте! Я робот-помощник <службы доставки>. Звоню Вам для подтверждения заказа, который оформлен на номер <number>. Он же будет контактным для курьера. Вы подтверждаете номер для заказа <number>?».  Меня зовут Дмитрий Лупонос. Я программист 1С, который любит интеграции со сторонними сервисами (да, я существую). Я веду задачи, которые иногда касаются управления голосовым роботом. И да, это не спам, а совершенно добровольное согласие пользователя, который самостоятельно ставит галочку в поле «Звонки от робота». С начала пандемии число пользователей доставки выросло лавинообразно. «По-старинке» через колл-центр работать становится неэффективно и затратно, поэтому бизнес ищет новые решения. Одно из таких – первичный звонок после заказа голосовым роботом, который проговаривает данные заказа и уточняет некоторые детали.  После предыдущей статьи, предлагаю отойти от 1С, и  посвятить время анализу достаточно сложного сценария звонка, описание которого находится под катом. В организации есть база, в которой появляется заказ. В течение 10 минут, пока склад начинает собирать его, необходимо убедиться, что получатель заказа знает о его создании, подтверждает свой номер телефона для контакта курьера организации, или меняет номер телефона без привлечения операторов. Если происходит замена номера, то склад при упаковке и вручении курьеру  должен уже распечатать лист заказа с корректным номером.  На стороне МТТ с использованием voicebox.mtt.ru у меня есть доступ к настройкам скриптов и кампаний обзвона. Номера могут быть различных регионов, в зависимости от региона скрипт должен позвонить клиенту с подходящего номера. Этот вопрос решается в CRM-системе на стороне СУБД, а скрипт МТТ получает при инициации необходимые данные.  Во время звонка могут произойти события, которые робот должен обработать с помощью распознавания голоса клиента:  Прием звонка и подтверждение номера телефона. Прием звонка и замена номера телефона. Прием звонка, но отказ от разговора в связи с занятостью. Прием звонка и отбой до завершения отработки скрипта. Отказ от приема – нет соединения или не ответ. Возможно, клиент не согласен общаться с роботом, поэтому необходимо соединять с оператором. В результате звонка обновляется статус документа, в том числе о том, что номер изменился, на стороне CRM. Звонок совершается один раз. Я предполагаю, что ранее номер клиента верифицировали, поэтому нормализация номера телефона из базы данных клиентов не нужна.  На рисунке 1 укрупненная блок-схема постановки задачи в работу и обработка ответа от МТТ: В интерфейсе 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-оповещения о статусе подтверждения формирует JSON-запрос и отправляет его по указанному адресу. Блок http-оповещения можно использовать в любом месте алгоритма скрипта для передачи различных статусов в CRM. В данном случае, при передаче на указанный адрес, формируется статус JSON с пустым значением переменной “number_new” и статусом подтверждения “accept”. На второй вкладке настройки блока http-оповещения можно указать переход на случай ошибки отработки этого блока и на случай успеха. Так как даже если у меня не получилось отправить ответ из МТТ в CRM, я все равно завершаю звонок. Поэтому финал работы блока всегда один: «Завершение» всего скрипта. На стороне CRM анализируется время ответа, и, если прошло 5 минут, а ответ не поступил, то операторам колл-центра поступает задача позвонить клиенту.  В случае, если клиент изменяет номер, а алгоритм распознал успешно данные номера, то я уведомляю CRM о смене номера передачей переменной “number_new”, которая сформировалась в блоке распознавания ответа клиента.  Приведу пример сообщения, которое формируется, если в блоке интерактивного меню появилось недовольство клиента.  Уведомление содержит текст, который призван успокоить клиента. После произнесения текста звонок завершается, и статус передается в предыдущем блоке настоящему блоку http-уведомления для того, чтобы при разрыве соединения информация все же поступила в CRM как можно оперативнее. Далее подключается оператор для корректной отработки возражений с таким клиентом.  Для начала работы в VoiceBox необходимо создать «Кампанию» исходящих звонков с инициацией по http-запросу.  В результате создания система сгенерирует логин, пароль для подключения к URL API VoiceBox, сам запрос, где будет указан метод, которым эту кампанию можно вызвать, и выдаст структуру запроса.  Со стороны CRM требуется сформировать запрос с данными и передать его по URL API следующей формы:  В результате этого запроса VoiceBox вместе с ответом 200ОК вернет call_id, обернутый в JSON. Его необходимо сохранить и привязать к заказу так, чтобы при поступлении post запроса из VoiceBox был возможен поиск заказа по call_id.  Post-запрос о результатах работы скрипта поступает вида:  В статье изложил настройки VoiceBox МТТ, которые привел на рабочем примере скрипта определения доступности номера телефона клиента, вероятной замены номера телефона, с которым требуется созвониться курьеру.  Всю нагрузку по формированию статусов звонка удалось реализовать на стороне МТТ. Это позволило разгрузить CRM от лишних проверок и контроля системы связи с клиентом. Кроме того, настройка скрипта позволила на практике исключить операторов из общения с клиентом по рутинной задаче и передать все управление роботу МТТ. Со стороны компании МТТ, уже привычно, оказана необходимая поддержка.  Всем спасибо за прочтение статьи, прошу все вопросы задавать в комментариях.