Как не терять заявки из мессенджеров: 12 точек контроля

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

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

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

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

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

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

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

За несколько минут до нарушения SLA система напоминает ответственному, после нарушения — уведомляет руководителя или возвращает чат в общую очередь. Так проблема становится видна до того, как клиент уйдёт.

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

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

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

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

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

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