Your CS team mapped out a customer journey a while back.
Onboard, Activate, Adopt, Expand, Renew, Advocate. Every CSM trained on it. Every QBR references it. Every customer record has a stage field.
Then you look at your customers — and almost none are where their stage says they are.
Why Customer Journey Maps Stop Reflecting Reality Over Time
The customer journey is a real piece of CS infrastructure. It aligns the team on what stages mean. It lets you plan capacity — onboarding takes more hours than advocacy. It gives leadership a legible view of the customer base. It teaches new CSMs how a customer's life with your product is supposed to unfold. The journey does useful work.
What fades over time is how well the documented journey continues to match the customers in front of you. The team kept moving. The product kept shipping. The customers kept changing. The map is what it was when it was drawn. The territory isn't.
The deeper problem is that the journey gets used as the field on the customer record that determines what work happens this week — because customers don't move along the journey the way the journey was drawn.
A customer can be doing great on product adoption while their champion just left and they're back to square one on the relationship. A customer can be expanding in one product area while struggling to get the second one configured. A customer can hit Adopt, fall back to Onboard after a leadership change, jump to Expand when a new initiative on their side surfaces, and end up at Renew without anyone updating the stage field that says they're still in Adopt.
The journey is a story about the customer. The customer is doing something else. The stage value can only hold one position at a time — and that one position misses every other thing that's currently true about the relationship.
What Moves the Customer's Position on the Journey
Customers don't move along the journey because of the journey. They move because of things the journey was never designed to represent — and there are more of them than any single stage value can hold.
The examples operators run into most often: a leadership change on the customer side resets the goals — the new VP doesn't share the old VP's priorities, and the work the team did to align on outcomes has to start over for the parts of the relationship that depended on the old sponsor. A new initiative on their side — a new market they're entering, a new compliance requirement, a new internal restructure — surfaces a use case nobody was tracking, and the customer is back at goal-alignment on that initiative even though they're at full adoption on everything else.
A new product or feature on your side resets where the customer is on the dimension that product touches. The customer was at Adopt on the platform when they were on the original product set. The new module ships, and they're back at Activate on that module — while still at Adopt on the rest. A missed value-action target — the workflow that was supposed to be running in month three is still being configured in month seven — quietly resets the customer's effective adoption back to early, even though the calendar says they should be deep in Adopt by now.
None of these resets shows up in the journey field. The stage value keeps moving forward on the calendar even when the customer's actual state moved backward in reality. The CS team can either update the stage and lose the history, or keep the stage and lose the truth. Most teams keep the stage. The truth gets lost.
Track Customer States Alongside the Journey Stage
Keep the journey for what it's good at — capacity planning, reporting, training, team-wide vocabulary. Don't use it as the single field that drives operational decisions about an individual customer. Add six parallel state fields to the customer record. Each represents where the customer actually is on a specific dimension of the relationship.
Six states. Each one is observable. Each one has a condition that says it's true, a condition that says it slipped, and a rule for what triggers a reset. Together they describe where the customer actually is, regardless of what their stage value says.
Retention · Grow Scalably
The customer journey is non-linear.
Track where the customer actually is, not where the stage says.
Six states that sit alongside the journey-stage field. Each one parallel to the others, each one with a signal that says it’s true, a slip condition, and a reset rule.
Signal
Goal owner identified, primary goal in customer’s language, reviewed in last 90 days.
Slip
Goal owner changes role, or review > 120 days old.
Reset
Leadership change resets unconditionally.
State 02
Configured for Goals
Signal
Workflows mapping to goals are live and in use — not “implementation complete.”
Slip
Goal change stales the config, or workflow gap reported.
Reset
State 01 change always triggers State 02 review.
State 03
Value-Action Adoption
Signal
Value-action workflow used in last 14 days at sustained frequency.
Slip
Two consecutive 14-day windows below threshold.
Reset
Stays at current state — triggers intervention, not reset.
State 04
Multi-Stakeholder Engagement
Signal
2+ active users from different functions, exec sponsor engaged in last 60 days.
Slip
Active users drop to 1, or exec unreachable 60+ days.
Reset
Stakeholder departure resets for that role only.
State 05
Outcome Attribution
Signal
Customer-reported outcome tied to a metric and period in last QBR.
Slip
Two cycles without attribution, or goal changes with no new outcome.
Reset
Decays naturally — must be re-earned each cycle.
State 06
Daily-Work Integration
Signal
Integrations live, product appears in new-hire onboarding on customer side.
Slip
Integration breaks or removed; new-hire docs drop your product.
Reset
Highest-risk slip. Escalate immediately.
Why six states next to the journey
The stage says where the customer is supposed to be. The six states say where they actually are.
6
parallel states on the customer record, each with slip and reset rules
The stage says where the customer is supposed to be. The six states say where they actually are.
The Six Customer Success States to Track on Every Account
Six states on the customer record. Each one parallel to the others. Each one with its own value — Hit, Slipping, or Reset — and a last-verified date.
One. Goal Clarity. The customer can articulate, in their own words, what they expect your product to do for their business, and which person on their side owns each goal. Signal: goal owner identified, primary goal documented in the customer's language, reviewed in the last ninety days. Trigger when it slips: goal owner changes role, or last review more than one hundred twenty days old. Reset rule: leadership change on the customer side resets this state unconditionally — schedule the goal-clarity conversation in the first thirty days of the new owner's tenure.
Two. Configured for Goals. The product is set up in a way that reflects the documented goals — workflows, integrations, permissions, custom fields. Not "implementation complete." Configured to deliver the goals from state one. Signal: the workflows that map to documented goals are live and in use. Trigger when it slips: goal change in state one makes the configuration stale, or the customer reports a workflow gap that the configuration was supposed to solve. Reset rule: state one changes always trigger a state two review. New goals don't get served by old configuration.
Three. Value-Action Adoption. The customer is using the product in ways that produce value, not just logging in. The specific value-action workflow — the one that, if used, predicts renewal — is being used at sustained frequency. Signal: value-action workflow used by the customer team in the last fourteen days, at a frequency that matches the customer's profile. Trigger when it slips: two consecutive fourteen-day windows of below-threshold usage. Reset rule: usage gaps don't reset to state one — they trigger an adoption intervention at the current state.
Four. Multi-Stakeholder Engagement. The right people on the customer side are using and understanding the product — not just the original buyer. At least two functional roles, including one with budget authority. Signal: two or more active users from different functions, executive sponsor engaged in the last sixty days. Trigger when it slips: active user count drops to one, or executive sponsor unreachable for sixty days or more. Reset rule: stakeholder departure resets this state for that role only. A champion leaving doesn't reset state three on adoption, but does reset state four until the role is replaced and re-engaged.
Five. Outcome Attribution. The customer can connect your product to a measurable business outcome — not "we use it" but "it contributed to this specific outcome this quarter." Directly or indirectly attributed, but named. Signal: customer-reported outcome captured in the last QBR or check-in, attached to a specific time period and metric. Trigger when it slips: two consecutive review cycles with no outcome attribution, or customer reports a goal change without a corresponding new outcome to attribute. Reset rule: outcome attribution decays naturally. Last quarter's outcome doesn't count for this quarter. The state has to be re-earned each cycle.
Six. Daily-Work Integration. The product is part of how the customer's team works — infrastructure embedded in their daily workflow, not a tool they remember to log into. Signal: integrations live to the customer's other primary tools, and the product appears in the team's workflow documentation or onboarding for new hires. Trigger when it slips: integration breaks or is removed, or new-hire onboarding doesn't include your product as part of the standard workflow. Reset rule: regression here is the highest-risk slip on the customer record. Escalate immediately. A customer who removed your integration is a customer planning their exit.
How the Journey Stage and the Six States Work Together
The journey gives you the stages — the team-wide structure for what a customer's life with your product is supposed to look like. The six states give you the per-customer truth. The journey field on the customer record says where the customer is supposed to be. The six state fields say where they actually are.
Here is what that looks like on one account. Take a customer two months from renewal — journey stage says Renew, and on the calendar, that's correct. The renewal motion is the right motion this quarter. But look at the six state fields on the same record: Goal Clarity, Configured for Goals, and Value-Action Adoption are all Hit. Daily-Work Integration is Hit. Outcome Attribution is Slipping. And Multi-Stakeholder Engagement just went to Reset — the VP who championed you left three weeks ago.
The stage alone sends the CSM into a routine renewal: thank them for the partnership, send the paperwork. The states tell the CSM the truth — this is no longer a renewal, it's a re-sell to people who never chose you. The person who could articulate your value is gone, and the Slipping on Outcome Attribution confirms no one has connected the product to a result in two cycles. The play changes completely: re-establish a champion and re-prove value in the next two weeks, before the renewal conversation, not during it.
Same record. Two layers doing two different jobs. The stage answered what motion does this account need this quarter — a renewal. The states answered what is actually true right now — the champion is gone and value isn't landing. The stage never changes because of the states, and the states never roll up into the stage. They sit side by side, and the work happens wherever they disagree.
The divergence is the work. The Renew example above is one shape of it; an Adopt customer quietly Slipping on Goal Clarity is another — manufacturing a churn signal nobody has seen yet, while the stage still reads healthy. The journey alone catches neither. The journey plus the six states catches both.
Three structural requirements make this work as an operating layer instead of a deck artifact.
The states live on the customer record itself. Not in a separate dashboard, not in a Notion doc, not in a journey-tracking tool the team has to remember to check. Six fields on the customer record next to the journey-stage field. Same record the CSM opens every day. If the state value lives anywhere except where the CSM works, it isn't part of the work — it's part of reporting.
Triggers fire on conditions, not on the calendar. A state-slip trigger doesn't wait for the next QBR. It fires when the signal condition is met. Sponsor change detected, value-action usage drops below threshold, integration breaks — the trigger fires the same day. Most CS teams operate on quarterly cadence because that's what fits in the manager's review meeting. The customer doesn't operate on quarterly cadence.
States are independent and re-enterable. A customer at Hit on Outcome Attribution for one initiative can simultaneously be at Reset on Goal Clarity for a different initiative after a leadership change. Both are true. The record represents both. The CS team works on whichever state is currently slipping. There is no aggregate "stage" the states collapse into — the aggregate is the journey, which is doing a different job upstairs.
What CS Teams See When They Track States, Not Just Stages
The shift isn't from one tracking system to another. It's from a single composite view of the customer to two layers that describe two different things — and the CS team gains the ability to see when one of them lies.
The journey says where the customer is supposed to be. The states say where they actually are. The gap between supposed and actual is the operational headroom — the place where churn signals surface before the renewal call and where expansion-readiness becomes visible before the customer asks. CS teams running both layers report finding at-risk customers months earlier than their stage values suggested anything was wrong, and finding expansion-ready customers in segments their stage values had marked as "still in onboarding."
The unit of work is the variable. Not the customer, not the team. Moving the unit of work from one composite stage to six parallel states doesn't add a tracking burden — it replaces an approximate value with several precise ones. The same CSMs, the same customers, the same conversations. A different field structure on the record they were already updating.
What to Do This Week
Three steps. None require new software. Each one takes under an hour.
One. Audit your current journey's adherence. Pull your CS journey map and ten current customers. For each customer, look at their journey-stage value and write down where each of the six states would score — Hit, Slipping, or Reset. For how many of the ten does the journey-stage value still feel like an accurate summary of the customer's state across the six states? If the answer is fewer than three, your journey is a story; the customer is doing something else. Takes sixty minutes.
Two. Add the six state fields to your customer records. Not as a migration project. Not as a rollout plan. Six fields, three values each (Hit, Slipping, Reset), one last-verified date per field. Add them to whatever customer record system you already use. The journey stage field stays exactly where it is. The six states sit alongside it. Takes thirty minutes.
Three. Pick one customer and populate all six states this week. Pull the data. Score each state honestly. Note which states are slipping and which the stage value was hiding. The first customer is the practice run. Do the work once. The structure proves itself on the first one.
You built a customer journey customers never followed. They were never going to. The journey isn't wrong — it just tracks a clock the customer was never on. Keep the journey for what it's good at. Track the six states for what the journey can't see. Then the team starts working on what's true about the customer, not what the deck says is true.
If this structural approach landed, the same shift applied to health scoring is the next post worth reading. Same logic, different surface — replacing one composite with structured states the system can act on.
.svg)
.svg)
.svg)
