Business development ops: facts, examples and context

Business development operations is the unglamorous half of growth: the definitions, records, and handoffs that decide whether anyone can answer "how are we actually doing?" without a week of spreadsheet archaeology. It is mostly a data hygiene and boundary problem, and it fails in predictable ways.

What to take away

• Ask five people in a company what counts as a qualified lead and you will get four answers and one shrug.
• Most pipeline stages describe the seller's activity: contacted, demoed, proposal sent, negotiating.
• Every organization has the same complaint: the data is out of date, so nobody trusts the reports, so nobody maintains the data.
• A forecast is a probability statement, and most organizations treat it as a commitment, which corrupts it in both directions: sandbagged so it can be beaten, or inflated to look confident.

Start with definitions, because everything else inherits them

Ask five people in a company what counts as a qualified lead and you will get four answers and one shrug. That single ambiguity propagates into the pipeline number, the forecast, the conversion rate, and every argument between marketing and sales about lead quality.

A definition is usable when it has an entry condition and an exit condition, both stated as observable facts rather than judgments.

Bad: "Qualified, the prospect is a good fit and shows genuine interest."

Better: "Qualified, we have spoken to someone who can describe the problem in their own words, we know who signs, and they have agreed a next meeting with a date."

Note what the second version does. Every clause is a thing that either happened or did not. Two people looking at the same record will classify it the same way. That property, reproducibility, is worth more than sophistication in the criteria.

Apply the same treatment to the boundaries either side: what counts as a lead at all, and what counts as closed. "Closed won" is more ambiguous than it looks in businesses with signature, deposit, onboarding, and first delivery as separate events. Pick one and hold it, or your revenue reporting and your pipeline reporting will never reconcile.

Stages should be about the buyer, not about you

Most pipeline stages describe the seller's activity: contacted, demoed, proposal sent, negotiating. This feels natural and produces a forecast that is nearly useless, because sending a proposal is something you control and tells you almost nothing about whether anyone will buy.

Stages defined by verified buyer facts behave better. Has the person you are speaking to confirmed a budget exists? Have you met anyone besides your original contact? Has the buyer described their own approval steps? Is there a date by which they need this, driven by something on their side rather than your quarter end?

The reason this matters is not philosophical. Activity-based stages let a deal advance through the whole pipeline without a single piece of evidence that the customer intends to proceed, and then stall at the last stage for two quarters. Everyone has seen that deal. It was never at that stage.

A practical migration: keep your existing stage names if changing them is disruptive, but attach one required piece of buyer evidence to each. The stage cannot be set without it.

Why the CRM rots, and what actually stops it

Every organization has the same complaint: the data is out of date, so nobody trusts the reports, so nobody maintains the data. It is a self-reinforcing loop, and it is rarely fixed by another reminder email.

The mechanism is usually one of these:

The person entering the data gets nothing back from it. If updates only ever feed a report that is used to question them, the incentive points at optimistic, sparse entries. If the record also produces something they want (the brief for the next call, the handoff to delivery, the reminder they would otherwise have to keep themselves), maintenance becomes self-interested.

There are too many required fields. Every mandatory field is a tax on every update, and taxes get avoided. People will type anything to get past a required field, which is worse than leaving it empty because you cannot tell the difference between a real value and a defensive one.

Nobody has ever removed anything. Fields accumulate across years and reorganizations, and no one deletes them because someone might be using them. Twice a year, list every field and find out who reads it. Anything with no reader goes.

The stale record has no consequence. A deal untouched for a quarter is not a deal; it is a hope. Have an explicit rule for what happens to them: automatically moved to a dormant state, or closed with a reason. The number that matters is not how much is in the pipeline but how much is in the pipeline and alive.

The handoffs: marketing to sales, sales to delivery

These two seams cause most of the operational friction in a growth function, and both fail the same way: the sending side thinks it has finished, the receiving side thinks it has not started.

For each, three things need to be agreed in writing:

What the receiving side is entitled to expect. Not aspirationally. The minimum set of facts without which they cannot begin.

What happens when it is not met. Bounced back, or accepted with a flag? Silent acceptance of incomplete handoffs guarantees they continue. A standard that is stated and then quietly not enforced decays one case at a time, which is the drift called normalization of deviance. The wider question of how many handoffs a process should have at all is in operating processes.

