Как составить ТЗ на чат-бота для заявок

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

Сначала опишите результат диалога

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

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

Я бы отдельно обозначил границу автоматизации. Какие вопросы бот разбирает по согласованному сценарию, а где предлагает помощь человека? Не стоит закладывать самостоятельное согласование нестандартных условий, если бизнес не подготовил для этого правила. Роль бота рядом с другими площадками можно определить, опираясь на разбор старта продвижения в VK и Max.

Что изменилось недавно. 30 октября 2026 года VK сообщила об итогах хакатона MAX, где участники представили прототипы чат-ботов и мини-приложений, в том числе в направлении «Эффективный бизнес». Реализация решений победителей описана как будущая работа; я рассматриваю новость как повод обсудить проектирование, а не как доказательство готовности конкретного продукта.

Соберите сценарии и исключения

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

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

Не превращайте список исключений в обещание, что выбранный конструктор всё умеет. Это требования для обсуждения с исполнителем. Попросите его отметить, что доступно в выбранном решении, что требует отдельной разработки, а что лучше исключить из первого запуска. Нерешённый вопрос стоит оставить явным, а не прятать за фразой «стандартная логика».

Я рекомендую согласовать и содержимое ответов. Условия услуги, ограничения и формулировки подтверждения должен проверить человек, который отвечает за предложение бизнеса. Исполнитель может собрать диалог, но ему не следует угадывать правила записи или причины отказа. Для меня понятный сценарий — тот, который можно прочитать и пройти до начала программирования.

Опишите передачу обращения сотруднику

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

Разделяйте действия системы и сотрудника. Бот может отправить сведения, но отметка о доставке сама по себе не означает, что менеджер начал работу. Я советую заранее договориться, как будет видно принятие обращения и кто проверит его, если основной сотрудник отсутствует. Не называйте передачу завершённой, пока не определён этот переход.

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

Для связи с внешней системой попросите исполнителя указать условия и ограничения обмена. Что считается успешной отправкой, как обнаружить отказ и кто увидит проблему? Без подтверждённой совместимости не стоит писать в задании, что любая нужная интеграция уже доступна. Понятное ограничение полезнее неподтверждённого ожидания.

Зафиксируйте требования и ограничения

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

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

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

Проверьте сценарий до приёмки

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

Включите в проверку:

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

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

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

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

Нужен ли ИИ в боте для заявок?

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

Можно ли начать без интеграции с CRM?

Можно обсудить более простой способ передачи, если команда способна принимать и учитывать такие обращения. В задании всё равно нужны место доставки, ответственный, состав сведений и проверка результата. Я рекомендую оценивать выбранный вариант по реальному процессу, а не по наличию названия системы в списке функций.

Как понять, что бот готов к запуску?

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

чат-ботызаявкиавтоматизациясценарии