Почему бот должен уметь молчать

«То есть мне это точно подходит?» — спрашивает клиент. Бот видит знакомые слова из базы знаний, собирает уверенный ответ и отправляет его. Через час выясняется: клиент спрашивал про старый тариф, на который правило не распространяется.

Проблема не в том, что бот ошибся. Ошибаются и люди. Проблема в том, что он ответил тогда, когда должен был остановиться.

В поддержке опасен не молчащий ассистент, а ассистент без тормозов. Если он отвечает на любой вопрос, команда получает не помощника, а ещё один источник инцидентов: красивых, вежливых и иногда неверных сообщений.

Уверенный тон не означает уверенный ответ

ИИ умеет писать так, будто он всё проверил. В этом и ловушка.

Клиент спрашивает: «Можно ли подключить оплату по счёту, если у нас ИП?» В базе знаний есть статья про оплату по счёту для юрлиц. Есть статья про документы для ИП. Есть старая инструкция, где формулировка отличается. Ассистент может связать всё это в гладкий ответ.

Для клиента такой ответ выглядит официально. Он не видит сомнение модели, не знает, какие фрагменты нашлись, и не понимает, что в вопросе не хватало детали: страна, тариф, тип договора, дата подключения.

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

Цена ошибки появляется позже. Клиент уже сделал действие по неправильному совету. Оператору приходится откатывать ожидание: «Коллега выше ответил неточно», «В вашем случае правило другое», «Нужно оформить заново». Это хуже, чем честное «я уточню».

Молчание — это часть сценария, а не поломка

Хороший ассистент должен знать не только как отвечать, но и когда не отвечать.

Есть вопросы, где автоматический ответ уместен: часы работы, ссылка на инструкцию, порядок возврата по простому сценарию, статус известной операции. Там риск ограничен, а база знаний даёт прямой ответ.

Есть вопросы, где нужна пауза:

• клиент просит исключение из правила;
• в вопросе есть деньги, блокировка, юридические условия;
• не хватает данных, чтобы выбрать правильный сценарий;
• найденные материалы противоречат друг другу;
• клиент злится и спорит с предыдущим ответом;
• вопрос касается старого тарифа, договора или ручной настройки.

В этих случаях молчание бота не должно выглядеть как исчезновение. Нормальный сценарий — коротко сказать клиенту, что нужен человек, и передать обращение оператору. Без попытки «на всякий случай» дописать совет.

У такого подхода есть цена. Часть обращений будет попадать к людям, хотя бот мог бы рискнуть и ответить. Очередь не исчезнет магически. Команде придётся смотреть, где ассистент слишком осторожен, а где слишком смел.

Но это управляемая цена. Лишнее обращение к оператору видно сразу. Неверный автоматический ответ часто всплывает позже, когда клиент уже обижен или сделал не то.

Правило «зови человека» нужно описать заранее

Нельзя просто сказать боту: «Если не уверен, не отвечай». Для команды это звучит разумно, но для системы слишком расплывчато.

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

Эти правила стоит писать тем же языком, которым пользуется поддержка. Не «эскалировать при высокой неопределённости», а «звать старшего, если клиент просит исключение по оплате». Так проще проверить, сработал сценарий или нет.

Ещё важный момент: после входа оператора бот должен замолчать. Иначе получается странный диалог, где человек уже разбирает частный случай, а ассистент продолжает подкидывать шаблонные ответы. Клиенту всё равно, кто именно ошибся. Для него это одна поддержка.

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

Завтра можно начать без большого проекта: выбрать одну рискованную тему, например возвраты или блокировки, и выписать случаи, где ассистент не должен отвечать сам. Потом проверить последние обращения по этой теме и отметить, где автоматический ответ был бы безопасен, а где лучше было сразу позвать человека.