Who closes the loop on the outcome. If marketing never hears what happened to the leads it passed, it will optimize for volume, because volume is the only thing it can see.

The sales-to-delivery handoff has one extra failure mode worth naming: promises made during the sale that are not in the contract and not in the handoff. The delivery team discovers them in week three, when renegotiating is expensive and the customer is already unhappy. A single question on the handoff, "what did we say we would do that is not written down anywhere?", catches a surprising amount of it, but only if answering honestly is safe.

Forecasting without theater

A forecast is a probability statement, and most organizations treat it as a commitment, which corrupts it in both directions: sandbagged so it can be beaten, or inflated to look confident.

Some things that improve the number:

Separate the forecast from the target. The target is what you want. The forecast is what you expect. Requiring them to match makes the forecast meaningless.

Ask for the reason, not the percentage. "70% confident" is a feeling. "They have the budget approved, legal has the contract, and the sponsor has done this before" is a set of facts you can evaluate, and someone else can challenge.

Track your own calibration. Over a few cycles, compare what was forecast at each stage with what closed. If deals at a given stage close half as often as everyone assumed, you have learned something more useful than any individual deal review. This requires keeping the old forecasts, which most organizations do not.

Treat slipped dates as data. A deal that has moved its close date three times is telling you something specific about the buyer's process that nobody has asked about.

Loss reasons are the most wasted asset

Almost every organization records why deals are lost, and almost none uses the data, because the taxonomy is useless. "Price" absorbs about half of everything, and "price" means at least five different things: we were more expensive than a competitor; they had no budget at all; they had budget but not for this; the value was not clear enough to justify the number; or the salesperson thinks price is a safer answer than "I did not reach the decision maker."

To get something usable, do two things. Make the categories distinguish those cases. And separate the loss reason from the competitive outcome: losing to a competitor, losing to no decision, and losing to an internal build are entirely different problems with entirely different responses.

Then, at least occasionally, ask the buyer. Their answer and your salesperson's answer will differ, and the gap is where the learning is.

Bad-fit customers cost more than no customer

A deal that closes and then consumes triple the expected delivery effort, escalates constantly, and churns after one term is worse than a deal that never happened: it consumed capacity that had an alternative use, and it produced a reference customer you would rather not have. Counting the hours of the specific people who would have done the other work is the same arithmetic as in strategic planning.

The operational fix is to make fit a stage gate rather than a post-mortem observation. Write down the characteristics of the customers who have gone well and the ones who have gone badly, from your delivery team's perspective rather than the sales team's. Ask the delivery team, specifically, what they wish they had known before the contract was signed. Getting a straight answer across a team boundary is a management problem before it is a process one, and it is treated in team management.

Then treat those as disqualification criteria that anyone can invoke. This costs revenue in the current quarter, which is why it rarely survives without explicit senior support. Deciding in advance how far someone can go without asking is one of the standing obligations in management foundations.

Coverage: who is responsible for which accounts

However you divide the market (by geography, size, industry, product), two questions decide whether the division works, and both are usually left implicit.

Is anything uncovered? Not deliberately deprioritized, which is a legitimate choice, but genuinely nobody's job. Uncovered segments are invisible in reporting by construction: no activity, no pipeline, no complaints.

Can two people claim the same account? If yes, you will get duplicated effort, a confused customer who has been contacted twice, and an argument at the end of the quarter. Write the rule for overlaps before you need it, including what happens when a customer's circumstances change mid-cycle.

The related question is capacity. A person responsible for more accounts than they can meaningfully contact is covering none of them; the accounts merely appear covered on the plan. A rough check: how many accounts could this person have a real conversation with in a quarter, and how many are assigned to them? Where the second number is a large multiple of the first, the coverage model is decorative, and you should either reduce the list or be explicit that most of it is unworked.

Changes to territory are disruptive out of proportion to their apparent size, because relationships and context do not transfer with the account record. If you must change them, do it at a clear boundary, hand over deliberately rather than by reassigning records, and expect a dip.

Renewals and expansion are a different operation

Existing-customer revenue is frequently run with the machinery built for new business, and it does not fit. Three differences matter operationally.

The trigger is a date, not a conversation. Renewals arrive whether anyone prepares or not. This makes them easy to systematize and easy to leave until too late, and a renewal approached in its final fortnight has already lost most of its options.

