What Is an SQL (Sales Qualified Lead)?
What an SQL actually means
An SQL is a lead that sales has examined, contacted, and judged to be a real opportunity worth working. The defining feature is acceptance by a human rep, not an automated score. Where an MQL signals "marketing thinks this person is interested," an SQL signals "a salesperson has verified there is a deal to chase here."
Why the distinction matters
The SQL stage is the contract line between marketing and sales. It separates interest (which marketing manufactures) from qualified demand (which sales validates). Counting SQLs accurately keeps both teams honest: marketing is measured on how many MQLs become SQLs, and sales is measured on how many SQLs become pipeline and revenue. Blurring the definition is the single most common cause of "marketing says it sent leads, sales says they were junk" friction.
SAL vs SQL: what's the difference?
A SAL (Sales Accepted Lead) confirms a rep agreed to follow up; an SQL confirms the rep followed up and found a qualified opportunity. SAL is an acceptance checkpoint, SQL is a qualification checkpoint. The lead passes through SAL on its way to becoming an SQL.
| Stage | Owner | What it confirms | Trigger |
|---|---|---|---|
| MQL | Marketing | Lead shows enough fit and intent to hand off | Score or behavior threshold met |
| SAL | Sales (acceptance) | A rep agrees the lead meets the bar and takes ownership | Rep accepts the routed lead |
| SQL | Sales (qualification) | After contact, a real, qualified opportunity exists | Rep confirms budget, need, fit and timeline |
Not every team uses the SAL stage, but it is valuable: it cleanly separates "did sales reject the handoff?" from "did sales work it but disqualify it?" Those are different problems. The first is a routing or quality issue, the second is a fit issue, and the SAL checkpoint lets you diagnose each.
What criteria qualify an SQL?
A lead becomes an SQL when a rep confirms it clears a qualification framework, most commonly a BANT-style check: Budget, Authority, Need and Timeline. The point is consistency: the same bar, applied by every rep, so the SQL count means the same thing across the team.
The BANT-style bar
- Budget: there is funding, or a realistic path to it, for a purchase in this range.
- Authority: the contact is a decision-maker or has direct access to one.
- Need: a genuine problem your product solves, not vague curiosity.
- Timeline: a workable window to buy, not "someday."
Beyond BANT
Many modern teams supplement or replace BANT with frameworks like MEDDIC or CHAMP, and layer in two extra filters: ICP fit (does the account match your ideal customer profile on size, industry and tech stack?) and buying intent (are they actively evaluating, not just researching?). Whatever the framework, write the SQL definition down and have sales and marketing sign off on it. A documented, mutually agreed bar is what makes the metric trustworthy.
How does the MQL-to-SQL handoff work?
The MQL-to-SQL handoff is the moment a marketing-qualified lead is routed to sales, accepted, contacted, and either promoted to SQL or returned with a reason. A clean handoff has clear routing rules, a fast follow-up SLA, and a feedback loop so disqualified leads sharpen marketing's targeting.
A workable handoff in five steps
- Define the bar together. Marketing and sales agree, in writing, what makes an MQL ready and what makes an SQL qualified.
- Route fast. When a lead hits MQL, assign it to the right rep automatically based on territory, segment or account ownership.
- Set an acceptance SLA. Reps accept (SAL) or reject within a fixed window, often same business day, so leads don't go cold.
- Qualify on contact. The rep works the lead against the agreed criteria and promotes it to SQL or disqualifies it with a coded reason.
- Close the loop. Disqualification reasons flow back to marketing to refine scoring, targeting and the MQL definition itself.
Watch the conversion rate at each step. If MQL-to-SQL is very low, the MQL bar is probably too loose or routing is too slow; if it is suspiciously high, the SQL bar may be too generous. The healthiest sign is a rejection feedback loop that is actually used. That is what turns the handoff from a hand-wave into a system.
Frequently asked questions
What is the difference between a SAL and an SQL?
A SAL (Sales Accepted Lead) is one sales has agreed to follow up on; it confirms the lead met the handoff bar and a rep took ownership. An SQL goes further: after a real conversation, the rep confirms a qualified opportunity worth active selling.
What criteria make a lead an SQL?
Most teams use a BANT-style bar: a confirmed budget, the authority or access to a decision-maker, a genuine need your product solves, and a workable timeline. Strong fit to your ideal customer profile and active buying intent round out the qualification before a rep marks a lead an SQL.
Who creates an SQL, marketing or sales?
Sales does. Marketing generates and qualifies MQLs, but only a sales rep can promote a lead to SQL because the status reflects a human conversation that confirms the opportunity is real. Marketing owns lead quality up to the handoff; sales owns qualification after it.
Is an SQL the same as an opportunity?
Not quite. An SQL is a qualified person sales is actively pursuing; an opportunity is the deal record that gets created once a clear buying process and potential value exist. Many teams convert an SQL into an opportunity the moment qualification holds up, so the line is often thin.
Last updated: 14 June 2026