The Diagnostic Method

What It Is

My approach to diagnosing issues can be summed up in two words, Ground Truth. The diagnostic method is a structured approach to understanding what a CRM environment is actually doing on the ground in production, not what the documentation says it does, nor what the team believes it does, but what it actually does with real data and real users today. The gap between intent and reality is the source of almost every CRM system problem. The diagnostic method closes that gap by working from evidence rather than assumption.

This method applies whether I am helping a client understand why their system has drifted, or helping a client stress-test a proposed architecture before it is built. In the first context it is forensic, tracing what went wrong and why. In the second context it is prospective, applying the patterns of failure that I have seen in production to identify which decisions will create problems at scale before those problems exist.

How It Works

The diagnostic method proceeds in consistent steps regardless of the specific problem domain being examined.

Scoping — The client and I agree what needs to be understood before any diagnostic work begins. What systems are in scope? What flows matter most? What are the visible symptoms that suggest something is wrong? Scoping prevents the diagnostic from expanding indefinitely and ensures the hours are directed at the highest-value questions.

Evidence gathering — I work with the nominated client working group, they bring the right combination of technical understanding, operational knowledge, and day-to-day system experience that is required to gather the evidence. Real records are examined end-to-end via queries, reports and the UI. Actual system behavior is traced against (un)documented design. The working group pulls the data and documents the findings; I direct what to look at, ask the questions the team is not asking, and help interpret what the observations mean about system behavior.

Scenario testing - If necessary specific controlled test scenarios are conducted, using client test instances, to measure behavior for client use cases and variations. The results of these prove how the system functions. These same scenarios are analyzed as part of the first principles reasoning to make sure they are correct and to use as test cases to prove the existing functionality is not working and to prove the later amended functionality does work once fixed.

Diagnosis — From the evidence, I help the client team identify where actual behavior diverges from operational reality, which divergences are structural and require architectural attention, which are configuration corrections, which are bugs or require enhanced functionality and which are operational. The distinction between structural and symptomatic problems is the most important output of the diagnostic process. Without it, changes address what is visible rather than what is actually wrong.

First-principles reasoning — Once the diagnostic evidence is assembled, I work with the team to reason from first principles about what the system should actually be doing. This is distinct from diagnosis. Diagnosis establishes what is wrong and why. First-principles reasoning asks what right looks like, not by reference to best practice or existing system logic, but from the ground up. What is this process actually for? What would it need to do to serve that purpose? What does that imply about the architecture? This step is where structural solutions are distinguished from symptomatic ones, and where the team develops the reasoning capability to make that distinction themselves going forward.

Transfer — the diagnostic process is designed to be visible and legible to the client team throughout. I do not produce a conclusion in isolation and then present it. I work through the diagnostic alongside the team so they develop the understanding themselves. By the end they know what their system is doing and why, not because I told them, but because we traced it together. That understanding is durable in a way that a report or a list of recommendations is not.

What the Client Team Is Equipped to Do

At the end of any scoped diagnostic engagement I leave the client team with:

•        A clear, shared, accurate understanding of what their system is actually doing in production

•        The ability to distinguish root causes from symptoms, so that changes address the structural source rather than the visible expression

•        A prioritized picture of what needs to change, in what order, and why

•        The diagnostic discipline to repeat this process themselves as their systems evolve, not dependence on external expertise to do it for them

Book a Discovery call

