Уведомления о переносе: как избежать противоречивых сообщений

Создавайте сообщение после изменения

Основанием служит подтверждённое изменение расписания, а не нажатие кнопки в форме. Если перенос не принят, уведомление о новом времени отправлять рано. У события должны быть номер записи, прежние и новые условия, автор и время изменения. Это позволяет отличить перенос от отмены и повторного создания. Для ручного предложения другого времени используйте отдельный текст: клиенту ещё нужно согласиться. Не называйте его визит изменённым, если вы только ждёте ответа.

Проверяйте актуальность перед отправкой

Пока сообщение стояло в очереди, запись могла измениться ещё раз. Перед отправкой сверяйте версию визита и отменяйте устаревшие напоминания, где это предусмотрено архитектурой. В Firebase Cloud Messaging срок жизни сообщения ограничивает время, в течение которого сервис пытается его доставить; принятие запроса не означает доставку на устройство. Поэтому срок полезности сообщения нужно задавать по событию, а не обещать клиенту мгновенное получение каждого push.

Документация: Firebase: срок жизни сообщения

Пишите достаточно для решения

В сообщении полезны услуга, точная дата, новое время и филиал, если это не раскрывает лишние сведения на экране телефона. Подробности переноса можно оставить внутри приложения. Избегайте одного слова «изменения»: человеку придётся искать, какой из нескольких визитов затронут. Когда причина понятна и уместна, укажите её коротко. Обязательно дайте путь к актуальной записи и действию, например подтверждению предложения или связи с администратором.

Согласуйте адресатов и каналы

При нескольких переносах за короткое время сотруднику полезно видеть последнюю договорённость с клиентом. Это снижает риск повторного звонка по уже решённому вопросу и помогает не обсуждать время из устаревшего сообщения.

В семейном профиле запись может оформить один человек для другого. Заранее решите, кто получает перенос, а кто только сведения об оплате. Если используете push и дополнительный канал, не создавайте несколько независимых рассылок без общей истории события. Для важных изменений сотрудник должен видеть, требуется ли ручной контакт. Отсутствие ответа на уведомление не означает согласия, если сценарий предполагает подтверждение клиента. Зафиксируйте срок ожидания и дальнейшее действие администратора.

Старая ссылка должна объяснять новое

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