Как проверить «недоставку» SMS, если клиент не получил уведомление

Как проверить «недоставку» SMS, если клиент не получил уведомление

Если клиент говорит, что SMS не пришло, сотруднику нужна не догадка, а короткий протокол проверки: найти отправку, сверить номер и время, посмотреть статус, затем дать человеку понятный ответ. Такой порядок помогает отличить ошибку в контакте, задержку на маршруте и ситуацию, когда сообщение дошло, но осталось незамеченным. В статье — поля для журнала, сценарий разговора с клиентом и правила, по которым поддержка передаёт задачу техническому сотруднику.

Почему фразы «SMS не было» недостаточно для проверки?

Клиент описывает свой результат: он не увидел сообщение в телефоне. Система фиксирует другое: был ли запрос на отправку, принял ли его шлюз, какой номер получил сообщение и какой финальный статус вернулся. Между этими точками могут возникнуть разные ситуации. Например, сотрудник указал устаревший номер, уведомление ушло позже ожидаемого времени или в тексте был неверный ориентир, поэтому клиент не связал SMS со своим заказом.

Начинайте разговор с конкретного события. Вместо вопроса «Вам точно ничего не приходило?» уточните, какое уведомление человек ожидал: подтверждение записи, статус заказа, код входа или сообщение о готовности услуги. Затем попросите назвать номер телефона и примерное время обращения. Этого достаточно, чтобы найти запись без длинной переписки.

Какие данные включить во внутренний протокол проверки?

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

  • дата и время обращения клиента;
  • тип ожидаемого уведомления и связанное событие: заказ, запись, вход в кабинет;
  • номер из обращения и номер, который хранится в рабочей системе;
  • время создания SMS и время передачи в шлюз;
  • идентификатор сообщения;
  • текст шаблона или его версия, без лишних данных клиента;
  • промежуточный и финальный статус;
  • решение сотрудника: повторная отправка, исправление номера, передача техническому специалисту.

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

В каком порядке проверять отправку и статусы?

Сначала сотрудник ищет событие в основной системе: заказ создан, заявка принята, код запрошен. Если самого события нет, проверять SMS рано — проблема находится в рабочем процессе. Когда событие есть, нужно найти запрос на отправку и его идентификатор.

  1. Сверьте номер в карточке клиента с номером, на который ушёл запрос. Ошибка в одной цифре меняет результат проверки.
  2. Проверьте время отправки. Для срочного кода разница между запросом и получением критична, а для статуса заказа важнее понять, сформировалось ли уведомление после смены статуса.
  3. Посмотрите статус: запрос принят, сообщение передано дальше, есть финальный результат или зафиксирована ошибка.
  4. Если есть ошибка, сохраните её формулировку в карточке. Слова «не работает» техническому сотруднику ничего не объясняют.
  5. Если финального статуса ещё нет, укажите клиенту время следующей проверки и не запускайте несколько одинаковых отправок подряд.

Для одноразовых кодов финальный статус особенно важен: он помогает отделить проблему доставки от ошибки в номере или действиях пользователя. При недоставке человеку не стоит оставаться в ожидании без пояснения (QUICKTEL, «OTP SMS для авторизации и подтверждения»). Контроль таких статусов удобно вынести в отдельный процесс: как настроить мониторинг доставки сервисных SMS.

Как отвечать клиенту во время проверки?

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

  • Если номер в системе отличается от номера клиента, сотрудник уточняет актуальный контакт и фиксирует, где его нужно исправить.
  • Если запрос на отправку не сформировался, сотрудник передаёт задачу тому, кто отвечает за связку рабочей системы и SMS-шлюза.
  • Если статус содержит ошибку, в обращение добавляют идентификатор сообщения и текст статуса, затем передают задачу техническому сотруднику.
  • Если сообщение доставлено, но клиент его не заметил, сотрудник повторно объясняет содержание уведомления или предлагает другой доступный способ получить нужную информацию.

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

Типичные ошибки при разборе недоставки SMS

  • Проверять только факт отправки и не ждать финальный статус.
  • Искать сообщение по имени клиента, когда в истории несколько заказов или обращений.
  • Пересылать клиенту технические статусы вместо короткого объяснения следующего действия.
  • Делать повторную отправку без сверки номера и срока актуальности уведомления.
  • Передавать задачу разработчику без идентификатора сообщения, времени и текста ошибки.

3 шага, которые можно сделать на неделе:

  1. Создайте единый шаблон карточки обращения с номером, временем, идентификатором SMS и финальным статусом.
  2. Дайте сотрудникам короткий порядок проверки: событие в системе, запрос на отправку, номер, статус, решение.
  3. Проверьте на одном сервисном сценарии, видит ли поддержка историю доставки без запроса к разработчику.