OTP Delivery Playbook: как разбирать задержки, retries и escalation

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