«Нужен бот с кнопками и CRM» — понятное начало разговора, но недостаточное описание для фиксированной сметы. Два бота с одинаковым меню могут сильно отличаться: один передаёт сообщение менеджеру, другой проверяет свободное время, резервирует запись и восстанавливает заявку после сбоя.
Хорошее техническое задание описывает действия клиента, правила бизнеса и проверяемый результат. Ниже — структура, которую можно заполнить до обращения к разработчику. Она подойдёт компании из России или Беларуси: особенности филиалов, валют и рабочего времени нужно указать отдельно.
Начните с одного результата
Запишите, какую задачу должен завершить пользователь. Например: выбрать услугу и оставить заявку на согласование времени. Не объединяйте в первую версию запись, программу лояльности, оплату и внутренний учёт, если для проверки идеи достаточно одного сценария.
Укажите, что происходит сейчас: клиент звонит, администратор уточняет детали и переносит их в таблицу. Затем опишите ожидаемое изменение: бот собирает данные, сотрудник получает полную заявку, клиент видит подтверждение получения. Это пример проектирования, а не результат внедрения у конкретного заказчика.
Опишите диалог и исключения
Для каждого шага нужны сообщение, варианты ответа и следующее действие. В Telegram доступны команды, обычные и встроенные кнопки; отдельный интерфейс можно реализовать через Mini App. Выбор зависит от сценария, а не только от внешнего вида. Возможности перечислены в официальной документации Telegram.
- Старт: объяснить назначение бота и предложить выбор услуги.
- Данные: запросить только сведения, нужные для заявки.
- Проверка: показать пользователю введённое и дать исправить ошибку.
- Отправка: создать заявку и показать её номер.
- Завершение: объяснить, кто и когда свяжется с клиентом.
Рядом запишите исключения: пустой ответ, неподходящий файл, возврат назад, повторное нажатие, продолжение через сутки. Отдельно решите, сохраняется ли незаконченная заявка. Эти детали часто обнаруживаются только при тестировании, если их нет в ТЗ.
Разделите роли и данные
Клиент должен видеть свои заявки; менеджер — обращения своего направления; администратор — настройки, которые ему разрешено менять. Составьте список конкретных действий каждой роли: просмотр, изменение статуса, экспорт, редактирование справочника. Само наличие кнопки администратора не заменяет проверку доступа на сервере.
Для каждого поля укажите назначение, обязательность и получателя. Например: «город — нужен для выбора филиала; передаётся в карточку заявки». Не добавляйте паспортные данные или полную историю клиента «на будущее». Сроки хранения и правила доступа согласуйте с ответственным за данные в вашей компании.
Зафиксируйте интеграции
Названия CRM недостаточно. Нужны сущность, поля, направление обмена и источник истины. Где хранится актуальный список услуг? Кто меняет статус? Что делать, если CRM не отвечает? Можно ли принять заявку во внутреннюю очередь и передать позже?
Важное правило для ТЗ: повторная доставка одного события не должна создавать вторую заявку. Опишите, как сотрудник узнает о неудачной передаче и где найдёт обращения, требующие ручной обработки. Состав работ по обмену данными разобран в статье об интеграции Telegram-бота с CRM.
Согласуйте приёмку до начала работ
Критерий «всё работает» нельзя проверить однозначно. Вместо него запишите конкретные проверки:
- После подтверждения создаётся одна заявка с согласованными полями.
- Двойное нажатие не создаёт дубль.
- При недоступности CRM данные не теряются, пользователь получает понятный статус.
- Клиент не может открыть чужую заявку по подставленному номеру.
- Менеджер получает контекст обращения и может продолжить работу.
- Заказчику переданы исходники, доступы и инструкция запуска.
Для производительности укажите ожидаемую нагрузку и согласуйте способ её проверки. Для уведомлений определите часовой пояс каждого филиала и поведение вне рабочего времени. Условия поддержки после запуска зафиксируйте отдельно от приёмки.
Короткий бриф, который можно отправить
Цель: собирать заявки на услугу. Пользователи: клиенты и менеджеры. Основной путь: выбор услуги → город → контакт → проверка → отправка. Результат: заявка в CRM и номер в чате. Исключения: повторная отправка и недоступность CRM. Администрирование: изменение списка услуг. Первая версия: без оплаты. Приёмка: успешный путь, ошибки и проверка прав доступа.
Дополните пример своими правилами и приложите обезличенный образец карточки заявки. Пароли и токены в документ включать не нужно. Если часть решений пока неизвестна, пометьте её вопросом для обсуждения: это полезнее случайно зафиксированного требования.
Такой бриф позволяет предметно обсудить разработку Telegram-бота. Ориентиры бюджета и факторы, которые меняют оценку, есть в материале о стоимости Telegram-бота.