Проработка умного IVR с распознаванием речи сервисной службы

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

  1. Когда человек слышит голосового ассистента, даже если тот представляется как бот-оператор, он не сразу понимает, что разговаривает с роботом.
  2. Даже если заготавливать список вопросов, человек, не поняв, что говорит с ботом хочет использовать свои вопросы.
  3. Очевидно, что те, кто звонит, надеются сразу пообщаться с человеком, но это, к сожалению, нынче очень дорого и, зачастую, нереально. Например, при сезонном характере продаж потребность в сервисе может менятся ов очень значительных пределах.
  4. Интеграция с CRM системой (service-desk) должна предполагать, что человек услышав бота положит трубку. Хотя проблема у него осталась. Для дальнейшей проработки IVR нужно фиксировать факт звонка в момент его совершения. Даже если клиент решил закончить разговор сразу.
  5. При распознавании бот ошибается, когда слово отсутствует в словарях, либо близко по звучанию с словами из словаря. Например, у нас в линейке производимой продукции есть два названия на английском: Stout и MyHeat. Это боль для системы распознавания. Она слышит совершенно по-разному и часто ошибается при распознавании этих слов.
  6. Для анализа фраз клиента нужно сохранять всю фразу распознанную ботом, чтобы сотруднику техподдержки не пришлось прослушивать аудиофайл. Это занимает гораздо больше времени, нежели прочитать стенограммму.
  7. Человек услышав бота, особенно если тот говорит не в попад, может выругаться. Целесообразно распознавать нецензурную лексику (в AimyLogic это зашито) и выдавать снимающее напряжение фразу.

Следуя вышеперечисленному примерная логика построения IVR следующая:

  1. Бот выдает приветственную фразу, представляясь, что он бот. Это позволит понять человеку, что он разговаривает с программой, которая не может вести диалог свободно. Подобные технологии уже есть для текстов, например, ChatGPT, но пока что я не видел нормального встраивания в системы умного (smart) IVR присутствующего на рынке России.
  2. Можно поставить блок расписание, чтобы исключить запись звонков в выходные. Инженеры не могут помочь в выходные, а до понедельника пользователь уже сможет почитать инструкцию и с высокой вероятностью решит сам. 🙂
  3. Некоторые нетерпеливые пользователи могут звонить повторно, если с ним не связались в течении нескольких часов. В этом случае имеет смысл смысл по номеру телефона взять номер заявки и сообщить этот номер. И узнать, у человека возникла новая проблема или он звонит по старой.
  4. Если позвонивший не бросил сразу трубку, значит стоит записать его контакт (номер телефона) в CRM (ServiceDesk), на случай если дальше произойдет обрыв соединения, либо клиент испугается (посчитает бесполезным) общение с ботом. Т.е. сервисная заявка должна создаваться ДО того как бот задаст клиенту вопросы. Хотя вопрос спорный.
  5. Создание сервисной заявки в самом начале диалога позволит в дальнейшем проанализировать процент людей, которые потенциально не готовы общаться с ботом. Это важно для развития системы.
  6. Далее бот начинает задавать наводящие вопросы для классификации проблемы, которая возникла у клиента. По мере получения ответов на вопросы бот добавляет в созданную сервисную заявку информацию. При таком подходе даже если у клиента пропала связь (звонки чаще всего с мобильного) у нас уже сохранен номер его телефона и можно перезвонить.
  7. В интентах (типовых шаблонах для распознавания ответов) невозможно предусматреть все типовые ответы клиента, поэтому при ответе («любая другая фраза») она должна сохранятся как есть и уведомление о том, что человек ответил на вопрос нестандартно (не как мы предполагали) должно отправляться по e-mail разработчикам бота.
  8. Нельзя в синтезе речи использовать только вопросительную фразу, поскольку бот интонационно не всегда передает вопросительный характер предложения. В обязательном порядке нужно после основной вопросительной фразы задать короткий уточняющий вопрос: «Верно?», «Правильно?», «Корректно?», «Правильно ли я поняла?» и т.д. На такие вопросы позвонивший, как правило, дает вполне типовой ответ, который хорошо распознается штатным интентом «Согласие» в AimyLogic.
  9. Дата (например, дата производства оборудования) плохо распознается ботом, поэтому нужно сохранять исходную фразу $queryText.
  10. Номера телефона распознается хорошо, однако клиент может пожелать, чтобы ему перезвонили на другой номер телефона. Стандартный интент по распознаванию номера телефона в AimyLogic работает дорстаточно надежно. При зачитывании номера для проверки нужно использовать регулярное выражение из моей предыдущей статьи, чтобы разбить номер телефона на блоки цифр по 3. Так удобнее воспринимать на слух.
  11. В конце разговора, перед тем как бот положит трубку, нужно передать в CRM в качестве стенограммы полную историю общения взятую из переменной $chathistory. Это позволит сервисному инженеру быстро пробежаться по вопросу клиента, не тратя время на прослушивание аудиозаписи.
Spread the love
Запись опубликована в рубрике IT рецепты с метками . Добавьте в закладки постоянную ссылку.

Обсуждение закрыто.