Ответы на однотипные вопросы клиентов без оператора

Исходная ситуация

Оператор в чате отвечает на одни и те же вопросы. Где мой заказ. Как поменять тариф. Приедет ли доставка в субботу. Почему не приходит письмо для входа. Как получить закрывающие документы.

Ответы уже существуют — в голове оператора, в личных заметках, в старой переписке. Каждый отвечает своими словами, поэтому два клиента с одним вопросом получают два разных ответа. Разных по смыслу, не только по формулировке.

Время теряется так:

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

Отдельный слой — вопросы, ответ на которые есть в документации. Клиент туда не дошёл, потому что искать неудобно.

Что смотрели

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

Практический порядок:

1. Выгрузить обращения за период — из системы чатов, почты, тикетов.
2. Проверить разметку ролей в выгрузке. Частая ловушка: реплики бота или автоответчика приходят помеченными как клиентские. Корпус, собранный без этой проверки, показывает несуществующие «вопросы клиентов», которые на самом деле фразы самой системы.
3. Сгруппировать по намерениям. Первый проход можно сделать моделью, второй — руками, иначе группы соберутся по словам.
4. Посчитать долю топовых намерений от всего потока.

Дальше — три числа, которые определяют, стоит ли браться:

• Доля обращений, закрывающихся одним сообщением. Прямой кандидат на автоматизацию.
• Доля обращений, где ответ уже написан где-то в документации. Показывает, есть ли из чего собирать базу.
• Доля обращений, требующих данных о конкретном аккаунте. Здесь поиск по тексту бесполезен, нужен вызов API.

Обращения делятся на три класса, и решения для них разные:

Что поменяли

1. База знаний собрана из ответов операторов. Источник — реальные удачные ответы из переписки, а не маркетинговые тексты с сайта. Единица хранения: формулировка вопроса, короткий ответ на три-пять строк, ссылка на подробности.

2. У каждого куска метаданные. Раздел, дата последней проверки, владелец. Кусок без владельца устаревает первым.

3. Поиск гибридный. Векторный поиск ловит переформулировки, поиск по ключам — точные термины, артикулы и коды ошибок. Один векторный поиск промахивается на редких словах и номерах.

4. Модель отвечает только по найденным кускам. Ничего не найдено — ответа нет. Генерация без опоры на источник запрещена системным промптом и проверяется на выходе.

5. Ссылка на источник в каждом ответе. Клиент может проверить, оператор может исправить, а отсутствие ссылки автоматически означает эскалацию.

6. Явный отказ встроен как штатный исход. Формулировка «не могу ответить точно, передаю оператору» обходится дешевле уверенной выдумки.

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

8. Передача человеку с контекстом. Оператор получает историю диалога, найденные куски и причину эскалации. Без этого разговор начинается с нуля, и клиент повторяет вопрос второй раз.

9. Отдельный путь для вопросов про аккаунт. Бот не ищет ответ в тексте, а вызывает API системы по идентификатору клиента. Идентификация проходит до вызова, а не после.

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

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

Что не трогали

• Живой чат. Оператор остался в том же интерфейсе, бот встал перед ним, а не вместо него.
• Телефон. Голосовой канал не автоматизировали: там выше цена ошибки и меньше шансов исправиться.
• Существующую документацию. Её не переписывали под бота, только дополнили недостающими ответами, оставив формулировки прежними.
• Продажи. Бот отвечает на вопросы и не ведёт сделку. Смешение справочной и продающей роли портит обе.

Обратимость

• Флаг выключения: бот отключается, чат идёт прямо оператору, интерфейс оператора не меняется.
• База знаний хранится обычными текстовыми файлами под версионированием. Откат правки — возврат коммита.
• Системный промпт лежит в конфиге, а не в коде, и меняется без выката.
• Режим тени: бот готовит ответ, но не отправляет, а показывает оператору как подсказку. Тот же режим используется для запуска — сначала неделя в тени, потом отправка на части каналов.

Границы

• Условия меняются, а базу никто не ведёт. Бот будет уверенно повторять вчерашние правила. Без назначенного владельца базы запускать нельзя.
• Эмоции и претензии. Недовольный клиент требует человека, автоматический ответ здесь ухудшает ситуацию.
• Юридически значимые формулировки. Гарантии, возвраты, обязательства — только через человека и согласованный текст.
• Разнообразный поток без выраженного топа. Если частые намерения закрывают малую часть обращений, база не окупит собственную поддержку.
• Вопросы, требующие решения. Сделать исключение, дать скидку, продлить срок — решает человек, бот только собирает для него данные.

Правило: отвечать только тем, что нашлось в базе, со ссылкой на источник, а всё остальное отдавать человеку вместе с историей диалога.