MQL vs SQL: What's the Difference (and How to Route Each in Salesforce)

Ask a marketer and a sales rep to define "qualified lead" and you'll usually get two different answers - which is exactly how a hand-raiser ends up in a nurture sequence while a whitepaper downloader gets three cold calls before lunch.

The MQL vs SQL distinction exists to prevent that. But the acronyms only earn their keep when two things are true: the criteria behind them are written down and shared, and your CRM does something different with each. Most articles cover the first half and wave at the second. This one covers both - what the terms mean, how the handoff between them should work, and how to route each stage in Salesforce so the labels actually change what happens next.

What is an MQL (Marketing Qualified Lead)?

A Marketing Qualified Lead (MQL) is a lead that has engaged with your marketing enough to signal genuine interest - meeting a defined threshold of fit and behaviour - but hasn't yet been vetted for a sales conversation.

MQLs are identified by marketing, usually through a lead scoring model that combines two dimensions:

• Fit (demographic and firmographic): job title, company size, industry, region - does this person look like your buyer?
• Behaviour (engagement): page visits, content downloads, webinar attendance, email engagement - is this person acting like a buyer?

A lead crosses into MQL territory when their combined score clears a threshold your team has agreed on. The key word is agreed - an MQL definition that lives only in the marketing automation platform, unseen by sales, isn't a definition. It's a rumour.

Typical MQL signals: downloaded a comparison guide, attended a webinar, visited the pricing page twice, matches your ICP on title and company size.

What is an SQL (Sales Qualified Lead)?

A Sales Qualified Lead (SQL) is a lead that has been vetted - by a human or against explicit criteria - and confirmed as ready for a direct sales conversation.

Where the MQL threshold measures interest, SQL qualification measures intent and viability. Most teams check some version of budget, authority, need and timeline (BANT) or a modern equivalent like MEDDIC. The questions behind the acronyms are the same:

• Is there a real problem we solve?
• Is this the person (or path to the person) who can buy?
• Is there budget and a timeframe?

Two routes into SQL status matter here, because they route differently later:

1. Promoted MQLs - leads nurtured and qualified by an SDR until they clear the bar.
2. Hand-raisers - demo requests, "contact sales" form fills, pricing enquiries. These often skip the MQL stage entirely and should be treated as SQLs (or at minimum, priority qualification) from the moment they arrive.

That second group is where rigid funnels fail. Forcing a demo request through an MQL nurture track because "that's the process" is how you lose deals to whoever called back first.

MQL vs SQL: the differences at a glance.

What it signals. An MQL signals interest and fit. An SQL signals intent and readiness to buy.

Who qualifies it. MQLs are qualified by marketing, usually through a scoring model. SQLs are qualified by sales or an SDR, through human vetting or explicit criteria.

Typical triggers. MQLs come from content downloads, webinar attendance, email engagement, and ICP fit. SQLs come from a demo request, a discovery call, or a confirmed budget and timeline.

The right response. MQLs should be nurtured, educated, and qualified further. SQLs need direct sales outreach, fast.

Response-time expectation. Hours to days for an MQL; minutes for an SQL.

Ownership in Salesforce. MQLs sit with marketing nurture or in an SDR queue. SQLs go to a named AE, assigned instantly.

Conversion metric. For MQLs, track MQL→SQL rate. For SQLs, track SQL→Opportunity rate.

Some teams add a stage in between: the SAL (Sales Accepted Lead) - an MQL that sales has formally accepted for qualification but not yet confirmed as an SQL. If marketing and sales argue about lead quality, an explicit acceptance stage gives you the data to settle it: you can see exactly where leads stall and who's holding them.

The handoff: where MQL vs SQL actually gets decided.

The definitions above are the easy part. The value is in the handoff - and the handoff is a process, not a moment. Four things make it work:

1. A written, shared definition.

Marketing and sales agree - in a document, not a meeting - on the exact criteria for MQL and SQL. Score thresholds, disqualifiers, and the hand-raiser fast lane. Review it quarterly. When your MQL-to-SQL conversion rate drifts, this document is the first thing you re-open.

2. A service-level agreement on both sides.

Marketing commits to a quality bar; sales commits to a response window. A common structure: every SQL gets a first touch within 15 minutes during business hours; every accepted MQL gets SDR outreach within one business day. Without the SLA, the handoff is a suggestion.

3. A feedback loop.

Sales must be able to send leads back - with a reason. "Not qualified: no budget" and "Not qualified: wrong persona" are different signals, and each should tune the scoring model. A rejection reason field costs you one picklist; not having it costs you your model's accuracy.

4. Routing that changes with the label.

This is the part most teams miss. If an MQL and an SQL are assigned the same way - same queue, same rotation, same (lack of) urgency - then the qualification work changes nothing. The label has to drive the routing.

How to route MQLs in Salesforce.

MQLs need managed patience: consistent ownership, timely qualification, and no pressure tactics. In practice:

• Route to an SDR qualification rotation, not a static queue. A round robin rotation across your SDR team keeps workloads fair and makes ownership unambiguous. Leads sitting in a shared queue get cherry-picked or ignored - usually both, depending on the lead.
• Segment the rotation by fit. Enterprise-fit MQLs to your enterprise SDRs; SMB to the high-velocity pod. Use lead attributes and territory logic so the right kind of SDR qualifies each lead.
• Set a soft SLA. One business day to first outreach is a sensible default. Slower than that and engagement decays; the MQL you scored on Tuesday is a colder lead by Friday.
• Keep account context attached. If the MQL belongs to an existing customer or a named ABM account, match the lead to the account and route it to the account owner instead of the general rotation. Nothing undermines an account relationship faster than a stranger from your own company cold-calling into it.

