Before You Forward That "OTP Not Arriving" Screenshot, Turn It Into a Ticket First

You took the screenshot, dropped it in the internal channel, and @-mentioned the sales lead for that region.

Five minutes later he replied: “What exactly is the situation?”

You opened the screenshot again and realized you could say exactly what was already on it — not one word more:

”— Can someone take a look? Indonesia user, Indosat, large-scale OTP failure after 7 PM, error 112, been three days.” (Illustrative composite scene, not a single original message.)

You read that back to yourself. The sales lead followed up: “Fixed hours or all day? What does that error code mean? One user reporting or multiple channels?”

You did not have the answers.

This is not about experience level. The message itself simply does not carry enough information to answer those three questions. OTP — one-time password, those six digits your phone receives when you register, log in, or confirm a transfer — delivery complaints all look similar in a group chat: a vague “not receiving codes.” Whether one is worth treating as a replacement window depends on whether you can break that single sentence into a structured ticket with concrete fields.

Here are the four fields.

Field One: Country + Carrier — What “Indonesia Indosat” Already Rules Out

The message gives two anchors: Indonesia and Indosat.

Those two words rule out one kind of ambiguity: this is not a roaming user catching intermittent failures on an unfamiliar network. It is a local user on their home carrier not seeing the code. The direction is clearer.

But “Indosat” here could mean the network the user is currently registered on, or the transit node the message route passes through. The first points to Indonesia’s local receiving gateway. The second involves the contractual routing between the sender and the international leg. Two different investigation paths diverge at step one.

Still needs human verification:

• Is this complaint from one client’s upstream user, or are multiple clients reporting the same thing? A single client’s feedback needs their daily send volume and delivery baseline to interpret — without baseline data, “large-scale” is a subjective adjective.
• Are other groups or channels mentioning Indosat in the same time window? If yes, the issue is more likely on the carrier-side gateway and independent of any specific sender.

Field Two: Time Window — “Evening Peak” Needs a Time Range to Compare Against

“After 7 PM” — if that time reference holds after verifying the original timestamp, it narrows the direction from “system failure” to “load-sensitive scenario.”

Indonesia’s WIB time zone (UTC+7) puts 18:00–22:00 in the congested range for international routing bandwidth. One pattern seen in this window is: normal delivery during the day, a drop starting at dusk, recovery late at night. If the data confirms that pattern, the probability leans toward rate-limiting or gateway overload rather than misconfiguration.

If the problem is uniform across the day — failure rates at 10 AM and 10 PM are nearly identical — the cause is more likely at the contract-configuration, account-whitelist, or content-template layer, independent of time.

Still needs human verification:

• Does “after 7 PM” mean Indonesia time or the reporter’s time zone? This must be checked against the original Telegram group’s send timestamp — it is not visible in a screenshot.
• Did the failure repeat at the same window each of the three nights? One sporadic night could be upstream maintenance. Three consecutive evening peaks recurring steadily is the pattern that carries signal value.

Field Three: Error Code — The Same Error Number Can Point to Different Failure Paths

“Error 112” — illustrative value, not a real SMPP protocol code.

In OTP delivery, failure codes come from the SMPP protocol (Short Message Peer-to-Peer, the protocol verification messages travel over). The same “can’t receive” symptom can map to different physical causes depending on the code:

• If the code means “destination network unreachable,” the routing link or the peer gateway has a problem.
• If it means “message rejected,” the sender’s account configuration or message content may be blocked by the destination network.
• If it means “validity period expired,” the message sat in the routing path too long and exceeded the carrier’s allowed time-to-live.

Beyond that, the same carrier can return different error codes at different hours — “unreachable” during evening peak, “delivered” during the day. The contrast in that pair carries more signal than any single error code alone.

Still needs human verification:

• What does this error code mean in the sender’s internal documentation? Different providers classify and map SMPP failure codes differently. A general interpretation is not a substitute.
• Did the error code stay consistent across the three days? If it changed every day, the problem may be switching upstream on the carrier side rather than fixed at a single point.

Field Four: Duration — “Three Days” and “Three Complete Evening Peaks” Are Not the Same Thing

“Three days” crosses the threshold of a one-off fluctuation. One day could be caused by a temporary cutover or a fiber fault. Three days with nightly repetition points more toward a structural routing issue.

But “three days” needs to be split into two questions:

1. Did it appear every night from day one, or were the first two nights normal with sudden deterioration on night three?
2. Does it mean three full evening-peak cycles, or counting from one evening to today as day three?

The first describes a stable pattern. The second may still be evolving — you need tonight’s data to judge the trend.

Still needs human verification:

• You need per-hour delivery rate curves from the sender for the three days. Only a curve can distinguish between “fixed-window rate limiting” and “a failure that is continuously worsening.”
• If the issue was already resolved by the sender on the morning of day three, the replacement window timestamp has expired.

Once the Four Fields Are Filled

Now the ticket is no longer “Indonesia, someone can’t receive codes.” It reads:

Indonesia | Indosat | UTC+7 18:00–22:00 | SMPP error (destination network unreachable) | Three consecutive evening peaks | Normal during the day

Six conditions together form a replacement signal worth verifying. But a signal is only a signal. The first thing to do after filling the ticket is not contacting the client — it is three verification steps:

1. Go back to the original Telegram group and read the full discussion thread. When you took the screenshot, you may have only seen the complaint, not the replies that followed — “route adjusted” or “confirmed carrier-side cutover.” If the review record preserved the message context and subsequent replies, reconstruct the discussion there. A screenshot captures one moment; a judgment needs the complete evolution of the thread.

2. Confirm where the problem lives. Failures concentrated on one carrier’s peak-hour window require first understanding which route the sender uses for Indosat traffic and whether that route has a known maintenance window during those hours — before contacting anyone.

3. Check the contract window. Does the client’s agreement with their current provider have terms that trigger a replacement clause, and what is the expiration date? Not every complaint window aligns with an open contract window.

Beyond the Screenshot, the Conversation That Followed May Have Changed the Answer

A screenshot captures one message. But after that message was posted in the Telegram group, things may have moved. The provider’s tech team may have replied “investigating” or “already contacted the Indonesia side.” Other clients may have chimed in below the same thread saying “we see the same,” or a group admin may have pinned a note: “Known issue, fix expected by tomorrow morning.”

None of that is in your screenshot. And it directly affects one call: is this an open replacement window, or a historical record the other side has already closed?

So after you fill this ticket, the last step is not forwarding it to sales. It is going back to the original group and reading every reply posted from that first message to now. If the issue is marked resolved, archive the ticket — do not follow up. If it is still hanging in the air and the contract window lines up, that is the point at which you decide whether to reach out.

How you open that conversation is up to you. The only thing this article can help with is this: the next time you see “can’t receive the code” in a group, you know to fill those four fields before you forward anything.

PRODUCT SCOPE

Market and risk discussion is supporting evidence

Top Prospect is primarily a Telegram lead-generation product. Market and risk discussion can add context to a candidate lead, but it does not become a verified incident, trend, or sales opportunity automatically.

Review the product workflow and boundaries →