ТЗ на Telegram-бота: сценарии, передача человеку и приёмка

Сначала задача, потом дерево кнопок

Бизнес-бот может записывать на услугу, принимать заявку, выдавать статус заказа или передавать вопрос поддержке. Эти задачи различаются по данным и ответственности. Формулировка «нужен бот с меню и AI» не позволяет оценить работу: неизвестно, что должно произойти после выбора, кто получит обращение и как пользователь узнает, что запрос принят.

Эта статья — о подготовке ТЗ, а не о календаре внедрения Telegram-бота. Результат — конкретные сценарии, состояния, ограничения Bot API, договорённости об интеграции и проверяемые тесты. Начните с одного законченного пути; если компания не знает, кто отвечает на заявки, бот только ускорит попадание клиента в пустую очередь.

Какие решения нужны до разработки

Отделите пользу для человека от выгоды для операционной команды и назначьте владельца результата.

• Выберите основную задачу: запись, статус, заказ, FAQ или первичный приём обращения. Для неё запишите исходное действие клиента, данные, которые уже известны, момент успешного завершения и кто отвечает за исключения. Второстепенные функции отложите, пока не проверен полный путь основной.
• Соберите реальные формулировки вопросов и типовые ошибки. Если клиент пишет свободным текстом, решите, какие намерения бот распознаёт уверенно, а какие передаёт человеку без угадывания. Для кнопочного пути предусмотрите возможность вернуться и изменить ответ; тупиковое меню нельзя считать готовым сценариевым дизайном.
• Опишите данные и согласие: имя, контакт, услуга, время, номер заказа, история диалога. Собирайте только необходимое для следующего шага. Согласуйте хранение, удаление, круг сотрудников с доступом и способ передачи обращения в CRM. В публичные уведомления не включайте лишние персональные детали.
• Укажите рабочее время, обещанный интервал ответа, резервную команду и правила эскалации. Если бот сообщает «менеджер ответит сегодня», компания должна иметь человека, который видит очередь и подтверждает приём. Иначе напишите честный режим ожидания и дайте альтернативный контакт.
• Проверьте техническую среду: кто владеет ботом и токеном, какая CRM или система записи уже существует, доступен ли тестовый контур, какие события и идентификаторы приходят извне. Токен бота не должен находиться в открытом репозитории или пересылаться в общий чат.

Разделы ТЗ, которые можно проверять

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

• Старт и навигация. Опишите /start, контекст перехода по ссылке, главное действие и понятное объяснение назначения бота. Укажите, что увидит человек после повторного /start посреди анкеты: начать заново, продолжить или выбрать другой сценарий. Не теряйте уже сохранённую заявку из-за повторной команды.
• Основной сценарий. Для записи перечислите выбор услуги, свободного времени, подтверждение, перенос и отмену. Для статуса — проверку права на заказ и отображение времени обновления. Для обращения — тему, описание, контакт и подтверждение. Слова «бот обрабатывает запрос» замените точными входом и выходом.
• Свободный текст и ошибки. Укажите допустимую длину, обработку вложений, неизвестной команды и сообщения не по теме. Если автоматическое распознавание неуверенно, бот сохраняет оригинальную фразу и предлагает человека. Не подменяйте слова клиента придуманной категорией без возможности исправления.
• Передача оператору. Опишите триггеры: прямой запрос, сложный вопрос, повторная ошибка или высокий риск. Передайте сотруднику исходный текст, уже полученные ответы, идентификатор диалога и время. Клиент получает подтверждение и ожидаемый следующий шаг; оператор должен явно принять обращение, а не просто получить уведомление.
• Интеграция. Для CRM или системы записи укажите сущности, поля, направление, идентификатор пользователя, идемпотентный ключ и реакцию на тайм-аут. Повтор доставки события или нажатие кнопки не должен создавать второй заказ. Временная недоступность внешней системы требует очереди, наблюдения и ответственного, а не сообщения «всё готово».
• Уведомления и согласия. Отделите сервисное подтверждение от рекламной рассылки. Опишите частоту напоминаний, условия прекращения и реакцию на запрет общения. Проверьте, что бот не раскрывает чувствительные детали человеку, который получил чужой номер заказа или пересланное сообщение.
• Эксплуатация. Укажите тестовое и рабочее окружение, владельца токена, ротацию секрета, мониторинг ошибок, резервное копирование необходимых данных и процедуру остановки сценария при инциденте. Передача проекта включает инструкции оператору и список типовых исключений, а не только код.

Пример сценария и критериев приёмки

