Why automation projects fail in 20-person practices

A practice owner called me last year about an AI scribe. He had read that it could cut his charting time in half, and he wanted to know which one to buy. I asked him a different question first: how long does it currently take, from the moment a patient leaves the room to the moment the chart is closed and the claim is submitted?

He didn't know. Nobody in his practice knew. There was no number.

That is where almost every automation project in a small practice goes wrong, and it goes wrong before a single tool is ever purchased. The owner reaches for the software before anyone has measured the problem the software is supposed to solve. He is prescribing before he has diagnosed.

You would never do that with a patient. You would not hand someone a prescription before you knew what was wrong with them. You would take a history, run the labs, look at the imaging, and only then decide on a course of treatment. The discipline that feels obvious in the exam room gets abandoned the moment the same person walks into their own back office.

The seduction of the tool

I understand why it happens. Tools are concrete. A demo is satisfying to watch. The salesperson is confident, the interface is clean, and the promise is specific: cut charting time in half, reduce no-shows by thirty percent, automate your intake. The owner is exhausted and the tool looks like rest.

But a tool is an answer, and the practice has not yet asked the question.

What I see, over and over, is a practice that buys the answer to a problem it has not defined. The AI scribe gets installed. Three months later, two of the providers have stopped using it because it does not match how they actually document. The medical assistants have built a workaround. The thing that was supposed to save ten hours a week is saving two, and nobody is quite sure even of that number, because there was never a baseline to measure against.

The tool did not fail. The sequence failed. The practice automated a process it had never actually understood.

A broken process, automated, is a broken process at scale

This is the part that owners underestimate. They assume that software imposes order — that the act of digitizing a workflow will clean it up. The opposite is true.

Software does not fix a broken process. It accelerates it. If your intake process has three different paths depending on which front-desk person is working that day, automating it does not resolve the inconsistency. It encodes the inconsistency and runs it faster. Now you have three automated paths, each of them slightly wrong, and a vendor contract that makes them harder to change than they were when they lived on paper.

The practices that get real value from technology are the ones that did the unglamorous work first. They mapped the process. They agreed on the single right way to do it. They ran it manually, with people, until it was clean and consistent and measured. And then — only then — they automated the thing that had already earned the right to be automated.

A process that works on paper will work better in software. A process that does not work on paper will fail in software, and cost more while it fails.

What diagnosis actually looks like

When I start with a practice, I do not talk about tools for the first several weeks. I do something that looks almost too simple. I listen, then I observe, then I measure.

First, I talk to the people who do the work — not the owner's idea of how the work happens, but the actual account from the front desk, the clinical staff, the billers, the people who touch the workflow every day. What they describe is rarely what the official process says. That gap is the first finding.

Then I watch. I shadow the practice through real operating days and time the work as it actually happens. What people report and what actually happens are never identical, and not because anyone is lying. We all normalize our own routines. The biller who says reconciliation takes "an hour or so" is genuinely surprised when it turns out to take three.

Then I measure. I capture a small set of numbers that become the practice's operational vital signs: cycle time, the wait at each handoff, the no-show rate, the time from visit to chart closed, the denial rate, the hours staff spend on work that does not require their training. These numbers are the "before." Without them, you can never know whether anything you change actually helped. You will be operating on impressions, and impressions are how practices end up paying for tools that feel productive but move nothing.

Only after all of that do I diagnose — and even then, I do not try to fix everything. I look for the vital few: the twenty percent of issues that drive eighty percent of the friction. I fix those first, manually, and I re-measure. If the numbers move, the process was right and now it has earned the right to be made permanent, and eventually, automated. If the numbers do not move, better to learn that with a whiteboard and a week than with a software contract and a year.

The order is the whole thing

None of this is complicated. That is what makes it hard to sell and easy to skip. There is no product to demo, no dashboard to show in the first meeting, nothing that photographs well. It is just the discipline of doing things in the right order.

Diagnose before prescribing. Manual before digital. Fix the vital few and measure before you scale.

Most automation projects in small practices fail not because the technology is bad but because the practice reached for the technology first. The owner bought the answer before asking the question. By the time the tool is installed, the disorder it was supposed to fix has simply been wired into place, faster and harder to undo.

The practices that win with technology are not the ones that adopt it earliest. They are the ones that earned it — that did the quiet, unglamorous diagnostic work first, proved the process by hand, and only then let the software make permanent what was already working.

That sequence is what Steady Flow is built around. We diagnose practices the way physicians diagnose patients: by listening, observing, measuring, and only then prescribing. If you are about to buy a tool, it might be worth a conversation first.