MQL vs SQL: what each stage means, who decides it, and how a lead crosses from marketing to sales.

Definition

The difference between MQL vs SQL is who made the judgment and on what evidence: marketing qualifies an MQL from data and behavior, sales qualifies an SQL from a conversation with the buyer.

An MQL, a marketing qualified lead, is a contact marketing believes is ready for a sales conversation. An SQL, a sales qualified lead, is a contact a sales rep has spoken to and confirmed is worth a sales process. HubSpot's default lifecycle stages use similar definitions, quoted in the CRM section below.

Everything else about the two terms is local. The stage names, the score that triggers them, the fields that have to be filled: those are decisions your company makes and writes down. This page is about the boundary between MQLs and SQLs, the handoff across it, and the document that settles it.

MQL vs SQL at a glance

Read the table as a chain of custody, not a ranking. An SQL is not a better lead than an MQL. It is the same lead after a person on the buyer's side said something that can be written down and checked.

The MQL side, briefly

An MQL is an opinion formed without the buyer. Marketing looks at who the contact is, which company they work for, and what they did, then decides that the combination clears an agreed bar. Adobe's Marketo Engage glossary describes MQLs as people whose behavior and characteristics meet your success criteria to be passed to sales.

Two halves matter equally. Fit comes from the ideal customer profile: industry, size, region, role. Engagement comes from the record: pages viewed, content downloaded, events attended, emails answered. Neither half alone makes an MQL.

The criteria, the scoring model, the threshold and the first message to an MQL are covered in depth on the MQL entry. This page picks the lead up at the moment marketing says yes, and follows it across the boundary to sales.

SQL: the sales qualified lead, and what makes one

A sales qualified lead is a lead that a sales rep has worked and found worth continuing. HubSpot's lifecycle documentation defines it as a contact or company that your sales team has qualified as a potential customer. The distinguishing feature is the source of the evidence.

Somebody at the buying company answered questions, and the answers were recorded. SQLs carry buying intent that a person stated, not intent the team inferred from clicks. That is why SQLs are fewer than MQLs, and why each one costs more rep time to produce.

Salesforce's Trailhead module on qualifying leads makes the same split. Scoring weeds out leads that are obviously a poor fit. Qualifying is the extra step that checks whether someone who looks great on paper is promising in reality, before reps put hours or weeks into a deal.

Trailhead's practical advice is to give reps a place in the CRM to record what qualification found, such as the customer's budget and whether the person has authority to decide. It even suggests requiring those fields before an opportunity moves forward.

The questions that fill them in, and the qualification frameworks teams use to ask them, are covered in how to qualify sales leads.

What an SQL sales qualified lead definition must contain

The five items below were chosen for this page as a workable minimum. Write them as criteria the rep can answer from one first conversation with a prospect, not as a form, and keep the list short enough that it gets filled in.

• Named need: a problem the buyer described in their own words, not a category you assigned.
• A person with a stake: someone who owns the problem, plus who else has to agree.
• Money reality: whether a budget exists, who controls it, or what would have to happen for one to exist.
• A timeline with a reason: a date attached to an event, such as a contract ending or a project starting.
• An agreed next step: a meeting already in the calendar, not an intention to follow up.

Those five map loosely onto budget, authority, need and timeline, often shortened to BANT, with a next step added. The letters matter less than the rule: if the rep cannot write each item down in the buyer's words, the lead is not an SQL yet.

Why the letters SQL mean two different things

In revenue teams, SQL is a sales qualified lead. In engineering, SQL is Structured Query Language, the language used to query databases. The collision is harmless until a report, a job posting or a meeting invite mixes the two audiences.

That is one reason the longer phrase "SQL sales qualified lead" exists at all. The extra words name the field the term belongs to, so a reader from marketing and a reader from data engineering land in the same place.

Write the words out on first use in any document that leaves your team. In dashboards, label the column "Sales qualified leads" rather than "SQLs". It costs nothing and removes a class of confusion that returns every time a new analyst joins the team.

