ТЗ на WhatsApp-бота: согласие, сценарии и передача оператору

Задача бота и условия запуска

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

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

Согласие и инициирование диалога

Политика WhatsApp Business требует учитывать согласие получателя и прекращать нежелательные сообщения. В ТЗ запишите, где человек оставляет номер и разрешение на коммуникацию, какие сообщения ожидает и как может отказаться. Не считайте наличие телефона в CRM автоматическим разрешением на любую рассылку. Источник и состояние согласия должны быть проверяемыми.

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

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

Сценарии и память диалога

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

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

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

Передача оператору без потери контекста

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

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

Проверьте смену оператора, закрытие обращения и возвращение клиента. Новый сотрудник должен понимать, какие действия уже выполнены и какие ещё требуют подтверждения. Событие «назначен оператор» не равно «оператор ответил». Эти состояния стоит различать в интерфейсе и мониторинге, иначе очередь выглядит обработанной при фактическом ожидании клиента.

Интеграция с CRM и сервисами

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

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

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

Сообщения, сроки и наблюдаемость

Различайте подготовку сообщения, принятие провайдером, доставку и прочтение, если соответствующие статусы доступны. Нельзя называть обращение решённым по факту отправки ответа. Для задачи бизнеса нужен отдельный результат: запись подтверждена, документ получен или оператор завершил обращение. В аналитике эти уровни считаются отдельно.

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

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

Приёмка на пограничных сценариях

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

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

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

Что подготовить перед оценкой

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

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