Как заказать чат-бота: короткое ТЗ, выбор исполнителя и приёмка

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

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

Какой тип решения нужен

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

Смешанный подход не является обязательным. Если нужно только показать статус по номеру заказа, модель может вообще не понадобиться. Выбор следует из задачи и допустимых ошибок.

Десять полей задания

Поле	Что зафиксировать на примере замера
1. Результат	Подтверждённая заявка передана ответственному
2. Пользователи	Новые и действующие клиенты, различия их запросов
3. Ситуации	Первое обращение, уточнение, перенос, отмена, жалоба
4. Факты	Действующий прайс, зона выезда, расписание и условия
5. Каналы	Один выбранный канал на пилоте
6. Связи с системами	Какие поля читать и какие разрешено менять
7. Передача человеку	Причины, адресат, срок реакции и поведение бота после передачи
8. Ограничения	Никаких вымышленных скидок, сроков и чужих данных
9. Данные	Цель сбора, основание, доступ, хранение и удаление
10. Приёмка	Входные условия, ожидаемое действие и доказательство результата

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

Кто будет делать и поддерживать

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

Двадцать ситуаций для приёмки

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

1. Новый клиент создаёт заявку.
2. Клиент меняет один параметр до подтверждения.
3. Согласованный адрес находится вне зоны выезда.
4. Выбранное время уже занято.
5. Клиент переносит подтверждённый замер.
6. Клиент отменяет запись.
7. Повтор того же сообщения не создаёт новую заявку.
8. Два последовательных сообщения дополняют один запрос.
9. Цена совпадает с действующим источником.
10. Отсутствующая в прайсе опция передаётся на уточнение.
11. Неизвестный вопрос не получает вымышленный ответ.
12. Жалоба направляется ответственному.
13. Прямая просьба о человеке выполняется.
14. Бот замолкает после вступления менеджера.
15. Недоступная CRM не превращается в ложное «заявка принята».
16. Неудачное уведомление менеджеру видно в журнале.
17. Просьба раскрыть чужую заявку отклоняется.
18. Команда клиента обойти правила не меняет права бота.
19. Отказ от дальнейших сообщений учитывается.
20. После восстановления связи проверяется фактическое состояние заявки.

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

Восемь вопросов исполнителю

1. Кто отвечает за проект и дальнейшие обращения?
2. Какие результаты входят в каждый этап?
3. Чем подтверждается приёмка?
4. Где проходят и хранятся данные, кто их видит?
5. Какие сторонние сервисы и модели оплачиваются отдельно?
6. Как решение ведёт себя при сбое и передаче человеку?
7. Как обновлять правила и кто исправляет ошибки после запуска?
8. Что получит компания при завершении сотрудничества?

Как проверить экономику

Условный пример: сотрудник тратил на подготовку карточек 30 часов в месяц, после запуска тратит 12 часов на проверку и исключения. Освободилось 18 часов, а не вся исходная нагрузка. Денежной экономией это становится только при изменении расходов либо подтверждённой полезной работе в освободившееся время.

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

Шесть ошибок, которые видно до старта

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

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