"SMS Down, Can You Do Voice?" — Troubleshooting or a Lead?
When SMS OTPs stop arriving, a Telegram group post asking for voice verification can be troubleshooting or a real fallback project. Two annotated example messages and a six-point checklist help you decide between verifying, quoting later, or offering a test.
Signals to watch
- post names target markets and a test volume
- poster offers compliance entity details
- reply includes a timeline like a contract renewal date
- post describes the failure pattern across markets
- message stays one line with no business context
You are scanning a Telegram group used by messaging and telecom providers on a Tuesday morning when a one-line post appears: someone’s text-message verification is not arriving and they ask whether any provider can deliver voice verification instead. No company name, no country, no volume. Reply to every post like this and your week is gone; ignore them all and a real fallback project — the kind your competitors will quote — slips past. The hard part is that a troubleshooting complaint and a procurement-ready request can share the same channel and nearly the same wording. This article walks through two example posts that look similar and shows why they are not, then gives you six things to verify before you reply and three response options that match the evidence rather than the noise.
Two posts that look alike, and why one is a project
First, the terms. OTP stands for one-time password: the short code that proves a user is who they claim to be during login, registration, or a transaction. An SMS OTP delivers that code as a text message — SMS means Short Message Service. Voice OTP delivers it through an automated phone call that reads the code aloud, and it is the standard fallback when SMS cannot reach the user. The acronyms are the easy part. The hard part is what the post around them does — or does not — say.
Illustrative message:
“SMS isn’t arriving for our users. Does anyone here provide voice OTP? DM me.”
That is the whole message. It contains two facts: SMS delivery is failing and the poster wants voice. Everything a salesperson needs to qualify a project is missing — the business behind it, the market, the failure pattern, any willingness to test, any compliance entity, and who would make the decision. It could be someone troubleshooting a live incident for an existing customer and checking every channel at once. It could also be the earliest stage of a real project. From the words alone you cannot tell.
Illustrative message:
“We run a logistics app for users in two markets where SMS delivery is intermittent. Voice OTP would be a fallback when SMS fails. We want to test with around 50 numbers across both countries before committing. We can provide our compliance entity details on request.”
Message B is still short, but it carries the skeleton of a project: a concrete business, named markets, a failure pattern (intermittent SMS in two specific markets), a test size, and awareness that compliance matters. Neither of these is a real group chat; both are composite examples built to show the difference you will meet in practice, where most posts sit somewhere between them.
Six things to verify before you reply
The checklist below is a reading order, not a script. Run through it once, then decide whether the thread deserves a reply with questions, a delayed quote, or a test offer.
-
Business object. Who is behind the request and what does the app do? SMS failure matters differently for a login flow, a payment confirmation, or a high-value transaction. Message A does not even say whether the users belong to the poster’s own app or a client’s. If the poster cannot answer “which app, for whom, why does verification matter,” there is no project to scope yet.
-
Delivery scope. Is voice a fallback for the numbers SMS failed, or a replacement for the whole user base? The difference changes volume, routing, and pricing. Message B says “fallback when SMS fails,” which is a supplementary channel, not a migration. If their team plans to integrate through an API (application programming interface), ask whether voice is a separate endpoint or a routing rule behind the same call — that detail sharpens the scope answer. If the poster wants a full switch, that is a different conversation with different risks on both sides.
-
Failure pattern. Does SMS fail in all markets or some, around the clock or in peaks, for OTPs only or for every message? Intermittent delivery in two countries, as in Message B, points to a regional carrier problem — a textbook case for a voice fallback. “Our users are not getting codes” with no detail tells you nothing about what to buy or where to route it.
-
Test conditions. What volume, for how long, and what does success look like? “Around 50 numbers across both countries” from Message B is a test a provider can actually scope. If the poster cannot name any test size, treat the message as an inquiry, not a project. Whoever reads the test results also matters: you want a counterpart who can interpret pass and fail, not a relay point forwarding screenshots.
-
Compliance entity. Who owns the numbers, who handles user data, and who answers to the regulator? Message B offers compliance entity details unprompted, which is a real procurement signal — companies running a compliance process can produce that paperwork. Message A offers nothing. In most markets, voice OTP numbers and call records sit under the same data rules as SMS, so the legal owner matters before a single test call.
-
Decision role. Can the person posting approve a budget, or are they forwarding a need upward? Message B’s “before committing” implies a commitment exists to be made, which means a decision-maker behind the thread. If you ask “who decides on the vendor and when,” a serious buyer answers directly; a curious bystander usually cannot.
None of this requires you to design their authentication system — that is the application team’s work. You are checking procurement characteristics: whether a need, a market, a test, and a decision-maker actually exist.
Verify, quote later, or test
The six checks land most posts in one of three responses:
| What the post shows | Your response | The one question you add |
|---|---|---|
| One line, no market, no volume, no compliance (Message A) | Verify: send two or three clarifying questions, no price | “Which markets, and roughly how many users?” |
| Real business, but volume, countries, or timeline missing | Delay the quote: state exactly what you need before pricing | “What test volume and timeline do you have in mind?” |
| Market, failure pattern, test size, compliance present (Message B) | Offer a test: a small, defined pilot with success criteria agreed in advance | “Who reviews the results and makes the call?” |
The point of the middle row is to protect your pricing. Quoting without volume and routing data means quoting blind; the numbers you would be guessing are precisely the ones that determine cost. Delaying is not a dismissal — it is a condition: give me these four facts and the quote follows.
The test row is where a qualified conversation turns into a project. A pilot on a defined number of lines, with a clear success standard, costs both sides little and produces the only evidence that matters: whether voice actually improves delivery for that user base. This is also where your engineering or operations contact gets introduced — the poster may be a product manager or a founder, not a technical buyer, so name the person who will own the pilot from your side.
What the reply tells you
The thread does not end at your first response; the follow-up is the second filter. Watch for timelines. A date in the reply is a strong signal that a procurement window is real.
Illustrative example: “Our current SMS contract renews in 60 days — we need a fallback decision before then.”
That is a buying process with a deadline you can plan around. Compare it with the other common reply.
Illustrative example: “Interesting, let us check internally and come back to you.”
No timeline, no owner, no next action — this is interest, not a project. Park it in your follow-up queue and do not spend sales engineering time on it until something concrete arrives.
Notice what is still missing in both cases: the reply either adds the missing facts (volume, countries, test window, decision-maker) or it does not. If the poster fills in the gaps, the thread moves from inquiry to project and your next message should confirm scope and test conditions in writing. If the reply adds nothing, treat it as the same message you started with, and move on.
The post is not the project
What distinguishes a real request is not tone, not the time of day it was posted, and not whether anyone else replied. It is information: a business object, a delivery scope, a failure pattern, test conditions, a compliance entity, and a decision role. When the next “can anyone do voice” post lands in your Telegram group, run it through those six checks before you reply. The evidence tells you which of the three moves fits — verify, quote later, or test — and that saves you from both wasted follow-ups and missed quotes.