Чат бот для уведомления отправляет человеку сообщение после подтверждённого изменения заказа, заявки, записи или готовности документа. Рабочая схема связывает событие, получателя, шаблон, доставку и обработку ошибки. Сообщения подходят там, где адресат ждёт конкретное изменение и может управлять предпочтениями канала.
Подтверждённое событие
Отправка начинается только после записи нового статуса в учётной системе; у каждого события есть получатель, шаблон и запись о результате доставки.
Для первого сценария выберите одно событие, которое человеку действительно важно: заказ передан в выдачу, окно записи подтверждено, документ готов. Переход статуса должен быть сохранён в 1С, Битрикс24 или другой системе до отправки сообщения. Если оператор поменял значение и тут же вернул прежнее, правила отправки должны разобраться, нужен ли адресату сигнал. Иначе бот создаёт шум и заставляет людей игнорировать действительно важные обновления.
Эта задача отличается от массовой рассылки в мессенджерах. Рассылка адресуется сегменту подписчиков по кампании, а здесь отдельное событие запускает уведомление конкретному человеку. В боте для проверки статуса заказа пользователь сам спрашивает состояние; событийный бот сообщает о смене состояния по выбранному правилу. Для обоих случаев требуется верная связь заказа и адресата. Владелец процесса заранее описывает, какие изменения считаются окончательными, кто отменяет ошибочную отправку и какое уведомление получает человек при исправлении статуса. Это упрощает разбор жалоб.
Возьмите событие с однозначным признаком завершения, например сохранённый статус «готово». Зафиксируйте, кто вправе получать сообщение и где хранится согласованный канал.
Маршрут сообщения
Сначала система создаёт событие с идентификатором заказа или заявки. Затем обработчик ищет адресата и его настройки. Шаблон заполняется только разрешёнными данными, отправляется через выбранный канал, а результат фиксируется в журнале. У каждого этапа своё состояние: «ожидает», «отправлено», «ошибка», «отказ». Такой маршрут даёт ответ на вопрос поддержки, что именно случилось, без угадывания по переписке с клиентом.
- Подтвердите изменение статуса в исходной системе и присвойте событию уникальный идентификатор.
- Проверьте связь адресата с заявкой, выбранный канал и допустимость сообщения для этого типа события.
- Соберите короткий шаблон с безопасной ссылкой на детали, отправьте сообщение и запишите технический результат.
- При ошибке примените ограниченный повтор, а затем передайте случай сотруднику или в очередь разбора.
Связка через n8n или штатный механизм CRM годится для первого пилота, если там видны условия и журнал ошибок. Сложный поток лучше вынести в отдельный сервис обработки событий. Конкретная площадка доставки и её функции зависят от действующих правил платформы: проверьте их при проектировании. Общий чат команды для персонального статуса клиента исключите. Там легко раскрыть чужой номер заказа, телефон или подробности обращения.
Для каждого канала полезно определить резервное действие. Оно может означать задачу оператору, без автоматической отправки того же текста во все доступные каналы. Дубли раздражают человека и затрудняют разбор жалобы.
Текст и предпочтения
Уведомление отвечает на три вопроса: что изменилось, к чему относится изменение и что сделать дальше. Текст «Ваша заявка обновлена» оставляет читателя в неопределённости. Лучше назвать безопасный тип изменения и дать путь в защищённый кабинет или к оператору. Если данные чувствительны, в самом сообщении оставляют минимум подробностей. Ссылка должна вести на страницу с проверкой доступа; одного знания адреса из сообщения для просмотра документа недостаточно.
| Событие | Сообщение | Проверка |
|---|---|---|
| Окно записи подтверждено | Время и ссылка на детали | Часовой пояс и адресат |
| Документ готов | Ссылка на защищённый кабинет | Права на просмотр |
| Заказ передан в выдачу | Номер заказа и действие | Совпадение статуса в 1С |
Предпочтения пользователя храните рядом с разрешёнными каналами и типами сообщений. Человек может захотеть получать готовность документа, но отказаться от промежуточных этапов. Для уведомлений с разным правовым основанием порядок отказа и согласия различается; ответственный сотрудник проверяет основание до запуска. Интерфейс должен позволять изменить настройку и понять, что именно отключается. Настройка предпочтений — часть процесса, и влияет на каждую отправку.
Проверьте шаблоны на крайних случаях: длинное имя, пустой номер, перенос записи и повторная готовность после доработки документа. Подставлять в текст поле без проверки опасно: сообщение может уйти с чужими данными или бессмысленным пустым местом. Для разработки чат-бота под процесс состав шаблона и правила доступа согласуют вместе с владельцем данных.
Повторы и отказ
Ошибка доставки бывает временной, например короткий сбой соединения, и постоянной, когда канал для адресата закрыт. Для временной ошибки допустим ограниченный повтор с интервалом; постоянная отправляется в разбор и меняет доступность канала. Отдельно нужна защита от двух одинаковых событий. Идентификатор события позволяет проверить, уходило ли такое уведомление, даже если обработчик перезапустился после сбоя. Это снижает риск повторных сообщений при восстановлении потока.
- Отписка сохраняется как отдельное предпочтение и проверяется до каждой будущей отправки соответствующего типа.
- Ручная правка статуса сопровождается журналом: кто изменил запись, какое событие создано, какой шаблон отправлен.
- Ошибки с персональными данными передаются ответственному по внутреннему порядку; детали запрещено копировать в общий чат.
Тестируйте сценарий также на ошибках доставки. Измените статус дважды, удалите канал связи, отмените запись после подтверждения, поменяйте адресата и проверьте уже созданные события. После каждой операции журнал должен объяснять, почему сообщение отправлено, подавлено либо ожидает решения. Это хорошая основа для разговора между владельцем процесса, техподдержкой и разработчиком: каждый видит конкретную причину.
Стоимость такой системы обсуждают после карты событий, каналов, источников данных и требований к журналу. Основной риск сметы обычно скрыт в неясных статусах и разрозненных контактах. Вопрос о составе процесса важнее выбора красивого интерфейса бота.
Какие статусы вашей заявки требуют сообщения клиенту?
Пилот на статусе
Для пилота соберите реальные обезличенные переходы выбранного статуса: обычный путь, откат, повторное подтверждение и отмену. Назначьте владельца правила, который решает, когда сообщение действительно полезно. Затем согласуйте текст с поддержкой: именно она получит вопросы, если формулировка вводит людей в заблуждение. Измеряйте долю событий с корректным адресатом, доставку, количество дублей и обращения после сообщения. Эти показатели показывают качество конкретного сценария лучше общего числа отправок.
Сначала отправляйте тестовые уведомления на служебные адреса, затем подключите ограниченную группу пользователей с проверенным основанием для сообщений. Сверяйте журнал с исходной системой ежедневно на старте. Если запись в CRM меняется задним числом, решите, какое состояние считается источником истины для уже отправленного текста. Исправление ошибки через новое уведомление требует отдельного шаблона и понятного объяснения человеку. Простое стирание записи из журнала лишит команду истории события.
После пилота расширяйте матрицу по одному событию. У каждого нового статуса могут быть собственные адресаты, канал, допустимое время и смысл отказа. Результат хорош, когда клиент получает ожидаемое действие, а сотрудник способен восстановить путь сообщения по журналу. Тогда бот становится частью сервиса с понятными правилами оповещения. Перед расширением повторите тест для каждого нового канала: порядок доставки и доступные подтверждения у площадок отличаются. Журнал должен сохранять исходное событие и итог действия.