Sales Qualified Lead (SQL) Definition: How to Set B2B Handoff Criteria Sales Will Actually Accept
By Rick Elmore ·
Every marketing team thinks it's sending over qualified leads. Every sales team thinks marketing is dumping garbage on them. Both can't be right, and the reason they disagree is almost never effort or intent—it's that nobody wrote down a sales qualified lead definition that both sides signed. Fix the definition and half the pipeline arguments disappear.
This isn't a lead scoring post. Scoring tells you which leads are hottest relative to each other. Qualification tells you whether a lead has crossed a hard threshold that obligates sales to work it. Those are different jobs, and conflating them is why so many handoff systems quietly fail. Below is the framework we use when we build revenue engines for clients—the exact criteria, the codification, and the cross-team agreement that makes sales stop rejecting leads.
How to build a sales qualified lead definition sales will accept
1. Start with the rejection right, not the lead
Before you define what qualifies, define what sales is allowed to reject and why. A definition sales can't push back on is a definition sales will ignore. Give reps a structured way to bounce a lead—with a reason code—and you turn every rejection into data instead of a grudge. The goal isn't zero rejections. It's that every rejection points at a specific criterion you can tighten. When a rep sends a lead back marked "wrong company size," that's the system working, not breaking.
2. Separate the three qualification layers explicitly
An SQL should clear three independent gates. If you blur them, you'll approve leads that fit the profile but show no interest, or leads that are excited but can't buy. Keep them distinct:
- Firmographic — is this the kind of company you can actually close and serve?
- Behavioral — has this person done something that signals real intent, not curiosity?
- Intent/context — is there a reason to buy now, and is this person close enough to the decision?
A true SQL clears all three. Two out of three is a nurture lead, not a handoff. Writing this rule down ends the eternal debate about whether an enthusiastic intern at a company that's too small counts.
3. Set firmographic thresholds as hard filters, not preferences
Firmographics are binary. A company either fits your serviceable market or it doesn't. Decide the non-negotiables and make them disqualifiers rather than scoring points. Common gates:
- Company size band (employees or revenue) you can profitably serve
- Industry or vertical you have a real right to win in
- Geography you can sell and deliver to
- Tech or operational profile that means your solution applies at all
The mistake most teams make is treating "too small" as a low score instead of a hard no. If a company can't afford you or can't use you, no amount of behavioral heat should promote it to SQL. Bake the hard filters in first, then let scoring rank what's left.
4. Define behavioral signals by weight, not volume
Not all activity means the same thing. Ten blog visits is noise. One pricing-page visit plus a demo request is a buying motion. When you define the behavioral gate, rank signals by what they actually predict:
- High intent: demo request, pricing page views, "contact sales" form, reply to a sales sequence
- Medium intent: multiple return visits, bottom-funnel content downloads, webinar attendance with engagement
- Low intent: single newsletter signup, one top-of-funnel download, a passive social follow
An SQL should require at least one high-intent action, or a tight cluster of medium ones inside a short window. A stack of low-intent touches spread over six months isn't qualification—it's a subscriber. Say so in the definition.
5. Add a recency window so stale leads don't leak through
Intent decays. A demo request from last Tuesday is an SQL. The same request from four months ago, with silence since, is a re-engagement lead. Put a time box on your behavioral and intent criteria—most teams find somewhere between 14 and 45 days works, depending on sales cycle. Without a recency rule, your CRM slowly fills with "qualified" leads that went cold, and reps start distrusting the SQL label entirely because half the ones they touch are dead on arrival.
6. Require a person, not just an account
Account-level intent data is useful, but sales can't call an account. Your SQL definition needs a known contact with enough context to work: a name, a role, and ideally a reason to believe they influence the decision. A company showing intent signals with no identifiable human attached is an account to research, not a lead to hand off. Make "an actionable contact exists" an explicit part of the definition, or your reps will get handed accounts and told to figure out who to call.
7. Codify the definition as rules a system can enforce
A definition that lives in a slide deck is a suggestion. A definition that lives in your CRM and automation platform is a standard. Translate each criterion into a field, a value, and a rule so the handoff happens the same way every time—not at the discretion of whoever's routing that day. The pattern we build for clients looks like this:
- Firmographic filters enforced by enrichment data on the contact and account records
- Behavioral thresholds tracked as scored events with timestamps
- A single "SQL" status that only flips when all three gates are cleared inside the recency window
- Automated routing that assigns the lead the moment status flips, with the qualifying evidence attached
When a rep opens an SQL and can see exactly why it qualified—the firmographic fit, the specific actions, the dates—acceptance goes up on its own. People trust what they can inspect. If you want help wiring this into a working system, that's the kind of build our RevOps packages are designed around.
8. Write the definition together, in one room
This is the step everyone skips, and it's the one that actually matters. A sales qualified lead definition handed down by marketing will get rejected. A definition sales helped write gets defended. Get the marketing lead, the sales lead, and whoever owns RevOps in the same session and force agreement on each threshold, line by line. Argue about company size in the room, not in Slack after a lead gets bounced. The document you produce is a contract: marketing commits to only passing leads that meet it, sales commits to working every lead that does.
9. Build the rejection loop into the definition, not around it
When a rep disqualifies an SQL, that has to feed back into the definition. Set a standing review—monthly is usually right—where you look at every rejected SQL and ask one question: was the definition wrong, or was the data wrong? If reps keep rejecting for the same reason, the definition needs a new filter. If they're rejecting good-fit leads out of habit, that's a coaching conversation. Either way, the feedback keeps the definition honest. A qualification standard that never changes is one nobody's actually using.
10. Version it, and treat changes like a release
Your market shifts, your ICP sharpens, your sales cycle changes. The definition should change with it—but deliberately, not quietly. Put a version number and a date on it. When you tighten a threshold, announce it to both teams and explain why. This does two things: it keeps everyone working from the same current standard, and it stops the slow drift where marketing is optimizing against last year's definition while sales expects this year's. Treat your SQL definition like production code, because in a real revenue engine, it is.
What separates this from lead scoring
Worth repeating because it trips up so many teams: scoring is a ranking, qualification is a gate. Scoring tells a rep which of ten SQLs to call first. Qualification decides whether a lead becomes one of those ten in the first place. You need both, but you build them differently. Scoring can be fuzzy and weighted. Qualification should be closer to pass/fail, because its whole job is to create a clean line that both teams agree to respect. Blur that line and you're back to arguing about lead quality every Friday.
Frequently asked questions
What is the difference between an MQL and a sales qualified lead?
An MQL (marketing qualified lead) has shown enough interest for marketing to consider it worth nurturing—it's a signal of engagement. A sales qualified lead has cleared firmographic, behavioral, and intent thresholds that both teams agreed obligate sales to work it. The MQL is marketing saying "this looks promising." The SQL is a contract saying "this meets the bar, go sell." The gap between the two is where most handoff friction lives, which is exactly why the SQL definition needs to be written jointly.
How many criteria should a sales qualified lead definition include?
Enough to cover all three gates—firmographic, behavioral, and intent—without becoming so strict that nothing qualifies. In practice that's usually a handful of hard firmographic filters, one or two required high-intent behaviors, a recency window, and a requirement for an actionable contact. If your definition is so tight that reps are starved for leads, you've overcorrected. Loosen the behavioral gate before you touch the firmographic filters, since fit is harder to fix than timing.
How do we stop sales from rejecting qualified leads?
Three things. First, let sales help write the definition so they own it. Second, attach the qualifying evidence to every handed-off lead so reps can see exactly why it qualified. Third, build a rejection loop with reason codes and review it monthly, so rejections tighten the definition instead of just breeding resentment. Rejection stops being a problem when it becomes feedback that visibly improves the leads reps get next month.
If your SQL definition currently lives in three different heads and none of them agree, that's the fix worth making first. Book a Revenue Systems Audit and we'll map your qualification gaps and show you how to codify a handoff both teams will actually accept.