OTP Delivery Playbook: How to Triage Delays, Retries, and Escalations

# OTP Delivery Playbook\n\nTreat OTP delivery as an order workflow, not a single request-response event. When a code is late or a request stays pending, the fastest teams do not keep retrying blindly. They first confirm inputs, then check live state, then decide whether cancellation or retry is justified.\n\n## 1. Confirm inputs first\n\nBefore assuming a delivery failure, verify that the service code matches the target platform, the country still has live inventory, the account has sufficient balance, and the request was created with a unique idempotency key. A surprising number of incidents are caused by duplicate requests or stale service-country combinations.\n\n## 2. Check the live state\n\nSeparate normal waiting from true failure. Confirm whether the number was allocated, whether the supplier still reports the activation as active, and whether the order has already exceeded the expected waiting window. If the request is still inside the normal window, keep polling. If the window is clearly exceeded, stop waiting and move to a real decision.\n\n## 3. Retry only when something changes\n\nIf you retry, change something meaningful: the country, the supplier pool, the number type, or the business timing. Repeating the exact same request often reproduces the same failure and only increases cost.\n\n## 4. Escalate with evidence\n\nA good support escalation includes the account email, request ID, target service, country, approximate timeline, and any downstream error screenshot or message. This lets the review team separate supplier issues from client-side workflow issues quickly.\n\n## 5. Turn it into a process\n\nStore request IDs, log retry decisions, track cancellation windows, and assign ownership for refunds or supplier fallback. That is what turns delivery incidents from ad hoc firefighting into repeatable operations.