What is SQL (Sales Qualified Lead)?

A Sales Qualified Lead (SQL) is a prospect that a sales rep or team has reviewed and formally accepted as worth pursuing toward a closed deal, sitting after marketing or SDR qualification and before an open opportunity.

At a glance

• Used by sales and revenue operations teams to mark when a lead enters active pursuit.
• Typically created after a discovery call or meaningful qualification conversation.
• Common gates include confirmed budget, a named decision-maker, identified pain, and timeline.
• SQL-to-close rate multiplied by average ACV drives ARR forecasting math.
• A vague SQL definition inflates pipeline while revenue stays flat.

How does an SQL actually get created?

Most B2B teams run a handoff sequence. Marketing generates a lead, an SDR or BDR works that lead, and only after a discovery call or meaningful qualification does it become an SQL. The moment of conversion is usually tied to a specific action: an AE accepts the lead into their pipeline, a meeting is booked and confirmed, or a formal scoring threshold is crossed.

In practice, an SDR might run 60 to 80 touches per prospect before a single SQL surfaces. At a mid-market SaaS company targeting $30K ACV deals, converting 1 in 12 MQLs to SQLs is a reasonable benchmark, though that ratio shifts considerably based on ICP fit and channel.

Why does the SQL definition matter for forecasting?

SQL volume and conversion rate are two of the most direct inputs into ARR forecasting. If you know your SQL-to-close rate and average ACV, you can work backward to determine how many SQLs a quarter you need to hit a number.

That math only works if the definition is consistent. One AE accepting anything that picks up the phone, another holding a high bar, and the forecast breaks before you even start. A vague SQL definition makes the pipeline look full while revenue stays flat.

When does the SQL stage break down?

• Loose acceptance criteria. “Interested” is not an SQL. Without clear gates, reps accept weak leads to hit activity metrics, and those leads clog the pipeline.
• No feedback loop. If AEs are not reporting back which SQLs went nowhere and why, the SDR team keeps generating the same low-quality profile. A weekly review, even a short one, fixes most of this.
• Confusing SQL with SAL. Some organizations use a Sales Accepted Lead stage between MQL and SQL. Blending the two removes visibility into exactly where the handoff breaks.
• Measuring volume, not quality. A team hitting 50 SQLs a month that closes at 4% is underperforming a team hitting 30 SQLs that closes at 18%. The metric that matters is closed revenue per SQL, not raw count.

How does SQL connect to adjacent concepts?

SQLs live inside a broader qualification architecture. BANT is one common framework for setting the criteria. In ABM motions, the SQL definition often tightens because teams run coordinated plays on a named account list rather than casting wide. CAC calculations depend on accurately counting SQLs and the cost to generate them, so an inconsistent SQL definition inflates or deflates true acquisition cost.

Teams running GTM pods, where SDR, AE, and marketing functions operate in one coordinated unit, tend to maintain sharper SQL definitions because the handoff happens inside the same team rather than across separate departments.