FREQUENTLY ASKED QUESTIONS

  • A standard CRM audit typically measures a system against a framework, a set of best practices, a vendor checklist, or an industry benchmark. It tells you how far your system deviates from a defined standard. That is useful as far as it goes, but it does not tell you why your system behaves the way it does in production, or what the structural cause of that behavior is.

    The diagnostic method works from evidence. It starts with what the system is actually doing with real data and real users today, and works backwards to understand why. The output is not a score or a deviation report. It is a shared understanding, held by your team, of what is structurally wrong and why, grounded in evidence that your team gathered and can trace back to its source.

    The other difference is transfer. An audit produces a report that sits with the auditor. The diagnostic produces understanding that sits with your team. That distinction determines whether the findings lead to durable change or another cycle of the same problem.

  • It depends on the scope agreed at the start of the engagement. A well-defined, contained problem can move through the full diagnostic process in 2-3 weeks. A complex structural issue spanning multiple systems, functions, or integration points will take longer. There is no standard duration, each issue has it’s own DNA, because no two CRM environments have drifted in exactly the same way or at the same scale.

    Speed also depends on how much time the client wants to commit and how they choose to structure their hours. A Full subscription provides 16 hours per month. Those hours can be distributed in whatever way works best for the engagement. A client who wants to move quickly can front-load the available hours, concentrating more sessions into the early part of the engagement to accelerate the diagnostic phase, then spreading the remaining hours across the rest of the time for review and follow-up work. The pace is in the client's hands within the available hours.

    What the scoping step does is establish a realistic picture of what needs to be understood and in what order. That gives both parties a working estimate before the diagnostic begins. As the work progresses the estimate is reviewed and adjusted at the regular sponsor review meetings. If the diagnostic surfaces new threads worth pursuing, those are agreed as additional scope rather than absorbed silently into the original estimate.

    The goal is always to use the minimum time necessary to reach an evidenced, understood root cause and a clear path to resolution.

  • Yes. In practice, documentation may be incomplete, outdated, or absent entirely. Many CRM environments have evolved over years without anyone maintaining a reliable record of why decisions were made or how the system was configured. If your documentation accurately reflects how your system behaves in production, you probably would not be reading this. The gap between what the documentation says and what the system actually does is often part of the problem being diagnosed.

    The diagnostic does not rely on documentation as its primary source. It relies on the system itself. Real records, real data, real behavior observed directly in the production environment. Documentation is useful context where it exists and is trustworthy. Where it does not exist or cannot be trusted, the system is the source of truth.

    What the engagement does require is people who know the system from working in it every day. The institutional knowledge held by the working group, even when it is incomplete or partially incorrect, is the starting point. The diagnostic process tests that knowledge against what the system is actually doing and corrects the picture where the two diverge. By the end the team has an accurate understanding of their system grounded in evidence, not in documentation that may not reflect reality. At that point the documentation can be updated to reflect what the system actually does and why.

  • A diagnostic engagement is designed to reveal what is actually wrong, not to produce a list of work that justifies further spend. Sometimes what it reveals is more than the organization can address immediately. That is useful information, not a failure of the engagement.

    The diagnostic output becomes a prioritized picture of what needs to change, in what order, and why. Not everything may need to be fixed at once. Some structural problems are more consequential than others. Some can be worked around temporarily while more critical issues are addressed. The diagnostic gives the client team the understanding to make those prioritization decisions intelligently rather than by instinct or urgency.

    The findings belong to the client team. The implementation of fixes is theirs to execute, in their own time, through their own processes. The key point is the team has the accurate knowledge of what is wrong.

  • Yes. The diagnostic method has two contexts. The first is forensic, applied to an existing system that has drifted from operational reality, tracing what went wrong and why. The second is prospective, applied before a system is built or a significant architectural decision is made.

    In the prospective context the method works differently but draws on the same foundation. Rather than tracing evidence of what went wrong, it applies the patterns of failure that production experience reveals to stress-test proposed architecture before it exists. The questions are the same: what is this process actually for, what does the system need to do to serve that purpose, and what architectural decisions will create problems at scale that are not visible yet.

    Catching those decisions before they are built is significantly less expensive than diagnosing them after the fact. If you are in the process of designing or selecting a new CRM environment, a prospective diagnostic engagement is worth considering before the architecture is finalized. This also applies to clients who are evaluating whether to replace their existing CRM entirely. Understanding the structural issues in the current system before making that decision ensures the replacement is specified to solve the real problems, not just the visible ones, and avoids rebuilding the same structural issues in a new platform.