Which business development ops mistakes quietly cost you a pipeline?

None of these are errors of effort. Every one of them is something a competent team does on purpose, for a reason that made sense at the time, and keeps doing after the reason stops applying.

Each mistake below replaces a hard question with an easier countable one. That substitution is what makes them survive.

What to take away

1. Counting a stage change as progress

What it looks like. The weekly review reports movement: eleven deals advanced. Everyone leaves reassured.

What it costs. Stages that can be advanced by an internal decision measure activity, not progress. A pipeline can advance continuously and close nothing, and it will keep doing so for a full cycle before the closure numbers reveal it.

The fix. Require a buyer-caused event, with a date, for each advance. Not a bigger process, one field.

2. Close dates that follow your calendar

What it looks like. A histogram of close dates with a spike in the last two weeks of every quarter.

What it costs. It corrupts everything built on the date: capacity plans, delivery schedules, cash forecasts. It also trains buyers, who learn that waiting until your quarter end produces a discount.

The fix. Ask what the buyer's own approval steps are and how long each takes, then set the date from that. Where the answer is unknown, record it as unknown rather than as your quarter end.

3. Reviving dead deals instead of qualifying out

What it looks like. A pipeline containing deals from three quarters ago, kept alive by a monthly email, because removing them lowers a number someone is measured on.

What it costs. Attention, mostly. Each dormant deal takes a share of the finite number of live conversations a person can hold, which is the real limit on throughput rather than lead volume.

The fix. A dormancy rule with no penalty attached. A deal with no buyer response in a defined period leaves the pipeline automatically and can be re-entered the day something happens.

4. Discounting as the default unblocker

What it looks like. Price is the lever reached for whenever a deal stalls, regardless of what caused the stall.

What it costs. It answers a question the buyer did not ask, and it teaches the ones who did ask that the first price was not real. Worse, it hides the actual blocker, which is usually an unresolved risk or a missing internal sponsor.

The fix. Before any discount, write down the sentence the buyer said that the discount is meant to answer. If there is no such sentence, the stall is not about price.

5. Measuring activity because activity is countable

What it looks like. Calls made, emails sent, meetings booked, all tracked weekly and all rising.

What it costs. The measure becomes the target and the behavior reshapes around it, so the counts rise while the outcome does not. This is the effect described by Campbell's law: a quantitative indicator used for decisions comes under pressure to distort the thing it was measuring.

The fix. Keep activity counts for diagnosis and out of the scorecard. Diagnostically they are useful, because low activity explains an empty pipeline. As a target they produce activity.

6. Running two motions through one pipeline

What it looks like. Small self-serve deals and long committee-driven deals in the same stages, the same reviews, the same conversion reports.

What it costs. Every average becomes meaningless, because the two populations have nothing in common. Worse, the process gets designed for the average, so it is too heavy for the small deals and too light for the large ones.

The fix. Split the reporting first, which costs nothing, before splitting the process. If the two populations behave differently once separated, you have the evidence for the harder change.

7. Adding a stage to fix a behavior

What it looks like. Deals keep skipping a step, so a new mandatory stage appears in the pipeline.

What it costs. A stage is a reporting object, not a control. People pass through it and carry on doing what they did. Meanwhile every historical comparison breaks, because the stage set changed.

The fix. Find out why the step gets skipped. It is usually skipped because it costs the seller something and produces nothing they can see, and that is a design problem in the step rather than a compliance problem in the person.

8. Treating the record system as a reporting tool

What it looks like. Data is entered on Friday afternoon so that the report runs on Monday.

What it costs. Everything in the system is a reconstruction, written to look reasonable, at least a week stale. Decisions then get made against a description of the past written by people who wanted it to look fine.

The fix. Make one thing the seller actually needs live in the system, so opening it is part of doing the work rather than reporting on it. Usually that is the next step and the account history, not the forecast fields.

9. Rewarding the recovery, not the avoidance

What it looks like. The person who rescues a collapsing deal in the last week is visible and celebrated. The person whose deals never collapse is invisible.

What it costs. It selects for late heroics, which are expensive, and it quietly teaches everyone that the smooth path earns nothing. Over time the smooth path stops being worked.

The fix. Report the count of deals that closed without an escalation alongside the recoveries. Both are results. Only one of them is currently visible.

The two checks that catch most of this

Where the underlying design questions live

Six of the nine above are symptoms of a stage set that describes the seller instead of the buyer. Rewriting stages as buyer-caused events removes them without any of the individual fixes, and the argument for building stages around the buyer is in business development ops.

Two more come from measuring what is easy rather than what carries information, which is a general operational problem covered in operating processes metrics. The last one is about what a team learns from what gets noticed, which is a management question rather than a pipeline one, and it sits in management foundations.

If any of these fixes changes the team's daily work, sequence it deliberately rather than announcing all nine. The reasoning is in change management.

The mechanism by which a written procedure quietly drifts away from what is done is documented in the human factors work on organizational change. The UK Health and Safety Executive published that work.

Common questions

Which one should we fix first?

The one producing a number your leadership already quotes. Fixing a mistake nobody has built on is easy and changes nothing; fixing one that a plan depends on is harder and worth doing first.

Our stage definitions came with the system and nobody owns them. Now what?

Someone owns them the moment you write down who. Until then every conversation about them ends with a shrug. Adding one field of your own, recording the last buyer event, gets you most of the benefit without a fight over the standard set.

Is it fair to stop rewarding late recoveries?

Nobody said stop. The suggestion is to make the alternative visible too. A team that only sees rescues rewarded will produce more situations needing rescue, and that is a design outcome rather than a character one.

How do we know a fix worked?

Decide in advance what would tell you, and pick something you can see within one cycle. If the only evidence would take a year, you will not be able to separate the fix from everything else that happened, and the change will be judged on whether people liked it.