MQL vs SQL: Definitions, Differences, and How to Define Both

Most B2B funnels don’t leak because the MQL and SQL definitions are wrong. They leak because marketing and sales never wrote them down together. To be clear: SQL here means sales qualified lead, not the database query language. This guide gives you working definitions, a side-by-side comparison, and a framework for drafting both in your own funnel so the handoff stops being an argument.

MQL vs SQL: Quick Comparison

An MQL is an ICP-fit contact who has passed marketing’s engagement threshold; an SQL is a lead sales has qualified against documented criteria and committed to work. MQL is owned by marketing; SQL is owned by sales. The table below compares both across definition, signals, owner, exit criteria, metric, CRM placement, conversion rate, and common pitfalls.

Dimension	MQL	SQL
Definition	An ICP-fit contact who has passed marketing’s qualification threshold but hasn’t been vetted by sales.	A lead sales has confirmed has real buying intent, documented need, and a next sales step.
Signals	Score threshold, form fills, high-intent content, demo-page visits, event attendance.	Demo booked, pricing conversation, budget/authority confirmed, discovery held, next meeting on calendar.
Owner	Marketing (demand gen, marketing ops).	Sales (SDR or AE, depending on motion).
Exit criteria	Routed to sales (becomes SAL or SQL) or recycled to nurture.	Converted to opportunity, disqualified, or recycled with a reason code.
Common metric	MQL volume and MQL→SQL conversion rate.	SQL→opportunity and SQL→closed-won conversion.
Where it lives in CRM	Lifecycle stage in HubSpot/Marketo; lead status `MQL`/`Accepted` in Salesforce.	Status `Qualified`; opportunity record created.
Typical conversion rate	13–15% median MQL→SQL for B2B SaaS, but 5–60% by lead source (RevOps Report, 2026).	15–25% SQL→closed-won, varies widely by ACV and motion.
Common pitfall	Defined by engagement alone, no fit filter.	Defined by “sales liked it,” no documented threshold.

What Is a Marketing Qualified Lead (MQL)?

A marketing qualified lead (MQL) is an ICP-fit contact who has shown enough buying signal — through fit and engagement combined — to justify sales attention, but hasn’t yet been vetted or accepted by sales. Marketing owns the definition, the scoring model, and the moment the lead crosses the threshold.

Typical signals that trigger MQL status:

ICP fit: company size, industry, geography, title. Engagement without fit doesn’t count.
Behavioral score threshold: a points total in the CRM. GitLab’s public handbook uses 100 points combining fit and behavior.
High-intent page visits: pricing, demo, product comparison, integrations.
Direct form fill on a demo, contact, or gated-asset page — the clearest single MQL signal there is.

Marketing owns the MQL end-to-end: ops sets the scoring rules, demand gen generates the signals, and the marketing qualified lead definition itself is marketing’s written contract with sales. Once a lead clears the threshold, it routes — usually to an SDR queue — and the next status is either Accepted (becoming a Sales Accepted Lead) or recycled back to nurture.

What Is a Sales Qualified Lead (SQL)?

A sales qualified lead (SQL) is a lead a rep has spoken to, qualified against documented criteria — fit, problem, timing, next step — and moved forward into active pipeline. It sits downstream of the MQL and the SAL (Sales Accepted Lead), and it’s the first funnel stage where the revenue number starts to matter.

Signals that distinguish an SQL from a still-engaged MQL:

Sales has had a real conversation — discovery, demo, or direct pricing — not email back-and-forth.
Documented need and timeline, not curiosity.
Identified buyer or a clear path to the buyer, not a blocked champion.
An explicit CRM stage transition with a reason code — not “sales liked it.”

Sales owns the SQL, and the owning rep is working against an acceptance SLA. GitLab’s public standard is 2 business hours on a routed MQL — the window to decide accept, reject, or recycle. After acceptance, the rep has to document why the lead qualifies as a sales qualified lead. Without that documentation, the record sits in limbo and breaks the downstream pipeline math.

MQL vs SQL: The Five Real Differences

MQL and SQL sit on the same funnel but measure different things: readiness, ownership, and accountability. The five differences below — intent signal, owner, metric type, feedback loop direction, and reversibility — are what determine whether a given lead gets prioritized, nurtured, recycled, or dropped.

Intent signal vs intent + fit signal