Where MQLs and SQLs sit in the sales funnel

The funnel view maps the same boundary onto buyer intent. MQLs sit in the middle, where interest is forming and content is doing most of the work. SQLs sit lower, where a purchase decision is forming and a person is doing the work.

The funnel describes buyer behavior, not a promotion ladder. Leads skip rows, disappear for months, and sometimes arrive at the intent row on their first visit. Treat the mapping as a guide to which team should be in front of them, and when.

The middle rows are where lead nurturing does its work. MQLs that are not yet ready for a rep still need the right content at the right time, so that when a buying reason appears, your company is the one they already know.

What MQLs and SQLs engage with

The content a lead reads is one of the clearer signals of where it sits. The split below is this page's working view, written to help a team decide what to send, not a rule from any study.

A pricing page view is engagement, not a stated need. It can make an MQL ready for first touch, but it cannot make a sales qualified lead. Only a conversation turns interest into the five items above.

Who owns each stage, and who owns the boundary

In this page's view, many disputes about MQL vs SQL are ownership disputes wearing a definition costume. Naming the owner of each stage, and of the moment between them, removes more friction between sales and marketing teams than any scoring change.

The third row is the one teams skip. When nobody owns the accept or return step, MQLs sit untouched, marketing counts them anyway, and sales quietly builds a private pipeline that no report can see.

Salesforce's Trailhead notes that marketing has traditionally decided which actions earn points and at what level a lead goes to sales, and encourages sales leaders to weigh in. That is the second column in practice: the MQL bar belongs to both teams, even if marketing operates it.

How a lead moves from MQL to SQL: the handoff

Between the two stages there is a handoff, and at the end of it there is an event: a conversation. Not an email open, not a form, not a meeting that was booked and never held. Somebody talked to somebody and learned something.

1. Marketing qualifies the lead

   The MQL rule fires on fit plus engagement. The lead's lifecycle stage changes, and the date it changed is recorded, because every later measure depends on that timestamp.

2. The lead is routed with a note

   An owner is set by territory, account or rotation, as described in lead routing. The note says why the lead qualified: which actions, on which dates, and which fit data.

3. A rep accepts or returns it

   Inside the agreed window, the rep either commits to working the lead or sends it back with a reason from a closed list. Silence is not an option the agreement allows.

4. The rep holds a first conversation

   The rep makes the agreed number of attempts and, when they connect, asks the questions that fill the SQL criteria. Each answer goes into a field, not into the rep's memory.

5. The rep decides, and the stage follows

   All five items confirmed: the lead becomes an SQL. Some confirmed: it stays worked and accepted. A clear no: it goes to a disqualification path with a reason.

Three things have to be true at the last box. The rep reached a real person at the target company. That person described a problem your product addresses. And both sides agreed on something that happens next, with a date.

The note that travels with the lead, the meeting between marketing and sales, and the warm or cold versions of the transfer are covered in sales handoff. This section covers only the stage logic that decides whether the lead crossed.

Signals that an MQL may be ready for a sales conversation

• A direct request: a demo, a quote, a call or a reply asking how something works.
• Repeated visits to buying pages: pricing, security, integrations, terms, across more than one day.
• Several people at one account: different roles at the same company engaging in the same weeks.
• A stated event: a form answer or reply that names a deadline, a renewal or a new project.

None of these makes an SQL. They tell the rep which MQLs to call first. The conversation still has to happen, and the answers still have to be written down. Readiness signals sort leads; qualification decides them.

What lead scoring can and cannot decide

Lead scoring is how many teams run the MQL rule at volume. HubSpot's scoring tool, for example, builds fit, engagement and combined scores, and labels combined scores from A1 to C3, where the letter is fit and the number is engagement. The scoring model itself is covered on the MQL page.

