SQL Definition and Acceptance: What Sales Actually Commits to When They Accept a Lead

The leads sit in Salesforce. Status: SQL. Age: 17 days. First touch: never.

Marketing sees the accepted count and thinks the handoff worked. Sales says the leads weren't any good. Nobody's technically wrong, and that's the problem. Acceptance happened. Accountability didn't.

An SQL without an acceptance SLA is just a label. When sales clicks "accept" on a lead, that action needs to mean something specific: a commitment to act within a defined window, with defined next steps, or return the lead with a documented reason. Without that contract, your MQL-to-SQL handoff is theater. Two teams performing alignment without actually achieving it.

This article lays out what an SQL definition should contain, what acceptance genuinely obligates sales to do, and how to document the agreement so both sides can be held to it.

The Acceptance Theater Problem

The Gartner SQL definition treats SQL status as a confirmed transition of ownership, but ownership without accountability is the gap most teams never close.

Here's how acceptance theater plays out in most B2B companies:

Marketing passes a batch of MQLs to sales at the end of the week. Sales accepts them, because the SLA says they have to respond within 48 hours. But "accept" means clicking a CRM button. It doesn't mean the rep looked at the lead, researched the company, or plans to call within a reasonable window.

Two weeks later, marketing pulls the report. All MQLs were "accepted." Great. Except only 3 of 20 were ever contacted. The other 17 are now cold.

When marketing raises this in the next alignment meeting, sales says: "Those leads weren't good." Marketing says: "You accepted them." Both sides are technically right. Neither side is accountable.

The root cause is definitional. Most companies define an SQL only in terms of criteria for passing: what signals a lead needs to hit before sales takes ownership. They don't define what sales owes in return. That asymmetry is what makes the handoff fail.

Key Facts: SQL Performance and Handoff Quality

• Only 27% of leads forwarded to sales are ever contacted, according to MarketingSherpa research on B2B lead follow-up rates.
• Companies with formal SLA agreements between marketing and sales are 2.4x more likely to report year-over-year revenue growth, per HubSpot's State of Marketing report.
• The average B2B company loses 71% of internet leads because they aren't contacted quickly enough, according to research by Drift and Heinz Marketing.
• Leads contacted within 5 minutes of initial inquiry are 21 times more likely to qualify than leads contacted after 30 minutes, per a joint MIT and InsideSales.com study.
• 61% of B2B marketers send all leads directly to sales, but only 27% of those leads are actually qualified, per MarketingSherpa.

SQL vs. MQL: The Ownership Shift

The MQL-to-SQL transition isn't just a status change. It's supposed to be an ownership transfer.

When a lead is an MQL, marketing owns it. Marketing decides whether to nurture it, accelerate it, or disqualify it. When a lead becomes an SQL, sales owns it. Sales decides whether to advance it, return it, or close it out.

But ownership without accountability is empty. Sales "owning" an SQL needs to mean something operationally. It means:

• Sales is responsible for the first meaningful contact
• Sales must either advance the lead or reject it within a defined window
• Rejection requires a documented reason that routes back to marketing

Until you define what ownership actually requires, the handoff just moves a record from one team's view to another. Nothing changes about the lead's fate.

The MQL-to-SQL handoff process covers the mechanics of that transfer. This article focuses on what the acceptance commitment should contain. For the broader funnel context both teams share, the agreed funnel model defines ownership at every stage.

The Two-Part SQL Definition

The SQL Two-Part Definition Framework

A complete SQL definition covers two equally binding commitments: qualification criteria (what makes a lead SQL-ready) and acceptance commitments (what sales owes once they accept). Most teams write Part 1 and skip Part 2. That asymmetry is where handoffs break.

Part 1: Qualification criteria. The signals that make a lead SQL-ready. Covers fit (ICP match, buying authority), intent (demo request, pricing visit), and timing (active project, budget cycle alignment).

Part 2: The acceptance SLA. What sales commits to upon clicking accept: first meaningful touch within 24 hours, discovery attempt within 5 business days, disposition (advance or return with reason) within 10 business days.

Both parts live in the same signed document. A definition that only covers Part 1 is a handoff without accountability.

