Техническое задание на разработку чат-бота: шаблон из 9 разделов и типичные ошибки
Техническое задание (ТЗ) на чат-бота фиксирует бизнес-задачу, пользователей, каналы, обмен данными с другими системами и критерии приемки. Оно не обязано быть длинным: несколько страниц с конкретными сценариями обычно полезнее объемного списка пожеланий. Ниже — шаблон из девяти разделов и рекомендации, которые помогут заказчику и исполнителю одинаково понимать объем работ.
Зачем нужно ТЗ и можно ли обойтись без него
ТЗ помогает сравнить предложения подрядчиков по одному объему и заранее договориться, что будет считаться готовым результатом. Без этого один исполнитель может оценивать простой FAQ-бот, а другой — решение с CRM и платежами. Сравнить такие цены напрямую нельзя.
Составлять подробное ТЗ самостоятельно необязательно. Можно начать с краткого брифа о задаче, аудитории, каналах, системах, бюджете и сроках, а требования уточнить вместе с подрядчиком на этапе discovery. Полезный ориентир — стандарт ISO/IEC/IEEE 29148 по инженерии требований: требования должны быть понятными, проверяемыми и связанными с целью. Для обычного бизнес-бота стандарт не является обязательным шаблоном.
Шаблон ТЗ на чат-бота: 9 разделов
Минимальное ТЗ включает девять тем:
| № | Раздел | Что указать | Пример формулировки |
|---|---|---|---|
| 1 | Цель и метрика | Какую проблему решаем и как измеряем результат | «Сократить время первого ответа на заявку с 4 часов до 5 минут» |
| 2 | Пользователи и роли | Кто общается с ботом и кто управляет им | «Клиенты, менеджеры по продажам, администратор контента» |
| 3 | Каналы | Telegram, Viber, сайт или Mini App | «Telegram и Viber с одинаковой логикой» |
| 4 | Сценарии | Шаги, варианты ответов и развилки | «Заявка: 4 вопроса → подтверждение → сделка в CRM» |
| 5 | Контент | Кто готовит тексты, языки и FAQ | «FAQ из 40 вопросов заказчик предоставляет на украинском» |
| 6 | Интеграции | Системы, события, направления обмена и поля | «KeyCRM: создание контакта и сделки, статус обратно в бот» |
| 7 | Админ-панель | Что команда должна менять самостоятельно | «Тексты, FAQ, рассылки с сегментацией» |
| 8 | Нефункциональные требования | Нагрузка, данные, доступы и хостинг | «До 5 000 пользователей, данные на серверах заказчика» |
| 9 | Приемка | Как проверяем готовность и фиксируем ошибки | «30 тест-кейсов из таблицы пройдены без ошибок» |
Формулируйте требования конкретно. Например, вместо «бот быстро отвечает» укажите целевое время и условия измерения; вместо «подключить CRM» — какие события создают контакт или сделку и какие статусы возвращаются в бот.
Как описывать сценарии, чтобы их поняли одинаково
Сценарий — это последовательность действий и ожидаемый результат, а не просто название функции. Для сбора заявки опишите, откуда приходит пользователь, какие вопросы видит, что происходит при нестандартном ответе и где менеджер получает данные.
Для каждого сценария зафиксируйте триггер, шаги, развилки, результат и обработку ошибок. Например: пользователь открывает ссылку, отвечает на четыре вопроса, подтверждает данные; бот создает сделку в CRM, а при недоступности CRM ставит событие в очередь и сообщает ответственному. Текстовое описание и схема процесса должны совпадать.
Что указать в ТЗ об интеграциях
Интеграции влияют на стоимость и риски, поэтому одного пункта «интеграция с CRM» недостаточно. Для каждой системы укажите ее название, доступность API и тестовой среды, направление обмена, события, поля, правила поиска дублей и ответственного за доступы.
Уточните, что бот отправляет и получает, как обрабатываются повторные запросы и сбои, и кто предоставляет учетные данные. Пошаговый разбор есть в материале об интеграции чат-бота с CRM. При замене учетной системы отдельно зафиксируйте связанные изменения; общий контекст — в статье о переходе с 1С/BAS.
Если в боте будет AI
Для AI-бота опишите источники знаний и границы ответов, а не только пожелание «пусть отвечает умно». Укажите, кто обновляет документы, какие темы и действия запрещены, когда бот должен признать, что не знает ответа, и как он передает диалог человеку.
Согласуйте контрольный набор примеров с ожидаемыми ответами и критериями оценки. Зафиксируйте месячный лимит расходов на API и поведение системы при его достижении. Дополнительно полезно определить права доступа модели к инструментам и данным. Дополнительный контекст о границах и доступах — в статье о безопасности AI-чат-ботов.
Типичные ошибки в ТЗ
Чаще всего проекту мешает неопределенность: требования нельзя проверить, а интеграция описана одной строкой. Другие распространенные ошибки — ссылка «сделать как у конкурента» без объяснения нужных деталей, функции без бизнес-цели, отсутствие админ-панели и неясное распределение ответственности за контент.
Не включайте Mini App, AI и геймификацию в первую версию «на всякий случай». На discovery разумно определить один основной сценарий, метрику и минимально необходимые интеграции, а остальное запланировать отдельными этапами. Логику формирования цены BotLabs описывает на странице стоимости чат-бота.
Краткий бриф вместо полного ТЗ
Если подробного документа пока нет, подготовьте семь пунктов: задачу и метрику успеха; пользователей и ожидаемый объем; каналы; три главных сценария; системы для интеграции; желаемый срок первой версии; ориентировочный бюджет или диапазон. Этого достаточно, чтобы подрядчик задал уточняющие вопросы, но не всегда достаточно для окончательной оценки.
Примеры решений разного масштаба собраны в портфолио BotLabs, в том числе Viber-бот для REHAU и система для сети «Файні Льоди».
Вывод
Хорошее ТЗ отвечает на девять вопросов: зачем нужен бот, кто им пользуется, где он работает, каковы сценарии и контент, с чем он интегрируется, что можно менять в админ-панели, какие есть технические ограничения и как проходит приемка. Если времени мало, начните с семи пунктов брифа и уточните требования вместе с исполнителем.
Часто задаваемые вопросы
Цель и метрика, пользователи и роли, каналы, сценарии, контент, интеграции, админ-панель, нефункциональные требования и критерии приемки.
Для типового бизнес-бота может хватить нескольких страниц с четкими сценариями и проверками. Однозначность требований важнее объема документа.
Да. Подготовьте краткий бриф, а подробные требования согласуйте на discovery. Без описания задачи предложения разных подрядчиков будет трудно сравнить.
Название системы, направление обмена, события, карту полей, правила поиска дублей, доступность API и ответственного за доступы.
Укажите источники знаний, ограничения, передачу диалога человеку, контрольные примеры и лимит расходов на API.
Для каждого важного сценария задайте входные данные, ожидаемое поведение, обработку исключений и того, кто подтверждает результат.
Источники
Консультация по ТЗ на чат-бота
За 15 минут со специалистом BotLabs по внедрению обсудим, как вы принимаете заявки или заказы и что должно попадать в CRM. Определим, какие требования и примеры нужно подготовить для ТЗ первой версии.
Обсудим процесс.
Уточним требования.
15 минут со специалистом по внедрению: обсудим заявки, CRM и требования к первой версии.
