Every pipeline stage claims to mean something. “Proposal” claims a proposal exists. “Negotiation” claims a buyer is negotiating. Ask most sales teams to prove it and the answer is a shrug, because the stage is a dropdown value that any rep can set on any deal at any time for any reason, including the reason that the weekly pipeline review is in ten minutes.
A stage gate is the mechanism that turns a stage from a label into a claim the system will defend.
What a stage gate actually is
A stage gate is an enforced condition on entering a pipeline stage: the CRM refuses the transition, and says what is missing, until the condition is satisfied. That refusal is the whole feature. A required-field warning that can be dismissed is not a gate. A report that lists non-compliant deals after the fact is not a gate either, because by then the forecast has already been built on them.
Three kinds of condition cover most real pipelines.
| Gate type | Condition | The question it answers |
|---|---|---|
| Required field | A named field must be populated | Do we know the basic commercial facts? |
| Required document | A quote must be attached | Does the thing this stage is named after exist? |
| Required activity | A logged activity of a given type | Has a human on the buyer’s side actually engaged? |
The third is the one teams skip and then miss most. A deal can have a close date and a quote and still be entirely one-sided, where the rep has done everything and the buyer has done nothing. A required logged activity is the cheapest available proxy for “someone on the other side responded.”
Why the forecast collapses without gates
A weighted forecast works by multiplying each deal’s value by a probability associated with its stage. The arithmetic is trivial. The assumption underneath it is not: that stage membership is determined by evidence rather than by the rep’s optimism.
Break that assumption and the failure mode is specific. The forecast does not become noisy in a way that averages out. It becomes systematically high, because the pressure on stage assignment runs in one direction. Nobody moves a deal backwards to look responsible. So every stage accumulates deals that do not meet its implied criteria, each carrying a probability calibrated for deals that do.
You then discover the problem in the least useful way: not as an error message, but as a quarter that misses by an amount nobody predicted, followed by a meeting about whether the probabilities need retuning. The probabilities are usually fine. The stage assignments are not.
The concrete failure: the quarter that was 40% air
A team runs a five-stage pipeline with the standard weights, and closes the quarter 38% under a forecast that had held steady for six weeks.
The post-mortem finds three mechanisms, all of them ordinary.
Eleven deals sat in Proposal with no quote attached. Six of those had never had a quote sent; the rep had “walked them through pricing on a call.” At the Proposal weighting, those six contributed real forecast value for a document that did not exist.
Nine deals had an expected close date inside the quarter that had been set once, on creation, and never revisited. The field was populated, so any required-field check would have passed. A close date that is three months stale is not evidence, it is residue.
And four large deals showed no logged activity with the buyer in over five weeks. Each rep could explain why. Collectively they represented the largest single block of the miss, and all four had been discussed in pipeline review without anyone opening the activity history.
The forecast was not wrong because the model was bad. It was wrong because the stage field was accepting claims it never checked, and every review meeting was conducted against the same unchecked field.
The opposite failure: gating until reps route around the CRM
Over-gating is the more common failure in teams that have just discovered gates, and it is worse, because it destroys the data instead of degrading it.
The mechanism is simple. Each gate is a tax on recording reality. Add enough of them and the cheapest path for a rep becomes: do the work outside the system, enter the deal when it is nearly closed, and fill in the required fields retrospectively with whatever passes. The pipeline now contains deals that appear for the first time at the Negotiation stage, and early-stage visibility is gone entirely.
| Gating level | What the pipeline shows | What you can trust |
|---|---|---|
| No gates | Everything anyone typed | The names, and roughly the values |
| One or two gates on decisive stages | Early activity, plus checked late stages | The forecast, mostly |
| A gate on every stage | Late-stage deals with backfilled fields | Almost nothing, and you will not know |
The diagnostic for over-gating is the age of a deal when it first appears in the CRM. If deals are born at stage four, your gates have taught the team to hide work.
Practical rules that hold up: gate the transitions where a wrong answer is expensive, usually entry to the heavily weighted stage and entry to the closing stage. Leave the first stage free. Never gate on a field the rep cannot know yet. And when you introduce gates, apply them to future transitions rather than retro-blocking deals that are already sitting somewhere.
How Oneop handles this
In the Oneop CRM, stage gates are enforcement rather than advice. You configure conditions such as “no deal reaches Proposal without an expected close date” or “none reaches the closing stage without a quote or a logged activity,” and a move that does not qualify comes back as a 422 with the exact list of what is missing. Three gate types ship: a required field, a required quote, and a required logged activity.
Two design decisions there are worth naming, because they are the ones that decide whether a team keeps using gates after month two. The refusal states what is missing, rather than failing generically, so a rep learns the rule from the error instead of from a training session. And no gates configured means no enforcement: existing pipelines are never retro-blocked, so turning the feature on does not freeze deals that were created before the rule existed.
The lead side of the pipeline runs on the same principle. Leads move through new, working, qualified, converted and merged, and converted and merged are terminal: a lead that owns a downstream contact or deal cannot be moved backwards. Converting creates the contact, the company and the deal in one action. That is a state machine rather than a status label, which is the same distinction as the one between a gate and a reminder.
Scoring, routing and gates are all deterministic and points-based rather than AI. Change a rule and you can predict the result, and every lead score is stored with the factor breakdown that produced it. For a pipeline discipline mechanism, predictability is the feature.
What gates cannot fix
A stage gate checks that an artifact exists. It cannot check that the artifact is any good. A quote attached to satisfy a gate is still a quote nobody asked for, and a logged activity can be a rep’s own voicemail. Gates raise the floor on pipeline hygiene; they do not substitute for reading the deal.
The judgement about where to automate a rule and where to leave it to a person is the same one covered in when not to automate, and it applies with unusual force here, because sales data quality is one of the few areas where a badly designed control reliably produces worse data than no control.
Two adjacent pieces: the outbound half of pipeline hygiene depends on sequences that stop when a prospect replies, and all of it assumes the deal, the ticket and the invoice hang off one customer record. What the gated pipeline then feeds is covered on reporting.