An MQL is mostly an intent signal: someone engaged enough to trip a threshold. An SQL layers fit and documented context on top — the rep confirmed the company looks right, the person is the buyer or near it, and the need is real. One engaged SMB intern can hit MQL easily; that same intern will never be an SQL. Teams that MQL on engagement alone then complain about low MQL→SQL conversion; the gate is too wide.

Owned by marketing vs owned by sales

Marketing owns the MQL definition, the scoring model, and the routing logic that fires when a lead qualifies. Sales owns the SQL — they decide whether the routed lead meets acceptance criteria, and they carry the number from there on. When one team owns both, the feedback loop disappears and definitions drift. Clear ownership is why the handoff is a contract, not a score comparison.

Engagement metric vs revenue metric

MQL volume is a lead-quality diagnostic — useful to marketing ops, less useful to the board. SQL volume and SQL→closed-won conversion are revenue metrics that forecast pipeline and set quota coverage. Teams that report MQLs as a board KPI are reporting leading activity, not revenue outcomes — the dashboard looks healthy while the pipeline shrinks.

Nurture loop vs pipeline forecast

An MQL that doesn’t progress feeds back into the nurture engine — the scoring model learns, the campaigns retune, the lead stays warm for the next quarter. An SQL that doesn’t progress has to be closed-lost with a reason code or recycled with explicit next steps. MQL is a loop; SQL is a commitment to a forecasted deal. Mixing the two breaks both systems.

Reversible vs (mostly) terminal

An MQL can fall back to a lower status if it goes cold, gets reclassified, or turns out to be bad data — marketing can bring it back later. An SQL rarely reverts cleanly: once sales has accepted it, the rep has to disposition it — won, lost, disqualified, or recycled with a documented reason. That’s what makes SQL volume trustworthy enough to forecast against.

How to Define MQL and SQL in Your Own Funnel

Borrowing someone else’s definition is why most MQL/SQL models break. Build your own from five inputs: fit criteria, behavioral threshold, score threshold, exclusion rules, and exit criteria. Then stress-test against three motions — sales-led, product-led, and account-based — to see where the definition holds and where it needs to flex.

MQL definition checklist

Fit criteria: ICP firmographics and persona — company size, industry, region, buyer role. Reject outside ICP even with strong engagement.
Behavioral threshold: the combination of signals that qualifies — a minimum number of high-intent actions in a rolling window.
Score threshold: the number from your B2B lead scoring model that trips routing. GitLab uses 100 points; yours might be 50.
Exclusion rules: students, competitors, free-mail domains, duplicates, active opportunities, current customers.
Exit criteria: write the exit states before you turn routing on — SAL, Recycle, or Disqualified.

SQL definition checklist

Fit criteria: the same ICP gate, plus a named buyer or a clear path to one.
Behavioral threshold: a real conversation — discovery, demo, or pricing — not email ping-pong.
Qualification threshold: framework-backed (BANT, MEDDIC, CHAMP). Document which boxes are ticked, not “rep confirmed interest.”
Exclusion rules: no authority, no timeline, no budget signal, or active opportunity conflict.
Exit criteria: opportunity created, disqualified with reason code, or recycled with an explicit requalification trigger.

Example 1 — Sales-led mid-market SaaS (adapted from GitLab’s public model)

GitLab’s public handbook runs a 100-point MQL threshold with a 2-business-hour routing SLA and explicit lifecycle statuses: Accepted, Qualifying, Qualified, Disqualified, Recycle, Bad Data, Ineligible. GitLab isn’t mid-market — adapt down:

MQL: 50-point threshold. Demo form, pricing visit, or webinar attendance plus a second touch.
SAL: SDR accepts within 4 business hours if contact info is valid and the account is ICP.
SQL: Discovery call held, pain documented, buyer confirmed, next meeting booked.
Recycle/disqualify: Reject reasons — no fit, no authority, not in-market, bad data, active customer — each map to a specific next status.

Example 2 — Product-led SaaS (PQL-first, MQL secondary)

For a self-serve plus sales-assist motion, ProductLed’s PQL framing applies: PQL goes before MQL. The widely-cited Slack example — 2,000 messages sent in a workspace — is a meaningful activation threshold, not a signup. Treat ProductLed’s examples as a secondary source, not Slack’s current internal documentation.

PQL: workspace hits activation threshold, business email domain, three or more active users.
MQL (secondary): non-user contact — pricing visit, high-intent content, partner webinar — from an ICP account.
SQL: PQL account shows expansion intent (admin on pricing, multi-user seat request), or a non-user MQL books a demo.
Decision rule: if a user is active in-product, PQL outranks MQL. If not, MQL still matters for buying-committee members who never touch the product.

