Sales qualified lead (SQL): definition, criteria and metrics

What is a sales qualified lead (SQL)?

A sales qualified lead (SQL) is a prospect that a salesperson has reviewed against agreed criteria and accepted as ready for a direct sales conversation. The review usually checks two things: the prospect fits your ideal customer profile, and the prospect has shown real buying intent — a demo request, a pricing question, a reply to outreach. Salesforce's SQL guide draws the same line: a lead becomes an SQL once sales has vetted it and accepted it as ready for the next step in the pipeline (Salesforce).

An SQL sits between a raw lead and an opportunity. It is not yet a deal: no value, stage or close date is attached. It is a person or account that sales has agreed to spend time on. That acceptance is the whole point of the term — without a salesperson's confirmation, a promising lead is still just a lead. Some teams qualify leads by product usage instead of conversations; those are product qualified leads, a separate path with its own criteria.

How an SQL differs from an MQL

A marketing qualified lead (MQL) is a prospect marketing has scored as likely to buy — based on fit and behavior such as downloads, page visits or email clicks — but sales has not yet accepted it. An SQL is the same kind of prospect after a salesperson has confirmed fit and intent and agreed to pursue it. The difference is who makes the call and what evidence they use: marketing judges signals, sales judges conversations. The handoff between the two stages, and the disputes it causes, are covered in MQL vs SQL; this page stays on the SQL side.

Qualification frameworks: BANT, CHAMP, MEDDIC

Teams disagree about what "qualified" means until they write it down. Three frameworks are common; pick one, adapt it, and keep the criteria short enough that an SDR can apply them on a call.

• BANT checks Budget, Authority, Need and Timing: can the prospect pay, who signs, what problem are they solving, and when do they want it solved. It is the classic starting point for small and mid-size sales teams (HubSpot).
• CHAMP reorders the same ideas as CHallenges, Authority, Money and Prioritization — it starts with the prospect's problem instead of their budget, which suits consultative selling where the pain is not yet obvious (Revenue.io).
• MEDDIC is a six-part checklist for complex enterprise deals: Metrics, Economic buyer, Decision criteria, Decision process, Identify pain, Champion. It is heavier than BANT and pays off when deals involve committees and long cycles (MEDDIC Academy).

A framework is a checklist, not a score. Whatever you choose, the output is the same: a salesperson can say why this lead is worth pursuing, and the next person can check the reasoning.

Who confirms an SQL?

Sales confirms SQLs — not marketing, and not a form fill. In most teams an SDR (sales development rep) runs the first qualification call, and an AE (account executive) accepts the lead into their pipeline. Microsoft's Dynamics 365 training describes the same flow: a salesperson qualifies the lead against the organization's criteria, and only then does it move toward an opportunity (Microsoft Learn).

Three habits keep the label honest:

1. Write the criteria down. Fit plus intent, in plain language, with examples of what does not count.
2. Record the decision in the CRM. Who confirmed it, when, and against which criteria. The CRM is where qualification and scoring live; a spreadsheet label is not an SQL.
3. Let marketing supply evidence, not verdicts. Source, UTM, pages visited and chat transcripts help the SDR decide, but marketing does not mark its own leads as SQLs.

SQL-to-opportunity rate and average time-to-close

Two numbers tell you whether your SQL definition is working. Both are simple ratios you can recompute from a CRM export.

SQL-to-opportunity rate = opportunities ÷ SQLs × 100%. Count the SQLs confirmed in a period, then count how many became opportunities — a deal with value and stage attached. A low rate means sales is accepting leads it cannot work; a very high rate can mean the bar is so strict that only sure things get through.

Average time-to-close (average sales cycle) = sum of days from SQL confirmation to closed-won ÷ number of closed-won deals. Use the SQL confirmation date, not the first form fill, so the number measures the sales cycle you actually control.

Sample data: one quarter, 80 SQLs confirmed, 28 became opportunities, 10 of those closed-won. Days from SQL to closed-won for the 10 deals: 24, 31, 18, 45, 27, 38, 22, 51, 33, 41.

One caveat: the 33-day average only includes deals that closed. The 18 opportunities still open — especially the slow ones — are excluded, so the true cycle is usually longer. Track the same two rates quarter over quarter; your own trend is more useful than any published benchmark. For the wider funnel math, see lead conversion rate.

When SQLs are too few or too many

The count itself is a diagnostic. Before you change the definition, check the pipeline around it.

Too few SQLs. Work backwards: Are criteria too strict — for example, requiring budget confirmation before any conversation? Are MQLs low quality, with the wrong source or persona? Is the handoff broken, so SDRs never call marketing's leads? Is the source mix shifting toward channels that never fit? Fix the stage that is actually leaking before you loosen the SQL bar.

Too many SQLs. Check the opposite failures: criteria too loose, so every demo request counts; sales marking leads as SQL to hit a quota; a low SQL-to-opportunity rate that nobody reviews. A flood of SQLs that never become opportunities is worse than a smaller, honest list — it hides the real conversion problem and burns SDR time.

Common mistakes

• Treating every demo request as an SQL. A form fill is intent, not qualification. Someone still has to confirm fit and timing.
• Letting marketing label SQLs. When the team that generates leads also grades them, the count inflates and sales stops trusting it.
• Counting SQLs without counting opportunities. Volume feels like progress; the SQL-to-opportunity rate is the number that tells you if qualification works.
• Averaging time-to-close over closed deals only. Still-open long deals drop out of the average, so the cycle looks shorter than it is. Say which deals the average covers.
• Changing criteria without telling anyone. If the bar moves mid-quarter, the rate moves for reasons that have nothing to do with lead quality.

How to see lead evidence in TapCub

Confirming an SQL is a human judgment made in your CRM; TapCub is not a CRM and does not score leads. It answers the three questions a rep asks before accepting a lead.

• Where did they come from? Web analytics › Sources shows the channel, source and UTM campaign behind the visit, so an SDR knows whether the lead came from a paid campaign, a search or a referral.
• What did they do? For identified users (via tapcub.login), the profile in All-platform analytics › Users › People shows a day-by-day timeline of events: pages, demo requests, pricing visits. Fit and intent get judged on actions, which is what the "need" and "timing" parts of BANT-style frameworks ask for.
• What did they say? If they chatted, Live chat › Inbox keeps the conversation next to their current page, source and last two days of browsing, and View in analytics opens the visitor profile. Chat and analytics share one visitor ID, so nothing has to be matched by hand.
• Which actions predict SQLs? Mark the actions that tend to precede acceptance, such as a demo request, as conversions in Web analytics › Goals, and compare their rate by campaign when SQLs are too few or too many.

Sources

• Salesforce, Sales qualified lead: definition and qualification steps.
• Microsoft Learn, Lead to opportunity process (Dynamics 365).
• HubSpot, BANT sales qualification framework.
• Revenue.io, What is CHAMP?.
• MEDDIC Academy, MEDDIC sales methodology checklist.