Five business development ops calculations you can do on paper

Five calculations follow. Each one takes a few minutes, uses numbers you already have, and answers a question that otherwise gets settled by whoever speaks with most confidence.

Every figure below is invented to show the shape of the arithmetic. None of them is a benchmark, and if you find yourself quoting one of these numbers back to someone, the example has failed.

What to take away

One: is the target arithmetically possible

The question. Someone commits to a revenue number for next quarter. Is there enough in the pipeline to produce it, ignoring for a moment whether the deals are any good?

The sum. Take the value of deals that could close in the period. Multiply by the historical close rate for deals at that stage. Compare against the target.

Worked, with invented numbers: 600 units of pipeline value able to close this quarter, a historical close rate of one in five at that stage, gives 120 units expected against a target of 200. The gap is 80 units, which at the same close rate needs another 400 units of pipeline, none of which exists yet.

What it settles. Not whether the team will hit the number. Whether the number can be hit from what is currently in play. If the answer is no, the useful conversation is about where 400 units come from and how long that takes, not about effort.

The trap. The close rate you multiply by has to come from deals at the same stage and of the same type. A blended rate across all stages will flatter a pipeline full of early deals and punish one full of late ones.

Two: where the process actually loses deals

The question. Everyone has an opinion about which stage is the problem. Which stage is it?

The sum. Take deals that entered the pipeline in one month, three or four months back, and follow that group forward. For each stage, count how many of that original group reached it.

Worked, with invented numbers: of 100 deals that entered in a given month, 60 reached the second stage, 30 reached the third, 24 reached proposal, and 12 closed. The largest drop is between the second and third stages, where half disappear.

What it settles. Where to look. It does not tell you why, and the why is usually found by reading ten of the deals that dropped rather than by staring at the percentages.

The trap: doing this on the current pipeline instead of a cohort, which holds deals of every age. Counts per stage then describe how long deals sit, not how many survive.

Only the cohort version answers the question, and the reasoning for following a group forward instead of a snapshot is in cohort analysis.

Three: how long a deal really takes

The question. When someone asks how long your sales cycle is, what should you say?

The sum. Take closed deals from the last two quarters. For each, count days from first buyer response to signature. Sort them and read the middle value, then read the value one tenth from the slow end.

Worked, with invented numbers: median 54 days, slowest tenth beyond 160 days. The average, dragged up by a few very long ones, comes out around 78, which describes neither the typical deal nor the difficult one.

What it settles. What you can promise. If planning assumes 78 days, half your deals will beat it and the tail will still be open two quarters later, which is where forecast credibility goes to die.

The trap. Counting only closed deals. Deals still open are systematically the slow ones, so a cycle time computed from closures alone is optimistic by construction. Say so when you report it, or report it alongside the age of the open pipeline.

Four: how many accounts one person can actually cover

The question. A territory is being redrawn and someone proposes a number of accounts per person. Is it a real number?

The sum. Decide how many touches an account needs per quarter to stay warm and how long a touch takes including preparation. Multiply. Compare against the hours the person actually has for account work after everything else.

Worked, with invented numbers: 4 touches per account per quarter at 1.5 hours each is 6 hours per account. A person with 180 quarterly hours genuinely available for account work covers 30 accounts. Assign them 80 and the arithmetic says two thirds of the accounts get nothing, whatever the coverage model claims.

What it settles. Whether a coverage plan is a plan or a wish. It also tells you which accounts to deliberately not cover, which is the decision the plan was avoiding.

The trap. Overstating available hours. Take the figure from a real two-week trace rather than from a job description, because the gap between the two is where every capacity plan goes wrong.

Five: what a bad-fit customer costs

The question. A deal is available from a customer who needs something outside your normal shape. It pays. Should you take it?

The sum. Estimate delivery hours for this customer against delivery hours for a typical one, then convert the difference into the work you would otherwise have done with those hours.

Worked, with invented numbers: a typical customer takes 40 delivery hours in year one. This one is estimated at 140. The extra 100 hours come from the same team that would have onboarded two typical customers.

The revenue is 1.3 times a typical deal. So you pay two customers' worth of capacity for 1.3 customers' worth of revenue, before counting the support load that follows.

What it settles. That the comparison is not revenue against cost. It is revenue against the next best use of the same capacity, which is the comparison that gets skipped because the alternative is not sitting in front of you asking for a decision.

The trap. Estimating the delivery hours from the sales conversation. The person who wants the deal is the worst available estimator of what it will take, which is not dishonesty, just the ordinary optimism described as the planning fallacy. Get the number from whoever will do the work.

Using these without fooling yourself

Do them on paper first. A calculation you can do on paper is one you understand, and the version in a spreadsheet with fourteen inputs is usually the same sum with more places to hide an assumption.

Write the inputs beside the answer, always. Six weeks later somebody will quote the output and nobody will remember whether the close rate was blended or by stage, and the number will be used to decide something. The general habit of keeping definitions attached to figures belongs to every operational number, and the fuller treatment is in operating processes metrics.

Then check whether the pipeline these sums describe can hold the work at all. That is a capacity question, not arithmetic, and it is treated in business development ops framework.

If the answer changes what you do about accounts and coverage, the wider view sits in business development ops. How a result like this should and should not travel to other teams is in operations case studies.

Common questions

Which of these five should I do first?

The first one, because it is the shortest and it most often changes a conversation that was about to happen anyway. It takes about ten minutes and it either supports the plan or ends an argument.

My data is too messy for any of this.

Then do the fourth one, which needs no historical data at all, only an estimate of touches and hours. It is also the one whose answer people most often find surprising.

Can I use industry figures where my own history is thin?

For the shape of the sum, yes. For the inputs, no. A close rate taken from somewhere else describes a different product sold to different buyers by different people, and dropping it into your arithmetic produces a confident answer about somebody else's business.

How often are these worth redoing?

Once a quarter for the first three, and after any change to territories, pricing, or stage definitions. A definition change invalidates the history the sums are built on, which is the reason to write the definition next to the number in the first place.