What Is a Sales Qualified Lead (SQL)?
A sales qualified lead (SQL) is a prospect that the sales team has evaluated and confirmed as meeting specific qualification criteria — making them worth active pursuit as a sales opportunity. SQLs go into your CRM pipeline as open opportunities with an associated ACV estimate and expected close date.
The SQL designation matters because it represents the boundary between "potential buyer" (MQL) and "active sales opportunity" (SQL). Everything before SQL is marketing's domain — generating and nurturing interest. Everything at and after SQL is sales' domain — developing and closing the opportunity.
For a detailed look at the MQL-to-SQL conversion rate and what drives it, see our MQL to SQL conversion rate guide.
SQL vs. MQL: The Key Distinction
| Dimension | MQL | SQL |
|---|---|---|
| Who creates it | Marketing automation (rule-based) | Sales rep (human judgment) |
| Basis | Firmographic fit + behavioral signals | Confirmed qualification criteria |
| Confirmation | Not yet confirmed by sales | Sales rep has spoken with or reviewed the lead |
| CRM stage | Contact/Lead record | Open Opportunity with ACV estimate |
| Accountability | Marketing (generated the MQL) | Sales (owns the opportunity) |
The Four SQL Qualification Criteria
Despite the variations across qualification frameworks (BANT, MEDDIC, SPICED), the core criteria that make a lead an SQL are consistent across most B2B SaaS companies:
1. ICP Fit
The company matches your ideal customer profile — the right size, industry, geography, and stage. A lead that doesn't meet ICP criteria should not become an SQL regardless of how much they engage with your content. ICP fit is a necessary condition, not just a scoring input.
2. Identified Problem
The prospect has a specific problem that your product solves — and they've acknowledged it in conversation or through their booking behavior (e.g., specifically requesting a demo of the routing feature, not just the product generally). "General curiosity" is not a qualifying problem. "We're losing inbound leads because they're sitting unassigned in our CRM for 48 hours" is a qualifying problem.
3. Authority or Path to Authority
The contact you're speaking with either has decision-making authority or has identified and agreed to bring the decision-maker into the evaluation process. A champion without a decision-maker is still worth pursuing, but they should not be counted as an SQL until you have a confirmed path to the economic buyer.
4. Timeline or Trigger
There is an identified timeline — a quarter they want to implement by, a pain that's becoming urgent, or a business event (new hire, fund raise, product launch) that creates urgency. "We'll get to this eventually" is not a qualifying timeline. "We're scaling our inbound program in Q2 and need this in place before that ramp" is a qualifying timeline.
Common SQL Qualification Frameworks
BANT
Budget, Authority, Need, Timeline. The classic framework. Simple and widely understood. The limitation: "Budget" is often not confirmed until late in the sales process — requiring confirmed budget to create an SQL can miss early-stage deals that are worth pursuing. Many modern teams use BANT but remove "confirmed budget" as a strict gate.
MEDDIC
Metrics, Economic Buyer, Decision Criteria, Decision Process, Identify Pain, Champion. The most comprehensive framework — popular at enterprise-oriented companies. MEDDIC is thorough but can slow SDR handoff to AE because not all criteria can be confirmed in a first qualifying conversation.
SPICED
Situation, Pain, Impact, Critical Event, Decision. A modern framework that emphasizes the business impact of the pain (not just its existence) and the critical event that creates urgency. SPICED produces higher-quality opportunities because it forces documentation of why the prospect cares and why they'd buy now.
Simplified B2B SaaS Framework (Recommended for Early Stage)
For companies under Series B, a simplified framework is more practical than MEDDIC:
- Does the company fit our ICP? (size, industry, geography)
- Does the contact have a specific problem our product solves?
- Can they make or influence the buying decision?
- Is there a timeline or urgency driver?
If yes to all four: SQL. If yes to three: worth one more discovery touchpoint. If yes to two or fewer: return to nurture or disqualify.
How to Define SQL Criteria Across Your Team
The most common SQL problem: every rep has a different mental model of what an SQL is. Rep A creates SQLs after a single 15-minute call. Rep B requires multiple conversations and confirmed budget before creating an SQL. The result: your pipeline forecast is unreliable because the pipeline composition is inconsistent.
Fix: write down your SQL criteria in a single document and require reps to document which criteria were met when they create an SQL in the CRM. Add a required field in Salesforce or HubSpot: "Qualifying criteria met (check all that apply)." This forces consistency and creates data for later analysis.
How to Qualify Faster
Speed and quality in SQL qualification are not in conflict — with the right approach, you can qualify faster without degrading quality.
Improve Routing First
If leads reach the wrong rep, the first qualification call is spent determining the right person to handle the opportunity — not actually qualifying. Routing improvements that put the right rep on each lead from the start are the most direct path to faster, better qualification. See our guide on MQL routing.
Pre-Qualify With Form Data
Collect qualification data before the first call via your demo request form. Ask about company size, current tool setup, and what triggered their interest. When the rep reviews the lead before the call, they already know which qualification criteria are likely met and which need confirmation.
Standardize Discovery Questions
Give every rep the same set of discovery questions for a first qualification call — one question per SQL criterion. The rep learns exactly what they need to create or reject an SQL in the first 10 minutes of the call. No ambiguity, no drift.
Set a Qualification SLA
Every MQL should be dispositioned (accepted as SQL or rejected with a reason code) within X business days of assignment. Standard target: 2 business days for inbound MQLs. An undispositioned MQL that sits for a week is pipeline signal wasted.
Get the right lead to the right rep — and qualify faster.
Lead Dispatcher routes every inbound MQL to the rep most likely to convert it, instantly. Qualified leads reach the right rep before intent decays.
Book a DemoFrequently Asked Questions
What is a sales qualified lead (SQL)?
A sales qualified lead is a prospect the sales team has evaluated and confirmed meets specific qualification criteria — ICP fit, identified problem, authority or path to authority, and an identifiable timeline. SQLs become active pipeline opportunities.
What is the difference between an MQL and an SQL?
An MQL is identified by marketing automation based on attributes and behavior. An SQL is confirmed by a sales rep based on qualification criteria. The MQL-to-SQL transition is the primary marketing-to-sales handoff and the most commonly measured conversion metric between the two teams.
What are the most common SQL qualification frameworks?
BANT (Budget, Authority, Need, Timeline), MEDDIC (Metrics, Economic Buyer, Decision Criteria, Decision Process, Identify Pain, Champion), and SPICED (Situation, Pain, Impact, Critical Event, Decision). Most B2B SaaS teams use a simplified version of one.
When does an MQL become an SQL?
An MQL becomes an SQL when a sales rep confirms: ICP fit, an identified problem the product solves, authority or path to authority, and a timeline or urgency driver. This is typically confirmed in a qualification conversation or through review of pre-qualification form data.
How do you qualify leads faster without sacrificing quality?
Improve routing so the right rep handles each lead, use pre-qualification forms to collect data before the first call, standardize discovery questions, and set a disposition SLA so every MQL is accepted or rejected within a defined time window.