Pipeline
Every sales process document is a gate nothing enforces.
And every enforced gate gets routed around by the last week of a quarter, or it gets switched off after the first time it blocked a real deal.
Which is why the interesting decision is not the checklist. It is what happens to the person who has to move a deal anyway.
The checklist
Six things a deal can be asked for, and six things it can be asked to have.
The fields: an amount, an expected close date, a written next step, a primary contact, a named primary competitor, an owner. The artefacts: a logged call, a meeting, an email, any activity at all, a note, or a next step on the record.
Each stage gets its own selection and its own coaching text, which is shown to the rep at the moment they are stopped rather than living in a document nobody opens.
- Amount, greater than zero
- Expected close date
- Primary contact
- Next step written
- A meeting logged
- An amount must be more than nothing —
Not merely present. A zero-amount deal fails the amount requirement, which is the whole reason to have one.
- A next step made of spaces is not a next step —
Whitespace fails. Small, and it is the difference between a gate and a ritual.
- The requirements belong to the stage being left —
Not the one being entered. "What must be true before this deal leaves discovery" is the question teams actually have.
- A stage with nothing configured shows nothing —
No empty card, no zero-of-zero. It is simply absent from the deal.
The override
Two policies, because the honest answer differs by stage.
For most stages the requirement is a prompt, not a law. So the move can be forced by somebody holding the permission, with a written reason — and the reason, the stage it came from, the stage it went to, the person, and every unmet check are all kept.
For the stage where the answer is genuinely no, the override is not offered at all. The button is not rendered, and the refusal is unconditional.
That pair is why the gate survives. A gate with no override is routed around; a gate with a silent override is not a gate.
- Coaching text is shown where the stop happens —
Your own words, at the moment somebody is blocked — not in an onboarding deck they read once.
- A retired requirement never strands a deal —
If a requirement is removed from the catalogue later, a deal configured against it passes rather than becoming permanently unmovable.
- Nonsense never persists —
An unrecognised requirement is dropped when the stage is saved, so a mistyped configuration cannot sit there silently failing every deal.
›Who can force a move through?
Only somebody holding the override permission, and only on a stage set to allow it. Under the stricter policy nobody can, regardless of permission.
›Can we read back the overrides later?
Not in the product today. Every override is recorded with its reason and its failed checks — and there is no screen or export that reads them back. If reviewing overrides is part of why you want this, that report does not exist yet.
›Does this apply when a deal is closed rather than moved?
No. Closing is a separate path with its own requirement — the close reason. Stage requirements govern movement between working stages.
›Can requirements depend on the deal's value or type?
No. The selection is per stage and applies to every deal in that pipeline. A high-value deal cannot be asked for more than a small one.