MQL, SAL and SQL are not three labels for the same lead. They are three different decisions in the movement from marketing evidence to sales ownership and opportunity judgement.

An MQL is a person or account that marketing has judged ready to present to sales under agreed fit and behaviour criteria. A SAL is an MQL that the receiving sales owner has explicitly accepted for timely action. An SQL is a lead that sales has investigated and judged to represent a credible potential buying opportunity.

The purpose of the MQL to SAL to SQL model is not to make a funnel look orderly. It is to make every handoff decision, owner and reason inspectable.

That distinction matters because a lifecycle stage is useful only when it changes responsibility. If marketing can create an MQL without showing why, sales can ignore it without recording why, and both teams can redefine an SQL after the quarter closes, the CRM contains statuses but the business has no operating system.

This guide explains how to define each stage, when SAL is worth using, what evidence should travel with a lead and how to build a six-part handoff contract that improves through real acceptance and rejection data.

MQL vs SAL vs SQL at a glance

The terminology is not universal. HubSpot's current lifecycle stage documentation defines an MQL as a contact or company marketing has qualified as ready for sales, and an SQL as one sales has qualified as a potential customer. Adobe Marketo's lifecycle modelling guidance shows SAL as a configurable intermediate stage for a lead accepted by a sales representative.

Use the names only if the underlying decisions are clear:

  • MQL: ready to offer. Marketing has enough evidence of fit and relevant behaviour to place the lead in the sales acceptance queue.
  • SAL: responsibility accepted. A named sales owner has reviewed the evidence, accepted the lead and committed to the next action within the agreed response window.
  • SQL: opportunity potential verified. Sales has established enough need, fit, access and timing to treat the lead as a credible potential opportunity.

The sequence is not a claim that every buyer follows a linear journey. It is a control model for the organisation receiving and acting on evidence.

Why the handoff needs more than a lead score

A score can help order attention. It cannot carry the whole decision.

Behavioural points often reward visible activity such as repeat visits, form submissions or event attendance. Fit scores may use role, company size, geography or industry. Both can be useful, but either can produce false confidence. A highly engaged student can outscore a quiet buying committee member. A perfect-fit account may be researching for a future cycle rather than an active purchase.

Current buyer research makes that ambiguity more important. The 6sense 2025 Buyer Experience Report, based on nearly 4,000 B2B buyers, found that first seller contact occurred at about 61% of the buying journey and that buyers initiated the first interaction 79% of the time. It also found that 95% of winners came from the buyer's Day One shortlist.

This does not mean teams should stop qualifying leads. It means qualification should interpret evidence, not confuse data collection with buyer readiness. A lead may arrive late in its own decision process while appearing new in your systems.

The website therefore has work to do before the handoff. Clear positioning, accountable leadership and relevant proof help buyers evaluate independently. Our guide to B2B trust signals before contact explains how to make that evidence inspectable before a form is submitted.

The six-part lead handoff contract

A lead handoff contract is a shared operating agreement between marketing and sales. It defines what qualifies, what evidence travels, who decides, how quickly they act, how rejection is recorded and how the system learns.

It does not need to be a long policy. One clearly owned page, reflected in CRM fields and review routines, is more useful than a deck that no one uses.

1. An explicit entry definition

Start with the minimum conditions for an MQL. Separate fit from behaviour so teams can see why a lead qualified.

Fit may include:

  • organisation type, size or operating complexity;
  • relevant geography or serviceability;
  • role, function or likely influence in the decision;
  • a problem the business is equipped to solve;
  • exclusions such as vendors, students, job applicants or unsupported markets.

Behaviour may include:

  • a direct request for a conversation, assessment or proposal;
  • repeated engagement with high-intent service or solution material;
  • participation in a relevant event or product evaluation;
  • a known account showing meaningful multi-person activity;
  • an inbound question that reveals a live operational need.

Do not make every content download an MQL. A threshold should identify a reason for sales attention, not merely a person marketing can identify.

Document important exceptions. A direct contact request from a strong-fit account may qualify immediately even without a high score. An obviously irrelevant request should not qualify simply because automation added enough points.

2. A portable evidence packet

The lead record must explain the decision without forcing sales to reconstruct the history across tools.

