Insights / Put it to work

A pipeline stage should explain what is true.

“Called twice” tells you what someone did. “Waiting for the customer’s decision” tells you where the request stands. Build stages around the second kind of information, then keep the next action visible beside them.

By JetSynapse AI · Practical guide · Illustrations are fictional

Give every stage one job

A stage should help someone decide how to handle a request now. If two teammates read its name and expect different actions, the definition needs work. A longer list of stages rarely fixes an unclear agreement.

Keep the current owner, next action and due time as separate facts. The same request can remain “Waiting for a decision” while its next action changes from checking a revised scope to making an agreed follow-up call. Creating a new stage for every task makes the overall path harder to read.

HubSpot’s pipeline documentation describes stages as positions within a process and recommends separate pipelines when processes genuinely use different stages. The example below applies that principle to an illustrative repair-estimate path, not a promised software configuration.

Start with a small, observable path

On a small screen, swipe or scroll sideways to read the full table.

Illustrative repair-estimate stages
StageEvidence for enteringDecision that moves it on
New inquiryA request has arrived and has not been reviewed.Does the team have enough context to help?
Clarifying the workA specific detail is still needed.Is the agreed scope ready for an estimate?
Preparing the estimateThe team has agreed what it will price.Has the estimate actually been provided?
Waiting for a decisionThe estimate was provided; a decision is not recorded.Did the customer accept, decline, request a change or ask for more time?
Accepted for schedulingAcceptance is recorded under the business’s agreed process.Who now owns scheduling and its requirements?
Closed without proceedingA reason for closure is recorded.Is any appropriate final action still outstanding?

This is a starting point, not a universal template. An on-site assessment may need its own clearly defined stage in your process. Acceptance still does not prove a booking, completed work or payment. Track those events with their own evidence.

Write the rule before moving the card

Use this six-line worksheet for each proposed stage:

  1. Name: what can a teammate understand without an explanation?
  2. Entry: what observed event or recorded decision makes this stage true?
  3. Owner: who is responsible while the request is here?
  4. Next action: what needs to happen, and when should it be reviewed?
  5. Exit: what evidence permits movement to the next stage?
  6. Exception: where does a changed, disputed or incomplete request go?

If nobody can fill in the entry and exit lines, hold off on creating the stage. “Hot lead” may express enthusiasm, but without a shared definition it is a judgment rather than a reliable operating state.

Test three ambiguous situations

Fictional example one: an estimate email is sent, but delivery is uncertain. Record what is known and give someone the task of checking the handoff. Do not turn “sent” into “read” or assume the customer is ignoring it.

Example two: the customer asks for a different material. Reopen the scope or estimate work, retain the earlier version, and set the next action to resolve the requested change. A reminder to accept the old estimate would miss the point.

Example three: the customer accepts but has not chosen a date. The request can be accepted for scheduling without being marked booked. Keep any deposit or agreement requirements separate and follow your actual business terms.

Ask two teammates to classify these situations independently. Compare their reasons, not just their selected labels. A disagreement reveals where the written rule is missing.

Improve the definitions before adding stages

Review a small authorized sample with the people doing the work. Look for requests that repeatedly move backward, sit without a next action, or carry conflicting notes. These are prompts to investigate, not automatic evidence that the team performed badly.

Before renaming or merging existing stages, map old definitions to new ones and check how historical reports will be interpreted. Keep a dated record of the change. Otherwise a report may appear to improve simply because the categories changed.

Start with one customer path. Once someone can reliably answer “where is it, who owns it, and what happens next,” the stage system is doing its job.