Conversational AI для обслуживания клиентов чаще всего терпит неудачу по предсказуемым причинам: бот отвечает, основываясь на догадках, а не на контенте компании, скрывает путь к человеку или оценивается по количеству отклоненных запросов, а не по решенным проблемам. Агентства избегают этих ошибок, основывая бота на проверенной базе знаний, заранее проектируя переключения на оператора, ограничивая то, что бот может обещать, и измеряя результаты, которые важны для клиентов. Технология способна на многое; настройка определяет, будут ли клиенты благодарить вас или жаловаться.
Что такое Conversational AI в обслуживании клиентов?
Conversational AI здесь означает чат- или голосовых помощников, которые понимают вопросы в свободной форме и отвечают на естественном языке, обычно работающих на базе большой языковой модели. Они размещаются на веб-сайтах, в приложениях, в WhatsApp и Messenger, и все чаще на телефонных линиях. Такие платформы, как Zendesk AI, Intercom Fin, Salesforce Agentforce, Freshworks Freddy и Customer Engagement Suite от Google, предлагают это «из коробки», а многие компании создают свои собственные на базе моделей OpenAI, Anthropic или Google.
Отличие от старых чат-ботов заключается в гибкости. Скриптовые боты следовали деревьям решений и ломались, когда клиент формулировал что-то неожиданное. Боты на базе языковых моделей хорошо справляются с разнообразными формулировками, именно поэтому им нужны более строгие защитные барьеры: они выдадут плавный ответ, даже когда им вообще не следует отвечать.
Ошибка 1: Позволять боту отвечать на основе собственных знаний
Общая модель много знает о мире, но ничего достоверного о ваших правилах возврата. Когда бот не привязан к контенту компании, он заполняет пробелы правдоподобными догадками. Суды и регулирующие органы уже привлекали компании к ответственности за то, что их чат-боты говорили клиентам, поэтому выдуманная политика — это реальная ответственность, а не мелкий сбой.
Решение — поиск по базе (retrieval). Бот ищет по утвержденному набору справочных статей, политик и данных о продуктах и отвечает только на основе того, что находит. Когда ничего релевантного не находится, он сообщает об этом и предлагает связаться с человеком. Большинство коммерческих платформ поддерживают этот паттерн; работа заключается в написании и поддержке исходного контента. Короткие статьи, каждая из которых отвечает на один вопрос, работают лучше, чем длинные страницы политик, охватывающие десять тем сразу.
Ошибка 2: Скрывать человека
Некоторые команды измеряют успех тем, сколько разговоров никогда не доходит до агента, поэтому они скрывают переключение на оператора. Клиенты это замечают. Быть запертым в цикле с ботом, который продолжает перефразировать один и тот же бесполезный ответ, — один из самых быстрых способов превратить небольшую проблему в публичную жалобу.
Спроектируйте переключение на оператора прежде всего остального. Хорошая практика включает:
- Четкая опция «поговорить с человеком», доступная в любой момент.
- Автоматическая эскалация после двух неудачных попыток или когда клиент выражает разочарование.
- Передача агенту полной истории разговора и выявленного намерения, чтобы клиенту не приходилось повторяться.
- Честные сообщения о времени ожидания, когда агенты заняты, с возможностью оставить сообщение.
Почему боты дают обещания, которые не должны?
Языковые модели обучены быть полезными, и полезность может перерасти в чрезмерные обязательства: «Я оформил ваш возврат», когда система возврата не вызывалась, или «вы получите это завтра» без данных о доставке. Эти утверждения звучат как действия, но являются лишь текстом.
Отделите слова от действий. Если бот может действовать, например, проверить статус заказа или инициировать возврат, он должен вызывать определенную систему через API и сообщать реальный результат. Если он не может действовать, его инструкции должны запрещать формулировки, подразумевающие, что он это сделал. Протестируйте это специально с помощью промптов, которые пытаются заставить бота пообещать компенсацию или исключения.
Чувствительные темы требуют фиксированных путей
Споры по счетам, отмены, вопросы безопасности, юридические угрозы и все, что связано со здоровьем, должны следовать фиксированным путям, обычно прямо к обученному персоналу. Бот может собрать детали и классифицировать проблему, но сам ответ не должен быть импровизированным.
Какие метрики должны заменить коэффициент отклонения (deflection rate)?
Коэффициент отклонения легко посчитать и легко манипулировать. Бот, который завершает разговоры, ничего не решив, показывает отличные цифры отклонения. Лучшие показатели смотрят на результат клиента:
- Решение, подтвержденное клиентом через короткий вопрос «это решило вашу проблему?»
- Частота повторных обращений в течение нескольких дней по той же проблеме.
- Удовлетворенность клиентов для разговоров только с ботом по сравнению с разговорами с агентами.
- Причины эскалации, сгруппированные, чтобы показать, с какими темами бот справляется плохо.
- Среднее время обработки для агентов в эскалированных чатах, которое должно снижаться, если переключения содержат контекст.
Когда повторные обращения растут при росте отклонения, бот перекладывает проблемы дальше по цепочке.
Тон и язык
Бот, который отвечает жестким, формальным английским клиенту, пишущему на разговорном турецком или немецком, кажется чужим. Установите язык ответа в соответствии с клиентом и напишите краткое руководство по тону с примерами хороших и плохих ответов. Извинения должны быть краткими и конкретными, а не повторяться в каждом сообщении.
Ошибка 4: Запустить и забыть
Продукты, цены и политики меняются. База знаний, написанная для запуска, устареет через несколько месяцев, и бот будет уверенно повторять старую информацию. Журналы разговоров также выявляют новые вопросы, которые никто не предвидел.
Назначьте ответственного. Каждую неделю просматривайте выборку разговоров, особенно с низкими оценками, и обновляйте исходные статьи. Каждый месяц просматривайте причины эскалации и добавляйте или исправляйте контент для основных. Эта рутина поддерживает рост качества, а не его медленное снижение.
Как Alien Road применяет Conversational AI для обслуживания клиентов
В типичном проекте мы начинаем с чтения реальных данных поддержки: несколько сотен тикетов, чатов и электронных писем, сгруппированных по темам. Это показывает, какие вопросы являются частыми и достаточно простыми для автоматизации, а какие должны оставаться за людьми.
Затем мы проводим аудит и переписываем справочный контент, на который будет опираться бот, потому что большинство справочных центров были написаны для просмотра, а не для поиска. Мы настраиваем выбранную платформу с поиском по этому контенту, пишем правила переключения и фиксированные пути для чувствительных тем, а также подключаем системы заказов или бронирования только там, где API и разрешения ясны. Перед запуском мы проводим тест с реальными и состязательными вопросами. После запуска мы ежемесячно отчитываемся о решении, повторных обращениях, удовлетворенности и причинах эскалации, вместе с изменениями контента, сделанными в ответ.
С чего начать на этой неделе
Возьмите пятьдесят недавних разговоров поддержки и отметьте каждый как «бот мог бы полностью решить это», «бот мог бы собрать детали» или «нужен человек». Разделение показывает вам, сколько бот может сделать реалистично. Это также дает вам первый тестовый набор, который стоит больше, чем любая демо-версия поставщика.
Читать далее: CRM-система · AI Marketing