OTP Delivery Playbook: как разбирать задержки, retries и escalation
Практический workflow для pending-активаций, задержек SMS, окон отмены и подготовки материалов для поддержки.
OTP Delivery Playbook
Когда активация слишком долго остаётся в pending или SMS приходит с задержкой, проблему лучше рассматривать как часть order-workflow, а не как единичную ошибку запроса. Самые эффективные команды сначала подтверждают входные данные, затем проверяют live-state и только после этого решают, нужен ли cancel, retry или escalation.
1. Сначала подтвердите входные данные
До того как считать доставку проваленной, убедитесь, что service code соответствует целевой платформе, по стране есть live inventory, баланса достаточно, а запрос был создан с уникальным idempotency key. Многие инциденты оказываются дублями заказа или устаревшей парой сервис-страна.
2. Отделяйте задержку от реального сбоя
pending не означает failed. Проверьте, был ли номер вообще выделен, остаётся ли активация активной на стороне поставщика и вышли ли вы уже за ожидаемое окно ожидания. Пока окно нормальное, продолжайте polling. Когда оно явно превышено, переходите к решению, а не к бесконечному ожиданию.
3. Retry должен что-то менять
Если вы повторяете запрос, меняйте значимое условие: страну, пул поставщиков, тип номера или тайминг. Повтор того же самого сценария часто воспроизводит ту же проблему и только увеличивает стоимость.
4. Эскалируйте с доказательствами
Для быстрого разбора поддержке обычно нужны email аккаунта, request ID, сервис, страна, примерный таймлайн и текст ошибки или скриншот с downstream-платформы. Если дать это сразу, разбор пойдёт заметно быстрее.
5. Встраивайте разбор в процесс
Сохраняйте request IDs, журналируйте решения о retry, отслеживайте окна отмены и заранее определяйте, кто отвечает за refund и supplier fallback. Тогда инциденты становятся повторяемым операционным процессом, а не хаотичным firefighting.