Define a pipeline stage by what is true

A pipeline is useful when a stage has a consistent meaning. If one person moves a lead after sending a proposal and another moves it only after a signature, the dashboard cannot reliably tell the team what needs attention.

A practical sequence

1. Write the entry condition and next action for every stage.
2. Keep proposal sent, agreement accepted and payment confirmed distinguishable.
3. Define lost, paused and future-interest outcomes instead of letting old leads look active forever.
4. Review exceptions with an owner and a date.

Work through an example

A deposit-required booking remains in a proposal stage after signature because the payment is still pending. The team can see the exact remaining action. Once a verified payment is recorded, the booking moves forward without a second person guessing from a success screen.

Where judgement matters

Do not use stage changes as a hidden message-sending mechanism. If moving a card will send an email or start a sequence, show that consequence before the move and preserve a record of what was actually sent.

Make it usable

Open the working tool and change the example to match your own event. Then adapt the structured template. Keep the original assumptions visible until the people responsible have confirmed them.

Work the decision

A practice case

An original fictional scenario. Numbers are illustrative inputs; this is not a customer result or a provider performance claim.

A studio labels a lead Consultation complete as soon as a calendar slot ends. The couple did not attend, so the stage now exaggerates progress. A better stage boundary requires a completed conversation record and a next decision. Stage names become useful when two colleagues would move the same record under the same conditions.

Three decisions and why each matters

Decision	Why it matters
Write evidence for entry and exit.	A scheduled event and a completed event are not interchangeable facts.
Give stalled records a next action.	A lead that remains in a stage needs an owner, date or explicit reason to close it.
Keep lost reasons separate from open stages.	Price mismatch, unavailable date and no response suggest different improvements.

Make one usable artifact

Define four stages using an observable entry condition, required fields, exit condition and stale-record review. Test them against three real anonymized journeys.

Then test the difficult case

A client accepts a proposal but the required deposit is still unpaid. State which stage changes now and which milestone remains incomplete.

Use the linked tool or structured template below to record the result. Confirm it against the actual people, agreements and permissions before using it for an event.