Executive Summary
Customer Success inside an MSP has become increasingly process oriented. Teams define onboarding workflows, create playbooks, document QBR structures, and map out client journeys. During a recent research session with Luis Giraldo, Denes Purnhauser, Joe Markert, and Kevin Clune, the group set out to define the intersection between these processes and the use of technology in Customer Success. The goal was to understand how the two disciplines support and influence each other and where the lines are drawn in-between.
As the conversation unfolded, a deeper issue surfaced. Even the most polished processes could and often do fail in practice. The problem was not always the process design itself. Rather, it was often the absence of governance to reinforce it.
This paper explains why processes cannot operate in isolation. Customer Success is built on an operational architecture that includes systems, data structures, decision rights, and role clarity. Without this architecture, the process becomes fragile, inconsistent, and difficult to scale. With it, MSPs create a reliable and repeatable experience across every client.
The lesson is simple. Process gives shape to Customer Success, but governance (in the form of technology) gives it stability. Without the underlying architecture, process alone will not survive real world complexity.
How the Conversation Revealed a Hidden Problem
The discussion began with an attempt to clarify the structure of Customer Success. The group set out to categorize disciplines, frameworks, and methods. As they worked through this exercise, they realized that many of the problems MSPs experience in Customer Success had nothing to do with weak processes. They often came from a myriad of issues including unclear goals, inconsistent data, disconnected systems, and a lack of shared definitions.
Luis noted that the process is often treated as the solution. MSPs build steps and templates and assume the work is complete. But as he explained, “process can quickly become tactical. It is not the operating system.” What he meant was that workflows function only when the systems behind them are aligned and governed.
Joe reinforced this point by describing how MSPs often view Customer Success as execution. But execution depends on a foundation of structure, data, and visibility. In his words, “we can only do what the client enables us to do,” and that is true internally as well. A person in the Customer Success role cannot execute a playbook when the tools do not support the logic behind it.
Denes added that MSPs love diagrams and workflows, but “the actual execution breaks down when the systems do not support the decisions the process assumes.” That moment clarified the real issue. Customer Success is failing not because MSPs lack process, but because they lack the architecture to uphold the process in place.
Why Process Breaks Without Governance
Once the group recognized the pattern, the root cause became obvious. Many MSPs have good processes and intentions, but technology governance is missing. Tools are layered on top of one another without a clear structure. Different people interpret definitions differently. Health scores mean one thing in one system and something else in another. Deliverables vary by the Customer Success role because no system enforces consistency.
This leads to a predictable list of operational failures:
- Handoffs break because data lives in multiple places.
- Health scoring becomes subjective.
- Task systems generate noise instead of clarity.
- QBRs feel inconsistent from one client to another.
- Prioritization becomes emotional, not analytical.
- CSMs create workarounds that slowly erode standardization.
These are not failures of process design. They are failures of system alignment. The processes are not supported by enforceable rules, shared definitions, or reliable data structures. As Luis put it, “the tool forces clarity.” Without tools that enforce accuracy and structure, the process becomes optional.
How Tools Shape Behavior More Than Process Documents Do
A major insight from the conversation was that tools determine behavior more reliably than written procedures. Every MSP has seen this. A task queue determines what gets attention. A health score determines what gets escalated. An automation determines what gets ignored. A reporting system determines what leadership believes is happening.
Luis summarized this idea simply. “The tool does not support the process. The tool defines the process.”
This does not mean technology is more important than strategy. It means the system that executes the strategy must be designed intentionally. If a tool cannot support a capability, the capability does not exist in practice.
Examples raised in the session illustrate this clearly.
- Segmentation: A strategy that depends on maturity based segmentation will fail if the tool only supports revenue tiers.
- Playbooks: Plays that rely on usage signals cannot run if the system does not capture those signals.
- Health scoring: If each user can modify the scoring model, the score is no longer a shared language.
- Deliverables: If QBR templates are created manually, they will diverge from one another over time.
These issues are not caused by bad process. They are caused by weak or non-existent architecture.
The Execution Gap Between Workflow Design and Workflow Reality
Denes explained that MSPs often design processes that assume certain data structures, triggers, or handoffs exist. But when those assumptions are not supported by the technology stack, the entire workflow deteriorates.
For example:
- A process may require a signal to trigger a playbook, but no system captures the signal.
- A process may require a handoff, but no system clearly assigns ownership of the handoff.
- A process may require reporting on outcomes, but no system stores the outcome data.
When this happens, the Customer Success role must choose between following the process or working around the system. Over time, workarounds always win.
The group agreed that processes fail not because people ignore them, but because the system does not make them possible. Inconsistent execution is not a people problem. It is a design problem.
The Human Impact of Poor Governance
While the conversation focused heavily on structure, the implications are deeply human. Those responsible for CS rely on clarity, predictability, and accurate information. When systems are unclear, the role becomes stressful and inconsistent.
Luis noted that “if the system is unclear, the relationship becomes unclear.” An organization who cannot trust the data spends more time validating, interpreting, and compensating than serving clients.
This leads to:
- reactive behavior
- internal disputes over priority
- inconsistent client experiences
- difficulty managing workloads
- increased burnout
Strong architecture protects people by clarifying expectations and reducing ambiguity. It also strengthens the client relationship. Clients trust what is consistent. A governed system ensures that trust.
Conclusion: Process Is the Script, but Technology Governance Is the Stage
As the discussion unfolded, the group reached a unified conclusion. Customer Success is not sustained by process alone. It depends on the architecture behind the process. Systems define behavior, data defines visibility, and governance defines consistency.
Customer Success becomes scalable, predictable, and effective only when the architecture is clear. Without it, the best processes remain theoretical. With it, MSPs create a foundation that supports every discipline, every workflow, and every client relationship.
This is the hidden architecture. It is the backbone of a successful Customer Success practice.
Looking to level-up your Customer Success practice?
Access M2M’s cutting edge research and experimental AI apps for MSPs.