How to route SQLs in Salesforce.

SQLs need speed with precision. The research on response time is brutal: contact within five minutes dramatically outperforms contact within thirty, and the first vendor to respond wins a disproportionate share of deals. Your routing has to deliver:

• Instant assignment to a named AE. No queues, no triage step, no "the manager assigns them each morning." The moment a lead qualifies - or a hand-raiser arrives - assignment fires automatically.
• Availability-aware logic. Instant assignment to a rep who's on PTO is worse than slow assignment to one who's online. Routing must check real-time availability, working hours and capacity before it picks an owner - the full playbook on speed-to-lead covers this in depth.
• A hard SLA with auto-reassignment. Give the assigned AE a first-action window (five to fifteen minutes is typical for hand-raisers). If it lapses, the system pulls the lead back and re-routes to the next available rep. Speed isn't a value you hope for; it's a failsafe you configure.
• A booking path that skips the back-and-forth. The fastest SQL handoff is one where the prospect books the meeting themselves. Pairing routing with Salesforce-native scheduling means a demo request can go from form fill to confirmed calendar slot in one motion.

Native Salesforce vs dedicated routing for the MQL/SQL handoff.

Salesforce's built-in tools can express the basics. Lead Assignment Rules can send leads with different statuses to different queues, and Flow can trigger assignment on a status change. For a small team with simple criteria, start there.

The cracks appear exactly where the MQL/SQL distinction lives:

• Assignment Rules can't run a round robin, check availability, or enforce an SLA - the three things SQL routing depends on.
• Flow can be built to approximate them, but the result is admin-owned automation that gets riskier to touch every time your team, territories or thresholds change.
• Neither gives managers a way to adjust rotations or pause a rep without a ticket.

That's the gap Distribution Engine fills - natively, inside Salesforce, with no code:

• Status-driven routing: MQLs flow into weighted SDR rotations; SQLs and hand-raisers trigger instant, availability-checked assignment to AEs.
• SLA timers with auto-reassignment: untouched SQLs get pulled back and re-routed before they cool.
• Lead-to-account matching: leads from known accounts route to the owner, protecting your ABM motion.
• A full audit log: when marketing asks what happened to the MQLs they handed over, the answer is a report, not an argument.

The bottom line: labels only matter if routing changes.

MQL vs SQL isn't really a vocabulary question - it's an operations question. The teams that get value from the distinction are the ones where a lead crossing from one stage to the next triggers something concrete: a different owner, a different SLA, a different play. Define the stages together, write the handoff down, and then make Salesforce enforce it - so an interested lead gets nurtured, a ready lead gets called in minutes, and nobody's good work dies in a queue.

Fancy giving Distribution Engine a try?

You can trial Distribution Engine for free, or get in touch if you'd prefer to chat.

Free trial · Talk to us

Related articles

• What Is Lead Scoring? A Complete Guide to Models, Thresholds & B2B Examples
• Understanding Lead Assignment In Salesforce: Core Concepts & Best Practices
• 10 Best Practices to Improve Speed to Lead in Salesforce
• The 2026 Guide to Salesforce Lead Routing: Building Systems That Scale

‍

Frequently asked questions.

What is the difference between MQL and SQL?

An MQL (Marketing Qualified Lead) has shown enough interest and fit - through engagement like content downloads and webinar attendance - to be worth nurturing and qualifying. An SQL (Sales Qualified Lead) has been vetted against explicit criteria (such as budget, authority, need and timeline) and confirmed as ready for a direct sales conversation. MQL measures interest; SQL measures intent.

What comes first, MQL or SQL?

MQL comes first in the standard funnel: visitor → lead → MQL → SQL → opportunity → customer. However, hand-raisers - demo requests and "contact sales" enquiries - often skip the MQL stage and should be treated as sales-ready immediately rather than forced through a nurture track.

What is a good MQL-to-SQL conversion rate?

It varies significantly by industry, channel and how strictly you define each stage - commonly cited B2B ranges sit somewhere between 10% and 40%. The trend matters more than the number: a falling MQL-to-SQL rate usually signals drift between marketing's scoring criteria and sales' definition of "ready," and is your cue to revisit the shared definition, not to buy more traffic.

How do you route MQLs and SQLs differently in Salesforce?

Route MQLs into a fair SDR qualification rotation (round robin, segmented by territory or fit) with a soft SLA of about one business day. Route SQLs instantly to a named, available AE with a hard first-touch SLA - typically 5–15 minutes - and auto-reassignment if the window lapses. Native Assignment Rules can separate the two by status, but rotations, availability checks and SLA enforcement require Flow builds or a dedicated routing tool like Distribution Engine.

What is a SAL (Sales Accepted Lead)?

A Sales Accepted Lead is an optional stage between MQL and SQL: a lead that sales has formally agreed to work but hasn't yet confirmed as qualified. Adding an explicit acceptance step creates accountability on both sides of the handoff and makes it easy to see where leads stall.

‍