A collection of representative B2B lead discovery scenarios, showing how AI identifies qualified sales opportunities from real-world business conversations.
He Used to Find RPC Demand Three Weeks Before Mainnet by Luck. Now He Finds It in Records
A Web3 RPC salesperson used to scroll more than ten Telegram groups without separating technical discussion from real selection demand. With TOP Prospect, he reviews contextual candidate records before manually verifying the window.
This is an illustrative scenario designed to explain the product’s judgement logic. It is not a real customer case, testimonial, contract, revenue result, or conversion claim.
01Situation
02Signal judgement
03Confidence vs priority
04Human next step
Signals considered
- The project gives a specific mainnet or TGE date
- The writer considers changing RPC providers or names a capability gap
- Specific requirements such as European nodes, failover, or multichain support appear
- The writer can add call volume, chain scope, or a technical decision-maker
At 1 AM, an RPC salesperson finishes another round of group scrolling. Project groups, developer groups, and Web3 infrastructure groups—he follows more than ten and spends three hours reading them. He reaches one conclusion: many people discuss RPC, but none of them is someone he can follow up with.
Demand is not absent. It appears every day. Someone complains that a node is down again. Someone asks for an RPC with European nodes. Someone says they want to switch before mainnet launch. But he cannot separate real demand from technical discussion, and by the time he confirms it, the project has usually made its decision.
The window in this industry is absurdly short: projects need an RPC solution only two to four weeks before TGE—the token generation event—and once that window closes, the opportunity disappears. By the time he notices demand, the buyer has usually compared prices and is preparing to sign.
On Thursday, his working method changes. Instead of opening the group list, he opens the TOP Prospect workspace. Overnight, the system has organized messages from the highly relevant groups he connected into candidate records. He reviews them in fifteen minutes, dismisses two technical discussions, marks one “need to switch RPC before mainnet” message as Pending Follow-up, and only then sends a direct message.
That evening, he runs the numbers: three hours of group scrolling used to retrieve things that looked like demand. Fifteen minutes of record review now retrieves things worth verifying. The difference is not time. It is whether he found the right thing.
This article follows one person: an RPC salesperson and what changed after he began using TOP. It shows what the product organizes, ranks, and preserves—and what it never does for him. Judgment, outreach, and closing remain human work.
NOTICE: The team, group messages, and business conditions in this article are composite illustrations used to demonstrate the product workflow. They do not represent a real customer, conversation, contract, revenue result, or conversion outcome.
Before: Three Problems That Kept Him Going in Circles
Problem one: buyers and sellers use the same language in the same group.
The RPC ecosystem has an unusual characteristic: buyers and providers gather in the same groups and say almost exactly the same things. A project says “recommend an RPC.” A provider says “we recommend our RPC.” The same term comes from one party spending money and another trying to earn it. Half the RPC discussion he sees every day is peers promoting themselves, and half is technical exchange. Genuine demand is buried inside like a needle in the ocean.
Problem two: technical discussion and real demand look identical.
“The node returned 429.” Is that technical discussion or the first sign of a provider switch? “We need an RPC with failover before mainnet.” Is that casual conversation or active selection? A single message does not reveal the difference. He has learned the hard way. Once, he pursued someone complaining about a 429 error for half a day, only to learn that the person was passing through and did not use a competing provider. Another time, he ignored “launching next month and considering a new RPC.” Two weeks later, the project had signed with someone else.
Problem three: the window is too short, so seeing demand is still too late.
Even after recognizing genuine demand, the RPC selection window lasts only two to four weeks. Projects move from initial search to provider choice remarkably fast. He often sees the demand only after the buyer has completed price comparisons. The demand exists; he simply sees its second half.
Together, these three problems produce a familiar result: he is in groups every day and closes nothing month after month.
After: Three Things the Product Does for Him
First: Separate Project Groups From Peer Groups So the Signal Source Is Right
He reorganizes his monitoring sources. TOP Prospect only processes groups he actively connects and is authorized to access. He treats groups where projects gather—Web3 project communities, infrastructure-selection groups, and developer groups—as demand sources. RPC provider communities become market observation, used only for market intelligence and excluded from the sales queue.
The result: he used to mix more than ten groups together; now only five or six remain as demand sources, and every message deserves more attention. Projects that may buy RPC services discuss them in project communities, not in peer promotion groups. For the first time, he sees that the problem was not too few groups. He had spent half his time watching peers.
The corresponding product capability is monitoring-source management. You choose the groups; the system does not join groups for you. Demand sources and market observation remain separate, and peer groups do not enter the sales queue.
Second: A “Want to Change RPC” Message Becomes an Evidence-Backed Lead Card
The “want to change RPC” message he used to retrieve manually now looks like this in the system:
| Field | Content |
|---|---|
| Business category | RPC service replacement demand (commercial opportunity) |
| Original message | The complete message, preserved word for word |
| Source | XX Web3 Infrastructure Selection Group · sender ID |
| Time | 2026-08-07 01:32 (UTC+8) |
| AI score | A 0–100 ranking score and “High Priority / Important / General” label calculated from factors such as the base score, signal strength, importance, number of matched keywords, recency, and repeated mentions |
| Rationale | Matches “mainnet launch / change RPC / failover”; semantic assessment suggests a real project expressing replacement demand rather than technical discussion or peer promotion |
| Status | New lead |
This card solves his first two problems. The original words, source, time, and context remain together, and he can return to the original message. Instead of guessing whether it is technical discussion or genuine demand, he can judge from the context in the record. The score only tells him which record to review first. He still makes the judgment, but he no longer has to retrieve the message manually from the discussion.
The corresponding product capability is extraction rules + lead organization. You define what counts as an event worth reviewing in your business language, such as mainnet launch, changing RPC, or needing failover. Keywords perform coarse retrieval, and AI assesses intent. The product organizes and ranks; a person returns to the original message to judge the facts.
Third: Give Every Lead a Status So the Window No Longer Depends on Memory
He now assigns each lead a status: New Lead → Pending Follow-up → Followed Up → Converted (terminal), or Invalid (reversible). When he marks one invalid, he adds a short reason—“technical discussion,” “window passed,” or “chose another provider.”
At month-end, those invalid reasons become the most valuable data. The team can immediately see which messages are only technical discussion and should be excluded, and which needs repeatedly receive slow follow-up and require more speed. He adds pure technical discussion such as “node returned 429” to the exclusion terms and gives more weight to the combination “mainnet launch + date.” The following month’s candidates look more like records he would genuinely review.
The corresponding product capability is status flow. The team updates status manually. The product does not read direct messages and does not know whether a deal closed; it records the status selected by the team. Who follows up and how the conversation proceeds remain human decisions.
One Complete Path: From “Want to Change RPC” to a Trial Customer
Follow his actual handling process from beginning to end.
On Tuesday, a message appears in a Web3 infrastructure-selection group:
“Our project launches mainnet next month. The current RPC does not support European nodes or failover, so we want to switch. Any recommendations?”
System assessment: The message matches “mainnet launch / change RPC / failover,” indicating replacement demand. Semantic assessment finds a specific business—our project—a defined time—launching next month—and concrete capability requirements—European nodes and failover. It appears to come from a real project rather than technical discussion or peer promotion.
He opens the record: The original message, source group, time, and rationale are present. He opens the writer’s history. The same person asked last week which RPC works for cross-chain calls. It is a longstanding account, which increases credibility. He marks the record Pending Follow-up.
He sends a direct message using the context from the card:
“I saw your message in the XX Infrastructure Selection Group saying that you launch mainnet next month and want an RPC with European nodes and failover. Could I first ask about the approximate call volume and which chains you mainly use?”
Why ask this? RPC is not a question of whether it exists, but whether it can carry the load. Call volume determines the required configuration, and chain count determines whether multichain support is necessary. Until he understands the volume and chains, he cannot know whether his service fits or which solution to quote. This is not intelligence gathering. It helps the project define its need.
The person replies: Mainnet is expected to reach 50,000 monthly active wallets, mainly on Ethereum and one L2. The current provider has high latency in Southeast Asia, and the project wants someone with European nodes.
That sentence opens the window. The salesperson does not rush to quote. He sends a pre-mainnet RPC selection checklist covering node distribution, failover, rate-limiting strategy, and SLA, then asks the CTO to run a self-check. The project sees that he understands the problem.
On Friday, the person asks: “What is the approximate latency of your European nodes? Can you issue a test key so we can run it for two days?”
The salesperson changes the status from Pending Follow-up to Followed Up and records the test key, the CTO as decision-maker, and “European nodes + failover” as the selection reason. Two weeks later, the test is stable, the project enters the formal contracting process, and he updates the status to Converted.
During review, he records one rule: The combination “mainnet launch + date + specific capability requirements” almost always indicates real demand. Launching next month is the particularly valuable detail because it shows that the window has just opened and price comparison has not begun, so the record receives more weight.
Return to the Question: What Did the Product Actually Do for Him?
He did not change industries, customers, or sales language. He only changed where he spent his time:
| Before | After | |
|---|---|---|
| Finding signals | Three hours scrolling more than ten groups and finding things that look like demand | Fifteen minutes reviewing organized candidate records and finding things worth verifying |
| Separating real from false | Guesswork; technical discussion and real demand look the same | Original text, context, and history together for verification |
| Catching the window | By the time he sees demand, the buyer has usually compared prices | Marks the record Pending Follow-up when the window first opens |
| Result | In groups every day, no deals month after month | The same salesperson, with the same time, catches a message he would previously have missed |
But the product never does three things for him:
- It does not decide what is true. The AI score only ranks. It decides which record appears first; he decides whether it is genuine by returning to the original message.
- It does not contact customers. The product does not read direct messages or send messages automatically. He writes the opening himself.
- It does not close deals. He changes the status manually. The product does not know whether the conversation resulted in a sale.
The product organizes and ranks. Judgment, outreach, and closing remain human work. That organization turns him from a salesperson who scrolls groups into a salesperson who reviews records. What he retrieves is finally not something that looks like demand, but something worth verifying.
Further Reading
Complete method:
Product workflow:
- Business Signal Workflow—the complete process from joined groups to follow-up-ready records
Related scenario articles:
- An Exchange Has Seven Days to Add Travel Rule Support—By the Time the RFP Appears, the Provider Has Already Been Chosen
- Three KYC Rejections, Two False Positives, and Six Weeks Until Renewal—False-Rejection Rate Plus Renewal Window Is a Provider-Switching Signal
TOP Prospect continuously collects messages from Telegram groups the user has joined, defines events in the user’s business language, combines keyword and semantic assessment, and preserves the original evidence. It turns ambiguous group conversations into records that can be verified, ranked, and followed up. AI judgments organize and prioritize the work; the team decides whether to make contact.