A working SQL definition has two parts that most teams only half-build:

Part 1: Qualification criteria: the signals that make a lead SQL-ready. This is what most teams write.

Part 2: Acceptance commitments: what sales agrees to do once they accept. This is what most teams skip.

Both parts need to live in the same documented agreement. A definition that only covers Part 1 tells you who to hand off to. It doesn't tell you what to do next. And without Part 2, acceptance remains a formality.

Part 1: Qualification Criteria

SQL criteria should cover three signal categories: fit, intent, and timing.

Fit signals confirm the lead is genuinely in your target market:

• ICP match on company size, industry, geography. The shared ICP framework documents how to agree on these dimensions across teams.
• Confirmed or probable budget authority (title indicates buying role, or direct budget confirmation from form/call)
• Technology stack compatibility (they use systems your product integrates with, or they're replacing a system you displace)

Intent signals confirm active buying interest:

• High-value page visits: pricing, demo, comparison, ROI calculator
• Explicit request: demo booked, trial started, direct inquiry
• Competitive research behavior: visiting competitor comparison content

Timing signals confirm there's an active decision window:

• Form field indicating project timeline ("evaluating now," "Q2 budget allocated")
• Event trigger: contract renewal approaching, leadership change, funding round
• Inbound outreach (they contacted you, which implies some level of urgency)

No single signal should automatically make a lead an SQL. A lead who visited your pricing page once and matches your ICP isn't necessarily ready for a sales conversation. You want a combination, typically fit plus at least one strong intent or timing signal.

SQL Criteria Checklist

Minimum signals before sales takes ownership:

• Company matches ICP on at least 2 of 3 firmographic criteria (size, industry, tech stack)
• Contact has probable buying authority (VP or above, or confirmed economic buyer)
• At least one explicit intent signal (demo request, pricing visit, direct inquiry)
• No active disqualifiers (competitor, student, irrelevant geography)
• Lead source captured and verified

This checklist is a starting point. Calibrate it against your closed-won data. If leads that match all five criteria close at a materially higher rate than those who match three, your thresholds are roughly right. If five-criterion leads close at the same rate as three-criterion leads, you're over-gating.

The MQL definition framework covers the earlier-stage qualification decisions that feed into this criteria set.

Part 2: The Acceptance SLA

When sales accepts an SQL, they're committing to specific actions within specific timeframes. The acceptance SLA defines those commitments.

The 24-hour first-touch SLA is the one most teams miss. HBR research on online sales leads found that firms that tried to contact potential customers within an hour of receiving a query were nearly seven times more likely to qualify the lead than those that waited even an hour longer.

Quotable: B2B sales teams that respond to inbound leads within one hour of receiving a query are 7x more likely to qualify the lead than teams that wait even 60 minutes longer, according to HBR research on online sales lead response rates. The difference between 1 hour and 24 hours is already significant. If your acceptance SLA allows 48 hours for first touch, you're giving up pipeline before sales ever picks up the phone.

For teams that handle inbound demo requests, consider tightening this further. A five-minute response SLA is achievable for high-intent inbound and meaningfully changes conversion rates.

Writing SQL Criteria Your Team Will Actually Use

The Gartner MQL definition is a useful upstream reference here. The SQL criteria you write downstream should reflect exactly where the MQL definition ends and ownership transfers to sales.

SQL definitions fail for two reasons: they're either too loose (any MQL counts as an SQL) or too rigid (so many criteria that few leads ever qualify, and sales complains the definition is unrealistic).

A working definition is specific enough to be meaningful and flexible enough to account for the variety of real leads.

Avoid binary definitions. Instead of "budget must be confirmed," write "budget range indicated on form OR title suggests budget authority (VP or above)." This accounts for the reality that many buyers don't disclose budget at the awareness stage.

Build in explicit disqualifiers. Negative criteria matter as much as positive ones. A lead who matches your ICP perfectly but is from a direct competitor, a student, or a country you don't serve should fail the SQL criteria regardless of their intent signals.

Use "probable" language carefully. "Probable" buying authority is a valid criterion for SQLs in many motions, especially inbound where you rarely confirm budget on first touch. But "probable" requires definition. "Title of Director or above in the relevant function" is probable authority. "Anyone with a business email" is not.

Set a minimum score or signal count. For teams using joint lead scoring, define the minimum composite score required for SQL status. For teams without formal scoring, define a minimum signal count (e.g., "at least 2 fit signals and at least 1 intent signal").

The SAL Layer: When It Helps, When It Doesn't

Some revenue teams add a Sales Accepted Lead (SAL) stage between MQL and SQL. The SAL stage creates a brief window (typically 48-72 hours) for sales to review the lead before fully committing to the SQL SLA.

When SAL adds clarity:

• High-volume inbound where sales genuinely needs review time before committing
• Teams where the qualification criteria are complex and require CRM research before acceptance
• Organizations with formal SLA audits where partial commitment is meaningful

When SAL just adds friction:

• Teams with clean ICP criteria where review takes 2 minutes
• Low-volume environments where every lead is worth a full review anyway
• Organizations where SAL stage gets used to delay accountability rather than enable it

If you add a SAL stage, define a strict window (48 hours maximum) and a disposition requirement at the end of that window: accept to SQL status, or return with reason. A SAL that can sit for a week provides no benefit over an MQL. The lead routing rules your team applies determine which rep receives the lead once it clears the SAL window.

What Happens When Sales Rejects an SQL

Rejection is a valuable signal, but only if it's documented correctly.

Rejection reason taxonomy (structured codes, not free text):

Unstructured rejection reasons ("not interested," "bad lead") are useless for marketing. They don't tell you whether the definition needs updating, whether the nurture program failed, or whether sales is using rejection to avoid hard work.

Structured reason codes let marketing identify patterns. If 40% of SQL rejections come back as R2 (right company, wrong timing), marketing can build a faster re-engagement trigger. If 30% come back as R3 (outside ICP), the MQL definition has a problem.

The lead rejection and recycling process covers what happens to returned leads. This taxonomy feeds directly into that workflow.

Documenting the SQL Contract

The SQL definition and acceptance SLA should be a single written document, not a verbal understanding. Both VP Marketing and VP Sales sign off on it. Both teams have access to it. It has a version number and a last-reviewed date.

Template structure:

SQL Contract: [Company Name]
Version: [X.X]
Effective Date: [Date]
Last Reviewed: [Date]
Owners: VP Marketing, VP Sales

Section 1: SQL Qualification Criteria
- Minimum fit signals required: [list]
- Minimum intent signals required: [list]
- Disqualifiers: [list]
- Minimum composite score (if applicable): [score]

Section 2: Acceptance Commitments
- First meaningful touch SLA: [timeframe]
- Discovery attempt SLA: [timeframe]
- Disposition requirement: [timeframe and options]

Section 3: Rejection Standards
- Reason codes: [taxonomy]
- Routing actions per code: [table]
- Rejection SLA (feedback to marketing): [timeframe]

Section 4: Review Schedule
- Quarterly calibration meeting: [owners, format]
- Trigger for out-of-cycle review: [conditions]

Version control matters. When the definition changes (because your ICP shifted, a new channel started generating different-quality leads, or calibration data showed the thresholds were wrong) you need a record of what changed and why. Without version control, old definitions get followed after they've been superseded, and you can't diagnose performance gaps against the right baseline.

Rework Analysis: Teams that formalize a two-part SQL definition, with both criteria and acceptance SLAs documented, typically close the acceptance-theater gap within one quarter. The leading indicator is rejection rate with structured reason codes. When R1 / R6 codes are used consistently, MQL-to-SQL conversion stabilizes within 60 days because marketing can route returned leads accurately instead of re-passing the same disqualified contacts. Start with the acceptance SLA before optimizing criteria. Behavior before scoring.

Measuring SQL Quality Over Time

Three metrics tell you whether your SQL definition is working:

SQL-to-opportunity conversion rate. If fewer than 60-70% of SQLs become opportunities, your definition is too loose. You're passing leads that sales can't advance. If conversion is very high (>90%) and volume is low, your definition may be too strict and you're missing pipeline. The lead-to-opportunity conversion benchmarks from the pipeline side give you the downstream view of this rate.

SQL-to-closed-won rate. Track win rate from SQL stage, not just from opportunity. If you're creating lots of opportunities from SQLs but closing few, the quality problem shows up one stage later: the SQL criteria are passing leads that sales can work but not close. This is where opportunity qualification criteria become critical. What sales accepts as an SQL should align with what they can actually advance.

Rejection rate by reason code. A rising R3 rate (outside ICP) means your upstream qualification is drifting. A rising R2 rate (right company, wrong timing) might mean marketing is accelerating leads too fast, or that it signals an opportunity for timing-based nurture programs.

Review these metrics quarterly in the alignment meeting that covers the marketing-sales alignment glossary and shared definitions. When numbers move, trace back to the definition, not the team.

The Bottom Line

An SQL definition without acceptance commitments is a handoff without accountability. Marketing can point to accepted counts. Sales can point to lead quality. Nobody is responsible for the gap in between.

Writing the two-part definition (criteria plus commitments) closes that gap. Sales knows what accepting means before they click the button. Marketing knows what to expect after the handoff. When something breaks, the agreement tells you where.

Both teams need to own the document. Both need to have reviewed the data that informed the thresholds. And both need to feel the definition is fair, not a trap for either side.

That's how acceptance becomes a commitment instead of a formality.

Frequently Asked Questions

What is the difference between an MQL and an SQL?

An MQL (Marketing Qualified Lead) is a lead that marketing has determined meets minimum ICP and engagement criteria, making it worth nurturing toward a sales conversation. An SQL (Sales Qualified Lead) is a lead that has crossed a higher threshold, confirmed fit, active intent, and timing signals, and that sales has accepted responsibility to work. The ownership difference is the key distinction: marketing owns the MQL, sales owns the SQL.

What does SQL acceptance actually commit sales to?

When sales accepts an SQL, they commit to specific actions within defined timeframes: a first meaningful outreach within 24 hours, a discovery attempt within 5 business days, and a full disposition (advance to opportunity, or return with a structured rejection reason) within 10 business days. Acceptance without these commitments is theater, not accountability.

What should happen when sales rejects an SQL?

Sales should return the lead with a structured reason code, not free text like "not a fit." A rejection taxonomy (e.g., R1 = wrong persona, R2 = no active project, R3 = outside ICP) tells marketing exactly where the breakdown happened so it can fix the MQL definition or build better nurture programs. Unstructured rejection reasons are useless for upstream improvement.

What if sales never contacts an accepted SQL?

This is the acceptance theater problem: acceptance happened, accountability didn't. The fix is operational: build SLA reporting into your CRM that flags SQLs with no first-touch activity after 24 hours. Both VP Marketing and VP Sales should see this report weekly. When missed SLAs surface in a shared dashboard, both teams are accountable for the gap.

How often should the SQL definition be reviewed?

At minimum, quarterly. The SQL definition should be revisited whenever SQL-to-opportunity conversion drops more than 10 percentage points quarter over quarter, when a new channel starts generating significantly different-quality leads, or when your ICP shifts. Version-control the document so you can diagnose performance gaps against the right baseline.

What is a SAL (Sales Accepted Lead) and when should we add that stage?

A SAL is an intermediate stage between MQL and SQL that gives sales a brief review window, typically 48-72 hours, to confirm a lead meets SQL criteria before fully committing to the acceptance SLA. SAL adds value when qualification criteria are complex and sales genuinely needs research time before committing. It adds friction when it becomes a buffer for slow follow-up. If your SAL stage consistently ages past 72 hours, remove it.

How do we calculate the right SQL-to-opportunity conversion target?

Pull 3-6 months of clean CRM data. Count SQLs by entry date and count opportunities created from those SQLs. Divide opportunities by SQLs to get your baseline rate. B2B SMB benchmarks run 60-80%; mid-market runs 55-75%. If you're below 55%, your SQL definition is too loose. If you're above 90% but volume is low, you're over-gating and losing pipeline.

Learn More

• MQL Definition Framework
• MQL-to-SQL Handoff Process
• Agreed Funnel Model
• Lead Rejection and Recycling
• Five-Minute Response SLA
• Opportunity Qualification
• Marketing-Sales Alignment Glossary