At minimum, pass:

  • identity and account details that are lawfully available;
  • the source and most relevant interaction;
  • fit criteria met and exclusions checked;
  • recent high-intent behaviour with timestamps;
  • the page, campaign, event or referral that supplied context;
  • consent, territory and ownership information;
  • the specific reason marketing is presenting the lead now.

The packet should preserve useful context without exposing content or personal data beyond what the receiving role needs. This is one reason connected operating systems matter. Vinove Prism is designed to connect channel evidence, initiatives and review decisions, while Vinove Bond carries accountable revenue follow-through. Their connection is intended to preserve attribution and context while limiting unnecessary content exposure.

3. A named acceptance decision

An MQL is offered to sales. A SAL exists only when a named sales owner accepts responsibility.

Acceptance should answer three questions:

  1. Is this lead within the agreed qualification boundary?
  2. Is the evidence sufficient to justify direct action now?
  3. Who owns the next action and by when?

Do not let assignment masquerade as acceptance. Routing a record into a queue proves that software ran. It does not prove that a person reviewed the evidence or assumed responsibility.

If your sales volume is small and every qualified lead is reviewed immediately by a named owner, a separate SAL stage may add unnecessary administration. In that case, record acceptance as a timestamp and owner while moving from MQL to the sales qualification process. Use SAL as a distinct stage when queues, territories, partner routes or response commitments make acceptance a material control point.

4. A response clock with a stop condition

Define when the response clock starts, what action stops it and what happens when it expires.

The right response window varies by context. A direct request for a sales conversation normally deserves a different priority from an account that crossed a behavioural score. Avoid publishing one universal speed promise unless the organisation can reliably meet it.

The clock should distinguish:

  • review time: how long the assigned owner has to accept or reject;
  • first-action time: how long an accepted lead can wait for a relevant action;
  • pursuit window: how long and through which channels the team should attempt contact before recycling the lead.

An automated email should not count as meaningful first action when the contract requires human review. Equally, an unanswered call should not keep a lead permanently active. Clear stop conditions protect buyer experience and keep queues honest.

5. Controlled rejection and recycling reasons

Rejection is operational evidence, not a political weapon. Sales should be able to reject an offered lead quickly, but only through a short controlled set of reasons.

Useful reasons include:

  • outside the ideal customer or serviceability boundary;
  • insufficient evidence of current need;
  • duplicate or existing active opportunity;
  • invalid, incomplete or unreachable contact information;
  • existing customer or partner route required;
  • timing is credible but not current, so return to nurture;
  • qualification rule produced an obvious false positive.

Avoid an unrestricted “bad lead” note. It is difficult to aggregate and gives marketing nothing precise to improve. Require a comment only when the controlled reason cannot carry the necessary context.

Recycling must also be explicit. Define the owner, the condition for re-entry and the minimum quiet period where appropriate. Otherwise the same person can bounce between teams and inflate MQL counts without creating new evidence.

6. A learning review tied to decisions

Review the handoff as a system, not as two departments defending their numbers.

The most useful questions are:

  • Which MQL reasons produce the highest and lowest acceptance rates?
  • Why are leads rejected, and are those reasons changing?
  • Where does acceptance or first action exceed the agreed window?
  • Which sources create qualified opportunities rather than only MQL volume?
  • Which high-value opportunities arrived with weak or misleading marketing signals?
  • Are recycled leads returning because of new evidence or because automation reset a status?

Discuss examples from both success and failure. A lead that became an opportunity can reveal missing early signals. A rejected lead can reveal a poor rule, incomplete data or a correct decision that saved sales time.

How to decide when a lead becomes an SQL

Sales qualification should confirm a potential buying situation, not merely a pleasant conversation.

Salesforce's current SQL guidance describes an SQL as an MQL that has progressed to show clear buying intent, with the exact signal varying by business model. The operational definition should fit your sales motion rather than copy a generic framework.

An SQL decision usually needs evidence across four areas:

  • Problem: a material need or desired outcome the organisation can address;
  • Fit: a credible match between that need, the buyer context and the available capability;
  • Access: engagement with someone who can influence the decision or connect the right people;
  • Movement: a plausible next step, timing condition or evaluation path.

