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

Начните с одного полезного результата

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

Запишите результат обычным предложением: «Клиент описал проблему, получил номер обращения, а сотрудник увидел данные в рабочей очереди». Такая формулировка задаёт начало и конец процесса. Уже по ней можно обсуждать обязательные поля, время ответа и способ связи. Слова «удобный», «умный» и «продающий» оставьте как пожелания, но дополните наблюдаемым действием.

Разберите обращения, а не только пожелания

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

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

Нарисуйте разговор до разработки

Пройдите сценарий на бумаге: первое сообщение, варианты ответа, уточнение, итог. Формулируйте кнопки действиями клиента: «Описать поломку», «Узнать статус», «Связаться с человеком». В документации Telegram описаны кнопки под сообщением и другие элементы диалога; выбор конкретного механизма оставьте разработчику. Владельцу важнее проверить, понимает ли посетитель следующий шаг без отдельной инструкции.

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

Опишите исключения отдельными карточками

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

Для передачи менеджеру укажите рабочие часы, место получения обращения и текст ожидания. Обещание «Ответим сейчас» должно соответствовать реальной работе команды. Если никто не дежурит ночью, бот сообщает время следующего ответа. Отдельно определите, прекращает ли автоматический сценарий сообщения после подключения сотрудника. Иначе клиент одновременно получит разные вопросы от программы и человека.

Укажите, где живут данные

У заявки должен быть понятный рабочий дом: CRM, система учёта или специально сделанная очередь. Сообщение в Telegram может уведомлять о новой записи, но само по себе не объясняет, кто уже взял её в работу. В задании полезно указать поля заявки, ответственного, статусы и действия, которые меняют эти статусы. Начните с минимального набора, необходимого сотрудникам.

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

Согласуйте границу первой версии

Разделите документ на обязательное, следующее и исключённое. Для мастерской обязательны сбор обращения, подтверждение и передача сотруднику. Онлайн-оплата может ждать, если сумму всё равно определяют после диагностики. Искусственный интеллект тоже не нужен для выбора из нескольких фиксированных услуг. Это не отказ от развития, а возможность проверить основной процесс без лишних зависимостей.

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

Принимайте на конкретных диалогах

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

После демонстрации сохраните согласованную карту сценариев и список оставшихся ограничений. Именно они помогут оценить следующую доработку. На разбор в OBSION достаточно принести цель бота и несколько обезличенных разговоров: сначала определим основной путь, затем оценим его реализацию. Чем точнее описан результат, тем меньше причин спорить о составе проекта после старта.

Что проверить в своей задаче

1. Назван один основной результат для клиента и сотрудника.
2. Приложены обезличенные примеры частых и проблемных обращений.
3. Описаны возврат, отмена, повтор и переход к человеку.
4. Указаны место хранения заявки, поля и ответственный.
5. Зафиксированы границы версии, доступы и способ приёмки.