Marketo's glossary frames a scoring model as a way to judge lead quality and sales readiness. Readiness is the word to watch. A score can say a lead is ready for an attempt. It cannot say the buyer is ready to buy.

• Scoring can decide which leads get a rep's time first this week, from data the team already holds.
• Scoring can decide which behavior counts as interest in your product rather than interest in your blog.
• Scoring cannot decide whether a real problem exists, because nobody has asked the buyer yet.
• Scoring cannot decide the timing, unless a person said out loud when something has to happen and why.
• Scoring cannot decide who else has to approve the purchase at that company.

So an SQL cannot be produced by a scoring model, however good the model and however much data feeds it. A high score raises the odds that a conversation is worth having. Only the conversation produces the evidence.

The sales accepted lead: the stage between MQL and SQL

Some teams put a step between MQL and SQL: the sales accepted lead, or SAL. It records that a rep looked at the MQL and committed to working it. It is cheap to add, and it makes both sides of the handoff visible in reports.

Acceptance is not qualification. Accepting means "I will contact this person". Qualifying means "I contacted them and here is what they said". Collapsing the two is how a funnel report ends up with a clean MQL to SQL rate that nobody in sales believes.

HubSpot's default stages go straight from MQL to SQL and keep the finer steps in the Lead Status property. To track acceptance as a stage, a HubSpot Super Admin can add a custom lifecycle stage, and HubSpot creates the stage's calculated date properties automatically.

Add an SAL when MQLs go untouched and nobody can prove it. Skip it when the team is small enough that every MQL lands on one person's desk and the accept step would only be a click with no decision behind it.

Disqualification paths: return, recycle, disqualify

Every MQL that does not become an SQL has to go somewhere. In this page's view, a lead that goes nowhere is the most expensive outcome in the funnel, because the effort to create it is spent and the result is invisible. Design four exits, and give each one a destination.

The fourth row is the one teams forget. An SQL can still fail. When it does, the reason belongs in the same closed list, because an SQL that dies in discovery tells you more about the SQL bar than any MQL return does.

Reject reasons, as a closed list

A return reason written as free text is a complaint. A return reason picked from a short list is data. Keep the list under ten options, and make each one point somewhere specific.

The last column is the part that changes behavior. When every reason names the team that can prevent it, the monthly review stops being a mood and starts being a list of rule changes. Counted over time, the reasons also become the clearest picture of lead quality by source.

How disqualification works in the CRM

Microsoft's Dynamics 365 Sales documentation is explicit about why a disqualify action beats deletion. A disqualified lead keeps an audit trail, and if the person comes back, the record can be reactivated with its attachments and notes intact. Deleting the record removes them.

Dynamics also allows a lead to be disqualified only when no opportunity is associated with it, and lists qualified and disqualified leads together in a Closed Leads view. HubSpot's default Lead Status options include Unqualified, Attempted to Contact and Bad Timing, which cover several exits above.

Why the argument usually means the definitions are unwritten

Marketing says sales ignores good leads. Sales says marketing sends junk. Both are describing the same missing artifact: a sentence, agreed by both, that says what an MQL is and what an SQL is at this company.

The tell is simple. Ask four people to write the MQL definition from memory, separately, in one sentence. If you get four different sentences, the argument is not about lead quality. It is about a rule that exists in four heads and no document.

• Symptom: the same lead is called good and bad in the same week. Cause: two thresholds, one in the marketing tool and one in the rep's head.
• Symptom: the MQL number is met every month and pipeline is not. Cause: the definition is tuned to the target rather than the target to the definition.
• Symptom: nobody can say how many MQLs were rejected. Cause: there is no acceptance step, so rejection is invisible.
• Symptom: every funnel report gets rebuilt by hand. Cause: the CRM and the marketing platform define the stages differently.

None of these is fixed by better scoring. They are fixed by writing two sentences down, naming an owner for each, and putting a date on the next review.

The written agreement that settles it

The document below is the point of this page. It is one page long, it is signed by whoever runs marketing and whoever runs sales, and it is reviewed on a fixed date. Everything else follows from it.

