What a good diagnosis tells you

Why an automated mess is a faster mess

Dana’s shortlist from Chapter I has three items. Estimates that sit overnight. Appointment confirmations that do not go out. Dispatch questions that come back to her.

Her first instinct on the estimates is to buy estimating software. It would produce a clean-looking estimate in four minutes instead of twenty. And it would still sit overnight, because the reason estimates sit is not that they are slow to write. It is that the request lands in an inbox Dana reads once a day, and nobody else knows it arrived.

Automate that as it stands and you get faster estimates that are still late. The wait was never in the writing. It was in the hand-off.

This is the rule. A system makes a process run the way it already runs, only more. If the process waits on the wrong person, the system waits on the wrong person. Fix the wait first, then decide what deserves speed.

Write down what happens today, in order

The diagnosis starts with a boring document. For each item on the shortlist, write the steps as they actually happen, not as they should.

For Dana’s estimates it reads like this. Request arrives by web form, text, or phone. Whoever gets it forwards it to Dana or tells her in passing. Dana reads it, sometimes the same day. She calls the customer to ask two questions the form did not. She drives out, or sends a crew lead. She writes the estimate in a spreadsheet from the last similar job. She emails it. Nobody follows up unless the customer calls.

Nine steps. Written down, three things jump out that were invisible in her head. The request has three front doors and no single place it lands. The two questions she always asks could have been on the form. And the follow-up step does not exist.

You do not need a consultant for this. You need forty minutes and honesty about how it actually goes, including the parts that only work because someone remembers.

Find the step where things wait

In every written-down process, most steps take minutes and one or two take days. The days are the problem.

Look for the places where the work sits between one person and the next. A request waiting to be noticed. A question waiting for you to be free. A document waiting for a signature. Circle them.

Those circled steps are almost never the steps people complain about. Dana complained about writing estimates. Writing took twenty minutes. Waiting to be noticed took a day and a half.

Once the waits are circled, the fix is usually obvious and usually smaller than expected. Estimates need one front door and someone other than Dana watching it. That is the whole diagnosis for item one. It is not a build.

Sometimes the answer is a tool you already own

This is the part most people selling automation will not tell you.

A good share of what comes back from a diagnosis is a tool the business already pays for, set up properly. Dana’s phone system can send appointment confirmations by text. It has been able to for two years. Nobody turned it on because the setting was three menus deep and the dispatcher did not know it existed.

The same thing shows up in other businesses in other forms. The meeting notes app that could send a summary to the team automatically, and does not. The calendar that could hold a buffer between jobs, and does not. Something like Granola for meeting notes, connected to Claude to draft the follow-up, is a real fix for a real week, and it costs a morning to set up.

This is why the diagnosis comes before the build. Half the time the honest answer is “you have this, here is how to use it.” Building something on top of a tool that already does the job is how businesses end up paying for the same thing twice.

Decide what you will still approve by hand

The last piece of a diagnosis is a line. On one side, things a system may do without asking. On the other, things that come to you first.

Dana’s line looks like this. A text confirming tomorrow’s appointment goes out on its own. A text asking a customer whether they have questions about an estimate goes out on its own. An estimate over a certain size waits for her. A message to an upset customer waits for her. A crew reassignment goes to the dispatcher, never straight to the crew.

Draw the line before anything gets built, because it is the one thing that cannot be guessed. A builder who guesses will either ask you about everything, which puts the work back on your desk, or ask about nothing, which is how a customer gets a message you would never have sent.

The line moves later. It starts conservative.

Common mistakes

Diagnosing from memory. The process in your head is the one from the good days. Write the one from last Tuesday.

Skipping the part where you turn a setting on. It feels too small to count. It is usually the highest return on the whole list.

Letting the fix pick the problem. If you have already decided on a tool, you will find a problem it solves. Find the problem first.

Treating the diagnosis as the deliverable. It is a page, sometimes two. If it takes a week to produce, somebody is selling you the diagnosis instead of the fix.

What comes next

You now know, for each item on the shortlist, where the wait is, whether an existing tool covers it, and where the approval line sits. Some items are already fixed.

Whatever is left is a build. Chapter III is about where that build lives, and why the answer is never a new app.