I go into the systems you already run on (your CRM, booking or POS
system, phone logs, spreadsheets) and trace the problem you care about
to the cause. In two weeks you get the root cause, the evidence behind
it, and a plan to fix it, ranked by what each fix is worth. If the fix
is software, I can build it.
Fig. 01 / Symptom to root cause
01 / The symptom
"Our intro offers sell, but almost nobody becomes a member after the trial."
02 / The story
"Trials run 14 days from the first class."
≠
03 / The data
Bought
1st class
Trial ends
Sep 2
Sep 20
Sep 16
Sep 3
none
Sep 17
Sep 21
Sep 22
Oct 5
04 / Root cause
The trial clock started at purchase instead of the first visit.
05 / Ranked fix plan
1Start trials at first check-in
2Add a "paid, never came in" list
Illustrative records
i100 of 111active trials showing the wrong end date, found in a studio's own booking data
ii31paying customers who never came in, and no report anywhere showed them
iii12.6%of support cases with any root cause recorded, under a metrics plan that assumed the data was there
Why the problem keeps coming back
Everyone has a theory about the cause, and the theories don't match. Meetings end with more opinions, not an answer.
The report everyone trusts is quietly wrong: a timezone, a test account, a clock that starts at the wrong moment.
Money goes into new software or another hire before anyone checks which problem it's supposed to fix.
I start with the records, not the theories. Put what people believe next to what the data shows, and the cause is usually sitting where the two disagree.
01 How the two weeks work
One problem, fourteen days, a fixed price. I work from whatever you already have: CRM, booking or POS exports, phone logs, payment records, spreadsheets. Read-only access is enough.
1234567891011121314
01 Pull02 Disagree03 Trace04
Days 1 to 3
Pull the records
A short call on the symptom and what your team believes is causing it. Then I pull the raw data behind it.
Days 4 to 8
Find where it disagrees
Check the numbers against each other and against the story. Dates, duplicates, missing fields, accounts that shouldn't count.
Days 9 to 12
Trace it to the cause
Follow each mismatch back to where it starts, and test each cause against the records until one holds up.
Days 13 to 14
Hand you the plan
A written report: the cause, the evidence, and the fixes ranked by value and effort. We walk through it together.
02 Case files
File 01
The trials that ended before they started
SweatSet · fitness studio
31
paid intro customers nobody could see
The question
Who is in their 14-day intro trial right now, and who needs a follow-up?
The data
Intro purchases and class check-ins from the studio's booking system.
What it showed
100 of 111 running trials had the wrong end date. Most people bought the intro before opening day, so their trials looked expired before their first class. And 31 people had paid for the intro and never come in at all.
Root cause
The trial clock started at purchase instead of the first visit.
The fix
Trials now start at first check-in, and a new "paid, never came in" list shows up on the dashboard and in the nightly email.
File 02
A metrics plan built on empty fields
Hardware manufacturer · support team
12.6%
of cases with any root cause recorded
The question
Leadership had a detailed proposal for a service metrics program. Can the data actually support it?
The data
Support cases in the CRM, field by field, checked against each requirement in the proposal.
What it showed
The link from a case to the installed product was filled in on about 9% of cases. A failure analysis object had been built and never used. The detailed root-cause and diagnosis fields were empty. There was no first-response timestamp at all, and a one-day bulk close of 5,300+ cases was invisible to every metric.
Root cause
The plan assumed data the team had never been asked to capture.
The plan
Launch with the five metrics the data supports today (service level, abandonment, first contact resolution, 90-day repeat contact, backlog aging), and start capturing the rest going forward.
File 03
The AI answer that sounded right
Hardware manufacturer · AI support assistant
3
separate causes behind one wrong answer
The question
Why did the support assistant give a confident, wrong product compatibility answer in production?
The data
The assistant's full conversation trace, what it searched for, and the knowledge base it had to work with.
What it showed
It made up a serial-number decoding table instead of using the real one, then reasoned from the made-up table to a wrong verdict.
Root cause
Three things at once: nothing stopped it from inventing reference data, the knowledge base was out of date, and it never searched for the decoder document that already existed.
The fix
A guard on each of the three, so one failing on its own can't produce a wrong answer again.
03 Then I build the fix
When the fix is software, I build it myself and wire it into the systems you already use. These are running in production now.
~2,000calls a month
AI voice agent
Answers inbound support calls, handles the routine ones, and routes the rest to a person with the context attached.
One problem, traced to its root cause in your data. You get a written report with the evidence and a fix plan ranked by value and effort, plus a walkthrough call.
Build the fix
Fixed quote from the plan
If a fix on the plan is software (an automation, a dashboard, a voice agent, a data cleanup), I quote it as a fixed price and build it. You decide after you've read the plan.
Keep it running
$2,500 to $3,500 / month
Ongoing support once fixes are live: watching the numbers that matter, fixing what breaks, and making small changes as the business shifts.
05 Who you'd be working with
Chris Bullard
I work on operations problems for a living, and I build the software myself. Everything in the build list above is mine and running in production.
The build is rarely the hard part. Knowing which problem is real is the hard part, so that's what I sell first: two weeks in your records, finding the cause, before anyone spends money building.