Pipeline stages tend to change in small steps. Someone adds a stage for “waiting for legal”, someone else renames “Proposal” to “Quote sent”, and a quiet stage is deleted because nobody uses it. Each change makes sense on its own. Afterwards nobody can explain why last quarter’s conversion from proposal to won looks so different, or why a handful of deals ended up in the wrong stage. Pomio CRM recommends treating a stage change as a team decision with a date, not as a setting one person adjusts.
Why a stage change is more than a rename
Stages carry meaning that the rest of the CRM builds on. They often drive the probability of a deal, they hold the exit criteria salespeople use to move a deal forward, and they are the shared language between sales and management described in shared stage definitions. Change a stage without agreeing what it now means, and the forecast, the weekly review and the conversion reports all shift at once, while the people reading them do not know anything changed.
What to agree before the change
Keep it short. Agree the new definition of the stage in one or two sentences, including what has to be true before a deal may enter it. Decide where each open deal in an affected stage goes: when two stages are merged or one is removed, someone should move those deals deliberately rather than leave the CRM to guess. Check what depends on the stage, such as probabilities, required fields or automations. And pick a date, ideally at the start of a reporting period, so reports before and after the change are easy to separate.
Who makes the change
Proposals can come from anyone who works in the pipeline, but the change itself belongs with the small group of people who administer the CRM. That fits the advice on how many administrators a CRM should have: when only a few people can edit stages, changes cannot slip in unnoticed. If your CRM keeps an audit trail of who changed what, it shows when the stage changed and who did it, but it does not record why. That is what the short change note is for.
Keep the number of changes low
A pipeline that changes every month is hard to trust. Collect proposals and decide on them a few times a year, unless something is clearly broken. Before adding a stage, check whether it would push the pipeline past a sensible maximum number of stages, and whether the situation is better handled by a field or a separate pipeline. After the change, use the next monthly data-quality check to look for deals left in a removed or renamed stage and for deals whose probability no longer matches their new stage.