Most process fixes die quietly, not because the plan was wrong, but because nobody with authority ever agreed there was a problem worth fixing. A CS leader can map the current state, design the ideal state, and still watch the plan stall because sales leadership sees no issue on their side of the fence, and onboarding leadership thinks the complaints are overblown.
This is the step before the four-week rollout plan. It is not about running the fix. It is about earning the mandate to run it at all.
On a recent panel, Erin Felton put the underlying problem plainly: without leadership across sales, onboarding, and CS aligned on one overarching goal, anything built downstream gets undone. You can have the best-designed handoff in the world and it still falls apart if one leader thinks the problem belongs to someone else's team. Angela Sutton offered a specific way past that stalemate: build a short, true case study around one real customer at one specific stage, showing exactly where the disconnect happened and what it cost.
Why a slide deck of the ideal state doesn't move leadership
A current-state versus ideal-state map is useful for the people already doing the work. It is much less useful for getting a budget or a mandate, because it describes a process, not a consequence. Leadership does not act on a diagram. They act on a story they can picture and a number they can point to.
Angela Sutton's suggestion was to take one ideal customer profile, follow them through one stage, such as activation, and document exactly what happened: where they were asked the same question twice, where personalization was missing, where they got confused. That story becomes the argument, and the high-level goal becomes something to reverse-engineer, rather than trying to fix everything in the weeds at once.
Erin Felton connected this to a simple test: what's in it for the person who does not think this is their problem. A leader who believes renewals are someone else's job may not care about a process map. A specific story about a real account, with a specific cost, gives that leader a reason to care.
What makes the case study work
The case study Angela Sutton described has a few features worth naming.
- It is about one real customer, not a composite or a hypothetical
- It is anchored to one specific stage of the journey, not the whole lifecycle
- It names the actual disconnect, such as being asked about the same problem twice, rather than describing a general feeling of friction
- It is trackable, so leadership can later see whether the same disconnect happened to the next customer of that type
That last point matters because it turns the case study into more than a one-time pitch. Once leadership agrees the story describes a real problem, you have a natural way to check whether your fix actually worked: did the next similar customer, at the same stage, hit the same wall.
- Pick one ideal customer profileChoose the type of account this problem affects most
- Follow one stage closelyDocument what actually happened at that stage, in the customer's own experience
- Name the specific costRepeated questions, confusion, delay, whatever it actually was
- Take it to leadership as a storyNot a framework, not a diagram, a specific account with a specific outcome
- Use it as your baselineCheck whether the next similar customer hits the same wall
Why this has to come before the pilot
It is tempting to skip straight to a pilot, since a small pilot with a real customer sharing KPIs across two teams is genuinely a good next step once you have the mandate. But Erin Felton's point was that doing this work without leadership alignment first means redoing it later. If one leader is not bought in, the pilot either gets no support, no resourcing, or gets quietly undone once attention moves elsewhere.
The case study is what earns that alignment. It gives leadership something concrete to agree is a problem, before you ask them to commit to changing how their team works. The session that covers the handoff work itself, Bridge the Gap: Mapping Current vs. Ideal State Customer Processes, goes into where these breakdowns tend to show up once you have that mandate.
How this differs from a general customer story or testimonial
A case study built for this purpose is not a success story and it is not a testimonial. It is deliberately about a failure, told specifically enough that a leader can see their own team's fingerprints on it. That specificity is what separates it from the kind of vague framing, such as
Keep reading
Stay in the conversation