The Leverage Diagnostic
What £7,500 buys.
The deliverable in full, written out for a business that does not exist. Real diagnostic reports stay with the client who paid for them, so this one is an illustration. What it shows you is the depth.
This is an illustration, not a client engagement. No business described here exists. The company, the systems, the findings and every number in this document are invented to show what the deliverable contains, how deeply it goes, and how a recommendation gets argued. Real diagnostic reports are not published. They contain a live business’s operational weaknesses in present tense: where the process leaks, which numbers cannot be trusted, what the reporting is hiding. That belongs to the client and to nobody else, and it stays that way whether or not I have a stake in the business. What can be published is the shape of the work, which is what this is. The findings below are the kinds of thing a diagnostic turns up, written at the depth a real one is written at. If your business has none of them, that is a good sign and the diagnostic would tell you so.
1. The question you asked
You asked me to work out why the conversion rate had stopped improving.
The answer is that you cannot work that out, and neither can I, because nothing in the business records why a lead does not convert. You are measuring the outcome and not the cause, and no amount of analysis on the outcome will produce the cause.
So the real question is the one underneath: what would it take to know why? That is what the two weeks answer.
Out of scope: delivery quality, pricing strategy, staffing and the physical estate. All four came up. None of them is what is blocking this.
2. What I looked at
Ten working days. The systems, not the slide decks.
Databases. The production database, read-only, against a restored snapshot and never the live instance. The tables behind bookings, customer records, onboarding state and whatever the reporting layer reads from.
Reporting. The board pack for the last four quarters, the KPI definitions as they exist in code, and the dashboards the commercial team open day to day.
Calls. Forty recorded sales calls in the first week, weighted towards leads that did not convert, each coded by hand against a rubric written during the diagnostic. That hand-coding is the most useful thing in the document and it is also the thing that does not scale, which is most of the argument in section 4. The sixty calls used to test the working version in section 4 are a separate draw.
People. A couple of hours each with the commercial and operations leads, an hour with the people who take most of the inbound calls, and a session with whoever owns the reporting.
What I could not get at. Two things, and both limit what follows. Recordings older than nine months have been rotated out, so nothing here speaks to a full year of seasonality. And paid spend lives in the ad platforms rather than in the database, so cost per acquisition is stitched together by hand. I have used it for direction and not for arithmetic, and I would not put it in a board pack until item 3 is done.
A report that lists its own blind spots reads as competent. One that implies total visibility reads as a sales document.
3. What I found
Four findings. There were more things worth saying and they are not here, because narrowing is the part you are paying for. Each one is what is happening, how I know, what it is costing you, and why it has not been fixed already.
Finding 1: There is a field for the reason and it has never been filled in
What is happening. The CRM carries a decline-reason field. It is present on every lost lead and set on none of them. The team records the outcome of a call and closes it. Nothing captures what was said.
How I know. A count of distinct values in that field returns exactly one, and that one is the unset default. There is no partial adoption to build on.
What it is costing. Not measurable from inside the system, which is the problem. From the hand-coded sample the reasons cluster into a small number of causes, and some of them look addressable without building anything. I am not going to put a percentage on a sample of forty and neither should you.
Why it has not been fixed. Because filling the field in is unpaid admin at the end of a call that has just gone badly, and nobody has ever shown a salesperson what their entries were used for. This is the normal reason optional fields stay empty, and it is why the recommendation in section 4 does not ask anyone to start filling it in.
Finding 2: Lead source is captured inconsistently at the entry points
What is happening. Web, phone, paid social and walk-in all write different things into the same field, and a large share write nothing usable. A significant proportion of leads sit in an unmapped bucket.
How I know. Grouping leads by whether their source resolves to a known channel, and counting what does not.
What it is costing. Marketing spend cannot be judged. Every channel efficiency number in the board pack is computed on the minority of leads that happen to be attributable and read as though it describes all of them. That is not a reporting quirk. Spend decisions are being made on a biased sample and nobody in the room knows it.
Why it has not been fixed. Each entry point was built at a different time for a different reason, and each was individually sensible. Nobody owns the seam between them.
Finding 3: The headline number has more than one definition
What is happening. The headline rate comes from stored counters incremented as things happen. The board view derives its own from events. A third dashboard does a third thing. They disagree, and which one gets quoted depends on who pulled it.
How I know. Recomputing the same four quarters three ways and getting three answers. The gap is not rounding.
What it is costing. Every argument about whether a change worked becomes an argument about whose number is right. The cost is not the reporting error. It is that the business has stopped trusting its own numbers and started deciding on instinct.
Why it has not been fixed. Each of the three was correct when it was written, and no single person owns the definition.
Finding 4: Recent periods flatter themselves, systematically
What is happening. A conversion resolves the moment it happens. A non-conversion only resolves once enough time has passed to be sure it is not coming. Any period still in progress therefore contains all of its wins and only some of its losses, and its rate is too high. It falls as the period matures.
How I know. Tracking the reported figure for a fixed period at intervals after it opens. It declines for a couple of weeks, then settles. Every period does this. The board pack reports the in-progress figure without a caveat.
What it is costing. An optimistic number is being read as a real one, and the correction arrives a fortnight later when nobody is looking. It also means any intervention measured in its first fortnight will look like it worked.
Why it has not been fixed. It is invisible unless you go looking. The number is not wrong on the day it is printed. It is just not finished.
4. What I proved
Findings are opinions until something tests them. The plan below leans hardest on one assumption, so that is the one the fortnight put weight on.
Track: a working proof. Agreed on the first call, before you committed.
The assumption. That the loss reason can be read out of a recorded call accurately enough to run a business on. Everything in the plan that reports why you lose depends on it. If it is wrong, the recommendation is wrong, and you would have found out four months into a build.
What I built. A rough working version that takes a recording, transcribes it locally, and classifies the loss reason into your existing categories. It runs on one machine from a command line. Sixty calls were drawn at random from the last quarter, none of them among the forty hand-coded in week one.
The test we agreed before it ran. Two people from your team coded the same sixty calls by hand, blind to each other and to the machine. The bar was 80% agreement with the human consensus. Below that the plan changes.
The result. 50 of 60, which is 83%, and one category that failed badly.
| Category | Calls | Machine agreed with consensus | Rate |
|---|---|---|---|
| Timing, “not right now” | 22 | 20 | 91% |
| Fit, wrong product for them | 17 | 15 | 88% |
| Competitor named | 14 | 12 | 86% |
| Price | 7 | 3 | 43% |
It cleared the bar and then told me something more useful than the bar did. “Price” fails because your team uses the word for two different situations: a customer who cannot afford it, and a customer who can and is not convinced it is worth it. Those need opposite responses. The machine cannot separate them because the category does not.
What that changed. Two things, before either was built. The category gets split at the source, and the reporting in section 5 counts them separately from day one instead of being corrected in a year. Neither of those was in my plan on day one of the fortnight. The proof put them there.
What it deliberately does not do. It has no interface, no authentication, no retention policy and no error handling worth the name. It is not a system and must not be treated as the start of one. Reading sixty calls once is not the same problem as reading every call forever, and section 5 prices the real version.
Yours. The working version, the sixty transcripts, the hand-coded sheet and the comparison are handed over at the end of the fortnight, whatever you decide to do next. If you never build anything, you still know what your call recordings are worth, and you know that one of your four categories is two categories.
5. What I would build, in what order
The order matters more than the list. Findings 3 and 4 mean nothing you measure today can be trusted, so anything built before those are fixed gets evaluated against a number that moves for unrelated reasons.
Each one carries what it is for, what it takes, and how you will know it worked.
1. One canonical definition of the funnel
What it does. A single service that builds a cohort from source state and derives every stage from real events rather than stored counters. Every dashboard, KPI adapter and the board pack read from it. Nothing else computes a stage.
Why it is first. Everything downstream is measured against these numbers. Do it last and you will have spent the year improving a figure you cannot defend.
What it depends on. Nothing. It can start immediately.
How you will know it works. The competing sources produce the same number for the same period, or the ones that disagree have been deleted. A named person can state the definition of “converted” without looking it up.
Estimate. 8 to 12 days. Top of the range if historical counters disagree with events in ways that need reconciling rather than replacing.
2. A maturity rule on every reported rate
What it does. The funnel service computes how much of a period has had time to resolve, and below a named threshold reports converted-so-far and labels the period developing, instead of printing a flattering rate off a biased sample.
Why it is second. Small, depends on the first, and until it exists every period opens with a number wrong in a predictable direction.
What it depends on. Item 1.
How you will know it works. The reported rate for a period stops falling over its first fortnight, and an immature period is visibly labelled as such.
Estimate. 2 to 3 days.
3. Source attribution, repaired at the entry points
What it does. One taxonomy, written at every entry point, a backfill for what can be recovered, and an explicit unmappable bucket for what cannot.
Why it is third. It unblocks every spend decision and it is cheap. It sits below the funnel work only because attributing to a stage definition that is about to change means doing it twice.
What it depends on. Item 1.
How you will know it works. The unmapped share of new leads drops into single figures, and what remains is unmappable for a stated reason rather than by accident.
Estimate. 5 to 8 days.
4. Reading the calls at scale, on hardware you own
What it does. Call audio is transcribed locally, then read by a local language model that assigns each lost lead a structured cause, an owner and a verbatim quote supporting it. Every conclusion has to quote the sentence it came from. If it cannot, it is not shown.
Why it is fourth. It answers the original question and it is the largest piece. It sits after the definitions because a cause attached to a stage nobody agrees on is not usable.
What it depends on. Items 1 and 3, plus hardware, which is a capital purchase and not build days.
Where it runs, and why that is decided early. Recordings of customers are personal data, and some of what is said in them is more than that. Sending them to an outside service is not ruled out by that: with the right contract in place, it can be done lawfully. What decides it is how sensitive your recordings are, what the service does with them, where it processes them, and what your own policies and your sector require. For recordings of real customers, at least one of those answers points to keeping the processing in-house. The decision belongs at the start, because retrofitting privacy does not work, and be wary of a proposal that has not asked you a single one of those questions.
How you will know it works. A month of lost leads carries structured causes with quoted evidence, a manager can open any one and read the sentence it came from, and spot-checking twenty against the recordings agrees with a human coder more often than two human coders agree with each other.
Estimate. 20 to 30 days, plus hardware. Top of the range if audio quality across older recordings needs per-source handling.
5. Business context inside the assistants people already use
What it does. Servers exposing the real systems to whatever AI assistant each person already works in, so a question about the pipeline or a specific customer is answered from live data with that person’s permissions attached.
Why it is last. Highest leverage per day spent, and worth nothing until items 1 to 4 make the underlying numbers true. Given no context an assistant invents one, confidently, and a confident invention attached to your real business is worse than no assistant at all.
Estimate. 8 to 12 days for the first two.
If you only do one thing
Do item 1. The rest of the plan still stands afterwards, and without it none of the rest can be evaluated. If the budget halves, do items 1 to 3 and run the hand-coding from section 2 as a monthly manual exercise on a sample of twenty calls. That is a real answer at lower resolution for a fraction of the cost, and it tells you whether item 4 is worth its estimate before you spend it.
6. What I would not build
Half a page, and it does not get cut. My own writing tells buyers to ask a prospective CTO what they would tell them not to do. The diagnostic answers that before it is asked.
A CRM replacement. Raised on most engagements, and rarely the problem. Nothing writes the reason into the current one and a new one will have the same empty field.
Anything that asks the sales team to fill in a form after a call. This has normally been tried already. It fails for a structural reason, not a motivational one, and a second attempt with better training will also fail. Read the reason off the recording that already exists.
Predictive lead scoring. Several vendors will sell you this. Until findings 3 and 4 are fixed, a model trained on your conversion data is learning your reporting artefacts. Scoring leads before you can define a conversion is astrology with a spreadsheet attached.
A dashboard for a problem that needs an action. Some findings do not need measuring, they need a phone call and a reminder. Build the operational fix, not the report about it. If it does not move after two months of trying, instrument it then.
7. What this costs
| Item | Days | Illustrative cost |
|---|---|---|
| 1. Canonical funnel definition | 8 to 12 | £8,000 to £12,000 |
| 2. Maturity rule | 2 to 3 | £2,000 to £3,000 |
| 3. Source attribution | 5 to 8 | £5,000 to £8,000 |
| 4. Reading the calls at scale | 20 to 30 | £20,000 to £30,000 |
| 5. Business context servers | 8 to 12 | £8,000 to £12,000 |
| Total | 43 to 65 | £43,000 to £65,000 |
Illustrative of the format, at the published £1,000 day rate. A build is quoted against its own specification; this Diagnostic’s price does not depend on these days.
Not included. Hardware you buy once and own. Third-party licences. Your team’s time in review and acceptance, which is real and which people forget.
What moves the number up. Historical data needing reconciliation rather than replacement. Audio quality needing per-source handling.
What moves it down. Doing items 1 to 3 and stopping to look. That is 15 to 23 days and a legitimate place to stop.
If you build this with someone else. The plan is yours. It is written to be built from, with acceptance criteria on each item, so another competent team can execute it without me. I would rather you did that than did nothing, and I will answer questions from whoever you pick.
8. Risks, and what would change my mind
The finding I am least sure of is the size of the prize in finding 1. Forty hand-coded calls establish that causes exist and that they cluster. They do not size the recoverable share, and nothing above pretends they do.
What has to be true before you spend on item 4. Two months of the manual route come first. Hand-code twenty calls a month, take the most common cause you can act on, act on it for the lost leads it names, and count how many you win back. That turns the recovery rate from an assumption into a measurement.
Then compare the two routes over a year. Value means contribution, the margin a recovered customer adds and not their revenue, plus the staff time a route saves:
- Keep the manual route. The contribution from the leads twenty calls a month can reach, at the measured recovery rate, less the hours the coding takes.
- Build item 4. The contribution from every call, at the same measured rate, less the build, the hardware, a year of running costs and your team’s review time.
Approve item 4 only if what it adds over the manual route pays back its full cost within twelve months, and the estimate stays inside £30,000. If it does not, keep the manual route. That is a successful answer and not a failed diagnostic, and the two-month test costs a few days of someone’s time, not £20,000.
The assumption the whole plan rests on is that the causes of non-conversion are visible in the call. If a material share of leads never reach a call, the pipeline is answering a question about the wrong population. The attribution work in item 3 shows this within a fortnight of going live, which is another reason it sits early.
What would tell you in month one that the plan is wrong. If, after items 1 and 2, the reconciled numbers show the rate never stopped improving, and the plateau was young months being counted before their leads had time to convert, there is no conversion problem to diagnose. Items 3 to 5 would be solving a reporting error that item 2 has already fixed. I would tell you that and stop.
A report that names the condition under which it is wrong is worth more than one that does not.
9. Evidence appendix
Every figure above, with what produced it. Where something was not measured, it says so, and says what measuring it would take.
| Figure | Source | Method | When |
|---|---|---|---|
| Decline-reason field holds one distinct value | CRM, restored snapshot | Distinct values of the field across every lost lead | Day 2 |
| A significant share of leads have no usable source | CRM, restored snapshot | Group leads by whether the source resolves to a known channel, count the remainder | Day 3 |
| Three headline rates for the same four quarters | Stored counters, board pack export, event log | Recompute each quarter from each of the three sources | Day 4 |
| An in-progress rate falls over its first fortnight | Reporting layer | The reported figure for one fixed period, captured daily until it settled | Days 2 to 10, plus the history the layer keeps |
| 50 of 60 machine agreements, by category | The working version’s output against the hand-coded sheet | Two coders blind to each other, consensus against the machine, counts in section 4 | Days 8 to 10 |
| Cost per acquisition | Not measured | It lives in the ad platforms and not the database. Measuring it is item 3 plus a day of export work |
“Not measured, and here is what it would take” is a more useful sentence than a confident guess, and it is the discipline the rest of this document is asking you to buy.
What this document is not
It is not a proposal, and there is nothing to sign at the end of it.
It is not a pitch for the build. Some engagements conclude that the right next step is not a build at all. That is a real outcome and it is worth the fee, because the expensive version is finding out after the build.
And it is not a description of any real client. Real diagnostic reports stay with the business that paid for them.