Как составить ТЗ на чат-бота: шаблон для Telegram, MAX и сайта

Начните с результата, а не с технологии

Чтобы обсудить чат-бота с разработчиком, необязательно знать API, Webhook и названия библиотек. Хорошее техническое задание начинается с ответа на простой вопрос: что должен получить пользователь и что после этого должна сделать компания.

Формулировка «нужен современный умный бот» почти ничего не сообщает. Гораздо полезнее: «клиенты пишут после рабочего времени, бот должен уточнить задачу, собрать контакт и передать обращение менеджеру».

1. Опишите бизнес-задачу и роли

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

Для каждой роли укажите доступные действия. Клиент отправляет заявку, менеджер получает её, администратор обновляет содержание. Одинаковые права для всех — не упрощение, а риск.

2. Выберите канал и объясните причину

Для MAX заранее проверяют актуальные правила профиля и размещения. Для сложного интерфейса внутри Telegram отдельно оценивают Mini App; анкета из нескольких вопросов обычно в нём не нуждается.

• Telegram — если большая часть обращений уже происходит там или нужен повторный контакт.
• MAX — если аудитория или внутренний процесс требуют присутствия на этой платформе.
• Сайт — если бот должен помогать посетителю непосредственно на странице.
• Несколько каналов — если есть общий процесс, но интерфейс будет адаптирован под каждый API.

3. Опишите точку входа

Укажите, откуда пользователь приходит: кнопка на сайте, QR-код, ссылка в рекламе, профиль компании, сообщение в мессенджере или внутренняя ссылка для сотрудников.

Если источники нужно различать, предусмотрите метки или стартовые параметры. Так можно узнать источник заявки, не спрашивая человека вручную.

4. Нарисуйте основной сценарий

После основного пути добавьте исключения: отмену, повторную заявку, неожиданное сообщение и недоступную интеграцию.

• Что пользователь видит на каждом шаге.
• Что он может отправить и как проверяется ввод.
• Куда сохраняется результат.
• Можно ли вернуться назад или отменить действие.
• Что происходит при ошибке или молчании.

Старт
→ приветствие
→ выбор задачи
→ уточняющие вопросы
→ контакт
→ подтверждение
→ передача менеджеру

5. Перечислите данные

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

Не помещайте реальные пароли, API-ключи и токены в ТЗ. Доступы передаются отдельно через согласованный защищённый канал.

6. Опишите интеграции как операции

Фраза «интегрировать с CRM» недостаточна. Лучше: «после подтверждения создать одну сделку, приложить ответы и источник; при недоступности сохранить событие для повторной отправки и уведомить ответственного».

• Название и назначение внешней системы.
• Какие данные отправляются и какие возвращаются.
• Есть ли актуальная документация API.
• Что делать при ошибке или повторном запросе.
• Кто предоставляет тестовый доступ с минимальными правами.

7. Зафиксируйте правила для AI

8. Опишите передачу человеку и уведомления

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

• Какое событие запускает передачу.
• Кто получает уведомление и по какому каналу.
• Какие данные и история доступны сотруднику.
• Что в этот момент видит клиент.
• Как фиксируется принятие заявки.
• Нужна ли повторная попытка, если уведомление не доставлено.

9. Укажите доступы и журналирование

• Кто имеет доступ к заявкам и как подтверждается это право.
• Какие действия записываются и кто видит журнал.
• Как отзывается доступ сотрудника.
• Кто может менять настройки и базу знаний.
• Какие данные нельзя выводить в журнал.
• Как изолируются данные разных организаций.

10. Составьте проверяемые критерии приёмки

Критерий должен проверяться однозначно. «Бот работает быстро, надёжно и умно» не подходит. Хорошие примеры: при повторной отправке создаётся не больше одной сделки; без подтверждённого доступа нельзя просмотреть заявки; если AI не находит источник, он не придумывает условие и передаёт вопрос специалисту.

• Основной путь и обязательные поля.
• Неверный ввод и отмена.
• Повторное сообщение и защита от дублей.
• Временная ошибка CRM или другого API.
• Неизвестный вопрос и передача человеку.
• Попытка доступа без разрешения.

11. Опишите запуск и поддержку

У компании должен оставаться контролируемый доступ к своим ключевым аккаунтам и ресурсам.

• Кто регистрирует бота и владеет аккаунтом, доменом и рабочими ресурсами.
• Где размещается приложение и кто следит за ошибками.
• Как обновляется база знаний.
• Что входит в исправление дефектов после запуска.
• Как отдельно оцениваются новые функции.

Шаблон ТЗ, который можно скопировать

На первом этапе необязательно выбирать язык программирования, базу данных, AI-модель или библиотеку. Эти решения разработчик должен обосновать требованиями. Заказчику важнее точно описать процесс, ограничения и ожидаемый результат.

1. Название проекта:
2. Бизнес-задача:
3. Пользователи и роли:
4. Каналы:
5. Откуда приходит пользователь:
6. Основной сценарий:
7. Альтернативные сценарии и ошибки:
8. Собираемые данные:
9. Внешние системы:
10. Правила AI и источники:
11. Передача человеку:
12. Уведомления:
13. Права доступа:
14. Критерии приёмки:
15. Материалы заказчика:
16. Ответственные лица:
17. Порядок запуска:
18. Порядок поддержки: