Minimum viable lead: MQL, SAL, and SQL lifecycle rules

Three gates sit on the path from interest to opportunity, in flow order MQL then SAL then SQL. A Marketing Qualified Lead (MQL) says marketing judges the record worth sales attention. A Sales Accepted Lead (SAL) says sales has looked at it and accepted ownership, which is why it sits between the MQL and the SQL. A Sales Qualified Lead (SQL) says sales has worked the record and confirmed an active opportunity. Most teams run two of these gates and leave the third implicit. Making acceptance explicit separates ownership from qualification and gives both teams a place to record why a lead is returned.

What a minimum viable lead is

Underneath those three gates sits a single idea: the minimum viable lead. It is the smallest record state that can reasonably cross a gate for a given motion, with enough verified truth and fit to justify the next function’s time. That working definition sits behind most of the arguments marketing and sales have about what counts as qualified. Pitch it too low and sales spends time on records that go nowhere. Pitch it too high and marketing holds back pipeline to protect an acceptance rate that looks better than the business underneath it.

Companion guides cover the lead-quality standard, the human qualification layer and the intent signals that inform qualification. The lifecycle defines the thresholds between stages and the governance that keeps those thresholds from drifting.

MQL, SAL and SQL defined

Each stage is a boundary that someone owns and someone disputes. The leak starts when a team writes those boundaries down as dictionary entries and leaves them there. The fix is to run each one as a governed contract that names a threshold, an owner, and a reason for any change.

Marketing Qualified Lead. An MQL is a record marketing judges ready for sales attention, on the strength of fit and demonstrated interest. Ownership sits with marketing up to this gate. What is disputed is the threshold: how much interest, against which definition of fit, before the record earns a salesperson’s time. A lead that clears an engagement score but fails basic record checks is the most common bad MQL: engagement does not establish that a record is accurate, current, contactable and deduplicated.

Sales Accepted Lead. An SAL is a record sales has reviewed and accepted into its own pipeline, against agreed criteria. This is the acceptance gate, and the one most CRM defaults omit. HubSpot’s default lifecycle stages move from lead to MQL, SQL and opportunity without a separate SAL stage. Teams can customise stages or use other fields and workflows to record acceptance and rejection. Many teams use the SQL stage itself as an informal acceptance label, which is better than nothing but weaker than a governed SAL, because it folds “I accept this is mine to work” and “I confirm this is a real opportunity” into a single step and loses the rejection data in between. The SAL is where the marketing-to-sales contract is enforced. Without it, rejection tends to happen informally rather than in the system, so the reasons leads get sent back are rarely recorded and rarely acted on.

Sales Qualified Lead. An SQL is a record a salesperson has worked and confirmed as a real opportunity worth pursuing, against a qualification standard the team has agreed. Ownership is fully with sales. What is disputed is the qualification bar itself, and whether it is being applied or quietly lowered to hit a number.

The table sets out what crosses each gate. ICP means ideal customer profile.

Every gate re-tests the record rather than trusting the preceding gate. Each has a named owner responsible for its decision.

Set thresholds by motion

A single lifecycle definition applied across every motion is a common reason handoffs fail. An inbound demo request and an outbound list entry are not the same kind of record, and holding them to the same MQL criteria forces one of them through the wrong gate. The thresholds differ by motion even when the stages do not.

Inbound. The evidence is a declared need plus ICP fit plus reachability. The buyer has raised a hand, so the work is confirming the hand is attached to a real, serviceable account and a contactable person. The risk is over-trusting the declaration and skipping the data check.

Outbound. There is no declared need, so the MQL evidence is ICP match plus verified contactability plus a named trigger that justifies the outreach. A title that fits the ICP is not a trigger; a funding round, a tooling change, or a role move is. Where the gate does not ask for the trigger, outbound tends to send records that match on paper and convert at a lower rate than triggered ones.

ABM. In an account-based motion the lead object is a CRM proxy for an account-level state change. An MQL is the identification of a buying-group footprint inside a target account, for example three or more engaged roles showing coordinated activity, rather than one contact crossing a behavioural score. The CRM may route a person record, but the qualification logic is account-level.

Partner. The evidence is source trust plus a named project or deal context. A partner-sourced record inherits some credibility from the partner relationship, but the gate still needs to capture the specific opportunity context, or the record arrives warm but hard to act on.

In account-based and enterprise motions, the lead record stands in for an account state. Keep the people, roles and account evidence connected so that the lifecycle does not mistake one contact’s activity for the whole group’s readiness.

6sense and TrustRadius report different buying-group measures. 6sense’s 2024 Buyer Experience Report puts the average buying team at around eleven people, in its surveyed buying groups. The 2024 B2B Buying Disconnect study from TrustRadius and Pavilion, based on 2,164 technology buyers, found that 96% of buying groups have five or fewer members and 53% include at least one C-suite member, in the report’s headline takeaways. The operating point is that the unit of qualification is a group, not a single contact. The number of roles to cover scales with the motion and deal size.

Why the lifecycle leaks

A lifecycle leaks when records cross a gate they should not, or fail to cross one they should. The causes cluster into a short list: record quality, threshold design, routing rules, sales-acceptance behaviour, and the incentives that sit over all of it. The leak is usually treated as a sales-effort problem when more often it is an upstream record problem.

Take the most common case, worked through. A duplicate contact, or a record carrying an unverified business email, accrues engagement points across a few sessions and clears the MQL score threshold. On the engagement signal alone it looks qualified. It crosses the gate, routes to a salesperson, and falls over at first contact because the email bounces or the role is long out of date. Sales rejects it at the acceptance gate, if there is one to reject it at. What failed here was the record rather than the rep or the score, because the gate checked behaviour but did not check whether the record was true.

Without a governed SAL, the bad record is never formally rejected, the pattern never surfaces in reporting, and marketing keeps optimising a threshold that rewards the wrong thing. The cost of cleaning records that should not have crossed the gate is paid in sales hours, and a team can size it directly using its own loaded cost: multiply the number routed by the rejected-lead rate, then by the average hours spent per rejected record and the loaded hourly cost. As an illustration, a team routing 1,000 MQLs a month at a 30% rejection rate, with reps spending 20 minutes on each before sending it back, at a loaded cost of £45 an hour, is spending roughly £4,500 a month, or £54,000 a year, working records that should never have crossed the gate.

The incentive layer makes the leak worse. When marketing is measured on MQL volume rather than on pipeline that closes, the rational move is to lower the threshold, so volume rises while quality falls. The clearest published illustration comes from Cognism, whose then-CMO Alice de Courcy put first-party numbers behind the problem in Module 1 of the company’s Demand Gen Playbook. Two different measures sit behind her argument and should not be read as the same number. On a closed-won basis, gated-content leads converted to revenue at 0.2%. On a sales-opportunity basis, content-sourced MQLs reached Sales Qualified Opportunity (SQO) at under 2%, against close to 20% for inbound demo requests. An SQO is a confirmed sales opportunity, a later and stricter step than the SQL gate, so neither figure is comparable to a raw MQL-to-SQL conversion.

Cognism’s figures describe one company’s disclosed funnel, not a universal constant, and the useful move is to run the same two measures on your own data.

Checking compliance, truth and value at capture establishes whether the record is usable before it accrues a score, as the companion lead-quality article explains. The narrower lifecycle point is that gate integrity depends on the quality of the record entering it, which the team has to be able to verify.

Governing definitions so they do not drift

Definitions that are not governed drift, because every quarter brings pressure to hit a number and the easiest lever is to quietly redefine what counts. Governance is what stops the redefinition from happening by accident in a spreadsheet nobody reviews.

Two mechanisms do most of the work. The first is a change-control rule for the definitions themselves, so a threshold cannot move without the right people agreeing and a record of why. The second is an explicit marketing-to-sales contract at the acceptance gate.

The acceptance contract is where most of the day-to-day discipline lives. It needs four parts:

• The acceptance criteria sales agrees to apply.
• A fixed set of coded rejection reasons, so a returned lead carries a reason rather than silence.
• A recycle path back to nurture for a rejected but recoverable record, rather than dropping it.
• A service-level expectation for how quickly an accepted record is worked.

A workable rejection set is: out of ICP; bad or unreachable contact data; duplicate of an existing record; no genuine intent on contact; wrong timing (recycle to nurture); and already in an active opportunity. A short set the whole team uses consistently works better than a long list nobody can tell apart. Coded reasons let a recurring leak show up in a report instead of staying an argument between the two functions.

Speed of follow-up affects acceptance outcomes, so the contract should set a response expectation the team can actually meet. The human qualification guide covers how sales development representatives and salespeople apply judgement at those gates.

Is the MQL dead? Where the lifecycle is heading

Critics of a lead-centric lifecycle argue that ranking individual leads misdirects marketing toward volume the business cannot convert, and that the unit of attention should be the account and the buying group, measured on pipeline and revenue rather than lead count. The Cognism numbers above are the kind of evidence that case rests on.

For most teams, MQL/SAL/SQL remains a flawed but necessary taxonomy because the CRM, reporting and market are built around it. It earns its keep as a routing and accountability object. LeadScale recommends redefining the MQL rather than abandoning it, and fixing the record quality feeding it. The definition should use intent and buying-group footprint rather than raw engagement. Cognism also chose to redefine its MQLs, using its own definition of high-intent hand-raisers.

A fully account-based motion, with deterministic account-level intent data and a sales team that works accounts rather than individual leads, gains little from a per-lead stage model and pays a reconciliation cost to maintain it. A product-led self-serve motion is the other clear case: where product usage is the qualification signal and revenue comes through the product rather than a sales handoff, the lead stage adds no routing value the product does not already give. Outside cases like these, the lifecycle is worth keeping, provided it is governed.

Audit the gates together

For most teams the stages themselves are not the problem; the gates between them are where both the value and the leakage tend to sit. Define the minimum viable lead for each motion, make the acceptance gate a governed step rather than an implicit one, re-test the record at each gate, and govern the definitions so they do not drift without someone signing for the change.

A useful move many teams have not made, because the CRM does not prompt it, is a governed SAL with coded rejection reasons, which makes the leak visible enough to act on. Where an audit points back to record quality, the deeper fix is validating the record at the point of capture rather than after it reaches the CRM, which is the approach the LeadScale Engine takes. For most teams the practical starting point is smaller: a motion-specific gate audit that the two functions can run together in an afternoon, which is usually enough to show where the lifecycle is leaking and which gate to govern first.