ТЗ на Telegram-бота: чеклист перед стартом разработки

Хорошее ТЗ на бота — не роман на 40 страниц. Это список решений: кто пользователь, какой один сценарий в первой версии, куда уходит заявка и чего точно нет в MVP. Без этого смета плавает, а «ещё одну кнопку» просят бесконечно.

Цель одним предложением. Например: «клиент записывается на услугу и админ получает карточку в Telegram». Если цель звучит как «умный помощник всего бизнеса» — дробите на этапы до первой пользы.

Сценарий по шагам. Приветствие → кнопки меню → поля (контакт, слот, комментарий) → подтверждение клиенту → пуш ответственному. Нарисуйте путь как список; по нему видно лишние вопросы и дыры.

Роли. Кто клиент, кто админ, нужны ли курьер / куратор / руководитель. Для каждой роли — своё меню и запреты. Без ролей в ТЗ потом выясняется, что «все видят всё».

Уведомления и SLA. Кому писать о новой заявке, нужен ли повторный пинг, напоминание клиенту перед визитом или вебинаром. Текст и срок (за N часов) лучше зафиксировать заранее.

Интеграции честно. Сайт deep-link, таблица, CRM, оплата, склад — что обязательно в этапе 1, что «потом». Каждый внешний контур = риск и тест; не тащите всё в день старта.

Контент и тон. Формулировки кнопок, ошибки («слот занят»), политика / согласие на контакт. Пустые плейсхолдеры на релизе бьют по доверию сильнее, чем «неидеальный дизайн».

Критерии приёмки. Тестовая заявка проходит от кнопки до пуша; админ видит нужные поля; нет доступа к чужим данным. Без чеклиста приёмки споры «готово / не готово» тянутся неделями.

Что обычно в этапе 2. Оплаты, сложные сетки расписания, отчёты, автоназначение, двусторонний синк с CRM. В ТЗ явно напишите «не входит» — иначе ожидания разъедутся.

Как ускорить старт с DevFuture. Короткая заявка + демо узкого сценария часто в день обращения; затем фиксируем смету доработок. Чеклист выше — хороший каркас письма в бота. Для записи смотрите кейс салона и посадочные «бот под ключ» / MVP за день.