A Historical Perspective on Why SAL and SQL Appear to be Defined Backwards

Most startups today use some variation on the now fairly standard terms SAL (sales accepted lead) and SQL (sales qualified lead).  Below see the classic [1] lead funnel model from marketing bellwether Sirius Decisions that defines this.

One great thing about working as an independent board member and consultant is that you get to work with lots of companies. In doing this, I’ve noticed that while virtually everyone uses the terminology SQL and SAL, that some people define SQL before SAL and others define SAL before SQL.

Why’s that?  I think the terminology was poorly chosen and is confusing.  After all, what sounds like it comes first:  sales accepting a lead or sales qualifying a lead?  A lot of folks would say, “well you need to accept it before you can qualify it.”  But others would say “you need to qualify it before you can accept it.”  And therein lies the problem.

The correct answer, as seen above, is that SAL comes before SQL.  I have a simple way of remembering this:  A comes before Q in the alphabet, and SAL comes before SQL in the funnel. Until I came up with that I was perpetually confused.

More importantly, I think I also have a way of explaining it.  Start by remembering two things:

  • This model was defined at a time when sales development reps (SDRs) generally reported to sales, not marketing [2].
  • This model was defined from the point of view of marketing.

Thus, sales accepting the lead didn’t mean a quota-carrying rep (QCR) accepted the lead – it meant an SDR, who works in the sales department, accepted the lead.  So it’s sales accepting the lead in the sense that the sales department accepted it.  Think: we, marketing, passed it to sales.

After the SDR worked on the lead, if they decided to pass it to a QCR, the QCR would do an initial qualification call, and then the QCR would decide whether to accept it.  So it’s a sales qualified lead, in the sense that a salesperson has qualified it and decided to accept it as an opportunity.

Think: accepted by an SDR, qualified by a salesrep.

Personally, I prefer avoid the semantic swamp and just say “stage 1 opportunity” and “stage 2 opportunity” in order to keep things simple and clear.

# # #

Notes

[1] This model has since been replaced with a newer demand unit waterfall model that nevertheless still uses the term SQL but seems to abandon SAL.

[2] I greatly prefer SDRs reporting to marketing for two reasons:  [a] unless you are running a pure velocity sales model, your sales leadership is more likely to deal-people than process-people – and running the SDRs is a process-oriented job and [b] it eliminates a potential crack in the funnel by passing leads to sales “too early”.  When SDRs report to marketing, you have a clean conceptual model:  marketing is the opportunity creation factory and sales is the opportunity closing factory.

8 responses to “A Historical Perspective on Why SAL and SQL Appear to be Defined Backwards

  1. Thank you for answering the question that we all secretly ask ourselves in these meetings lol

  2. Thanks for flagging this linguistic ambiguity. I’ve encountered this language barriers while building a demand gen engine. Quota-carrying reps got hung up on the concept of “sales accepted” for not-fully-qualified leads headed their way. It took me a while to understand the objection.

    I’ve found the funnel terminology often adapts to however sales operations has implemented the CRM system – what’s a lead? what’s an opportunity? what’s stage 1 called? is there a “stage 0”? As long as there’s internal agreement and consistency from whoever’s measuring the KPIs, and a clear handoff moment from “marketing is driving the qualification” to “sales is driving the qualification,” there’s a good chance for operational success.

    • I’m a big believer in a Google doc that documents these definitions! Without such documentation, we are doing lots of reporting and analytics atop a sand foundation.

  3. Great explanation Dave. I’ve also found that calling SAL “opportunity stage 1” confuses your pipeline and the people running the end-to-end process (marketing+sales). SQLs and SALs relate to individuals. Opportunities relate to accounts. They can be more than one opportunity per account. And they will certainly be more than one lead per opportunity. Thus, an SQL simply CAN’T be an opportunity (unless you’ve identified the ONE person that uses the product and makes its purchase decision – which happens rarely in enterprise software).

    Finally, I also implemented a simple ‘opportunity rule’: an opportunity has a $$$ attached to it and a timeframe…which connects back to your earlier point: there can’t be any opportunity if the SAL has not been “Qualified” by a QCR.

    One last comment: you explanation makes it sound that this logic applies if SDRs work for sales (not marketing). I’ve had SDRs work in marketing apply the same logic. Your explanation is a sane one regardless who works for whom. In the end, we’re trying to build a predictable and repeatable process so we can run our business on math, not hope.

    • Agree on math vs. hope comment. At companies where I’ve worked you convert a lead to an oppty and put the oppty in stage 1 at the handoff to sales. If there is an existing oppty I believe you can attach the contact to it. If the person has no project or money then the SDR probably shouldn’t be passing it to sales as an oppty. But I do get your point, not every contact at HUGECO who might buy should get their own oppty. Agree also on your definition of what it takes to be an oppty: qualification by QCR for a real sales opportunity that is slated to close by time T. You may not get $ value off the first call, but you should have it by a certain stage downstreasm (e.g., 2 or 3 imho)

  4. Pingback: A Historical Perspective on Why SAL and SQL Appear to be Defined Backwards - News Views

  5. Pingback: A Historical Perspective on Why SAL and SQL Appear to be Defined Backwards – Real Estate

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.