The evidence is in delivery, not in sales. Whether a customer renews depends mostly on their experience since they bought, which sits in support tickets, usage, and the delivery team's impressions: none of which is usually visible to whoever owns the renewal.

The failure is silent. A prospect who goes quiet is a lost deal. A customer who has quietly stopped using what they bought looks identical to a happy one until the renewal date.

The practical consequence is that you need an early signal, and it has to come from outside the sales system. Whatever your business's version of engagement is (usage, contact frequency, support volume, participation), someone should be looking at it well before the renewal window, with a defined point at which it triggers a conversation.

Also record why customers leave, with the same discipline you would apply to lost deals, and separately from why they say they are leaving at the moment of leaving. Those two answers differ.

What to look at, and how often

Most reporting problems are cadence problems: weekly attention paid to numbers that only mean something over a quarter, which produces reaction to noise.

Weekly is for things that are actionable this week. Deals that need something, stalled items, work arriving. Small numbers, looked at for movement rather than level.

Monthly is for pattern. Conversion between stages, where deals are stalling, whether the pipeline is being added to as fast as it is consumed.

Quarterly is for the questions that need enough events to be meaningful. Forecast accuracy against what actually closed, loss-reason patterns, whether a segment is systematically better or worse.

Two habits worth adopting regardless of cadence. Look at the same view every time, because a report rebuilt each period is a report nobody can see trends in. And when a number moves, look at the underlying records before explaining it: most confident explanations of a moving metric in a small business are stories fitted to noise, and the records will tell you within ten minutes whether something real happened. Telling movement a measure produces anyway from movement that means something is exactly what a control chart was invented to do.

Partnerships and channel: what changes

Partner-sourced business breaks most of the assumptions above, because you cannot observe the buyer directly. Two consequences worth planning for.

Your pipeline data becomes second-hand. You are recording what the partner tells you, filtered through their incentives. Hold it in a separate view rather than mixing it with directly-observed pipeline, or your overall forecast quality quietly degrades.

Attribution disputes are structural, not incidental. Agree the rule before the first deal, in writing, including what happens when a customer talks to both of you. Every partnership that ends badly has an attribution argument somewhere in its history.

Choosing tools without regret

Tool selection consumes disproportionate attention because it is the part of this work that feels decisive. It is not. The failure modes above are all definitional and behavioral, and no system fixes them.

Three questions that filter more effectively than a feature comparison:

What does it cost us to get our data out? Export formats, API access, and what happens at the end of a contract. This is the constraint you will care about most in three years, and the one least examined at purchase.

Who is going to administer it? Every one of these systems requires someone who owns configuration. Unowned systems accumulate junk configuration until nobody trusts them.

What does it force everyone else to change? Adoption cost lands on the people using it daily, and it is usually absent from the business case.

Pricing, feature sets, and integrations change constantly, so check current details with the vendors themselves at the time you are deciding rather than relying on any comparison written earlier.

A short diagnostic

Answer these about your own operation. Each "no" is a specific thing to fix.

• Can two people classify the same deal into the same stage without discussing it?
• Does anyone check, afterward, whether last quarter's forecast was right?
• Does the delivery team see the deal before it closes?
• Does marketing find out what happened to the leads it passed?
• Is there a rule that removes dead deals from the pipeline without a human deciding to?
• Could you say, from records rather than memory, why you lost your last ten deals?
• Does anyone read every field you require people to fill in?

Common questions

How much process is too much for a small team?

The definitions are worth having at any size, because they cost nothing to maintain and everything to retrofit. The reporting apparatus is not. A team of three needs to agree what "qualified" means; it does not need stage-conversion dashboards.

Should the operations function report to sales?

Wherever it sits, the tension is the same: the function has to produce numbers that are sometimes unwelcome to the people it works for. What matters more than the reporting line is whether the definitions can be changed unilaterally by someone with an interest in the result. If they can, the numbers will drift.

We have several years of unreliable historical data. Is it worth cleaning?

Usually not all of it. Decide what questions you actually want the history to answer, clean only the fields those questions need, and mark the cut-over date clearly so nobody compares across it without knowing. A clean recent baseline beats a partially-corrected archive.

How do we know if any of this is working?

Pick the thing that is currently painful (forecast accuracy, handoff rework, time spent reconciling reports), and measure it before you change anything. Improvement in a definitional system shows up as fewer arguments and less reconciliation work, which nobody tracks by default.