Приостановите автоматическую отправку и проверьте очередь уведомлений до перезапуска CRM. Сверьте каждое сообщение с текущей записью, заказом или оплатой, а задания с неизвестным результатом отправки отложите до проверки у провайдера. Затем протестируйте сценарии и возвращайте отправку небольшими партиями. Такой порядок поможет бизнесу убрать просроченные напоминания, избежать повторных требований об оплате и сохранить актуальные сообщения. Ниже разберём, что поручить администратору, что проверить специалисту и по каким признакам разрешать запуск.
Что остановить сразу после сбоя CRM?
Попросите специалиста поставить на паузу процессы, которые передают сообщения из CRM в сервис отправки. Проверьте также резервные обработчики и задания по расписанию: основной процесс уже остановился, а другой всё ещё может разбирать ту же очередь. Форму заказа или онлайн-запись оставьте доступной, если она работает корректно и сохраняет обращения.
Очередь уведомлений — это список заданий, которые система должна выполнить. После восстановления связи в ней могут соседствовать полезное сообщение о готовности заказа и напоминание о встрече, которая уже прошла. Поэтому успешное подключение к сервису отправки ещё не означает, что очередь можно запускать.
- Приостановите все автоматические процессы отправки.
- Сохраните состояние очереди и журналы до изменения заданий.
- Зафиксируйте период сбоя, чтобы выделить сообщения для проверки.
- Назначьте сотрудника, который разрешит возобновить отправку.
Администратору задайте отдельное правило: срочное ручное уведомление нужно отмечать в карточке клиента или заказа. Если сотрудник уже сообщил о переносе записи, соответствующее автоматическое задание тоже требует проверки. Иначе клиент получит повтор после запуска очереди.
На этом этапе отправка остановлена, история сохранена, ответственный назначен. Для следующего этапа подготовьте список заданий с привязкой к заказам, записям и платежам. Если CRM не показывает эти связи, специалисту потребуется восстановить их по журналам.
Как отделить актуальные сообщения от просроченных?
Начните с события, о котором сообщает CRM. Текст проверяйте после этого. Напоминание может выглядеть безупречно, хотя клиент уже перенёс визит, забрал заказ или оплатил счёт. Время создания задания тоже не определяет его актуальность: за период сбоя обстоятельства могли измениться.
Для каждого сценария запишите условие, при котором сообщение ещё полезно. Затем распределите задания по результатам проверки.
- Актуально: событие ещё впереди, сведения совпадают с текущей карточкой.
- Устарело: событие прошло, заказ закрыт или причина уведомления исчезла.
- Требует уточнения: в CRM противоречат друг другу запись, платёж или история общения.
- Результат отправки неизвестен: система не сохранила подтверждение от провайдера.
Например, клиент перенёс занятие на вечер, пока CRM не работала. Утреннее напоминание нужно завершить с причиной «время изменилось». Для вечерней записи проверьте отдельное актуальное задание. Простая правка времени в старом SMS затруднит разбор: в истории станет непонятно, какое событие запустило сообщение.
Та же логика подходит сервисному центру, салону или небольшому интернет-магазину. Сообщение о готовности ремонта требует проверки статуса заказа. Напоминание об оплате требует сверки платежа. Предложение вернуться теряет смысл, если клиент уже сделал новую покупку.
Для фитнес-студии разбор очереди с учётом расписания и абонементов есть в статье на ossn.by. Общий принцип применим к другим услугам: у каждого уведомления должна быть связь с событием и понятный срок актуальности.
Не удаляйте просроченные задания без следа. Закройте их с конкретной причиной: «визит отменён», «заказ выдан», «оплата поступила». Это сохранит историю и поможет проверить, почему сообщение не ушло.
Что делать, если результат отправки неизвестен?
Заблокируйте автоматический повтор до сверки с сервисом отправки. Отсутствие ответа в CRM не доказывает, что сообщение не ушло: провайдер мог принять запрос, а CRM потеряла соединение до сохранения результата.
Различайте приём запроса и доставку клиенту. Подтверждение приёма означает, что сервис зарегистрировал сообщение. Отчёт о доставке отражает дальнейший результат. В журналах интеграции такой отчёт может называться DLR; сам по себе он не подтверждает, что человек прочитал SMS.
Передайте специалисту идентификатор сообщения, время запроса и связанную карточку. По этим данным он сопоставит журналы CRM и провайдера. Если идентификатор отсутствует, уточните у провайдера доступный способ поиска. До ответа оставьте задание в отдельной группе без повторной отправки.
Если сбой затронул одного получателя, начните проверку с номера и телефона. Если сообщения перестали доходить после обновления сайта, CRM или шаблона, сравните отправки до и после изменения. Такой порядок диагностики описан в материале о причинах недоставки SMS в Беларуси (smska.by).
Для защиты от повторов попросите специалиста связать уведомление с конкретным событием: например, с переносом определённой записи. Повторная обработка этого события должна находить прежнее задание. Отдельно уточните, поддерживает ли сервис отправки защиту от повторного запроса: внутреннее правило CRM не гарантирует такую же проверку у провайдера.
Как безопасно возобновить автоматические уведомления?
Сначала проверьте правила без отправки клиентам. Возьмите примеры отменённой записи, оплаченного заказа и сообщения с неизвестным результатом. Для каждого заранее запишите ожидаемое действие системы. Если CRM снова предлагает отправить просроченное напоминание, оставьте очередь на паузе.
- Проверьте на тестовых заданиях, что CRM исключает устаревшие сообщения.
- Отправьте актуальное контрольное сообщение на номер ответственного сотрудника.
- Сопоставьте результат в CRM со статусом у провайдера.
- Разрешите ограниченную партию актуальных сервисных уведомлений.
- Увеличьте поток после проверки ошибок, задержек и повторов.
Контрольная отправка на один контакт и инструкция для сотрудника помогают превратить экстренные уведомления в рабочую процедуру (isms.by). Используйте рабочий путь отправки: тест из личного кабинета провайдера не проверяет, правильно ли CRM выбирает получателя и передаёт текст.
Рекламные цепочки пока оставьте на паузе. Сначала разберите уведомления о ближайших событиях, но проверяйте актуальность непосредственно перед отправкой. Пока задание ждало в очереди, клиент мог снова изменить запись.
Следите за возрастом самого старого актуального задания. Уменьшение очереди само по себе не показывает, что процесс восстановился: сообщения всё ещё могут уходить после начала встречи. В таком случае специалисту нужно проверить скорость обработки и лимиты сервиса отправки.
Перед полным запуском полезно пройти проверку автоматических сценариев CRM. В задании на цифровую автоматизацию зафиксируйте наблюдаемый результат: перенос отменяет прежнее напоминание, платёж останавливает требование оплаты, неизвестный статус блокирует повтор. Так у владельца бизнеса и специалиста будет общий критерий приёмки.
Если сбой затронул и поступление новых обращений, отдельно проверьте путь от формы до CRM. Ошибка токена при передаче через API способна остановить создание сделок; для таких ситуаций полезны уведомление ответственному и журнал ошибок (crmlab.by). План сохранения новых обращений можно подготовить по принципам резервной работы с заявками при сбое облачной CRM.
Типичные ошибки при восстановлении уведомлений
- Удалить всю очередь. Сначала сохраните её состояние, иначе вместе с просроченными заданиями исчезнут актуальные.
- Повторить сообщения без подтверждения. Сверьте неизвестные результаты с провайдером до нового запроса.
- Проверить только текст. Сопоставьте сообщение с текущим состоянием записи, заказа или оплаты.
- Считать подключение концом восстановления. Проверьте также обновление статусов и получение отчётов о доставке.
- Оставить правила только в переписке. Сохраните инструкцию: кто останавливает отправку, кто проверяет очередь и кто разрешает запуск.
Ближайший шаг на две минуты: откройте одно напоминание из периода сбоя и сравните его с текущей карточкой заказа или записи. Если связь не видна, запишите задачу специалисту: «Показывать событие, которое запустило уведомление, и проверять его актуальность перед отправкой».