• The MQL sentence: one sentence, naming the fit rule and the engagement rule that together make an MQL.
• The SQL sentence: one sentence, naming the minimum information a rep must record before the stage changes.
• The exclusions: who never becomes an MQL, whatever they do, listed explicitly.
• The windows: how fast marketing routes, how fast the rep makes first contact, how fast a return is filed.
• The exits: the closed reason list, with where each one sends the lead.
• The system of record: which tool holds the true stage when two tools disagree.
• The review: a recurring date, who attends, and what each side brings.

MQL AND SQL DEFINITION AGREEMENT
Owners: {{marketingOwner}} and {{salesOwner}}
In force from {{startDate}}, reviewed on {{reviewDate}}

1. MQL
A contact is an MQL when the account matches {{fitRule}}
and the contact has done {{engagementRule}} within {{engagementWindow}}.
Nobody matching {{exclusionList}} becomes an MQL, whatever they do.

2. Routing and first touch
Marketing routes an MQL within {{routingWindow}} with the handoff note filled in.
The assigned rep makes first contact within {{firstTouchWindow}}.

3. Accept or return
The rep accepts or returns every MQL within {{acceptWindow}}.
A return must carry one reason from this list: {{returnReasons}}.
Returned leads go to {{returnDestination}}, not to nobody.

4. SQL
A lead becomes an SQL only after a conversation in which the rep recorded:
the problem in the buyer's words, who owns it and who else decides,
the money position, the timeline and its reason, and an agreed next step with a date.
Missing any of these, the lead stays where it is.

5. Disagreements
{{systemOfRecord}} holds the true stage when tools disagree.
Disputed leads go to the review on {{reviewDay}}, with the record open.

This example was written for this page. The bracketed values are yours to fill: no window, threshold or reason list here is a recommendation, and none is taken from a customer or a study.

The SLA at the boundary: what each side commits to

Some teams merge the definition agreement with the handoff service level agreement, then argue about both at once. Separating them keeps each short enough to be read. The agreement says what counts. The SLA says how fast each side moves, and what gets measured.

Commitments on each side

• Marketing commits to: the definition as written, a handoff note on every MQL, no MQLs from the exclusion list, and a forecast of volume so sales can staff for it.
• Sales commits to: an accept or return decision on every MQL, the first attempt inside the window, the agreed number of attempts, and one logged outcome per lead.
• Operations commits to: routing that sets an owner every time, stage dates that are recorded, and one report both teams read from.

The windows themselves should come from your own sales cycle and rep capacity. This page gives no number for them, because a window that suits a high-volume inbound team would be meaningless for a team that sells to a few dozen accounts a year.

Making the SLA visible in the CRM

An SLA nobody measures is a wish. HubSpot's documentation shows one way to enforce the sales side: lifecycle stage calculated properties record the date a record entered each stage, and a workflow can create a follow-up task for the owner when a contact entered the SQL stage more than a set number of days ago.

The same pattern works at the MQL to SAL boundary in any CRM that stores a stage entry date. Without that date, time to first touch and time in stage cannot be calculated, and the SLA becomes a matter of memory.

MQL and SQL as lifecycle stages in a CRM

The two terms are not only vocabulary. In CRMs they are values in a field, and the field has rules of its own that shape what your reports can say about MQLs and SQLs.

HubSpot lifecycle stages

HubSpot documents eight default lifecycle stages in sequential order: subscriber, lead, marketing qualified lead, sales qualified lead, opportunity, customer, evangelist and other. Stages can be customized, and they can be set by automation, workflows, imports, form submissions and integrations.

HubSpot's own definitions are worth copying into your agreement as a starting point. A marketing qualified lead is a contact or company that your marketing team has qualified as ready for the sales team. A sales qualified lead is one your sales team has qualified as a potential customer.

