Lead qualification: four gates, run in the cheapest order
BANT and MEDDIC qualify leads you are already talking to. This is the version for leads who have never heard of you, run cheapest gate first.
Most lead qualification frameworks assume a conversation is already happening. BANT, MEDDIC and the rest are questions you ask a person. For outbound, nobody is talking to you yet, so qualification has to run on what is observable from outside, and the only thing that matters is the order you check it in.
Outbound lead qualification is four gates run cheapest first: does the account match the profile, are they already solving the problem, is there a dated event, and can you write one specific sentence about them. Gate four needs a human reading carefully, so it should be looking at twenty accounts rather than four hundred.
The four gates
Each gate is more expensive per account than the one before it. A database runs gate one across ten thousand rows for nothing. Gate four is a person reading for ten minutes. Running them in that order is the difference between an afternoon and a fortnight.
Gate 1, profile. Does this match who actually buys? Not who could buy. This is an ideal customer profile question, and if the profile is a description rather than a filter, the gate does nothing.
Gate 2, problem. Are they already solving this another way? A clinic that already has online booking is a migration rather than a new install, which is a different message and usually a worse deal. Checking costs one page load.
Gate 3, timing. Is there a dated event that makes this month the month? Which events count as evidence and which are horoscopes is worth being strict about.
Gate 4, the sentence. Can you write one line naming something specific and checkable, with a link? This is the only gate that cannot be automated away, and it is the one that decides whether the message is worth sending.
Why reversing the order is so common
Because gate four is the interesting one. Reading about a company is more engaging than filtering a spreadsheet, so people start there, get through eleven accounts by lunch, and conclude that outbound does not scale.
It does not scale if you read four hundred companies. It scales fine if you read nineteen.
The other reason is that gates one to three feel like they are throwing away opportunity. They are throwing away work. The accounts removed at gate two were never going to reply to a message about a problem they already solved.
What each gate can and cannot be delegated to
| Gate | Can a tool do it | What goes wrong when it does |
|---|---|---|
| Profile | Yes, entirely | The source data is wrong more often than anyone admits; verify a sample by hand |
| Problem | Mostly | It checks the homepage and misses the feature two clicks deep |
| Timing | Yes, with sources | It reports events that are eight months old as current |
| Sentence | Drafting yes, deciding no | It always finds something, because it was asked to |
The last row is the one to watch when buying software. A system measured on how many qualified leads it produces will produce them. Restraint has to be designed in, and it usually is not, which is why an evaluation should test what a tool does when there is nothing to find.
Where the gates get their evidence
Each gate has a source that is cheap to check and a source that is tempting and wrong.
Gate 1 should read the company's own site, not the list vendor's field. Practitioner counts, headcount bands and industry codes are wrong often enough that a gate built on them passes accounts that do not exist as described.
Gate 2 should look for the feature, not the marketing. A homepage that mentions online booking and a booking flow that actually works are different findings.
Gate 3 should carry a date. An event without one is not a timing signal, it is a fact of unknown age, and old events get treated as current far more often than anyone expects.
Gate 4 is a person, or something that shows its work like a person would. Revtive's prospecting agent runs the first three and drafts the fourth with a source link attached, which is the split that matters: the gates that can be wrong quietly are the ones worth automating, and the gate that decides to send is not.
A worked funnel
Selling a booking tool to independent physiotherapy clinics.
- 400 rows bought from a list vendor.
- Gate 1, profile. Two to nine practitioners, verified against each clinic's own team page rather than the vendor's field. 212 survive, and about forty of the drops were bad data rather than bad fit.
- Gate 2, problem. No online booking already live. 61 survive.
- Gate 3, timing. A new practitioner announced, a second location, or a recent review complaining about phone hold times. 19 survive.
- Gate 4, sentence. One specific line, with a link, per account. 6 survive.
Six messages. The 394 were not waste, they were the cost of finding six accounts where the message is defensible, and the whole thing took a morning because only nineteen accounts ever got read properly.
When this framework is wrong
For inbound. Someone who filled in a form has already passed gates one to three by acting. Use BANT or something like it, and ask them.
When you have fewer than fifty accounts total. Then there are no gates, there is a list, and you read all of it. Frameworks are for triage and you do not need triage at that size.
When every gate passes. If four hundred rows produce two hundred qualified accounts, the gates are not filters, they are decoration. Usually gate one is too loose. Narrowing the profile until it hurts is the fix, and it is also the thing nobody wants to do in a quarter with a pipeline target.