Начните с одного входящего запроса
Для учебного примера возьмём мастерскую, где клиент сам спрашивает о статусе заявки. Бот должен понять намерение, запросить допустимый идентификатор и передать ответ из подтверждённой системы учёта. Он не должен угадывать статус по общим знаниям или выдавать сведения другого клиента. Сначала нарисуйте короткую цепочку состояний: новое обращение, уточнение, проверка, ответ, передача сотруднику. Для каждого состояния определите допустимые переходы. Если человек задаёт другой вопрос, нужен понятный возврат или передача, а не бесконечное повторение одной подсказки.
Отделяйте событие от выполненного действия
В программных интеграциях входящие сообщения и изменения статусов могут поступать через уведомления вебхуков. Получение события запускает обработку, но не означает, что ответ уже доставлен клиенту. Сохраняйте различие между подготовленным ответом, отправленным запросом и подтверждённым статусом доставки. Одно и то же событие может потребовать защиты от повторной обработки. Устойчивый идентификатор помогает проверить, выполнялось ли действие раньше. Если сетевой ответ потерян, нельзя автоматически считать, что ничего не произошло, и повторять изменение заявки без проверки.
Параллельность не должна смешивать диалоги
Несколько клиентов могут писать одновременно. Их состояние, история уточнений и идентификаторы должны храниться раздельно. Внутри одного диалога сообщения тоже могут приходить быстрее, чем завершается обработка предыдущего. Поэтому определите порядок применения событий и защиту от конфликтующих изменений. Например, новый номер заявки не должен сочетаться с ответом, подготовленным для старого номера. Параллельное выполнение полезно для независимых операций, но не заменяет контроль последовательности там, где шаг зависит от предыдущего. Быстрее не значит корректнее, если клиент получает чужой или устаревший ответ.
Предусмотрите согласие, минимум данных и передачу человеку
Входящее обращение по конкретной задаче не следует превращать в повод для неожиданных рекламных сообщений. Для исходящей коммуникации нужно учитывать согласие, актуальные правила платформы и понятный отказ от дальнейших сообщений. Запрашивайте только сведения, необходимые для текущего сценария, и не помещайте секреты подключения в журналы диалога. Если бот не уверен в запросе или система учёта недоступна, полезнее сообщить ограничение и передать задачу сотруднику, чем выдумать ответ. Пользователь должен понимать, что общается с автоматизированным помощником и как получить человеческую помощь.
Попробуйте на практике
Спроектируйте бот для проверки вымышленной заявки без подключения реальных аккаунтов и отправки сообщений.
- Создайте три тестовых диалога: правильный номер, отсутствующий номер и вопрос, не относящийся к статусу заявки. Используйте вымышленные данные.
- Нарисуйте состояния и переходы. Укажите, где проверяется право получить сведения и когда подключается сотрудник.
- Добавьте повтор одного события и два сообщения подряд с разными номерами. Опишите, как исключить дубль и устаревший ответ.
- Составьте журнал проверки без личных данных: идентификатор теста, состояние до обработки, выполненное действие и итоговый статус.
Как проверить результат. Ни повтор события, ни одновременная работа нескольких диалогов не смешивают данные. Неизвестный статус не придумывается, а внешний ответ не считается доставленным только по факту запуска отправки.
Частые вопросы
Нужна ли языковая модель каждому боту?
Нет. Для ограниченного сценария с понятными вариантами часто достаточно правил и проверок. Модель может помогать разбирать свободный текст, но её выводы всё равно требуют контроля перед изменением данных.
Можно ли оценивать бота только по числу сообщений?
Количество ответов не показывает, решена ли задача. Полезно отдельно считать корректно завершённые обращения, передачи человеку, ошибки и повторные запросы по той же проблеме.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.