Текст должен быть достаточно конкретным, чтобы заказчик мог лично пройти контрольный диалог.

• Сценарий записи: клиент выбирает услугу и предложенный слот. Бот запрашивает контакт только после объяснения цели, показывает все условия перед подтверждением и создаёт одну запись во внешней системе. Клиент получает номер и время; сотрудник видит источник и необходимые данные. Если слот заняли до подтверждения, бот предлагает альтернативу, не обещая несуществующую запись.
• Проверки: пройти новый диалог, вернуться назад, повторить кнопку подтверждения, прервать и возобновить, прислать неожиданный текст, отключить внешнюю систему, попросить человека и отказаться от уведомлений. Для каждого опыта запишите ожидаемое состояние в боте и CRM. Особенно проверяйте повторы: Telegram Bot API описывает механизм обновлений, но бизнес-идемпотентность реализует ваша система.
• Для передачи человеку проверьте два конца цепочки. Клиент видит, что запрос направлен и в какой срок ждать ответ; оператор видит контекст и может принять или переназначить задачу. Если до истечения обещанного времени владелец не назначен, система поднимает сигнал. HTTP-ответ от CRM сам по себе ещё не означает, что клиенту ответят.
• В разделе безопасности укажите права на данные, сроки хранения, журнал действий и запрет на публикацию токена. Если бот используют в группе, отдельно опишите, какие сообщения ему доступны и какие ответы допустимы публично. Не переносите личный сценарий в групповой чат без пересмотра риска раскрытия данных.

Что делает ТЗ непригодным

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

• Рисовать сотни кнопок до выбора одной измеримой задачи; пользователь не понимает, зачем ему проходить меню.
• Не описывать рабочее время и эскалацию, но обещать ответ менеджера в каждом сообщении.
• Создавать новый лид при каждом повторном webhook или нажатии подтверждения, не связывая события с одним диалогом.
• Добавлять AI-ответы на тарифы, сроки или юридические условия без проверенного источника и возможности передачи человеку.

Что измерять после запуска

Показы и число сообщений не доказывают, что бот помогает бизнесу.

• Доля начатых диалогов, завершившихся конкретным подтверждённым действием: записью, заявкой или полученным статусом.
• Время до первого содержательного ответа сотрудника после эскалации и доля обращений без владельца.
• Количество дублей записей, ошибок интеграции и диалогов, застрявших в одном состоянии.
• Причины перехода к человеку и шаги, на которых люди прекращают сценарий; анализируйте качество маршрута, а не стремитесь искусственно уменьшить число эскалаций.

С чего начинать заказ бота

Подготовьте один сквозной сценарий, карту состояний, правила данных и передачу человеку. На их основе команда оценит проект и сделает прототип диалога, который можно пройти до реального результата. Список «приветствие, FAQ, AI и CRM» без такой цепочки остаётся перечнем пожеланий.

Отдельно согласуйте владельца сообщений и операционной очереди. Автоматизация не решает организационный пробел: если у обращения нет ответственного, бот лишь меняет точку, где оно потеряется. Для календаря работ и запуска используйте самостоятельный план внедрения Telegram-бота.

Контрольный диалог для приёмки

Клиент пишет о переносе записи, затем присылает сообщение вне заранее заданного меню. Бот сохраняет исходный текст, предлагает контакт с человеком и передаёт оператору номер записи и уже известные ответы. Оператор подтверждает приём; клиенту показано, что запрос не потерялся. Повтор входящего события не создаёт вторую заявку, а временная ошибка CRM отображается как ожидание с ответственным за восстановление. Это один целый сценарий с проверяемым концом.

Составьте таблицу реплик не вокруг красивых формулировок, а вокруг переходов состояния. После выбора услуги бот знает её идентификатор и может предложить доступные слоты; после выбора времени — временно держит выбор до подтверждения; после успешной записи — хранит внешний номер. При возвращении назад прежний слот должен освобождаться по согласованному правилу. Если человек вводит произвольную фразу, система либо распознаёт предусмотренный переход, либо честно предлагает оператора. Не оставляйте непонятный текст без ответа и записи в журнале.

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

Передача человеку — не ссылка «напишите менеджеру» без контекста. В ТЗ назовите, какой сотрудник получает запрос, какие ответы и вложения ему видны, как он подтверждает принятие и как клиент узнаёт о следующем шаге. Если оператор не ответил в согласованное время, кто видит просрочку? Нужен резервный маршрут. При этом исходный текст клиента следует сохранить: автоматическое резюме может помочь, но не должно становиться единственной версией обращения, особенно когда классификация неуверенна.

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