Клиент приходит за заказом и говорит, что сообщение так и не получил. Самый быстрый ответ кажется очевидным: отправить SMS еще раз. Но так легко создать вторую ошибку, параллельный диалог или неверный отчет.
Лучше разобрать одну попытку от бизнес события до телефона клиента. В Dynamics 365 состояния отправки, ошибки и отсутствия ответа относятся к разным этапам. Для них нужны разные решения. Начните с одного клиента, одного сообщения, одного периода и одного ответственного.
Начните с одного обещания клиенту
За SMS почти всегда стоит реальное обещание: напоминание о встрече, готовность заказа, запрос оплаты или срочное изменение услуги. Зафиксируйте, что именно должен был получить клиент и к какому времени. Сохраните идентификаторы сообщения и разговора, номера отправителя и получателя, время, версию шаблона или потока и событие, запустившее отправку.
Сделайте это до изменения автоматизации и повторной попытки. Если доказательства меняются в ходе расследования, вы уже не отличите ошибку триггера от сбоя платформы, провайдера, оператора связи, адресата или последующего действия.
Не расширяйте выводы слишком рано. Одна жалоба не доказывает отказ канала, а серия похожих сбоев у одного отправителя за короткий период уже может быть сигналом. Вопрос не в том, сломан ли весь деловой SMS канал, а в том, где остановилось конкретное обещание. Тогда служба поддержки получает понятный статус, а не расплывчатую техническую формулировку.
Читайте результат буквально
Текущая документация Microsoft по проактивным обращениям разделяет результаты, которые легко спутать.
- 1Найдите попыткуСохраните клиента, сообщение, разговор, отправителя и время.
- 2Прочитайте результатРазделите отправку, ошибку, тайм аут и активный разговор.
- 3Проследите границуИдите от процесса к Dynamics, провайдеру и оператору.
- 4Защитите обещаниеВыберите одно безопасное восстановление или другой канал.
- 5Подтвердите итогЗапишите результат для клиента и масштаб проверки.
MessageSent означает передачу сообщения SMS провайдеру или оператору связи, но не подтверждает доставку на устройство. MessageFailed означает, что провайдер или оператор не смог доставить сообщение. ResponseTimeout говорит только об отсутствии ответа в заданное первое окно. Это не доказательство недоставки. ConversationExists означает, что отправка не состоялась из-за уже активного разговора между тем же отправителем и получателем. EngagementAbandoned может появиться, если до ответа клиента отправили новое обращение.
Повторять ResponseTimeout как технический сбой опасно: клиент мог прочитать сообщение и решить не отвечать. Обход ConversationExists может уничтожить защиту от параллельных диалогов. Считайте результат началом расследования, а не декоративным полем отчета.
Проследите доказательство до границы
Обновление Dynamics 365 Contact Center 26092 улучшает трассировку недоставленных SMS и сопоставление зависших сообщений с данными оператора связи. Это помогает найти границу сбоя. Если бизнес событие не создало попытку, проверяйте процесс. Если Dynamics передал сообщение дальше, но финального результата нет, продолжайте по следу провайдера и оператора. При отказе сначала сохраните причину, потом меняйте настройки.
У каждой границы должен быть свой владелец.
| Граница доказательства | Основной владелец | Что сохранить | Какое решение принять |
|---|---|---|---|
| Бизнес событие | Владелец процесса | Событие, правило допуска, версия потока | Должно ли было появиться сообщение |
| Запись Dynamics | Администратор платформы | Идентификаторы, результат, время, состояние разговора | Началась и завершилась ли обработка |
| Провайдер и оператор | Владелец канала | Ссылка провайдера, трасса оператора, причина ошибки | Возможен ли повтор или нужна настройка |
| Обещание клиенту | Владелец сервиса | Срок, срочность, согласие, запасной канал | Как помочь клиенту сейчас |
| Карточка инцидента | Руководитель операций | Масштаб, затронутая группа, действие, проверка | Сбой единичный или системный |
Такая карта не дает расследованию превратиться в обмен скриншотами без владельца клиента. Техническая проверка и восстановление сервиса идут вместе.
Восстановите услугу без второго сбоя
Выбирайте действие по доказательствам. Исправьте неверный номер до повтора. Восстановите просроченные учетные данные или конфигурацию до выпуска накопившихся сообщений. Если трасса неполна, оставьте инцидент открытым и эскалируйте его с уже собранными идентификаторами. Для срочного обещания используйте разрешенный другой канал или звонок человека, а не серию отправок в неизвестное состояние.
Выполните один контролируемый повтор после понимания причины или для безопасной проверки гипотезы. Свяжите новую попытку с исходным инцидентом. Остановитесь при активном разговоре, отказе клиента от сообщений или подтверждении результата другим способом.
Контроль автоматизации может применить условие остановки, а общий командный инбокс сохраняет объяснение и владельца. Но ни один из них не заменяет данные провайдера и оператора.
Превратите ошибку в полезный контроль
Закрывайте инцидент только когда понятно, что произошло, что увидел клиент, что изменилось и как проверен итог. Записи «отправили снова» недостаточно. Нужны исходное состояние, граница трассировки, восстановление, окончательный результат и решение о проверке других сообщений.
Ищите повторения по отправителю, провайдеру, региону, шаблону, версии потока и времени, но не меняйте всю платформу из-за единичной жалобы. Сохраните предпочтение клиента и результат в карточке клиента. Для повторяющейся ошибки задайте наблюдаемый порог и план с назначенным владельцем.
DripTell может связать SMS разговор, владельца процесса и контекст клиента. Практический тест прост: следующий сотрудник должен видеть, что отправлялось, почему не дошло и кто восстанавливает обещание. Для оценки такого процесса можно запросить предметную демонстрацию.
Часто задаваемые вопросы
Означает ли MessageSent доставку клиенту
Нет. Это передача провайдеру или оператору. Нужен последующий результат или трасса, подтверждающая состояние у устройства.
Является ли отсутствие ответа ошибкой доставки
Не обязательно. Тайм аут означает только отсутствие ответа в заданный период. Клиент мог получить сообщение и не отвечать.
Когда безопасно повторить SMS
После сохранения исходных данных и исправления известной причины либо как один контролируемый тест с владельцем и условием остановки.
Что хранить в карточке инцидента
Сохраните идентификаторы, номера, время, результат, данные провайдера или оператора, влияние на клиента, восстановление и окончательную проверку.
Помочь применить это руководство?Спросить команду DripTell
От чтения к действию
Нужна помощь с применением этого подхода в вашей компании?
Оставьте контакты. Мы учтём материал, который вы читаете, и начнём с полезного ответа для вашей команды.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники
