Метод двадцати вопросов: как поймать чат-бота на вранье до жалобы клиента

Метод двадцати вопросов — это проверка чат-бота не демо-диалогом, а заранее составленным списком из 20 реплик: часть из FAQ, часть провокационных, часть на стыке с учётной системой. Каждый ответ оценивают по пяти критериям и сравнивают итоговый балл с порогом, ниже которого бота нельзя выпускать на сайт без доработки.

Демо на трёх репликах — не тест

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

Три реплики демо и двадцать вопросов теста — разные вещи. Демо проверяет, что бот вообще запущен и отвечает по-русски на понятном языке. Тест проверяет, что бот не наврёт в ситуации, которую никто заранее не прописал в сценарии. Разница в том, что демо выбирает вопросы человек, который знает, как бот устроен, и невольно задаёт удобные — тест собирает вопросы из реальной жизни, включая те, что бота ломают.

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

Из чего собрать двадцать вопросов

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

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

Кто задаёт вопросы

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

Как считать очки: пять критериев ответа

Каждому ответу ставят баллы от 0 до 2 по пяти критериям, максимум 40 баллов на весь список из двадцати вопросов:

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

Сумма ниже 30 из 40 — сигнал, что бота рано выпускать на боевой сайт: слишком высокий риск, что клиент наткнётся на выдуманный ответ раньше, чем на живого менеджера. Балл 30–35 обычно означает точечные правки в паре сценариев. Выше 35 — бот готов, но список стоит повторить после следующего значимого изменения на сайте или в учётной системе.

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

Цена бездействия: во что обходится один провальный ответ

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

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

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

Что делать с результатами теста

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

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

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

Когда двадцати вопросов мало: многоходовые диалоги

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

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

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

❓ Частые вопросы

Сколько вопросов реально нужно для маленького сайта?

Двадцать — рабочий минимум, который закрывает пять категорий по 4 вопроса. Для сайта с узким ассортиментом и простыми сценариями можно сократить до 12–15, но убирать стоит только категории, которых нет в диалоге в принципе, а не самые неудобные вопросы.

Можно ли провести тест без разработчика?

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

Как часто повторять тест после запуска бота?

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

Бот путает остатки и цены — с чего начать?

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

Нужно ли специально проверять бота на грубость?

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