Что делать, если робот-продавец ошибся

Первые три минуты после того, как заметили ошибку

Пока диалог идёт по неверному пути, каждое следующее сообщение бота усугубляет ситуацию. Первое действие — остановить автоответ и переключить сделку на живого менеджера, а не пытаться исправить формулировку прямо в чате. Это делает та же связка, что и обычная передача горячего клиента: робот-продавец умеет отдавать диалог человеку, если знает, что его нужно отдать.

Второй шаг — зафиксировать сам факт ошибки: кому, в каком канале, на какой вопрос прозвучал неверный ответ. Без этой записи разбор превращается в пересказ по памяти, а причина находится случайно. Проще всего сохранить скриншот или ссылку на карточку сделки в CRM в момент обнаружения, пока переписка не ушла вниз по ленте.

Третий шаг — не удалять и не редактировать сообщение бота задним числом. Это единственное доказательство того, что именно пошло не так, и без него сложно понять, ошибся ли бот в фактах, в тоне или в логике передачи клиента менеджеру. Разбор без сохранённого оригинала обычно приходится начинать заново.

Что написать клиенту после ошибки

Клиент не обязан разбираться, где именно бот запутался — ему важно, что дальше. Формулировка «извините, здесь ответил бот, и он ошибся, сейчас с вами свяжется наш менеджер» работает вернее попытки объяснить техническую причину. Признание факта без оправданий снимает раздражение быстрее, чем длинное объяснение.

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

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

Где искать причину: промпт, база знаний или связка с CRM

Ошибки бота почти всегда происходят в одном из трёх мест, и они лечатся по-разному. Первое — промпт, то есть инструкция, по которой бот понимает вопрос и формирует ответ: если он не так интерпретировал формулировку клиента, нужно уточнять именно инструкцию, а не менять данные вокруг неё.

Второе место — база знаний: устаревшая цена, снятая с продажи услуга, неверное описание условий. Здесь проблема не в логике бота, а в том, что источник, из которого он берёт факты, не обновили вовремя. Такие ошибки повторяются у разных клиентов одинаково, и это первый признак, что дело не в промпте.

Третье место — вызов инструмента в CRM: бот спросил актуальные данные по сделке, но не получил их или получил не те. Это уже вопрос интеграции, а не текста, и чинить его нужно на уровне подключения каналов и полей, как это описано в разделе про внедрение CRM. Смешивать эти три причины в один разбор — самая частая причина, почему ошибка повторяется через месяц в другом виде.

Что делать со сделкой, если клиент уже сослался на неверную цену или условие

Если клиент показывает переписку и говорит «ваш бот обещал скидку», решение принимает не бот и не скрипт, а человек с полномочиями. Есть три пути: зафиксировать это как разовое исключение для конкретной сделки, частично компенсировать разницу или отказать с объяснением, что информация была ошибочной. Универсального правильного варианта нет — есть то, что дороже обходится бизнесу: разовая уступка или испорченные отношения с клиентом.

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

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

Как не потерять такие случаи и использовать их для обучения бота

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

Полезно прикреплять к карточке сам фрагмент переписки, а не пересказ своими словами. Пересказ теряет детали — именно те, которые нужны, чтобы понять, промпт это, база знаний или интеграция подвела. Разбор через две недели по памяти почти всегда неточен.

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

Что считать, чтобы видеть проблему раньше жалоб клиентов

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

Второй счётчик — доля ошибочных ответов при выборочной проверке переписок: сколько случайно выбранных диалогов при разборе оказались неточными по фактам. Это не разовая проверка, а регулярная выборка, иначе цифра быстро устаревает. Третий — время реакции менеджера после того, как бот передал ему сделку: если между эскалацией и первым ответом человека проходит слишком много времени, часть смысла в скорости бота теряется.

В действующем проекте GetGate при слепом сравнении ответ ассистента оказался не хуже ответа человека в 80% случаев — это ориентир для похожей задачи, а не гарантия для любого бизнеса. Именно такую проверку — сравнение ответов бота и человека на реальной переписке — стоит проводить регулярно, а не один раз при запуске. Подробнее о том, как это устроено на потоке, — в разделе про контроль качества.

Как это выглядит на практике, когда правила заданы нечётко

Частая причина ошибок — не сбой бота, а нечёткое правило на входе. Если по договорённости с руководителем бот должен обрабатывать все сделки, кроме крупных и VIP-клиентов, а эти исключения не закреплены как отдельное правило в CRM, рано или поздно бот возьмёт в работу именно ту сделку, которую должен был обработать конкретный менеджер. Формулировка «только их пока отрабатывает коллега» звучит понятно в разговоре, но должна быть записана как условие, а не как договорённость на словах.

Похожая ситуация — смена канала связи с клиентом. Если контакт в CRM обновили и клиент теперь пишет не в WhatsApp, а в другом канале, но карточка сделки этого не отражает, бот может продолжать логику по старому каналу или потерять историю переписки. Такие переходы стоит фиксировать сразу в карточке, а не держать в памяти у одного менеджера.

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

Как выстроить процесс так, чтобы ошибки не копились молча

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

В проекте GetGate 27% заявок приходят вечером и в выходные, когда раньше клиента ждали до утра — именно в эти часы живого контроля меньше всего, а бот работает без перерыва. Это ровно то время, когда правило эскалации и записанный лог инцидентов важнее всего: некому на месте поймать сбой, если он не зафиксирован автоматически.

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