Про чат-ботов, которые не взлетели, написано много, и почти всё — про сценарий: поставили без цели, запутали меню, не дали связаться с человеком. Это правда, но это половина правды, и та, что заметна снаружи.
Вторая половина технической природы, и она опаснее. Бот с плохим сценарием раздражает — на него жалуются, и вы узнаёте о проблеме. Бот со сломанной технической частью не раздражает никого: он просто перестаёт доносить заявки. Внешне всё работает, а выручка тихо падает.
Это массовая беда: заметная часть тех, кто ищет что-то про ботов, спрашивает не «как сделать», а «почему мой сломался».
Ниже — обе группы, с упором на вторую, потому что про первую вы уже читали.
- Бот не понимает вопрос
- Дерево меню без выхода на человека
- Длинные ответы не по делу
- Навязчивые рассылки
- Дубли заявок от повторных доставок
- Диалог теряет состояние на середине
- Вебхук отвалился, сообщения не приходят
- Упёрлись в лимит запросов на рассылке
- Бот не видит ваши актуальные данные
Тихие технические причины
Бот упал, и никто не заметил
Самая частая и самая дорогая. Сервер перезагрузился, сертификат истёк, платформа сменила адрес API — бот перестал получать сообщения. Он не пишет вам об этом, клиенты пишут в пустоту и уходят.
Проверить это можно только одним способом: бот должен сам сообщать, что жив. Простейший вариант — ежедневное сообщение вам в мессенджер с числом диалогов за сутки. Ноль диалогов там, где обычно двадцать, — это сигнал за минуту, а не через неделю.
Повторные доставки превращаются в дубли заявок
Механика, которую платформы описывают, а разработчики пропускают. Когда платформа присылает боту событие, она ждёт ответа. Ответили медленно или не ответили — событие придёт снова. Это не сбой, это штатное поведение: платформа не знает, дошло сообщение или нет, и на всякий случай повторяет.
Если бот на каждое событие создаёт заявку в CRM, менеджер получит три одинаковых заявки от одного человека. Дальше — звонки одному клиенту трижды и испорченное впечатление.
Лечится тем, что каждое событие получает опознавательный признак, и повтор с тем же признаком отбрасывается. Закладывать это надо сразу: после запуска дубли приходится вычищать руками. Как выглядит правильная обвязка приёма заявок целиком — от сохранения до уведомления ответственного, — разбирал в статье бот для приёма заявок.
Диалог теряет состояние
Бот спросил имя, потом телефон, потом задачу. Между вторым и третьим вопросом сервер перезапустился — и бот забыл, о чём был разговор. Человек получает «Здравствуйте! Чем помочь?» вместо ожидаемого вопроса и закрывает чат.
Так происходит, когда состояние диалога живёт в памяти процесса. Работает на тестах с одним пользователем, разваливается на реальной нагрузке и при любом обновлении. Состояние должно храниться отдельно от процесса — тогда перезапуск для человека незаметен.
Рассылка упирается в лимит платформы
У каждой платформы есть потолок запросов в секунду: у Bot API мессенджера MAX, например, это 30 запросов в секунду — по официальной документации. Пока бот только отвечает на входящие, выше этой планки он не поднимется. Первая же рассылка по базе в него упирается — и часть сообщений просто не уходит.
Без очереди с ограничением скорости вы этого не увидите: платформа не пришлёт отчёт «половина не доставлена». Вы увидите только странно низкий отклик на рассылку.
Бот отвечает, но данные у него вчерашние
Бот говорит «товар в наличии», а его нет. Записывает на время, которое занято. Называет старую цену. Технически бот исправен — он просто отвечает по данным, которые кто-то залил в него месяц назад.
Это граница между ботом-меню и ботом, встроенным в процесс. Если бот не ходит в вашу систему за актуальными данными, он неизбежно начнёт врать — вопрос только в том, когда это заметят.
Заметные причины: коротко, но с уточнением
Про них написано везде, поэтому только то, что обычно упускают.
Нет выхода на человека. Все пишут «дайте кнопку оператора». Уточнение из практики: кнопка должна быть на каждом шаге, а не в конце дерева. Человек, который трижды не получил нужного ответа, не пойдёт искать её в подменю — он закроет чат.
Дерево меню вместо ответа. Проблема не в количестве пунктов, а в глубине. Если до нужного три нажатия — нормально, если семь — человек уйдёт на пятом. Смотреть надо не на схему сценария, а на реальные пути: где люди обрываются, там и лишний уровень.
Бот выдумывает. Актуально для ботов на языковых моделях: модель отвечает уверенно и правдоподобно, даже когда не знает. Лечится не «улучшением промпта», а ограничением: бот отвечает только по вашим документам, а на всё остальное честно говорит «не знаю, соединяю с человеком». Придуманная скидка или несуществующее условие обходятся дороже любого молчания.
Бот не решает задачу, которую ему дали. Сложную консультацию, разбор нестандартной ситуации, торг по цене бот не закрывает. Это не повод от него отказываться — это повод отдать ему то, что он делает лучше человека: круглосуточные ответы на типовое, приём заявок ночью, запись, напоминания.
Отдельно про ботов на нейросети
С ботами, которые отвечают языковой моделью, добавляется четыре причины, которых не бывает у ботов на сценариях.
Модель отвечает уверенно, когда не знает. Это не поломка, а свойство: она собирает правдоподобный ответ из того, на чём училась. Клиент получает несуществующее условие доставки, придуманную скидку или гарантию, которой вы не даёте. Лечится не уговорами в промпте, а архитектурой: бот отвечает только по вашим документам, а на всё, чего в них нет, честно говорит «не знаю» и зовёт человека.
Стоимость растёт незаметно. Каждый ответ стоит денег, и чем длиннее диалог, тем дороже — модель получает всю переписку заново. Пять развёрнутых диалогов в день незаметны, пятьсот уже нет. Если расход не считается с первого дня, счёт приходит сюрпризом.
Модель обновилась — ответы поменялись. Провайдер выкатил новую версию, и бот, который вчера отвечал коротко и по делу, сегодня отвечает иначе. Ничего не сломалось, но клиент видит другого собеседника. Поэтому версия модели фиксируется, а обновление делается осознанно и с проверкой.
Промпт не тестируется сам по себе. Правку в сценарии видно сразу: кнопка есть или нет. Правку в промпте не видно вообще, пока кто-то не задаст нужный вопрос. Набор из двадцати типовых вопросов с ожидаемыми ответами, прогоняемый после каждой правки, снимает почти все такие сюрпризы.
Первые две недели после запуска
Бот почти никогда не ломается в день запуска — в этот день его смотрят все. Ломается он на второй-третьей неделе, когда интерес спал, а реальные люди пришли с реальными вопросами.
Что стоит делать эти две недели, пока внимание ещё есть: читать диалоги целиком, а не сводку. Двадцать прочитанных переписок дают больше, чем любая аналитика: видно, где человек переспрашивает, где отвечает не то, что ждал бот, и где вместо ответа получает меню.
Именно там, а не в сценарии на бумаге, находятся почти все правки первого месяца. Дальше частота снижается, но не до нуля: платформа меняет API, вы меняете цены и услуги, а бот об этом не узнает сам.
Как понять, что бот сломался, раньше клиента
- 1Считайте диалогиСколько начато за сутки и сколько дошло до цели. Одно число, но без него вы не знаете ничего
- 2Поставьте сигнал тишиныНоль диалогов там, где обычно двадцать, — сообщение вам в мессенджер
- 3Проверьте доставку событийВ настройках платформы видно, приходят ли события на ваш адрес
- 4Пройдите сценарий самиРаз в неделю, как обычный клиент, с телефона, до самого конца
- 5Сверьте данныеСпросите бота о том, что менялось вчера. Ответил старое — интеграции нет
- 6Посмотрите обрывыНа каком шаге люди уходят чаще всего. Там и лишний уровень меню
Если бот уже сделан и не работает
Сначала определите, какой из двух случаев ваш, — от этого зависит и цена, и смысл.
Случай первый: сломана обвязка. Отвалился вебхук, истёк токен, перестала работать интеграция, нет обработки повторов. Логика бота при этом нормальная. Это чинится точечно, за часы, и переделывать ничего не нужно.
Случай второй: бот собран без учёта того, как он будет жить. Состояние в памяти, никакой очереди, интеграций нет, мониторинга нет. Тут точечные правки бесполезны: каждая следующая проблема будет вылезать в новом месте. Честнее собрать заново, забрав из старого сценарий — он обычно единственное, что стоило работы.
Есть и третий случай, самый обидный: бот исправен, но решает не ту задачу. Его поставили принимать заявки там, где людям нужна консультация, — и он честно работает вхолостую. Это видно по диалогам за неделю: если люди пишут одно, а бот предлагает другое, чинить надо не код, а решение о том, зачем он вообще нужен.
Отличить одно от другого можно за час, посмотрев, как бот устроен внутри. Если хотите, чтобы посмотрел я, — расскажите задачу, разбор бесплатный, и я прямо скажу, чинить или пересобирать. Если окажется, что проще починить у того, кто делал, — так и скажу.
Про новые площадки: если бот живёт в молодом мессенджере, к списку выше добавляется скорость самой платформы. Как это выглядит на практике, разобрано в статье про создание бота в MAX — там API сменил адрес и ужесточил требования к вебхукам за несколько месяцев.
