SQL vs MQL — the difference (and how to move leads between them)

A marketing qualified lead is a prediction: this person's behaviour and attributes match the pattern of people who buy. A sales qualified lead is a verdict: a seller has examined this person and judged them worth working now. Prediction to verdict is the whole handoff, and it leaks because most teams write both definitions in adjectives rather than in conditions anyone can check. Both terms come from one framework with a date on it, and the firm that owns that framework has since said the first term should be retired.

Where the words MQL and SQL actually come from

They are not generic English. They are stage names from the SiriusDecisions Demand Waterfall, first launched in 2006 as a shared vocabulary so marketing and sales could argue about the same thing. The classic stages ran Inquiry, then Marketing Qualified Lead, then Sales Accepted Lead, then Sales Qualified Lead, then Close.

The middle stage is the one most teams drop and the one that carried the useful information. A sales accepted lead is a marketing-passed lead that sales has confirmed met the agreed criteria. Its output is an acceptance rate — the share of MQLs sales agrees were worth passing — and that single number is the only objective evidence about whether the MQL definition is any good. Drop the stage and you lose the feedback loop that keeps the definition honest.

SiriusDecisions was acquired by Forrester in 2019. Knowing that matters for the next section, because the criticism of the MQL is coming from inside the house.

Forrester says the MQL era should end — read that carefully

On 14 April 2022, Terry Flaherty, a Forrester VP and principal analyst, published a blog post whose position was blunt: "The MQL era is antiquated and needs to end immediately." Forrester's own B2B Revenue Waterfall guide describes the replacement as "a practical framework for shifting from managing individual leads to identifying, prioritizing, and advancing opportunities with connected buying groups", and the current waterfall was introduced in 2021 as the successor to the SiriusDecisions Demand Unit Waterfall.

The argument is structural rather than fashionable. If a purchase is decided by a group, scoring individuals produces two specific failures. Several members of one buying group each cross the MQL threshold and arrive as separate leads for one deal, so the pipeline double-counts. Meanwhile an important member — often the economic buyer, who reads nothing and downloads nothing — never crosses the threshold and is never passed, so the deal is worked without the person who signs it.

Now the part most commentary skips. Whether that argument applies to you is a question about your product, not about the framework. If your product is bought by one person with a card, buying groups are a solution to a problem you do not have, and an individual-level MQL is the right unit. If your product needs a security review, a budget holder and an end-user champion, the criticism lands squarely. Decide which you are before you redesign anything, and be honest that mid-market products often sit awkwardly in between.

The four things an SQL definition has to name to be enforceable

An unenforceable definition is worse than none, because it produces a metric everyone reports and nobody trusts. A definition is enforceable when a second person, given the same lead record, reaches the same verdict. That requires four things named explicitly.

• The fit conditions, as fields. Not "enterprise-ready" but company headcount, industry and country, each read from a specific field. If the field is empty on 40% of your records, the condition is not enforceable and you have a data problem before you have a definition problem.
• The need evidence, as an artefact. Not "has a pain point" but something written down: the sentence they wrote in the reply, the answer to the second discovery question, the tool they said they are replacing.
• The timing signal, with a boundary. Not "ready to buy" but a stated event with a date — a contract renewal, a project start, a budget cycle. "Sometime this year" is not a timing signal.
• The reachability fact. Whether you have a working way to contact the person who decides. A record with a perfect profile and no valid email is not a qualified lead, it is a research task.

Write those four and the acceptance argument stops being about vibes. It becomes a specific disagreement about a specific condition, which is a much shorter argument.

Where a qualification stage lives in a CRM that does not ship one

This trips up teams that expect a CRM to have an MQL field waiting. Most do not, and the reason is worth understanding rather than working around blindly.

In Autocloz a lead carries two different status concepts. The status column is constrained at the database level to nine values — new, queued, active, paused, replied, bounced, unsubscribed, converted and dnc. Read that list again: it is an outreach state machine. It says what the sending machinery has done to this person and what it is allowed to do next. It is not a qualification ladder, and forcing a qualification label into it would break the machinery that reads it.

Qualification has three legitimate homes instead.

The crm_status field. A separate free-form column whose options are configured per workspace through a status configuration table, with a key, a label, a colour and a sort order. This is where "MQL" and "SQL" belong if you want them as lead-level labels.

A tag. Cheaper to add, easier to combine, and it does not force a lead into exactly one qualification state. Useful when a lead can be marketing-qualified for one product line and not another.

A deal stage. Autocloz seeds a fresh workspace with a single pipeline called Sales Pipeline carrying six stages — Lead at 10% default probability, Qualified at 25%, Proposal at 50%, Negotiation at 75%, Won at 100% and Lost at 0%. If your SQL is really "worth forecasting", creating the deal at the qualification moment and letting the Qualified stage carry the meaning is cleaner than a parallel label, because it puts qualification and forecast in the same object. That pipeline, the custom statuses and the activity timeline all sit in the deals and CRM module.

One genuine gotcha to design around. Autocloz's workflow automation offers a condition.lead_status_is node, and it reads the engagement status, not crm_status. So a workflow cannot branch on an MQL label stored in crm_status. If you want automation to act on qualification, drive it from a tag, a score threshold or a deal-stage-changed trigger instead — all three of which the engine does support. Segmenting your CRM and lists covers how to keep those labels usable once there are more than a few.

A worked handoff, with the numbers that expose a broken bar

Illustrative numbers, chosen for clean arithmetic rather than measured from any customer.

A month produces 400 inquiries. The MQL bar passes 120. Sales accepts 66 of those as genuinely worth working, and 30 become sales qualified after a conversation. Twelve become opportunities.

