Your average stage-to-stage conversion times are:
MQL → 10 days → SQL → 15 days → Demo → 60 days→ Contracts → 15 days → Won
Your overall win rate from MQL to Won is 10%. The boss says "we need to cut the Demo to Contracts conversion time by 30 days.
Q1: What is your average sales cycle after shortening the conversion time?
Q2: You created 100 MQLs last month. What can you expect to sell from these? When?
Understanding Conversion Rate (CR) Models
CR models measure conversion rates between each sales stage and the next, like this:
Stage 1 → CR1 → Stage 2 → CR2 → Stage 3 → CR3 → Stage 4 → CR4 → Won
Where CRn means the percent of deals that convert from stage n to the next stage.
And conversion times like this :
Stage 1 → ΔT1 → Stage 2 → ΔT2 → Stage 3 → ΔT3 → Stage 4 → ΔT4 → Won
Where ΔTn ("delta Tn") means the average conversion time from stage n to the next stage.
These models are attractive because they seem to provide a leading indicator of success. And you can seemingly optimize your sales process by improving one stage's CR or ΔT. But these models elide the real issue—all you care about is wins. CRs and CR models can distract from that.
We often see people (egged on by consultants and RevTech vendors!) trying incorrectly to use time in CR models. For instance, by adding the ΔTs to come up with a total sales cycle. Perhaps surprisingly, you can't do this. The sum of the average times in stages doesn’t equal the average time to close a deal, because the sum of the times in stages includes deals that are not included in the overall sales cycle of won deals.
Why Adding ΔTs Fails
What’s wrong with summing the average time in each stage?
Mixing Different Deal Sets: The average time from Stage 1 to 2 includes deals that never advance to later stages. As a result, you’re combining different subsets of deals, rather than isolating the sales cycle of successful deals.
Deals may not pass through every stage: Some deals will skip stages so the average time in skipped stages won't apply to those deals. This can be corrected as by inventing data (and recalculating ΔTs) as detailed in this blog.
Example of Error: In one instance, summing the average conversion times produced a predicted sales cycle of 142 days, whereas the actual average time to close was only 80 days.
Can you use the actual average sales cycle in the CR model instead?
It’s tempting, but also not valid. The way most businesses compute CRs yields the "terminal" CR. That is, if you wait forever. Multiplying these together [1] produces the terminal win rate (again, if you wait forever). The problem is that the terminal win rate is not the win rate at the average sales cycle time.
Introducing TTW Models
TTW models take a different approach by measuring win rates as a function of time from each stage—regardless of the path taken:
Stage n → WRₙ(time) → Won
Where, WRₙ(time) represents the proportion of deals won (aka "win rate") from stage n as a function of time since entering stage n. Instead of static conversion rates, TTW models produce curves that reflect the progress of deals over time.
The Advantage of TTW Models
TTW models overcome these pitfalls by:
Directly measuring the time-dependent win rates from each stage.
Providing forecasts for any given period.
Eliminating the need to “invent” data for missing or regressing stages [1].
Conclusion
Returning to our questions above.
What is your average sales cycle after shortening the conversion time?
You created 100 MQLs last month. What can you expect to sell from these? When?
CR models can't answer these questions! But TTW models easily answer both of them—and much more!
Don’t be misled by Conversion Rate models. Instead, use a time-til-won by sales stage model—it’s easy to implement, more reliable, and more informative.
For a deeper dive into how to implement TTW models check out our blog here.
This is only valid under certain conditions. See this blog for details.
コメント