A CRM stage must describe an observable condition.
"Working," "qualified," and "hot" mean different things to different people. A stage definition should name the event that enters the stage, the evidence required to leave it, the next action, the owner, and the time limit. If staff cannot tell whether a record belongs in the stage, automation cannot either.
| Stage | Entry evidence | Required next action |
|---|---|---|
| New inquiry | Valid contact and service request captured | Assign an owner and due time for first response |
| Fit review | Basic scope and decision process known | Accept, refer, decline, or schedule discovery |
| Discovery complete | Problem, stakeholders, constraints, and timing recorded | Define proposal owner and due date |
| Proposal sent | Correct proposal version delivered | Set follow-up date and record questions |
| Closed | Won, declined, no decision, or disqualified reason recorded | Create onboarding or close-out tasks |
The names will differ by firm. The discipline should not. A stage is not a mood; it is a shared operating rule.
Automate the next action, not the relationship.
Useful CRM automation creates the record, assigns ownership, calculates a due date, prepares context, and makes overdue work visible. It can draft routine acknowledgement or follow-up from approved facts. It should not fabricate familiarity, send a proposal nobody reviewed, or keep contacting a person after a meaningful reply.
Every open opportunity should have one next action with an owner and date. A note that says "follow up later" is not actionable. If the prospect asks for a call next quarter, store the date and reason. If the firm is waiting on internal pricing, the next action belongs to the firm, not the prospect.
Owner view: Show records with no next action, overdue actions by owner, proposals waiting past the expected window, and replies not yet resolved. That work list is more useful than a funnel chart with perfectly colored stages.
Resolve duplicate identity before adding more integrations.
Professional-service relationships often include a person, a company, multiple contacts, and several engagements. Decide which objects the CRM represents and how they relate. Search for duplicate email, phone, domain, legal name, and known aliases before creating a record. Do not auto-merge uncertain matches.
Give staff a review screen that compares the two records, preserves notes and activity, and shows which downstream systems reference each ID. A duplicate created by a web form can become two mailing histories, two client folders, and conflicting reporting if the first integration simply pushes it everywhere.
Clean one pipeline before turning on automation.
- Export the active pipeline and identify stale stages, missing owners, duplicates, and records with no next action.
- Write stage definitions and close-out reasons with the people who do the work.
- Set the minimum required fields at each handoff, not at first contact.
- Connect one reliable inquiry source and prove record matching.
- Add assignment and due-date rules, then an exception queue for failures.
- Introduce messages only after status changes and stop conditions are dependable.
- Review a weekly aging report until the new stages match what staff say is happening.
Measure response time, overdue next actions, stage age, proposals without follow-up, duplicate creation, closed reasons, and staff corrections. Avoid claiming revenue attribution the CRM cannot prove. A smaller set of trusted fields beats a large database maintained for reporting nobody believes.