A pipeline should tell the office what needs to happen next and give reporting a reliable account of what happened. Give each stage an entry rule, an owner and an exit condition. If two staff members would put the same project in different stages, the labels need clearer definitions.
Start with the real sales process rather than every status a CRM can display. Enquiry received, project qualified, consultation booked, consultation attended, proposal delivered and work signed are useful distinctions. Your business may combine or add steps, but each should represent an observable event.
Write a stage dictionary before building automations
For each stage, specify the evidence required to enter it. Booked should mean an actual appointment exists, not that a staff member plans to call. Signed should mean the agreed acceptance event happened, not that an estimator expects the job to close.
Add responsibility and timing. A new enquiry needs a response owner; a proposal needs a follow-up owner. A stage without a next action can become a parking place for records the team assumes somebody else is handling.
- Received: contact and project details saved with an enquiry timestamp.
- Qualified: the agreed service and area criteria have been checked.
- Booked: a real consultation time has been confirmed.
- Attended: the responsible team member verifies the meeting happened.
- Proposal delivered: the reviewed scope and price were sent or presented.
- Signed or closed: the verified outcome and its date are recorded.
Keep the event history when the current stage changes
The current stage helps the office work today. Dated events explain the customer's journey. A contact can be booked in one month, attend in another and sign later. Moving the record to signed should not erase the earlier timestamps.
Reschedules, cancellations and reopened estimates need explicit handling. Preserve the original project relationship where appropriate, and avoid counting every calendar change as a newly acquired opportunity. Use stable identifiers to connect records across the form, calendar and CRM.
Give unresolved records a deliberate home
Use a review queue for duplicates, uncertain matches and missing outcomes. Unknown is more useful than a guessed status that quietly changes the report. Ask the person closest to the conversation to resolve the record with a short factual note.
Distinguish lost, paused and unsuitable. A homeowner delaying until next season may belong in a dated follow-up task rather than an active proposal column or a permanent rejection category. Keep contact preferences and requests to stop visible to the team.
Test reporting against a few real journeys
Choose examples that include a reschedule, a duplicate enquiry, a proposal that pauses and a job that signs later. Walk each record through the pipeline and compare the report with the original events. This exposes definition problems that a dashboard total can conceal.
During the weekly review, focus on records without an owner, overdue next actions and missing outcomes. During the monthly review, reconcile bookings and signed work to the relevant systems. A useful pipeline supports both operations and measurement without asking the office to maintain several conflicting versions.
Common questions
Should booked and attended be separate pipeline stages?
- Yes, when attendance is a meaningful checkpoint in your process. A confirmed time and a completed consultation are different events and should be distinguishable in reporting.
Can one contact have several project opportunities?
- Yes. Keep the relationship explicit so a repeat customer, a reschedule and a genuinely new project are not counted in the same way.