Как составить ТЗ на Telegram-бота

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

Фраза «сделать бота как у конкурента» не заменяет ТЗ. Полезнее прислать ссылку и отметить конкретные элементы: порядок вопросов, кнопки, способ оплаты, уведомление менеджера или работу с повторной заявкой.

Этот список можно скопировать, заполнить обычными словами и отправить разработчику. Если какого-то решения пока нет, так и напишите.

• 1. Цель

  Какую ручную работу или проблему должен убрать бот. Какой результат нужен бизнесу после запуска.

• 2. Пользователи

  Кто будет пользоваться ботом: клиент, менеджер, администратор или несколько ролей.

• 3. Первый запуск

  Что пользователь видит после /start, какие есть кнопки и с чего начинается основной сценарий.

• 4. Основной сценарий

  Вопросы и действия по порядку. Для каждого шага укажите допустимый ответ и следующий шаг.

• 5. Данные

  Что нужно сохранить: имя, телефон, сумма, адрес, комментарий, файлы, согласие или другие поля.

• 6. Интеграции

  Куда отправлять результат: Telegram менеджера, CRM, Google Sheets, база данных, сайт или внешний API.

• 7. Ошибки и повторные действия

  Что делать при неверном вводе, недоступности CRM, повторном нажатии и возвращении пользователя через несколько дней.

• 8. Администрирование

  Кто видит заявки, меняет статусы, редактирует тексты, делает выгрузку и получает сообщения об ошибках.

• 9. Готовность

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

• 10. Запуск и поддержка

  Где будет работать бот, кто оплачивает сервер, кому передаются доступы и какие изменения планируются после первой версии.

Ниже сокращённый пример по мотивам USDT Exchange Bot. Он показывает нужный уровень конкретики, но не раскрывает закрытые данные заказчика.

• Цель

  Собрать заявку на обмен внутри Telegram и передать менеджеру заполненные данные вместо свободного сообщения.

• Сценарий

  Пользователь выбирает направление обмена, указывает сумму и город, подтверждает найденный контакт и проверяет сводку.

• Данные

  Направление, сумма, офис, контакт пользователя, статус черновика и время последнего шага.

• Интеграция

  После подтверждения заявка сохраняется и передаётся в CRM через отдельный клиент.

• Особые случаи

  Неверная сумма, отмена, повторный запуск, незавершённая заявка и защита от повторного напоминания.

Критерий приёмки описывает проверяемое действие. Формулировка «бот работает корректно» слишком общая. Ниже примеры, которые можно пройти перед запуском.

• После /start пользователь видит приветствие и кнопку начала заявки.
• Бот не принимает текст вместо числовой суммы и объясняет, как исправить ввод.
• После подтверждения создаётся одна заявка, даже если пользователь нажал кнопку дважды.
• Менеджер получает все согласованные поля и ссылку на пользователя.
• При недоступности CRM заявка не теряется, а ошибка попадает в служебный журнал.
• После перезапуска приложения незавершённый сценарий можно продолжить по согласованным правилам.

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

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