Что должно быть в ТЗ на Telegram-бота: чек-лист с примерами
Хорошее описание задачи сокращает и смету, и сроки разработки Telegram-бота: чем меньше разработчик додумывает, тем меньше закладывает на риски. Ниже — чек-лист из 6 блоков, который я прошу заполнить клиентов перед оценкой проекта. Он же — фильтр от типовой ошибки: заказать «бота вообще» вместо бота под конкретный процесс.
1. Цель: какую метрику меняет бот
Один абзац, без которого всё остальное бессмысленно:
- Плохо: «Нужен бот для салона».
- Хорошо: «Клиенты записываются по телефону, администратор тратит на это 3 часа в день. Бот должен принимать 70% записей без участия человека».
Из цели вытекает и приоритет функций, и то, как мы поймём, что бот окупился.
2. Сценарии диалогов по шагам
Опишите 3–5 основных сценариев так, как их пройдёт живой клиент:
Сценарий «Запись на услугу»:
1. Клиент нажимает /start → приветствие + меню [Записаться] [Цены] [Вопрос]
2. [Записаться] → бот показывает список услуг (кнопки)
3. Выбор услуги → бот показывает свободные слоты на неделю
4. Выбор слота → бот просит телефон (кнопка «Поделиться контактом»)
5. Подтверждение → запись в календарь + уведомление администратору
6. За день до визита → автонапоминание клиенту
Такой формат отвечает на большинство вопросов проектирования: какие кнопки, какие данные собираем, кого уведомляем.
3. Граничные случаи и ошибки
Блок, который забывают в 9 из 10 брифов, а он определяет качество бота:
- Что видит клиент, если все слоты заняты?
- Что происходит, если клиент бросил диалог на середине и вернулся через день?
- Кто отвечает, если клиент задаёт вопрос не по сценарию? (вариант с ИИ-ответами по базе знаний я разбирал в статье про RAG-бота поддержки)
- Как клиент отменяет или переносит запись?
- Что делает бот при неудачной оплате?
4. Интеграции и данные
Перечислите системы, с которыми бот должен обмениваться данными, и в какую сторону:
| Система | Что передаём | Что получаем |
|---|---|---|
| CRM (amoCRM, Bitrix24…) | Контакт, сделка, ответы анкеты | Статусы, история клиента |
| Платежи (Stripe, Telegram Stars) | Счёт на оплату | Статус транзакции |
| Google Calendar / Sheets | Записи, заявки | Свободные слоты |
Если интеграция внутренняя (своя CRM, 1С) — приложите описание API или контакт того, кто им владеет. Как устроена связка бота с CRM технически — в отдельном руководстве с кодом.
5. Роли и права
- Кто администрирует бота (меняет тексты, смотрит заявки)?
- Кому приходят уведомления о новых заявках и оплатах?
- Нужна ли передача диалога человеку, и кто этот человек в рабочее/нерабочее время?
6. Нефункциональные требования
Коротко, но явно:
- Нагрузка: сколько пользователей в день ожидаете (10? 1 000? 10 000?) — от этого зависит архитектура.
- Языки: один или несколько.
- Данные: где хранить персональные данные клиентов, нужен ли экспорт.
- Ограничения платформы: у Telegram Bot API есть лимиты на частоту сообщений — массовые рассылки проектируются с их учётом.
Что происходит с этим брифом дальше
Заполненный чек-лист — это 1–2 страницы текста. По нему я готовлю спецификацию с этапами и фиксированной сметой (ориентиры по ценам — в статье сколько стоит Telegram-бот), мы согласовываем её, и разработка идёт с показом результатов каждые 3–5 дней.
Готовы описать задачу? Отправьте бриф через страницу разработки Telegram-ботов — отвечу с оценкой в течение 24 часов. Если сценарии пока не складываются — разберём их вместе на консультации.
Частые вопросы
Обязательно ли писать формальное ТЗ, или можно своими словами?
Своими словами — нормально. Хорошее описание задачи — это сценарии диалогов и список вопросов клиентов, а не ГОСТ. Формализацию в спецификацию я беру на себя на этапе брифа.
Кто пишет финальное ТЗ — заказчик или разработчик?
Разработчик, на основе вашего брифа. Вы описываете бизнес-задачу и сценарии, я превращаю их в спецификацию с состояниями, интеграциями и планом этапов — и мы согласовываем её до старта.
Насколько подробным должно быть описание?
Достаточно 1–2 страниц: цель бота, 3–5 сценариев диалога по шагам, список интеграций и примеры реальных вопросов клиентов. Детализация сверх этого редко ускоряет проект.
Что делать, если требования изменятся в процессе?
Это нормально и ожидаемо. Я показываю промежуточные результаты каждые 3–5 дней, поэтому правки вносятся по ходу, а крупные изменения объёма оформляются отдельным этапом, чтобы смета оставалась прозрачной.