### Deeper Into The Equation that Governs Your Sales Team’s Effectiveness

I saw this post ‘The Equation that Governs Your Sales Team’s Effectiveness‘ by Thomasz Tunguz. It is not a very long read, but every sentence is dense with details, so it provides a very good list of factors that affect ‘Sales Velocity’, or the rate at a sales team can deliver money.

The basic argument is that the Sales Velocity depends on the amount of possible sales in progress (or, ‘Work in Progress’) and the Sales Cycle (the time it takes to close a sale). If there are 20 possible sales contracts being negotiated and it takes 30 days to close a contract, then on average, 20/30 or about 0.66 contracts will close every day. If 20% of those closings are sales (the ‘Win Rate’) and each sale brings in \$15,000 (‘Average Price’), then the Sales Velocity is: Work in Progress x Win Rate / Sales Cycle x Average Price.

For these figures, we would expect the ‘Sales Velocity’ to be 20 x 0.2 / 30 x \$15,000 = \$2,000 per day

What happens if the Sales Cycle (the time it takes for the buyer to make a decision on whether or not to sign the sales contract) drops from 30 days down to 20?

In that case, the ‘Sales Velocity’ to be 20 x 0.2 / 20 x \$15,000 = or \$3,000 per day. By making the Sales Cycle shorter, the Sales Velocity goes up.

This all seems very straightforward, but as Mr. Tunguz points out, “these numbers donâ€™t move in isolation; they are not independent”. To see how that might work, I made a more-detailed simulation of the Sales process dynamics using a piece of software called STELLA.

Conceptually, I think of the flow of money to be like the flow of water through a pipe. I have shown Mr. Tunguz’s Sales Velocity as a pipe in the diagrambelow. The ‘Sales Velocity’ depends on the ‘Average Price’ (in dollars per sales contract) and the rate of ‘signing Contracts’ (which is the remainder of his equation: ‘Work in Progress x Win Rate / Sales Cycle’)

I think of the ‘Work in Progress’ (the number of possible sales contracts that are being negotiated) as a bucket, represented by the rectangle. There are only two ways to get out of the that bucket – have the customer say No and flow out through the ‘losing Contracts’ pipe or have the customer say Yes and flow out through the ‘signing Contracts’ pipe’. The rate of ‘closing Work in Progress’ is the amount of Work in Progress divided by the Sales Cycle and the rate of signing Contracts and therefore, the rate of losing Contracts, both depend on the ‘Win Rate’.

Mr. Tunguz mentions that Sales Development Representatives deliver a certain number of qualified leads per time, adding possible sales to the ‘Work in Progress’ bucket.

Now we have a more-detailed, more kneebones-connected-to-the-thighbone operational model of what is going on an how all the big pieces are connected. I ran a simulation using a value of ‘Sales Cycle’ of 30 for the first 20 days. We can see that the Sales Velocity is \$2,000/day. At Day 20, the value of ‘Sales Cycle’ drops to 20 days. That is, the account executives get faster at closing (both winning and losing contracts).

We can see that the Sales Velocity jumps up to \$3,000 per day… but just for one day! It slowly drops back to \$2,000/day by Day 90.

Even though the Sales Cycle is permanently shorter, the effect of the shortening quickly wears off. What is going on here? When we shorten the Sales Cycle, the flow rates out of ‘Work in Progress’ get faster (there are more contracts won and lost each day). But, the rate at which the Sales Development Representatives deliver leads (‘developing Work in Progress’) does no change. Higher out-flows from the bucket but the same rate of adding new work to the bucket means that the total amount of ‘Work in Progress’ must drop over time.

Shortening the Sales Cycle without adding more SDRs (or increasing their per-person productivity), means that the effect on the Sales Velocity will be short-lived.

Mr. Tunguz lays out all sorts of other scenarios (“increasing the average price”, “seasonality”, “company maturity”) that are too complex to deal with right here, but the simulation I have made could be the basis for exploring the ramifications of those in greater detail.

1. Brad, really great post. Thanks so much for laying out all these different scenarios

• Tom,
Thanks for commenting. Your blog is full of great material and a pleasure to read.
Best regards,

2. Wow Bradd you use STELLA, what a blast from the remote remote past. I think that thing was invented at Dartmouth in the late 80’s when I was in college there, I had no idea people still used it. Interesting finding though; makes sense!

• Ted,
Back in the late 90’s I used to work for the company that makes STELLA. I still think it is a fantastic tool for ‘rapid prototyping’ of models of complex systems since there are basically only 3 buttons to worry about – stocks, material flows and information flows.
I think there could be a fantastic e-book about using STELLA for business modeling – estimating sales team effectiveness, identifying useful KPIs, forecasting/projections, and other similar topics. Maybe I should write up a list of topics, write one blog post on each, and then cut and paste them all together into a single volume. I have done similar posts before: Check out this old one: ‘Conquering a Market by Killing It’: https://braddlibby.wordpress.com/2013/07/03/conquering-a-market-by-killing-it/
And thanks for reading my blog. I hope all is well with you.
Best regards,