Бот для сайта: требования к диалогу, сессии и передаче оператору

Определите роль бота в обслуживании

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

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

Разделите контекст страницы и личность

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

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

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

Спроектируйте виджет во всех состояниях

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

Учтите клавиатуру и сообщения о состоянии. Руководство W3C по status messages объясняет, почему изменения статуса должны быть доступны вспомогательным технологиям. Приёмка проверяет реальное объявление значимых состояний, а не просто наличие текста на экране.

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

Опишите диалог вне успешной ветки

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

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

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

Согласуйте передачу оператору

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

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

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

Проверьте действия во внешних системах

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

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

Подготовьте набор приёмочных разговоров

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

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

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

Соберите пакет первой версии

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

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