HubSpot also separates the stage from the detail. The Lead Status property holds sub-stages inside the sales qualified lead stage, with default options of New, Open, In Progress, Open Deal, Unqualified, Attempted to Contact, Connected and Bad Timing.

Moving backward also changes history. HubSpot notes that when a stage is manually set to an earlier value, the legacy "Became a" date for the later stage is cleared, while the newer calculated properties are not. Decide which date property your MQL to SQL reports read before anyone recycles a lead.

Salesforce leads and conversion

Salesforce models the boundary with a lead record and a conversion event. Trailhead describes a lead as a potential sales prospect who expressed interest but has not yet become a customer, and an opportunity as a qualified lead considered a viable business deal.

Conversion is the hard edge. Trailhead documents that converting a lead uses the lead's information to create a business account, a contact and an opportunity. Its walkthrough starts the lead at the status Open, Not Contacted and asks the rep to check the Converted Status before converting.

That matters for reporting on MQL vs SQL. If your definition of SQL is "converted", you are measuring the moment an opportunity is created, not the moment a rep confirmed the criteria. This page suggests keeping a distinct SQL status before conversion, so the two can be counted separately.

Dynamics 365 qualify and disqualify

Microsoft describes qualifying a lead in Dynamics 365 Sales as validating that it is a genuine sales opportunity, associating an account and a contact, and creating the opportunity record that tracks the deal. The qualified lead leaves the open leads view for the Closed Leads view.

Two details are useful when you write your own rules. If no opportunity is created, the business process flow does not advance even though the lead's status becomes Qualified. And where an admin has turned on multiple opportunity creation, one lead can produce up to five opportunities.

Microsoft's sales process overview puts the boundary in plain words: once you have determined that the lead is interested in your solution and has the appropriate purchasing power, qualify the lead. That sentence is close to an SQL definition, and it is written by the system's maker.

SAL, PQL and the other variants

MQL and SQL are the two terms everyone knows. Teams add letters when their motion needs a stage the pair cannot express. Add one only when a real decision hangs on it, and define it in the same agreement.

PQL is the one that changes the argument most. A product qualified lead has already used the product, often without talking to anyone, so the neat MQL to SQL handoff does not describe it. Whether marketing or sales follows up first is a decision to write down, not a default.

Teams that add PQLs and keep the old MQL rules can end up counting the same person twice: once for usage, once for engagement. Pick which stage wins when both fire, and say so in the agreement.

Measuring MQL to SQL conversion from your own CRM

The conversion rate from MQL to SQL is the number everyone asks for. It is worth tracking and it is rarely worth comparing to anyone else's, because both ends of the fraction are locally defined. Measure it from your own CRM, by cohort, with the formulas below.

Formulas used on this page

Count by cohort, not by calendar. A lead that becomes an MQL in one month may reach SQL in the next. Follow each month's MQLs forward until enough time has passed for your own sales cycle, then compare cohorts with each other. The arithmetic is covered in lead conversion rate.

A worked example, with invented round numbers

This example was written for this page, and the numbers are invented to show the arithmetic. A team routes 200 MQLs in a month. Sales accepts 150, returns 40 and leaves 10 untouched. By the end of the next month, 30 of the 200 have become SQLs.

The MQL to SQL rate is 30 divided by 200, or 15 percent. The accept rate is 150 divided by 200, or 75 percent. Of the 150 accepted, 30 reached SQL, so the accepted to SQL rate is 20 percent. The 10 untouched leads are the first thing to fix.

Now suppose marketing raises the MQL bar and routes 100 the next month, of which 25 reach SQL. The rate jumps to 25 percent while SQLs fall from 30 to 25. That is why the rate alone is never the goal: a team can raise it on Monday without closing one more deal.

How long it takes to move from MQL to SQL

There is no portable answer, and this page gives none. Time from MQL to SQL depends on your sales cycle, your windows and how often reps reach buyers. HubSpot's stage calculated properties record date entered and date exited for each stage, and add latest and cumulative time in a stage on Professional and Enterprise subscriptions.