Example 3 — ABM / enterprise (account-level qualification)

6sense and GitLab qualify accounts, not leads. 6sense’s default 6QA logic: Decision or Purchase buying stage in the last 60 days, Strong or Moderate profile fit, no opportunity created or lost in the last 90 days, no qualification in the last 60 days.

MQA (replaces MQL): 6QA status — fit plus in-market buying stage — with at least one engaged contact.
SAL: BDR accepts the account, confirms reachable contacts, and logs a reason code like “Decision-stage 6QA” or “integration intent surge.”
SQL: sales confirms an active project, named stakeholder, pain, and next step. The record is stored as an opportunity even though multiple contacts are involved.
Recycle: cool-off after a lost or created opportunity; requalify on a new buying-stage or intent surge.

The MQL → SQL Handoff (Where Most Funnels Leak)

The handoff between marketing and sales isn’t a status change — it’s a contract. Marketing sends; sales accepts or rejects within a set SLA; every reject has a documented reason; every recycle has a re-entry trigger. Without those four clauses, MQL→SQL conversion is measurement theater and sales alignment is a truce, not a system.

Diagram Of The Mql To Sal To Sql Handoff Flow With A Recycle Loop Back To Nurture And Reject Reason Codes — The Four Clauses Visualized: Marketing Routes The Mql, Sales Accepts Or Rejects It As An Sal Within The Sla Window, Recycled Leads Loop Back To Nurture With A Requalification Trigger, And The Rest Move On To Sql.

SLA on first sales touch. GitLab’s public standard is 2 business hours from routing to accept or reject. Mid-market teams usually land between 4 and 24 business hours. Any longer and the lead is cold.

Valid reject reasons. A short, closed list: no fit, no authority, bad data, not in-market, duplicate, active customer, vendor or competitor. Rejects without one of these codes go back in the queue.

Recycle loop. Not every reject is permanent. “Not in-market” or “timing wrong” should go back to nurture with a requalification trigger — new funding round, new hire, renewed intent signal. GitLab’s lifecycle distinguishes Recycle from Disqualified for exactly this reason.

SAL as the audit receipt. The Sales Accepted Lead status isn’t an extra acronym — it’s the line that separates marketing’s accountability (MQL→SAL conversion) from sales’ accountability (SAL→SQL conversion). When SAL is missing, every missed target becomes a blame argument. When it’s explicit, you know which side of the handoff needs fixing.

Track MQL→SQL conversion rate by cohort, not calendar month — an MQL from March often doesn’t SQL until April, and same-period math hides the lag.

Where MQL and SQL Break Down in 2026

MQL→SQL still works for most sales-led B2B motions. But three shifts — PLG self-serve activation, account-based buying committees, and pre-form-fill intent data — make the linear lead-level funnel a bad map for at least a third of revenue teams. The fix isn’t to kill MQL; it’s to replace or supplement it where it actually breaks.

PLG: PQL often replaces MQL. If the product is self-serve and the buyer activates before talking to sales, marketing-engagement signals lag the product signal by weeks. ProductLed’s examples — Slack at 2,000 messages, Facebook at 7 friends added, Drift at 100 conversations — all fire before any MQL signal would. Decision rule: if your buyer personally uses the product, PQL first; MQL only for non-user stakeholders.

ABM: qualify accounts, not leads. 6sense’s 6QA treats account profile fit and buying-stage movement as the primary signal, with lead-level engagement as supporting evidence. A single engaged contact from an out-of-ICP account is noise; a Decision-stage in-market account with one engaged contact is signal. Forcing 6QA logic into a lead-level MQL definition loses the accuracy of account-level qualification.

Intent data: signal arrives before form fill. When a buying committee reads reviews on G2, attends competitor webinars, and researches pricing without touching your site, the MQL signal shows up last, not first. Treat third-party intent as an input to the MQL scoring model, not a bucket that bypasses it.

Should MQL still exist in your funnel? RevOps Co-op’s framing is the most useful take: MQL belongs as an internal signal for sales/marketing attention, not a board-level KPI. Keep it if non-product buyers still enter through content, events, or partners. Drop it if every buyer is a product user and PQL already captures them.

MQL vs SQL Conversion Rate Benchmarks