Three ratios matter, and each one accuses a different part of the process.

Acceptance rate: 66 of 120, or 55%. Nearly half of what marketing passed, sales rejected on sight. That is a definition problem, not an effort problem, and the fix is to find the condition the rejected 54 share. Usually it is one field — wrong company size, wrong country, a job title that matched a substring.

MQL to SQL: 30 of 120, or 25%. Read this alongside the acceptance rate rather than alone. If acceptance were 90% and this were still 25%, the problem would be in the conversation rather than the bar.

SQL to opportunity: 12 of 30, or 40%. This one is about the seller's qualification skill and the offer's fit, and it is the ratio most improved by better discovery. Discovery call questions that qualify is the right place to start on it.

The diagnostic habit worth building: never quote one of these without the other two. A team celebrating a rising MQL count while acceptance falls is manufacturing work, and the total will look fine for two quarters before anyone notices.

Scoring is an input to the bar, not the bar itself

Lead scoring is where most teams try to make the bar automatic, and it half works.

Autocloz's scoring engine is deliberately narrow: one rule per row, no expression language, no boolean combinators. Seven rule types are supported — a regular-expression match on job title, an exact match on industry, a company size bucket, a country match, a tag match, recent engagement within a configurable number of days, and an email verification threshold. Each enabled rule contributes a delta, the deltas are summed onto the existing score, and the result is clamped to 0–100. The endpoint returns a breakdown listing every rule with whether it matched, sorted so the biggest contributor reads first.

Three practical consequences follow from that design, and they are the ones that bite.

A score compresses independent facts into one number, so it loses information. A lead at 70 because they are a perfect fit who has never engaged, and a lead at 70 because they are a poor fit who visits daily, are not the same prospect. Sort by score, then read the breakdown before acting.

The engine has no boolean logic, so a rule cannot express "senior title AND recent engagement". You approximate it by stacking two rules and picking a threshold that only both together can reach. That works, and it is worth knowing you are approximating rather than expressing.

The score does not maintain itself. Recalculation runs when it is asked to, from the recalculate endpoint behind the lead detail page's button. There is no periodic sweep, so an engagement-based rule that should decay as a lead goes quiet will not decay on its own. If your bar reads the score, something in your process has to trigger the recalculation, and a stale score silently promoting a cold lead is the failure this produces. What lead scoring is and a simple model to start with covers the model design; this is the operational caveat that goes with it. If you have not yet written down who you are qualifying for, the ideal customer profile generator is a faster starting point than a scoring rule.

Autocloz's free plan covers 5 users and 100,000 contacts with the scoring rules, custom statuses and deal pipeline all included — start free and write your bar as conditions before you write it as a number.

The five ways the handoff leaks, and how each is diagnosed

Leak one: the bar is written in adjectives. Diagnosis — hand the same ten records to two people and compare verdicts. Disagreement above about two in ten means the definition is not a definition.

Leak two: substring matching on job titles. A rule looking for "hr" matches "T-hr-eading", and a rule looking for "CHRO" misses "Chief Human Resources Officer". Diagnosis — export the titles your rule matched last month and read fifty of them. This is worth doing even when nothing seems wrong, because the failure is invisible in aggregate. Building a targeted B2B lead list goes deeper into why title filters misbehave.

Leak three: latency between qualification and contact. A lead qualified on Tuesday and called on Friday is a different lead. Diagnosis — measure the gap between the qualification timestamp and the first outbound activity, segmented by day of week, because Friday afternoon qualifications are where the gap hides.

Leak four: no feedback path. Sales rejects leads into a void, marketing never learns which ones, and the bar never improves. Diagnosis — if you cannot produce last month's rejection reasons in under five minutes, this leak is present.

Leak five: qualification applied to the wrong unit. You qualified a person when the purchase is decided by a committee, so the record moves forward without the budget holder attached. Diagnosis — for your last ten closed deals, count how many people were on the final call, and compare that to how many contacts were on the record at qualification. A wide gap is Forrester's argument arriving in your own data, and account-based marketing without a big stack is the response to it. Tools that centre the whole model on a scored contact record inherit this problem by design, which is the substance of the Autocloz and HubSpot comparison.

What changes when marketing is one person versus a team

At one marketer, the MQL is a formality. The same person sees the inquiry and works it, the definition lives in their head, and writing it down is only worth the trouble as preparation for the second hire. What is worth doing early is stamping provenance and keeping the raw inquiry data, because that is what you will need to write the definition later and it cannot be reconstructed afterwards.

At a team, three things change. The definition needs a version and a date, because otherwise nobody can tell whether last quarter's numbers were computed under the current bar. The acceptance rate needs an owner, because a metric that indicts two teams belongs to neither by default. And the bar needs a review cadence — quarterly is usually right — with a rule that it can only change on a review, so nobody quietly tightens it mid-quarter to make a number look better.

What Autocloz does not do for MQL and SQL

There is no built-in MQL stage, no marketing-automation nurture builder with a scoring canvas, and no lead-to-account matching that would let you roll a person's score up to their company automatically. Those are real absences, not oversights waiting for configuration.

The scoring engine has no boolean combinators, as described above, and no periodic recalculation sweep.

Workflow conditions read the engagement status rather than the free-form CRM status, so an MQL label stored there cannot drive a branch directly.

And nothing in the product decides your bar for you. It will store any definition you write and enforce any rule you configure, and it will do that just as faithfully for a bad definition as a good one. The judgement about what makes a lead worth a seller's afternoon stays with the people who have sat on those calls — the software's job is to make that judgement checkable, not to have it.