Business development ops framework: the pipeline is a queue, not a funnel

Most pipeline design starts from the funnel picture, which is a drawing of a shape rather than a model of anything. A funnel implies that more at the top produces more at the bottom, and that is the one thing about a busy pipeline that is not true.

A more useful model treats the pipeline as a queue with a limited number of servers. The servers are people. Each one can hold a certain number of live conversations before the quality of every conversation drops, and past that point adding work makes the whole thing slower.

What to take away

Work in progress is the limit that binds

Two quantities describe a queue: how fast work arrives, and how fast it leaves. The stock in the middle is what you carry, and carrying it is not free. Each live deal costs a share of attention that day, whether or not it moves.

The link between how much you carry, how fast work leaves, and how long each item takes is arithmetic, not opinion. It is stated as Little's law.

For a given closing rate, the more deals a person carries, the longer each takes to close. Not because anyone is lazy, but because the same attention spreads over more things.

That has an unpleasant consequence. When close rates fall, the standard response is to feed more leads in. If people were already at capacity, this raises the stock, lengthens every cycle, and lowers the close rate further. The move feels like effort and behaves like sabotage.

The counter-move is a cap. Decide how many live deals one person can hold, and treat that as a hard number. Anything beyond it waits in a named queue instead of being started. Holding unstarted work visibly is uncomfortable and honest; the same discipline under a different name is what work in process limits do in a production setting.

Finding your own cap

There is no correct number and anyone who gives you one is guessing. You can find yours from your own records in an afternoon.

Take the last two quarters of closed deals and count, for each, the other live deals that person carried during that deal's working month.

Group by that count, then check close rate and cycle time per group. The pattern is usually flat, then degrades, and the point where it starts degrading is your cap.

Placeholder numbers, invented to show the shape: close rate holds around a quarter of deals up to about ten live deals per person, drops to a sixth at fifteen, and to a tenth at twenty-five. Cycle time rises the whole way.

Two cautions about this exercise. It will be confounded by deal size, because bigger deals both take longer and crowd out others, so split by size band before you read it. And it tells you about the recent past under your recent process, so it needs redoing after any change to how the work is done.

A stage is a promise about the buyer

If a stage means anything, it means a specific thing has already happened, and it happened on the buyer's side. Written that way, a stage change is checkable by someone who was not there.

Compare two definitions of the same stage. "Qualified" as a feeling means the seller believes there is something here. "Qualified" as an event means the buyer described the problem in their own words, named who else has to agree, and said what happens if they do nothing.

The second one can be disputed on facts; the first one can only be disputed as a personality clash.

Three tests for a stage definition.

Where the queue actually blocks

The stage with the most deals in it is not necessarily your constraint. The constraint is the stage where deals sit longest without a dated event scheduled, because that is where nothing is pulling them forward.

Count it directly. For each stage, count the deals with no scheduled buyer event in the next fourteen days. That count, stage by stage, is a better map of where your operation is stuck than any conversion chart, and you can produce it today from data you already have.

Timing is why it beats conversion rates. A conversion rate reports what happened to deals that already left the stage. That is history.

Stalled counts cover the deals still in there, which is next quarter. A leading count you can collect by hand usually beats a lagging one that needs a report built. The general form of that argument is in operating processes metrics.

What to do when the constraint is a person

Sometimes the queue blocks at a specialist: one person who does the technical review, the pricing approval, or the security questionnaire. Every deal waits for them, and their calendar sets the pace of the whole operation.

Three responses, in the order worth trying. First, take work off them that does not need their judgment. That is usually more than half of it. Second, change the trigger so they enter earlier and once, not late and repeatedly.

Only then consider adding a second person. A second person needs the work to be dividable. If it is not, you have added coordination rather than capacity.

Resist the response of asking them to work faster. A person who is the constraint is already the most watched person in the operation, and speed is not the lever. The lever is what reaches them and when. The team-level version of this problem, including how to tell a bottleneck from someone who is merely busy, is in team management.

Putting it into practice this month

Start with the cap. Count live deals per person today, write down a number you think is the limit, and hold it for six weeks. You will be wrong about the number and you will learn more from being wrong about a stated number than from having no number.

Then rewrite one stage definition, the one that is disputed most often, as an event the buyer caused. Do not rewrite all of them at once; a pipeline where every definition moved in the same week produces a quarter of data that cannot be compared to anything.

Sequencing changes so that you can still read your own numbers afterward is the same problem treated in change management, and the arithmetic you will want when you read the result is in business development ops.

Common questions

Does a cap on live deals mean turning away leads?

It means holding them in a visible queue instead of starting them. A lead that is started and then neglected is worse than a lead that waits, because the buyer has been contacted and then dropped, which teaches them something about you.

What if deals vary enormously in size?

Then run separate caps per size band, or weight them. One large deal can occupy the attention of several small ones, and a single count treats them as equal, which will make the cap wrong in both directions.

Our stages are set centrally and we cannot change them. What now?

Add one field of your own that records the last buyer-caused event and its date. You then have the evidence layer without touching the stage layer, and you can run the stalled-deal count off your own field.

Is a stalled-deal count not just another number to game?

It is gameable, by scheduling meaningless events. That is why it belongs in a working conversation rather than a scorecard. Used to run the work it is useful; used to rank people it becomes a calendar-filling exercise within a month.