Directional benchmarks for MQL→SQL conversion cluster around 13–15% median for B2B SaaS, but the ranges are wider than any single “good” number suggests. Segment by lead source (demo requests convert 4–10x higher than outbound) and by motion (sales-led, PLG, ABM behave differently) — without segmentation, a blended benchmark tells you nothing actionable.

Two current sources give the cleanest directional picture, both with caveats.

RevOps Report (2026) — an operator/vendor source, not primary research — puts the median at 13–15% for B2B SaaS, with top-quartile teams at 20–30% and bottom-quartile at 5–8%. It segments by source: demo requests 40–60%, referrals 30–50%, paid search 15–25%, webinars/events 10–18%, gated inbound 8–15%, outbound 5–10%.

HubSpot’s 2025 benchmarks — HubSpot citing First Page Sage, so vendor citing vendor — land MQL→SQL at 13% for B2B SaaS, 11% for fintech, 13% for healthcare, and 21% for pharmaceuticals. Both sources corroborate the 13–15% B2B SaaS median, but neither is independent research. Use them as directional floors, not targets.

Measure by cohort, not month. An MQL created in March that SQLs in May counts against the March cohort. Same-period math — March MQLs divided by March SQLs — understates conversion when inbound is growing and overstates it when it’s declining. Our take on why MQL/PQL→SQL averages mislead walks through the cohort logic.

Qualification Frameworks That Sit on Top of MQL/SQL

MQL and SQL describe funnel state; qualification frameworks describe how sales confirms SQL. The four common ones — BANT, MEDDIC, CHAMP, GPCT — aren’t interchangeable. Pick based on deal complexity and buying-committee size, not on whichever framework the last VP of Sales brought from their previous company.

BANT (Budget, Authority, Need, Timeline) — IBM-era, best for transactional sales with single decision-makers.
MEDDIC (Metrics, Economic Buyer, Decision Criteria, Decision Process, Identify Pain, Champion) — enterprise, multi-stakeholder, complex deals. Too heavy for SMB velocity.
CHAMP (Challenges, Authority, Money, Prioritization) — inverts BANT by leading with the buyer’s problem. Good for consultative sales and early-stage buyers.
GPCT (Goals, Plans, Challenges, Timeline) — HubSpot-developed, best for longer discovery with content-educated buyers.

Whichever framework sales uses, map it to the SQL definition explicitly. “MEDDIC-qualified” is a meaningful SQL status; “rep thinks it’s qualified” isn’t.

Common Mistakes When Defining MQL and SQL

Most MQL/SQL problems aren’t edge cases — they’re the same five design errors repeated across teams: defining MQL by source alone, no agreed reject criteria, an undocumented SQL threshold, no recycle path, and definitions that never get revisited. Each one is fixable in an afternoon, but only if you name it first.

Defining MQL by lead source alone. “All demo requests are MQLs” ignores fit. A student from a non-ICP account requesting a demo should fail the gate when the scoring model weights fit properly.
No agreed reject criteria. When sales rejects without a reason code, marketing can’t recalibrate the model. GitLab’s lifecycle distinguishes Disqualified, Recycle, Bad Data, and Ineligible for exactly this reason.
“Sales liked it” as the SQL threshold. Subjective SQL means MQL→SQL conversion measures rep mood, not lead quality. Document the framework (BANT, MEDDIC, CHAMP) and the exit criteria — or stop calling it qualification.
No recycle path back to nurture. “Not ready now” should route to Recycle with a requalification trigger, not disappear. Teams without a recycle flow quietly lose 20–30% of otherwise usable leads.
Definitions that never get revisited. ICP drifts, buying patterns shift, scoring weights decay. If your MQL and SQL definitions haven’t changed in 18 months, at least one is probably wrong.

Key Takeaways

MQL is marketing’s contract with sales; SQL is sales’ contract with the forecast. Both need written definitions.
The handoff is a contract with four clauses: SLA, reject reasons, recycle triggers, and SAL as the audit receipt.
Sales-led, PLG, and ABM motions need different definitions. Borrowed definitions break at the first hard edge.
Benchmarks are directional: 13–15% MQL→SQL median for B2B SaaS, with 5–60% swings by source.
If MQL is reported as a board-level KPI, it’s measuring activity, not revenue.

Once MQL and SQL are defined, the next decision is which scoring model decides who hits each bar. Start with our B2B lead scoring framework — the model that makes the thresholds objective instead of political.