Чат бот Octery не звал менеджера при лимитах: как проверить своего бота за 40 минут

Octery отвечает лидам (потенциальным клиентам, которые оставили заявку) в чатах amoCRM, российской системы учёта клиентов и сделок, и передаёт сделку менеджеру. Разработчик Octery описал, как у каждой компании в админке настраиваются две границы разговора, почему обе оказались пустой формальностью и как это исправили.

Первая настройка называется Max Messages, «максимум сообщений». Это число ответов, после которых бот передаёт клиента менеджеру. Вторая называется Hard Stop Threshold, «порог жёсткой остановки». Это число бессмысленных сообщений подряд, после которых бот делает то же самое.

Зачем такие лимиты, автор объясняет просто:

• Если человек задал уже двадцатый вопрос, ему пора к живому специалисту, бот своё дело сделал.
• Если в чат пишут «ааа», «тест», «???» или отвечает другой бот, каждое такое сообщение стоит вызова модели, то есть денег.

Почему лимиты молчали и этого никто не увидел?

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

Вторая ошибка сидела в ветке, которая подменяла ответ на фразу «передаю менеджеру». Она записывала результат в неправильные поля. Следующие шаги, отправка ответа и запись в журнал, брали данные из более раннего разбора ответа модели. Даже после исправления И на ИЛИ клиент получил бы обычный ответ бота, а в журнале не осталось бы следа.

Логика жила не в коде, а в конфигурации пайплайна (цепочки шагов, через которую проходит каждое сообщение). На такую конфигурацию нельзя написать юнит-тест (автоматическую проверку маленького куска программы), а на проверке правок её изменение выглядело как «поправил условие». Довести тестовый диалог до лимита вручную долго, поэтому до него не доходили.

Что понадобится для проверки своего бота?

• Доступ к настройкам бота, где заданы лимиты.
• Тестовый канал или отдельный тестовый контакт в CRM, чтобы не путать проверку с живыми клиентами.
• Доступ к журналу диалогов или аналитике бота.
• От 20 до 40 минут на прогон, в зависимости от размера лимитов.

Как проверить лимиты по шагам?

1. Временно поставьте маленькие лимиты на тестовом контакте, например 3 сообщения и 2 бессмысленных подряд. Так до границы дойдёте за минуты.
2. Задавайте осмысленные вопросы и считайте ответы. По логике Octery бот должен ответить ровно столько раз, сколько указано в лимите, а на следующем сообщении передать диалог.
3. Отдельно проверьте второй лимит: шлите «ааа», «тест», «???» подряд.
4. Вставьте одно нормальное сообщение посреди бессмыслицы. Серия должна обнулиться.
5. Откройте журнал. Там должна быть запись о передаче и её причина, а не обычный ответ.
6. Проверьте, какую фразу получил клиент. Если шаблон фразы пустой, должна уйти фраза по умолчанию.

Сами формулы у Octery выглядят так:

// счётчик ответов считается до текущего сообщения
const byMessages = messageCounter >= maxMessages;
// серия бессмыслицы считается вместе с текущим сообщением
const byNonsense = !meaningful && nonMeaningfulStreak + 1 >= hardStopThreshold;
if (byMessages || byNonsense) { /* передать менеджеру */ }

Что делать с этим прямо сейчас, по ролям

Автору Дзена, который принимает заявки через чат бот GPT или похожего бота: прогоните пять тестовых сообщений сегодня. Пять минут защитят от бесконечных разговоров, на которые уходят деньги за каждый вызов модели.

Маркетологу: проверьте аналитику. Старая ветка Octery заодно помечала переданные сообщения как бессмысленные, и это искажало статистику. Если цифры качества лидов выглядят странно, причина может сидеть в логике бота.

Предпринимателю: amoCRM доступна в России, так что всё описанное применимо напрямую. Спросите подрядчика по боту одно: есть ли автоматический тест на каждую цифру в настройках.