Someone in the group wants numbers. Don't quote yet: three clues tell you which buyer you're facing
The same “I need numbers” means a deliverable channel for an APP developer, a programmatically addressable number pool for a QA team, and long-lived numbers for a marketing team. The evidence, the pricing unit, and the boundary differ for each, so answering the wrong one wastes the conversation.
At four minutes past ten in the morning, a BD (business development) person at a virtual number and OTP (one-time password) reception provider sees three messages appear in three different Telegram groups.
“Our app launches in Indonesia next week and the verification code piece is still open.”
“Is there an API for pulling numbers in bulk? We want it in CI.”
“Any numbers for country X that can be held long term?”
All three look like orders. He replies with the same sentence to all three: “Yes, we support that. How much per number?”
One of the three replies.
The three messages above are a composite illustration, not a real conversation record. Each one stands for a real class of buyer, and those three classes are not asking for the same product, from the deliverable down to the pricing unit.
Why the same reply to three “I need numbers” messages loses two of them
Put the three messages side by side and the easiest thing to miss is this: they all use the word “number”, but they are not describing the same item.
An APP developer wants a channel that delivers. When his own users sign up, the verification code has to land on their phones; the carriers, the routing, and the retries in between are your problem. He holds no numbers of his own.
A QA team wants a programmatically addressable pool. They need two hundred numbers to start a test run, released when it finishes, and available again for the next build. What those numbers look like is not their concern.
A marketing team wants numbers that can be held for a while. Which countries they sit in, how long they survive, and whether they drop mid-way are the things they actually care about.
Different deliverables pull different pricing units along with them: one is billed per message, one per concurrent slot or per call, one per number per day. The boundary differs too. The first two are you delivering a capability. The third requires knowing what the numbers will be used for before you can judge whether to take it at all.
So a single catch-all pitch is one key tried against three locks. It will not fail on the spot. What it costs you is the other two conversations going quiet at the second message, and the group view never shows you which sentence was the wrong one.
First class: an APP developer’s message usually carries a date
Developer messages have one easy tell: they state the time themselves.
“Launching next week,” “shipping at the end of the month,” “we start the staged rollout this week” — once words like these appear, the person is not asking out of idle curiosity. There is a schedule behind him and the verification code is one line on the launch checklist. As long as that line is open, he cannot ship.
What he needs is A2P (application-to-person) messaging: your channel carrying his verification codes to his users on his app’s behalf.
There are three things to ask, and the order matters.
Ask about the target country and the main carriers first. A developer usually knows he needs Indonesia; he does not know that Indonesia contains a spread of carriers and number ranges whose delivery behaviour differs.
Then ask about the expected daily volume. You are not after a precise figure. You are judging whether this route justifies a dedicated configuration, because an order of magnitude changes the route and the pricing model completely.
Then ask what happens when delivery fails. The value of that question is not the answer. It is that the answer immediately shows whether the other side has actually designed a signup flow. A team with a fallback path is usually a team that stays.
The sentence not to open with is “how much per number”. He has not established that your channel works yet, and a price only confirms that you did not understand his problem. Leading with price turns a technical evaluation into a comparison shop before it starts.
Second class: a QA team never asks about price, they ask whether they can call an API
QA messages are just as easy to spot: they carry an order of magnitude but no country.
“Two hundred of them,” “five hundred per run,” “can we pull them per call” — you will almost never hear “I need Indonesian numbers”. The countries a test covers follow the test cases, not the business.
What they need is a number pool plus an allocation endpoint (API, application programming interface). Once it is wired into the pipeline, every build or regression run can pick up numbers on its own.
The three things to ask are entirely different from the previous class.
Ask about the concurrency peak first. Not the total, the maximum per second. Testing is bursty by nature, and two hundred numbers spread over an hour and two hundred numbers packed into ten seconds make very different demands on a system.
Then ask whether a number has to stay fixed across test cases. Some cases must re-verify against the same number; others work better with a fresh one each time. This answer decides whether resources can be reused.
Then ask what happens to the numbers after the run. This step is easy to skip, but it determines how the batch gets billed and whether the other side comes back for the next round.
The sentence not to open with is “our numbers are very stable”. A QA team does not make decisions on number stability; it needs a number every single time a run starts. Answering an engineering requirement with a retail selling point tells them you have never worked with this kind of customer.
Third class: a marketing team’s “can we hold it long term” is where you stop and ask
Marketing messages tend to carry three words: registration, accounts, country distribution. They ask “can we hold it long term” and “will it drop partway”.
This demand is not unservable. It just differs from the previous two in one essential way: the first two deliver a capability, while this one’s purpose decides whether it can be delivered at all.
The same sentence — “numbers for country X that we can hold long term” — may come from a team building a localized product who needs to verify its own signup flow in the target market. It may also come from a team preparing to register accounts in bulk. Those two are judged by completely different standards, and the single line you see in the group does not tell them apart.
So the next question is not about price, it is about purpose. Where are these numbers going to be used, and can you say?
Someone willing to describe the purpose can keep talking. Someone who only wants confirmation that bulk is possible and will not state a use case stops here. That step is the only working boundary for this class, and it has nothing to do with politeness.
The sentence not to open with is “yes, we have that”. Once the door is open, you do not get a second chance to ask about purpose.
The figure places the three buyer classes side by side with the clue each one leaves in a message: an APP developer brings a date, a QA team brings an order of magnitude, a marketing team brings a purpose. The last column marks the point at which none of them can be quoted yet.
Putting all three sets of evidence into one rule
The three sets share one property: every judgement above rests on words the other side has already typed — whether there is a date, whether there is an order of magnitude, whether there is a purpose. All three can be written down as conditions in advance instead of being dug out of chat history by hand.
The practical move is to let the three sets run in one place. Messages mentioning launch, release, or our app go down the channel path. Messages mentioning bulk, testing, API, or per-call go down the pool path. Messages mentioning long term, registration, or country distribution get a path of their own, flagged as “confirm purpose first”.
The screenshot shows the TOP Prospect group search page. The search box looks up indexed public groups (50 loaded at the time of the screenshot) by name, category, tag or description, and each card states its category tag, main language, member count, last verified date and date added; AI search, Google, and Bing cover what the library has not indexed yet.
The real gain from splitting the paths is that each class reaches the right person at the right moment. Channel questions belong with whoever understands carriers and routing. Pool questions belong with whoever can talk endpoints and concurrency. The third class should stop at a human judgement every time.
Replying fast matters less than replying to the right class
Back to that morning. The BD got one reply out of three, not because the other two were not buying, but because the sentence he used was only true for one of the classes.
Replying before everyone else was never worth much on its own. When that sentence is wrong for two of the three classes, the gain is cancelled entirely, and you will not get any feedback about it. Silence does not tell you which part was wrong.
What is worth practising is not typing speed. It is the fraction of a second spent deciding which class a message belongs to before you type anything. Get that right and every question afterwards lands where the other side actually cares. Get it wrong and the faster you ask, the faster they leave.
If you already follow a handful of OTP reception and developer groups, try a light one-week record: tag every “I need numbers” message by class, and see which class shows up most and which one you most often answer wrong. After a week you will know whether what needs fixing is your script or your conditions.
To see what sustained triage across these three classes looks like, read on with How SMS providers find customers: reading OTP failure discussions to decide which demand is worth pursuing and “It worked yesterday, now a batch of accounts needs verification”: residential proxy sellers should not rush to quote a plan.
Sources and further reading
This article is human-authored. TOP Prospect processes only Telegram groups the user has explicitly authorized and connected. Its output supports human sales judgement; it does not replace human decisions and does not automatically contact or message group members.
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
