How a Diagnosis Actually Works

The situation

A mid-size company generates a steady stream of inbound leads through its website and referrals. Sales says marketing sends unqualified leads. Marketing says sales takes too long to follow up. Leadership isn't sure who's right, only that deals which should be closing aren't, and nobody can say with confidence how long a lead actually waits before someone responds.

This is a realistic composite of the kind of complaint a diagnosis usually starts with, built to show how the process works, not a description of one specific client or engagement.

Understand

The first conversation isn't about CRMs or automation. It's about what leadership actually knows versus what they assume. In a situation like this, nobody can answer, without checking manually, how long a lead sits before first contact, how many leads never get a second touch, or where in the process leads actually go cold.

Map

Mapping the path a lead actually takes, not the path anyone assumes it takes, is usually where the real picture shows up. A lead arrives through a form. It lands in an inbox, not a CRM. Someone copies it into a spreadsheet once a day, by hand. Sales works from whatever's on top of that spreadsheet, not necessarily the newest or most promising lead. There's no record of who followed up, or when, unless that person remembers to log it themselves.

Diagnose

Once mapped, the pattern is usually not what either side assumed. It's rarely that marketing sends bad leads, or that sales is lazy. It's that the handoff between "a lead exists" and "a person is accountable for responding to it" has no owner and no system: a disconnection problem, not a people problem. (See The Disconnection Gap.)

Design: applying Keep, Improve, Connect, Replace, Build

Running the actual framework against each part of a process like this usually looks something like:

• Keep the CRM already in place: it isn't the problem, and replacing it would solve nothing.
• Improve how leads are qualified, if the current criteria are inconsistent or undocumented.
• Connect the form submission directly to the CRM, removing the manual copy-and-paste step and the daily spreadsheet entirely.
• Build one small, specific piece that doesn't exist yet: a way to know, automatically, the moment a lead has gone untouched for too long.

Notice what's not on this list: a new CRM, a chatbot, or a general-purpose "AI sales assistant." The diagnosis rarely calls for the most dramatic option. (See Automation Is Not the Diagnosis.)

Build

In a case like this, "build" is usually small and targeted: a routing step that gets each qualified lead into the CRM the moment it arrives, and a lightweight alert if a lead has sat untouched past an agreed window. It's a detail in service of the diagnosis, not the headline of the engagement.

Verify & Measure

The measure gets defined before anything is built, not chosen afterward to justify it: time from lead submission to first human contact, and the share of leads that receive a documented follow-up at all. Whatever the diagnosis identifies as the actual cost (slow response, lost leads, wasted sales time) is what gets checked against, once the fix is live.

What this illustrates

The point of walking through this isn't the specific fix. It's the order: understand, map, diagnose, and design before anything gets built, and a design that's willing to say "keep" and "connect" more often than "replace." A handful of examples of what this looks like across different business functions are on the homepage, and a set of systems actually built this way is here too.