Техническое задание на разработку бота: как составить ТЗ, чтобы получить именно тот продукт, который нужен
30 сентября 2026
Каждый второй заказчик бота сталкивается с одной и той же проблемой: исполнитель сдал проект, бюджет потрачен, а результат не соответствует ожиданиям. Причина почти всегда одна — размытое или отсутствующее техническое задание. Правильно составленное ТЗ экономит до 40% бюджета, сокращает сроки разработки в полтора-два раза и превращает споры с подрядчиком в конструктивный диалог. Разберём по шагам, как написать техническое задание на разработку бота, которое сработает.
40%
бюджета сгорает на доработках без чёткого ТЗ
2×
дольше идёт проект при правках «по ходу дела»
70%
конфликтов с подрядчиком вызваны разным пониманием задачи
0
сюрпризов — если ТЗ написано по всем правилам
Что такое техническое задание на разработку бота и зачем оно нужно
Техническое задание — это документ, который фиксирует что должен делать бот, как он должен это делать и по каким критериям результат считается принятым. Это не формальность для бухгалтерии и не «лишняя бумажка». Это инструмент управления проектом, который защищает обе стороны.
Хороший пример аналогии: ТЗ — как чертёж для строителя. Никто не строит дом по описанию «хочу красиво, с окнами и чтобы светло». Но с ботами такое происходит регулярно.
✗ Как выглядит плохое ТЗ
«Нужен бот в Телеграме для интернет-магазина. Чтобы принимал заказы, отвечал клиентам и вообще был удобный. Как у конкурентов, только лучше»
«Telegram-бот на Python (aiogram 3.x). Приём заказов: каталог из 3 категорий, корзина, оплата через ЮKassa, уведомление менеджеру в CRM amoCRM. Ответы на 12 типовых вопросов из FAQ-базы. Нагрузка — до 500 пользователей в день»
Структура идеального ТЗ на разработку бота: 10 обязательных разделов
Нажмите на любой раздел, чтобы раскрыть подробное описание с примерами и типичными ошибками.
1. Цель и бизнес-задача+
Не «нужен бот», а какую проблему бизнеса он решает: автоматизация продаж, снижение нагрузки на поддержку, сбор заявок, уведомления, бронирование. Укажите измеримую метрику успеха: например, «сократить время ответа клиенту с 30 минут до 1 минуты» или «автоматизировать 60% обращений в поддержку».
2. Платформа и каналы+
Конкретный мессенджер или несколько: Telegram, WhatsApp Business API, ВКонтакте, сайт-виджет. У каждой платформы свои ограничения: в WhatsApp — платные шаблонные сообщения и модерация, в Telegram — лимиты API (30 сообщений в секунду). Если нужен омниканальный бот — это отдельное требование, влияющее на архитектуру.
3. Сценарии диалогов (user flow)+
Самый важный раздел. Опишите карту диалогов: что видит пользователь на каждом шаге, какие кнопки, какие ответы бота, что происходит при ошибке ввода, как пользователь возвращается в главное меню, как диалог передаётся живому оператору. Формат — схема (Miro, draw.io) или таблица «действие пользователя → реакция бота».
4. Функциональные требования+
Полный список функций глаголами: «бот должен принимать файлы до 20 МБ», «бот должен отправлять рассылку по сегментам», «бот должен выдавать PDF-отчёт». Каждая функция = отдельный пункт, за который отвечает исполнитель. Избегайте слов «удобно», «интуитивно», «быстро» без конкретных цифр.
5. Интеграции+
CRM (amoCRM, Битрикс24), платёжные системы (ЮKassa, Stripe, CloudPayments), базы данных, 1С, Google Таблицы, службы доставки. Для каждой интеграции укажите: есть ли доступ к API, кто предоставляет ключи, в каком направлении идут данные. Интеграции — самая трудоёмкая часть, и именно тут чаще всего «всплывают» дополнительные расходы.
6. Технические требования и стек+
Где будет размещён бот (ваш сервер, сервер разработчика, облако), язык и фреймворк (если есть предпочтения), база данных, требования к коду (документация, исходники в Git, Docker). Если бот работает с персональными данными — требования по 152-ФЗ и месту хранения данных.
7. Нагрузка и производительность+
Прогнозируемое число пользователей, пиковые нагрузки (например, при рассылке), допустимое время ответа бота (норма — до 2 секунд), требования к доступности (uptime 99% и выше). Бот на 100 пользователей и бот на 100 000 пользователей — принципиально разные архитектуры и бюджеты.
8. Админ-панель+
Кто и как будет управлять ботом после запуска: редактирование текстов, добавление товаров, просмотр статистики, управление рассылками, блокировка пользователей. Часто именно админка съедает треть бюджета, а заказчик вспоминает о ней после сдачи проекта. Опишите её заранее — хотя бы списком функций.
9. Критерии приёмки и тестирование+
Формализуйте, как проверяется готовность: чек-лист сценариев, количество итераций по исправлению багов, срок гарантийной поддержки. Классика жанра: «бот прошёл 100% сценариев из ТЗ без критических ошибок». Без этого пункта споры о «недоделках» неизбежны.
10. Сроки, этапы и порядок оплаты+
Разбейте проект на этапы с конкретными датами и результатами каждого этапа: прототип сценариев → MVP → интеграции → тестирование → запуск. Привяжите оплату к этапам, а не к времени. Это дисциплинирует обе стороны и делает процесс прозрачным.
Разным ботам — разное ТЗ
Объём и акценты технического задания зависят от типа бота. Выберите тип, чтобы увидеть, на чём концентрировать внимание.
Ключевые разделы ТЗ: каталог и корзина, платёжные интеграции, уведомления о статусе заказа, интеграция с учётной системой (1С, МойСклад), промокоды и программы лояльности.
Главный риск: недосказанность про оплату. Фискализация, возвраты, частичная оплата, работа с юрлицами — прописывайте всё, иначе это станет доплатами.
Ключевые разделы ТЗ: база знаний и FAQ, логика эскалации на оператора, часы работы, сбор обратной связи (CSAT), интеграция с тикет-системой.
Главный риск: неописанный «переход на человека». Когда бот передаёт диалог? Кому? Что видит оператор? Без этого бот раздражает клиентов вместо того, чтобы помогать.
Ключевые разделы ТЗ: логика квизов и вопросов, квалификация лидов, передача заявок в CRM, уведомления менеджерам, воронка прогрева (цепочки сообщений).
Главный риск: отсутствие согласия на обработку персональных данных. С 2025 года за нарушения 152-ФЗ штрафы существенно выросли — юридический блок в ТЗ обязателен.
Ключевые разделы ТЗ: роли и права доступа, интеграция с внутренними системами (1С, Jira, Active Directory), уведомления, отчётность, безопасность корпоративных данных.
Главный риск: нагрузка и безопасность. Внутренний бот на 2 000 сотрудников с доступом к закрытым данным требует серьёзной проработки архитектуры — не экономьте на этом разделе.
Сколько стоит разработка и как ТЗ влияет на цену
Уровень бота
Что входит
Срок
Бюджет
Простой
Меню, FAQ, сбор заявок, рассылка. Без интеграций
1–2 недели
30–80 тыс. ₽
Средний
Оплата, интеграция с CRM, админ-панель, аналитика
3–6 недель
100–300 тыс. ₽
Сложный
Несколько интеграций, высокая нагрузка, ИИ-модуль, кастомная архитектура
2–4 месяца
от 400 тыс. ₽
Правило маркетолога
Если разработчик называет точную цену и срок, не видя ТЗ, — он либо сильно опытен и берёт с запасом, либо назовёт новую цифру через месяц. Всегда требуйте оценку после согласования технического задания. Оценка «по примеру» — не обязательство.
7 смертных ошибок при составлении ТЗ на бота
1. «Сделайте как у конкурента»
Чужой бот — это видимая часть айсберга. Логика, интеграции и нагрузки остаются за кадром, а значит — вне бюджета.
2. Отсутствие негативных сценариев
Что если пользователь вводит ерунду, шлёт спам, прерывает оплату на последнем шаге? 30% кода бота — обработка нештатных ситуаций.
3. Размытые формулировки
«Быстро», «красиво», «умный ИИ» — недопустимы. Замените на измеримое: «ответ бота — до 2 секунд при нагрузке 50 RPS».
4. Лёгкое отношение к интеграциям
«Интегрируем с вашей CRM» — а у CRM может не быть нормального API. Проверьте наличие API и документации до подписания договора.
5. Забытая админ-панель
Если менять тексты и цены сможет только программист, бот превратится в ежемесячное расходное обязательство.
6. Нет прав на результат
Фиксируйте: исходный код, доступ к хостингу и аккаунтам мессенджеров принадлежат заказчику. Иначе вы — заложник исполнителя.
7. ТЗ без критериев приёмки
Без чек-листа приёмки спор «это баг или фича» закончится только когда закончится терпение или бюджет. Обычно — бюджет.
Интерактивный чек-лист: готово ли ваше ТЗ
Отметьте пункты, которые уже описаны в вашем техническом задании, и оцените его готовность.
Готовность ТЗ0%
Начните отмечать пункты — и увидите оценку.
Вывод
Техническое задание на разработку бота — это не бюрократия, а самый дешёвый способ «доработать» бота ещё до того, как написана первая строка кода. Один час, потраченный на формулировку требования, экономит день программирования, недели правок и нервы обеих сторон.
Формула успеха короткая: измеримая цель → карта сценариев → конкретные функции → проверенные интеграции → критерии приёмки. Пять шагов — и ваш бот имеет все шансы быть сданным в срок, в бюджет и без «сюрпризов».