Приёмка чат-бота: что проверить перед запуском

Коротко: тем, кто задаёт вопросы и как фиксируется результат. На демонстрации вопросы подбирает исполнитель, на приёмке — вы.

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

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

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

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

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

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

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

Четыре критерия к каждому ответу: точен (совпадает с утверждённым), полон (не потерял важное условие), понятен человеку, правильно уходит человеку там, где должен. Отдельно — отрицательные случаи: спросить то, чего в базе нет. Консультант обязан не выдумывать и не спорить.

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

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

Заготовьте: «дайте гарантию, что не сломается», «а скидку дадите?», «назовите срок, которого нет в прайсе», «поставьте диагноз по фото», «проконсультируйте юридически». По каждой ожидаемый результат один: отказ и передача человеку, а не попытка ответить.

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

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

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

Проверяется до подписания акта, потому что после вы уже не в позиции заказчика.

Что должно быть у вас, а не у подрядчика: доступ к диалогам, возможность выгрузки, понятный ответ на вопрос «кто видит персональные данные». Если доступ даётся «по запросу в поддержку», это тоже ответ, и его стоит зафиксировать.

Правовая рамка, без которой эта группа неполна. По 152-ФЗ «О персональных данных» оператором данных посетителей остаётесь вы. Отдельно полезен принцип из ст. 5: обрабатываемые данные не должны быть избыточными по отношению к заявленным целям (официальный текст). Это прямой аргумент против «пусть клиент напишет всё, а менеджер разберётся».

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

Коротко: тестом «ненайденный ответ». Задать вопрос, которого нет в базе, и посмотреть, кто получил его, за какой срок и сохранилась ли история диалога.

Задайте вопрос, которого заведомо нет в базе, и смотрите на три вещи: появился ли адресат (кто получил), есть ли срок реакции (а не «когда-нибудь»), сохранилась ли история диалога — чтобы человек не начинал с «здравствуйте, чем помочь» после нескольких реплик.

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

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

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

Сколько стоят работы и что входит в каждый вариант — на странице тарифов.

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

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

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

Люди. Даже идеально принятая система ломается, если сотрудник, которому уходит эскалация, не знает, что она теперь на него приходит.

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

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

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

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

Нет договора и акта. Принимать нечего: приёмка — процедура по документу. Если подрядчик работает «на словах», сначала документ, потом проверки.

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

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

Вы. Подрядчик может дать доступ и показать, как смотреть логи; приёмка — ваша процедура, иначе она превращается в самопроверку исполнителя.

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

Для проверки договора и документов по персональным данным — да. Для проверки ответов и маршрута заявки юрист не нужен.

Можно, если зафиксировано, какие ответы отсутствуют, и есть срок, к которому они появятся. Приёмка «с открытым списком» нормальна; приёмка «мы не смотрели» — нет.

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

Получить демо на своём сайте — прогоните их до того, как подписывать что-либо.

Читайте также: Почему бот не отвечает по базе знаний — и что с этим делать · Как посчитать эффект от ИИ-консультанта — методика без обещаний · Технические вопросы клиентов: что отдавать инженеру, а что закрывать на сайте · Семь вопросов поставщику ИИ-консультанта — до подписания договора · Сколько стоит ИИ-консультант на сайте — и из чего складывается цена · Все статьи блога

Павел Гмир, основатель LeanAgent. Пятнадцать лет на производстве, запуск RAV4 на «Тойота СПб», два цеха. Разбираю, как компании теряют обращения на входе в поток. Обсудить можно в Telegram или в TenChat.

Источники: публичная оферта LeanAgent, 12.04.2026 (п. 7.1, п. 3.7) — leanagent.ru/of · 152-ФЗ «О персональных данных», официальный текст — kremlin.ru