I get pitched in Telegram, LinkedIn and Twitter daily by BDRs who clearly haven’t spent thirty seconds figuring out whether I’m the right person to talk to.
A protocol selling MEV-resistant routing pings me about “exploring synergies.” I sell vesting infrastructure. We are not synergistic. Another wants me to onboard their RPC service to my “validator stack.” I do not run a validator stack. A third opens with “we’d love to integrate with Sablier’s bridge.” We do not have a bridge. Auditors try to sell me audits, market makers try to sell me their service, and I’m clearly not the right person to reach out to on either. The standout is the bare “we’d like to explore collaborations” DM with no context at all.
Those are ICP failures. The prospect is wrong before BANT even applies. But the bigger problem starts after that. Even when crypto BDRs do pitch the right company, most of them skip the four-question test that would tell them whether the company is actually a buyer. They send the DM, the prospect says “interesting,” the AE’s calendar fills up, and the founder spends an hour on Zoom with someone who was never going to buy.
The most expensive minute in any BD org is not the one you spend prospecting. It’s the one your AE spends on a call with an unqualified lead. That’s the minute you should be optimizing against.
This is a field guide to qualifying crypto leads using BANT (Budget, Authority, Need, Timing). It’s not the only framework. MEDDIC and its successors are arguably better fits for complex enterprise deals, and I’ll touch on why I’m still recommending BANT. But for the typical crypto BDR motion, BANT is the cleanest starting point, and most Web3 BDRs I’ve met hit one or two dimensions and skip the rest.
Why crypto BD struggles at qualification
Web2 SaaS reps are also bad at qualification on average. The spray-and-pray outbound industry runs on the same bad habits. But crypto adds two structural amplifiers on top.
The deals are small and the pipelines are wide. A typical Web3 deal cycle for infrastructure is small enough that nobody bothers building proper qualification. They just push more outreach in. The result is a fire hose of low-quality conversations and AEs whose calendars are clogged with discovery calls that go nowhere.
Founders themselves model the bad behavior. Early founder-led BD often skips qualification because the founder is the qualifier. They can read a room in two minutes. When a BDR gets hired, that judgment doesn’t transfer, but the loose-prospecting habit does.
The four specific failure modes that follow from this (dirty fundraising signal, blurry personas, politeness inflation in DMs, unbounded “someday” timelines) map directly onto BANT. The rest of this post walks each.
BANT, briefly
BANT (Budget, Authority, Need, Timing) was popularized by IBM in the 1960s and declared dead approximately every eighteen months since 2010. The critique has merit. MEDDIC and MEDDPICC explicitly model Champion, Decision Criteria, and Decision Process, three things BANT collapses into “Authority.” For complex enterprise deals (six-figure ACV, six-month sales cycles, formal procurement), MEDDIC is probably the better tool, and your AEs should be filling those fields after the first call. (A small CRM schema for that handoff is at the end of the piece.)
For most crypto BDR work, BANT is enough. The four dimensions:
- Budget — Does the prospect actually have money to spend on what you sell, in a form you can take?
- Authority — Are you talking to someone who can decide? Pitching a head of marketing, a community manager, or a head of BD on products only the founder has authority over is futile.
- Need — Does the prospect have a specific, articulated pain that your product solves, or are they just being polite?
- Timing — Is there a buying window the prospect can actually name?
Budget
A fundraising announcement looks like a buying signal but isn’t. A $20M raise tells you a project has cash. It doesn’t tell you who controls that cash, what it’s earmarked for, or whether the team has any need that maps to your product. Most crypto BDRs treat “raised in the last 90 days” as a synonym for “qualified.” It is not.
Crypto Budget has two real complications.
The first is that the treasury is not the budget. A protocol with $80M in its treasury does not have $80M to spend on you. The treasury is a mix of native tokens (illiquid, volatile, often locked in DAO contracts), stablecoins held for ops, and reserves earmarked for specific commitments. The actual operating budget (the pool that pays for infrastructure, tooling, services, and headcount) is usually a small fraction of the treasury and lives in a multisig that two or three people control.
The second is that procurement workflow varies wildly. A small labs team might send stablecoins on founder discretion the same day. A larger DAO-governed protocol might require a forum post, a temperature check, a Snapshot vote, and signatures from a 5/9 multisig: three to six weeks minimum. The same $50K commitment lands very differently depending on which path applies.
Authority
Authority is the dimension where crypto BDRs lose the most time, because the question “who decides?” rarely has a clean answer.
As you can imagine, a head of BD or community manager has very limited say on something like a security audit, and is unlikely to be a good internal champion for your product, even if they can forward your pitch to the actual decision-maker (founder or CTO in the case of audits).
So what’s the point of booking a call through such a person? An engineer at the same org is in a much better position to land you the conversation with the CTO.
Where the BDR finds Authority signal before contact:
- Team page, LinkedIn and recent X posts: who speaks publicly for the org on commercial topics
- GitHub if you’re selling to a technical team: look at who has recently committed code related to your service area
- Conference speaker assignments: the person who represents the org publicly often has internal weight
What the BDR confirms in outreach: the named decision-maker. First name, role, why you believe this is the right person.
What the AE confirms on the call: the actual path to a signed contract.
The cleanest test for the AE call:
“If we agree on terms today, what does the path to a signed contract look like? Who else needs to be in the loop, and how long does it usually take?”
A real buyer can answer this in two sentences. A non-buyer will be vague, defer, or invent. If the AE doesn’t get a clean answer here, the lead drops back into nurture even if Budget, Need, and Timing all looked clean to the BDR.
Need
Need looks easy and isn’t. A lot of projects will say they have a need, politely, in DM, where saying “interesting” costs them nothing. Most BDRs read this as signal. It usually isn’t. It’s politeness, the path of least resistance for a busy founder who doesn’t want to be rude.
Real Need is specific. It’s a problem the prospect has named, that costs them something today, and that they would solve even if you didn’t show up. Your job is to figure out whether they would build it themselves, hire a contractor, or pay you, and to confirm that the pain is acute enough that doing nothing is not an option.
The first-message qualifier I use on Telegram, before booking anything:
Hey [name], saw [specific signal: their X post, their job ad, their governance proposal]. We help teams in your spot with [one specific job-to-be-done]. Two quick things to check before I take more of your time:
- Is [specific problem] something you’re actively trying to solve, or is it parked for later?
- If active, is the call I should be on with you, or with someone else on the team?
This script is deliberately Need + Authority only. Budget and Timing should already be hypothesis-confirmed from public signal before you send it. If you don’t have B+T hypotheses, you’re not ready to DM yet. Go back to research.
Where the BDR finds Need signal before contact:
- Founder X posts complaining about the problem. “We spent two weeks spec-ing X and it’s a mess” is a louder Need signal than a deck would be.
- Governance proposals about the problem space (someone is already advocating for a solution internally)
- The team’s own technical content or blog. What they write about reveals what they care about.
- Engineering hiring patterns. Three open roles in one area means that area is a bottleneck.
The questions for the AE call, to separate need from politeness:
- What problem are you currently solving with a workaround, a spreadsheet, or a part-time engineer?
- If you don’t solve this in the next quarter, what breaks?
- Have you already evaluated alternatives? Which ones, and why didn’t they work?
- Who internally is asking for this: a founder, a customer, a regulator, an investor?
A prospect with real need will answer all four crisply. A prospect with fake need will give generalities (“we’re definitely thinking about that space,” “it’s on the roadmap”). Generalities are signals to deprioritize, not to push harder.
A useful frame: every BDR should be able to articulate, in one sentence, the specific job-to-be-done their product gets hired for. If you cannot complete the sentence “the prospect would buy this product to ____,” you do not have a need-qualified lead.
Timing
Timing is the dimension I treat as most decisive in my niche, because token-launch infrastructure has a hard window. If a project’s TGE is twelve months out, they don’t need a vesting contract today. If their TGE is next month, they don’t need a sales call. They need to wire the money and ship. The qualified window for what I sell is roughly three to six months before launch, and identifying which prospects are inside it is most of the qualification work.
For other crypto products the timing question looks different, but the principle holds: there is some external event or internal milestone that creates the buying moment, and you need to know where the prospect is relative to that moment.
Common timing anchors in crypto:
- TGE / token launch date. Drives demand for vesting, airdrops, KYC vendors, market makers, exchange listings, custodians, legal review.
- Mainnet launch. Drives demand for monitoring, security audits, RPC providers, indexers, block explorers.
- Regulatory deadline. MiCA, the GENIUS Act, state-specific licensing. These create hard windows.
- Funding milestones. A close-to-closing Series A often unlocks budget that didn’t exist a month earlier; a runway-low team will postpone every non-essential purchase.
- Conference cycles. ETHDenver, Token2049, Devcon. Many crypto teams plan launches and partnerships around these.
Where the BDR finds Timing signal before contact:
- Founder X posts naming the TGE quarter
- Governance proposals scheduling token-related votes
- Funding announcements with roadmap language
- Audit firm engagement announcements (typical two to four months pre-launch)
A qualified lead is one where you can name the timing anchor for your specific product, place the prospect on the timeline, and confirm they are inside (or about to enter) the buying window. The window is product-specific. My vesting window is three to six months pre-TGE. An audit firm’s window starts six to twelve months pre-mainnet. A custodian’s might start nine to eighteen months out. There is no universal “X days” rule. There is only “do you know your product’s window, and is this prospect inside it?”
The disqualifying question I rely on most: “Is there a date on the calendar where this becomes urgent?” If the answer is no, the lead is not timing-qualified. It might become qualified later, in which case it goes into nurture.
The mistake junior BDRs make is conflating “they responded” with “they’re ready.” A reply is not timing. A meeting is not timing. Only a date is timing.
The opposite mistake: over-disqualification
Aggressive disqualification has its own failure mode. Once a BDR discovers the joy of saying no, they can start killing leads who would have closed if given another conversation. Two patterns to watch for:
The quiet buyer. Some prospects are early in their thinking and don’t yet have crisp answers to Authority or Timing questions. That doesn’t mean they’re not buyers. It means they’re at the front of the funnel. The right move is to move them to nurture and re-qualify in sixty to ninety days, not to delete them from CRM.
The wrong-persona-but-right-org. A BDR talks to a community manager at a target protocol who has no infra purchasing authority and gets blown off. That doesn’t disqualify the protocol. The eng or ops lead might still buy. (This is also why the SaaS heuristic of “talk to senior people only” misfires in crypto: protocols often run flat, and an engineer can be the actual decision-maker on infrastructure choices. Persona, not seniority, is what matters.)
The signal that distinguishes “not yet” from “never” is whether the prospect has a real pain (Need) and a real event-anchored timeline (Timing), even if Budget and Authority are fuzzy. Good BDRs sort fuzzy-but-real from polished-but-fake. Lazy ones treat anyone fuzzy as disqualified, which is just a different kind of waste.
A real disqualified lead
Concrete example, lightly anonymized.
Last quarter I researched a Series A protocol with strong surface signals: a $25M raise from a tier-1 fund, a TGE rumor in their Discord, an active founder on X. Public Budget signal looked clean: recent stablecoin OTC, multisig with a known operations signer. Public Need signal looked plausible: their last technical post mentioned vesting in passing.
I sent the qualifier DM. The reply: “interesting, can you send a deck and we’ll discuss internally?” Exact politeness pattern. No specifics. No named decision-maker.
I followed up once with the second qualifier: “happy to send a deck. To make sure it lands with the right person, who on the team owns vesting?” Reply: “we’ll look at it together and circle back if it makes sense.”
That is not Authority confirmation. That is deflection. The prospect didn’t name a specific owner, didn’t acknowledge there is one, and reverted to the language of group consideration. Exactly the pattern that produces a “we’ll consider it” reply six weeks later. (If they had said “send it to me, I run vendor selection” or even “the founder picks but I gather options first,” that would have been a real path, and I would have booked the AE call. “We’ll look at it together” is not.)
I disqualified, moved them to nurture, and did not book the AE. Two months later they launched with a competitor’s vesting setup that they had been spec-ing internally for months. They had never been actually shopping. The disqualification was correct. The cost of being wrong (one nurture-list slot) is much smaller than the cost of being right and still booking (one wasted AE hour and a mis-set expectation downstream).
The pattern to watch for: surface signals that look strong, DM responses that are polite but specific-free, and Authority answers that defer rather than name. Three of those is a kill.
What this looks like in practice
The rule I use with my own pipeline: if I can’t summarize a lead’s BANT in four sentences for my AE before the call, I haven’t done my job. The AE shouldn’t have to discover what they’re walking into, though they will deepen all four dimensions on the call and translate them into MEDDIC fields for the CRM afterwards.
A realistic handoff (with one fuzzy dimension flagged) looks like:
“[Project] is a Layer 2 with mainnet targeted for Q3 per their latest governance proposal. Champion is [name], head of engineering, who confirmed in DM that they own audit vendor selection and route to the founder for budget sign-off. Need: their last X post complained about a slow cycle with their previous audit firm and explicitly mentioned re-evaluating vendors this round. Authority: unclear at the foundation level. DAO governance may need to ratify any audit vendor change beyond a certain spend threshold. Need to confirm the actual scope of internal authority on call.”
Three of four passed, one flagged for the AE. That’s a real handoff. Anything more polished than this is fiction or an unusually clean lead.
The disqualification habit
The single most important pipeline metric for a BDR is post-AE-call disqualification rate. If your AE keeps killing leads after running discovery, the BDR is booking the wrong meetings, full stop. Pre-AE disqualification protects time. Post-AE disqualification rate exposes the BDRs who pass leads through on politeness and surface signals as if they were qualification.
Most reps still treat a disqualified lead as a loss. It is not. Pre-AE disqualification (the BDR killing a lead before booking) protects the AE’s time. Time that doesn’t go to a bad meeting is time the AE gets back for a real conversation. But that’s the easy half. The hard half is making sure the leads that do get booked actually hold up under discovery.
Track three numbers together:
- Pre-AE disqualification rate — what fraction of prospected leads get killed before the AE call.
- Post-AE disqualification rate — what fraction of booked leads the AE kills after discovery. The lagging indicator of BDR quality, and the one that matters most.
- AE conversion rate — what fraction of AE meetings become deals.
A BDR with high pre-AE disqualification but high post-AE disqualification is filtering on the easy signals while missing the harder ones. The polite “interesting” replies still slip through. The goal is post-AE disqualification trending down and AE conversion trending up. Healthy ranges are pipeline-specific. Set baselines from your first quarter and demand improvement against them, rather than importing SaaS benchmarks calibrated on different deal shapes.
If you’re a founder reading this with a BDR whose meetings keep getting disqualified after discovery, you have a coaching problem. Crypto BD runs on Telegram, not phone calls, so the right audit isn’t to shadow calls. It’s to read their last twenty Telegram threads end-to-end and tag the moments where a polite “interesting” got mistaken for a Need signal. Then audit the AE’s post-call disqualification reasons. If “no real need surfaced” or “wrong decision-maker” dominate the tags, the BDR is passing through leads they should have killed in DM. Coach the harder follow-up. Reward leads that survive the AE call, not just leads that get booked.
Where this connects
For the BDR/AE structure that BANT plugs into, see Scaling Founder-Led Sales. AI now does most of the public-signal work: treasury dashboards, fundraising tracking, job-ad scraping, governance-forum monitoring. (My own setup is in How I Built Myself an AI BDR Sidekick.) Where AI still falls short is reading politeness inflation in DM threads and judging whether a fuzzy answer is “not yet” or “never.” That call is still human work, and BANT is the discipline that human work runs on.
Crypto BD will get better when reps stop measuring themselves on outreach volume and start measuring themselves on the three numbers above. BANT used the right way (public-signal research for Budget and Timing, outreach for Need and Authority, AE call for depth on all four) is the simplest tool to get there.
