Manufacturing and supply chain teams have never confused these two numbers. Cycle time is how long a process takes once someone starts working it. Lead time is the full duration from trigger to outcome, including every stretch spent waiting in a queue before anyone touches it. B2B sales reporting, by contrast, mostly collapses both into a single figure called "sales cycle length," and in doing so quietly writes off the part of the journey that often takes the longest.

This isn't a semantic nitpick. It changes what a team believes is slow, and therefore what they try to fix.

Two numbers that get treated as one

Ask most B2B revenue teams how long their sales cycle is, and the answer is usually measured from first sales engagement, a discovery call, an SQL handoff, to closed-won. That's a genuinely useful number. It's also, structurally, closer to cycle time than lead time: the time actively spent working a deal once someone picked it up.

What it leaves out is everything that happened before someone picked it up, and everything that happens whenever the deal sits untouched in between. A lead created on a Tuesday that doesn't get a first response until the following Monday has already lost four business days that never show up in the sales cycle metric, because the clock in most CRMs doesn't start until a rep engages.

The one-sentence distinction

Cycle time answers "how long does it take once we're working it." Lead time answers "how long does it actually take, including the parts where nobody was." Most B2B reporting only answers the first question while implying it answers the second.

What cycle time and lead time actually measure

The distinction comes from manufacturing and supply chain operations, where getting it wrong has direct, measurable cost. Cycle time is the duration of the value-adding process itself, the time a machine actually spends producing a unit, or the time a worker actively spends on a task. Lead time is the total elapsed time from when an order is placed to when it's fulfilled, which includes cycle time plus every queue, wait, and handoff delay along the way.

Supply chain term
B2B pipeline equivalent
Cycle time
The time a rep actively spends working a deal, from first meaningful engagement to close. This is what most "sales cycle length" metrics actually measure.
Queue time
Time a lead spends waiting, for a first response, for an internal approval, for someone to pick up a stalled thread. Rarely tracked as its own number, even though it's often the largest single component of the total.
Lead time
Cycle time plus queue time, measured from the actual trigger, typically when a lead first enters the pipeline, to the final outcome. The number that reflects what the buyer actually experienced.

Where the untracked queue time actually lives

Queue time doesn't announce itself. It accumulates in a handful of predictable places, none of which show up in a metric that only starts counting once a rep is actively engaged.

1
First response delay

The gap between a lead entering the CRM and someone actually contacting them. Research on lead response consistently shows this window is where the largest, most avoidable delay sits, and it's entirely invisible to a sales cycle metric that only starts once contact happens.

2
Internal approval queues

A proposal sitting with a deal desk, a discount requiring manager sign-off, a contract clause awaiting legal review. From the buyer's side, the deal has stalled. From the CRM's side, the stage often hasn't changed, so nothing flags it as slow.

3
Handoff gaps between functions

Every handoff, marketing to sales, SDR to AE, AE to customer success, has a natural pause built in while the receiving party catches up. A pipeline with more handoffs accumulates more of these small, individually reasonable delays, and they compound the same way any queue does.

Measuring both, and what to do once you can see them separately

The fix isn't complicated, but it does require timestamping stage transitions properly, not just the start and end of the pipeline.

How to start separating the two numbers
  • Timestamp every stage entry and every stage action, not just stage entry: The gap between "lead entered stage X" and "someone acted on stage X" is your queue time for that stage. Most CRMs can capture this with existing fields, it's usually a reporting gap, not a data gap.
  • Report total lead time and active cycle time as two separate figures: A deal with a 40-day cycle time and 15 days of queue time is meaningfully different from one with the same cycle time and 60 days of queue time, even though both would show identical "sales cycle length" today.
  • Set a queue time SLA at the stages that matter most: First response time is the highest-leverage one to fix, since it's usually the largest single chunk of queue time and the easiest to act on directly.
  • Investigate the largest queue, not the longest cycle: When a deal takes longer than expected, check whether the delay was active work or waiting. The two problems have completely different fixes, and conflating them means fixing the wrong thing.
Key takeaways
  • Most "sales cycle length" metrics measure cycle time, active working time, not lead time, the full duration including queues
  • Queue time hides in first response delay, internal approval steps, and handoffs between functions, none of which typically get their own metric
  • Timestamp stage actions, not just stage entries, to see the gap between the two numbers directly
  • A slow deal caused by queue time and a slow deal caused by active cycle time need completely different fixes
See where time is actually being lost in your pipeline

Our attribution modelling work tracks stage-level timing properly, separating active selling time from queue time, so you can see exactly where a deal is genuinely being worked and where it's simply waiting.

Explore Attribution Modelling →