Read the distribution, not the average. A few leads that sat for months will drag an average far from what a typical lead experiences. Look at the middle of your own records, and at the slow tail separately, because the tail is where an SLA tends to break.

Rewriting definitions that are already broken

1. Collect the four versions

   Ask marketing, an SDR, an account executive and operations to write both definitions from memory, separately, in one sentence each. Do not discuss first.

2. Read fifty real records

   Take fifty leads that crossed the boundary last quarter and read what actually happened. The pattern in those records is your current definition, whatever the deck says.

3. Write one sentence per stage

   Draft the MQL sentence and the SQL sentence together, in one room, with the records open. Argue about the records, not about the wording.

4. Name the exclusions out loud

   List who never qualifies whatever they do. This is often shorter and less controversial than the positive rule, and it removes many repeat disputes.

5. Add the accept step and the exits

   Decide the accept window and fix the return, recycle and disqualify reasons as a closed list. Make returning a lead a normal, counted action rather than an accusation.

6. Put it in the system, then in the calendar

   Set the stages in the CRM to match the words, pick the system of record, and book the review before anyone signs anything.

Fifty records is a size chosen for this page because one person can read them in an afternoon. The number is not magic. What matters is reading real records rather than summaries, so the definition you write describes what your sales process actually does.

Where the two definitions drift apart

Even a signed agreement erodes. The drift is mechanical, and in this page's view it tends to show up in the same four places.

• Two systems, two thresholds: the marketing platform scores one way and the CRM stage is set another. Pick one system of record and make the other follow it.
• Stage skipping: a demo request lands and a rep creates an opportunity directly. Legitimate, but it has to be a named path, or the MQL to SQL rate quietly excludes your best leads.
• Backward moves: recycled leads either keep their old stage dates or lose them. Decide which, write it down, and make the reports match.
• Quiet retuning: the threshold gets lowered to hit a number. Every definition change should have a date and an author, like a code change.

A quarterly audit catches all four. Pull a sample of records that crossed the boundary, read them, and check whether the definition on paper matches what actually happened. The gap is your real definition.

Can a lead skip the MQL stage?

Yes, and it should be allowed on purpose. A buyer who asks for a demo, replies to a rep with a real question, or is introduced by a customer can go straight to a sales conversation.

Record that path as its own source, so the MQL to SQL rate is not distorted by leads that never passed through the MQL stage. Those leads can be among the most ready to buy, and hiding them makes marketing's numbers look worse than they are.

Common mistakes with MQL vs SQL

• Treating SQLs as a better grade of MQLs. They rest on different evidence, and one is not a higher score of the other.
• Letting a booked meeting create SQLs automatically. A meeting that was never held confirms nothing about the buyer.
• Comparing your conversion rate to a published figure built on somebody else's stage definitions.
• Running the boundary with no acceptance step, so returns are invisible and untouched leads look like rejections.
• Defining SQL as "converted", so the stage measures when an opportunity was created rather than when criteria were confirmed.
• Deleting leads that did not qualify instead of disqualifying them, which throws away the history needed if they return.
• Changing the MQL threshold to hit a monthly number, without a date, an author or a note in the agreement.
• Adding PQL or MQA before the MQL and SQL sentences exist, which multiplies the disagreement instead of resolving it.

When you send one back

Many return notes are one word in a picklist, which is fine for counting and useless for fixing. The internal note below adds the two lines that make a return worth reading: what the rep found, and what would change the answer.

To: {{marketingOwner}}
Subject: Returning {{contactName}} at {{companyName}}: {{returnReason}}

Returning this one under {{returnReason}}.

What I found: {{whatTheRepLearned}}

What would change the answer: {{whatWouldQualifyIt}}

Sending it to {{returnDestination}}. Happy to bring the record to the review on {{reviewDay}} if you read it differently.

{{repName}}

Frequently asked questions