Budget and formal authority may not be visible in the first conversation, especially in complex buying groups. Do not invent certainty. Record what is known, what is inferred and what remains to be established.

An SQL is also not automatically an opportunity. Some organisations create an opportunity at SQL; others require a confirmed project, commercial path or agreed evaluation. Choose one rule and preserve it. Reporting becomes unreliable when individual sellers decide retrospectively which label makes the funnel look healthier.

The measurements that reveal handoff quality

Raw MQL volume is an input. A useful operating review connects volume to decisions and time.

Track at least:

  • MQLs offered, segmented by qualification reason and source;
  • acceptance rate and median time to acceptance;
  • rejection rate by controlled reason;
  • time from acceptance to meaningful first action;
  • SAL to SQL conversion by cohort;
  • SQL to opportunity conversion under one stable definition;
  • recycle rate and repeat qualification rate;
  • opportunity and outcome contribution by source or initiative;
  • missing-data and ownership exceptions.

Read the measures together. A rising acceptance rate can be positive, or it can mean sales stopped recording rejection. Faster action can improve responsiveness, or it can reflect low-quality automated touches. Attribution can inform investment, but only when stage history and source evidence remain intact.

Our guide to mapping the B2B customer journey beyond last click explains why the final touch should not absorb all credit for a decision shaped across many interactions.

A practical implementation sequence

Do not begin by rebuilding every CRM workflow. Begin with the decisions.

  1. Audit the current stages. Sample recent records and write down what actually caused each transition.
  2. Agree the definitions. Marketing and sales leaders approve the minimum entry, acceptance and SQL criteria.
  3. Design the evidence packet. Remove fields no one uses and add only information that changes the receiving decision.
  4. Create controlled reasons. Keep rejection and recycling values short enough to use and specific enough to learn from.
  5. Set clocks and owners. Define the review, action and pursuit expectations by lead type.
  6. Implement the workflow. Configure routing, permissions, timestamps and alerts after the operating agreement is clear.
  7. Pilot with one segment. Review examples weekly and fix ambiguous rules before wider adoption.
  8. Govern changes. Record who can alter definitions and preserve historical meaning when the model changes.

Automation should reduce coordination work, not conceal judgement. AI can summarise activity, detect missing context or suggest a priority. It should not silently convert uncertain signals into a qualified opportunity. Keep the decisive stage changes attributable to an approved rule or accountable human owner.

Frequently asked questions

What is the difference between an MQL and an SQL?

An MQL is a lead marketing has judged ready to present to sales based on agreed fit and behaviour criteria. An SQL is a lead sales has investigated and judged to represent a credible potential buying opportunity. The difference is the team making the decision and the evidence required.

What does SAL mean in sales and marketing?

SAL means sales accepted lead. It records that a named sales owner has reviewed an MQL, accepted responsibility and committed to the next action. It is useful when acceptance is a meaningful control point, but it does not need to be a separate lifecycle stage in every organisation.

Should every MQL become a SAL?

No. Sales should accept MQLs that meet the shared contract and reject or recycle those that do not, using a controlled reason. A 100% acceptance rate may indicate excellent qualification, but it may also indicate that acceptance is automatic and therefore meaningless.

Is a lead score enough to create an MQL?

Not by itself. A score can rank evidence, but the MQL definition should also account for fit, high-intent behaviour, exclusions and important exceptions. The record should explain why the lead is ready for sales now.

Is an SQL the same as an opportunity?

Not necessarily. An SQL is a sales-qualified potential customer. An opportunity normally represents a more formal commercial pursuit. Some organisations create both at the same moment; others require additional evidence. The important requirement is one stable, documented rule.

Make the handoff a decision system

The best MQL, SAL and SQL model is not the one with the most sophisticated score or the largest dashboard. It is the one in which a leader can inspect a record and answer: why did this qualify, who accepted it, what happened next and what did the organisation learn?

Build the definition before the automation. Pass evidence with the lead. Make acceptance visible. Capture rejection without blame. Then connect marketing investment to revenue outcomes through a stage history both teams trust.

That is how a funnel stops being a reporting diagram and becomes an accountable operating system.