При переносе записи система должна закрыть старую цепочку SMS и создать новую с актуальными датой и временем. Иначе клиент получит два противоречащих сообщения: сначала напоминание о визите во вторник, затем подтверждение на четверг. В статье разберём сценарий переноса по шагам, покажем, какие статусы хранить, когда отменять уведомления и как проверить доставку. Такой процесс можно настроить через API, а отправку контролировать по статусам доставки.
Почему старые SMS нужно отменять после переноса записи?
Запись клиента обычно запускает несколько уведомлений: подтверждение сразу после бронирования, напоминание за день и короткое сообщение в день визита. Если администратор изменил время, уже созданные SMS продолжают жить по прежнему расписанию. Система рассылки сама не узнает, что запись перенесли, если CRM или программа учёта не передаст ей новое событие.
Представим обычный сценарий для салона в Минске, медицинского кабинета в Гомеле или мастерской в Бресте. Клиент записался на 15:00 в среду, а затем попросил перенести визит на 11:30 в пятницу. После изменения записи нужно отменить напоминания на среду, пересчитать отправки на пятницу и направить новое подтверждение.
Старое сообщение нельзя оставлять «на всякий случай». Оно содержит уже неверные сведения и может привести к пропущенному визиту, звонку администратору или повторному переносу. В медицинской практике SMS-напоминания применяют для приёмов, анализов и повторных консультаций, а для салонов указывают название услуги, дату и время записи (QUICKTEL; Messaggio).
Как должна работать SMS-цепочка при переносе визита?
Надёжная схема начинается с идентификатора записи. У каждого визита должен быть свой номер, а каждое SMS должно ссылаться на конкретную версию записи. Если визит перенесли, версия меняется. По этой отметке система понимает, что запланированное сообщение относится к старому расписанию и его нельзя отправлять.
- Клиент или администратор меняет дату либо время визита.
- CRM передаёт событие «запись изменена» в сервис SMS.
- Система находит все будущие сообщения по старой версии записи.
- Запланированные SMS получают статус отменённых.
- Сервис рассчитывает новые сроки отправки по новой дате и времени.
- Клиент получает подтверждение с актуальными данными.
Последовательность имеет значение. Если сначала создать новую цепочку, а потом искать старую, при сбое можно получить две активные серии. Безопаснее сначала заблокировать старые отправки, затем записать новую дату и только после этого поставить сообщения в расписание.
Для типового визита достаточно хранить в событии название услуги, дату, время, номер записи и текущую версию. В текст SMS можно включить название организации, дату, время и просьбу связаться с администратором, если клиент не сможет прийти. Такой состав соответствует рекомендациям для напоминаний о записи в салонах и клиниках (Messaggio; Girafffe).
Какие статусы нужны для контроля переноса?
Одного признака «SMS отправлено» мало. Сообщение может находиться в очереди, уйти оператору связи, доставиться или завершиться ошибкой. Для каждой отправки полезно хранить отдельный статус, время изменения статуса и идентификатор записи, к которой она относится.
| Статус | Что он означает | Действие при переносе |
|---|---|---|
| Запланировано | SMS ещё не отправили | Отменить и создать новое по новой дате |
| Передано | Запрос уже ушёл в SMS-сервис | Проверить, можно ли остановить отправку; новую цепочку создать отдельно |
| Доставлено | Сообщение дошло до телефона | Не пытаться отменить; отправить уточнение с новой датой |
| Ошибка | Сервис не отправил сообщение или не получил подтверждение | Зафиксировать ошибку и не считать старое SMS действующим |
| Отменено | Отправка закрыта до передачи получателю | Не повторять старое напоминание |
Статус доставки должен возвращаться в карточку записи. Тогда администратор видит, дошло ли подтверждение, а разработчик может проверить, почему клиент получил или не получил сообщение. Такой подход отдельно отмечен в материалах о SMS для записи на услуги (QUICKTEL).
Если старое SMS уже доставлено, отменить его технически нельзя: сообщение уже находится у клиента. В этом случае отправьте короткое уточнение: «Запись перенесена на пятницу, 11:30. Предыдущее время больше не действует». В CRM при этом нужно сохранить новую дату как единственную актуальную.
Как передать перенос записи через API?
На уровне интеграции полезно разделить три операции: изменить визит, отменить будущие уведомления и создать новые. Каждая операция должна возвращать результат. Если сервис не ответил, система не должна молча считать перенос завершённым.
Пример логики события выглядит так: запись имеет номер 4821 и версию 3. После переноса версия становится 4. Все SMS с номером 4821 и версией 3, которые ещё не доставлены, получают признак отмены. Затем создаются сообщения версии 4: подтверждение, напоминание за сутки и сообщение перед визитом, если такой сценарий нужен бизнесу.
Повторная передача одного и того же события не должна создавать дубликаты. Для этого используют уникальный ключ, например сочетание номера записи, версии и типа уведомления. Если запрос «перенос на пятницу» пришёл дважды, система проверяет ключ и оставляет одну цепочку.
Для малого бизнеса это можно внедрить поэтапно. Сначала подключают подтверждение записи, затем добавляют отмену старых напоминаний, после этого включают мониторинг доставки и обработку ошибок. Сценарий автоматических SMS по действиям клиента разобран в материале «Как настроить автоматические SMS по действиям клиента».
Как проверить, что клиент не получит два разных напоминания?
Проверку лучше проводить на тестовой записи, а не на реальном визите. Создайте запись на ближайшую дату, убедитесь, что система поставила SMS в очередь, затем перенесите её несколько раз. После каждого изменения проверьте список уведомлений и карточку визита.
- У старой даты не осталось сообщений со статусом «запланировано».
- Новая цепочка содержит правильные дату, время и название услуги.
- В карточке записи указан результат каждой отправки.
- Повторное событие переноса не создало второе подтверждение.
- Ошибка API попала в журнал и доступна сотруднику, который отвечает за интеграцию.
Отдельно протестируйте быстрый перенос. Например, клиент изменил время за несколько минут до запланированного напоминания. Система должна определить, успело ли старое SMS уйти в отправку. Если отмена уже невозможна, отправьте уточняющее сообщение и пометьте старое уведомление как неактуальное в карточке записи.
Какие ошибки чаще всего ломают сценарий переноса?
- Отменяют только одно напоминание. У записи могут оставаться другие будущие SMS, поэтому отменять нужно всю цепочку старой версии.
- Меняют текст, но не меняют время отправки. Новое сообщение с правильной датой, отправленное по старому расписанию, создаёт другую ошибку.
- Не различают запись и клиента. Один человек может иметь несколько визитов, поэтому уведомление связывают с конкретной записью.
- Считают передачу SMS доставкой. Запрос к сервису ещё не означает, что сообщение дошло. Нужен отдельный статус доставки.
- Не защищают обработчик от повторов. При повторной отправке события система создаёт дубликаты, если у уведомления нет уникального ключа.
- Не предусмотрели ручной перенос. Если администратор меняет визит в интерфейсе, это действие тоже должно запускать тот же процесс отмены и пересчёта.
3 шага, которые можно сделать на этой неделе:
- Опишите все SMS, которые отправляются после записи, и привяжите их к номеру визита.
- Добавьте событие «запись изменена», которое сначала отменяет будущие уведомления старой версии.
- Проверьте тестовый перенос и включите мониторинг статусов доставки, чтобы видеть результат в карточке записи.
