Automating a Broken Process: Why It Backfires and What to Fix

You don't, at least not as it stands. Fix it first: map the steps as they really happen, count the exceptions, cut steps that only exist to repair earlier errors, standardise what comes in, then run the cleaned version by hand for two weeks. Automate only the part that now runs the same way nine times in ten.

Automating a broken process makes it fail faster and more quietly, and it can set bad steps in concrete. The fix is mostly unglamorous tidying: five passes over the process, then a clear split between steps for simple rules, steps for AI, and steps that stay with a person.

Follow me on Instagram@sagnikteaches

What a broken process looks like from the inside

Broken rarely means chaotic. Most broken processes work, eventually, because someone patches them every time. These signs are rules of thumb, but two or more together usually mean the process needs fixing before any automation:

Connect on LinkedInSagnik Bhattacharya

• More than one case in ten needs redoing or chasing. Rework is the clearest signal.
• Nobody can write the steps down without saying "it depends" more than twice. Each "it depends" is an undocumented rule.
• Work waits at more than three hand-offs. Each hand-off is a queue where things sit.
• One person holds the know-how. If the answer to "how does this work?" is a name, the process lives in their head.
• Private workarounds exist. A personal spreadsheet, a sticky note, a folder only one person uses.
• Clients get asked for the same thing twice. Information goes in somewhere and doesn't reach where it's needed.

A quick test takes ten minutes: ask two people who both do the task to write down its steps separately, without conferring, then compare. If the lists differ in more than small details, such as one person checking something the other skips, or doing steps in a different order, you have two processes sharing one name. Automation can only follow one of them, and the other person will either work around it or stop using it.

Subscribe on YouTube@codingliquids

Here's that test run on new-client set-up at an illustrative domestic cleaning company, with two supervisors writing separately:

Supervisor A                          Supervisor B
1. Take details on the phone          1. Send the online booking link
2. Visit to quote                     2. Quote from photos the client sends
3. Email the quote                    3. Text the quote
4. Book first clean on acceptance     4. Take a deposit, then book
5. Collect a key at the first clean   5. Ask for a key-safe code
                                      6. Send the "what to expect" sheet

Every step differs, and only one of them sends the sheet that stops first-clean complaints. Until the company picks one route (probably B's, with a visit for larger homes), there's nothing coherent to automate.

For a structured readiness test, how to tell if a process is ready to automate gives a scored version.

Three ways automation makes a broken process worse

A line widely attributed to Bill Gates sums up the principle: automation applied to an efficient operation magnifies the efficiency, and applied to an inefficient one, it magnifies the inefficiency. In a small firm, the magnifying happens in three specific ways.

It fails faster

A flawed step done by hand twenty times a month becomes a flawed step done twenty times in an afternoon. A reminder sequence built on an unreliable "still missing" list will chase clients for things they sent last week, all of them, on the same morning.

The human patches disappear

The person doing the task by hand was quietly fixing problems: noticing a file was missing and phoning the client, spotting that two requests were the same job. Nobody wrote those patches down because nobody thought of them as steps. The automation doesn't know about them, so they simply stop happening.

It sets the bad design in concrete

Once a fourteen-step automation exists, nobody wants to touch it. Changing the process now means rebuilding, re-testing and possibly paying someone, so the awkward steps stay. A process that was easy to change on paper becomes hard to change in software.

The fix-first method, in five passes

This takes about three weeks elapsed for a typical small-business process, but only five or six hours of actual work. Most of the elapsed time is counting.

Pass 1: map it as it really happens (1-2 hours)

Take three recent real cases and trace each one from start to finish with the people who handled them. Write every step, including the waiting and the chasing. Don't map the process as it's supposed to work; map what happened to those three cases. If nothing is written down yet, documenting your processes before adding AI has a simple format.

Here is what one traced case looks like for an illustrative four-person property-maintenance firm that handles repair requests from letting agents. Tag every step that only exists because something earlier was missing:

CASE 3: dripping tap, flat 2 (request from a letting agent)
Day 0   Agent emails request: no photo, no tenant number
Day 0   Office replies asking for a photo and access details   [chase]
Day 2   Agent sends tenant's number; tenant texts a photo
        to the engineer's own phone                            [side channel]
Day 2   Office phones tenant to book a slot; no answer         [chase]
Day 3   Tenant calls back; visit booked for day 6
Day 6   Engineer attends; the right washer isn't on the van    [repeat visit]
Day 9   Second visit; job done
Day 10  Office types up the engineer's paper job sheet         [re-keying]
Day 24  Agent asks for the invoice again "for the landlord"    [asked twice]

Six of the nine lines carry a tag. A dripping tap took 24 days and two visits, and the actual repair was about 20 minutes of work. Automating this as it stands would mostly speed up the chasing.

Pass 2: count the exceptions (two weeks, a few minutes a day)

Keep a tally of every case that didn't follow the main route, with a one-line reason. Two weeks is usually enough to see the pattern: most exceptions come from two or three causes.

An assistant can do the grouping for you, as long as you check its sums. The same maintenance firm ends the fortnight with 38 tally lines and pastes them in with this prompt:

Below is a two-week tally of repair jobs that didn't follow our
normal route, one line each: date, job type, what went wrong.
Group the reasons into no more than five categories, give a count
for each, and quote two example lines per category.
Don't suggest fixes yet.

[38 lines pasted here]

An illustrative reply:

1. Missing access details or tenant contact: 14
   "no tenant number, agent out of office"; "key safe code missing"
2. No photo, so wrong part or wrong trade sent: 11
   "was the cistern, not the tap"; "needed an electrician"
3. Invoice or job sheet requested again: 7
4. Same job reported twice (agent and tenant): 6
5. Other: 3

The categories are useful. The counts aren't: they add up to 41, not 38, because the assistant put three lines in two categories. Ask it to assign each line to exactly one category and list the line numbers under each, then do the count yourself in a spreadsheet. The pattern survives the correction, though: missing access details and missing photos account for most of the exceptions, and both are fixed at the point the request comes in.

Pass 3: remove the repair steps (1 hour)

Look for steps that exist only because something earlier went wrong: chasing because the request was unclear, re-keying because information came in the wrong format, checking because a previous stage is unreliable. Fix the earlier cause, and the repair step goes.

A small print shop shows how this works. Its order process had a step called "prep artwork": a member of staff opened every customer file, converted it, stretched it to the right size and added the extra margin a printer needs at the edges, about 15 minutes an order. It existed because customers sent whatever they had: phone photos, word-processor files, logos at thumbnail size. The tempting automation was an AI tool to resize and fix files. The fix-first answer was a downloadable template for each product with the margins already drawn, a one-line spec next to the upload button, and an automatic rejection of files below a minimum resolution, with a message saying why. The prep step shrank to the few orders that still arrived wrong, and nobody needed an AI tool to repair files that no longer came in broken.

Pass 4: standardise what comes in (2-3 hours)

This is usually the biggest single win. A form instead of an open email, a checklist agreed at the start, one place to send files, a naming rule. Inputs that arrive in the same shape can be handled the same way, by a person or a machine.

For the maintenance firm, the before is an email like "Hi, tenant at flat 2 says the tap's dripping, can you sort? Thanks." The after is a one-page request form that agents fill in instead:

Every field answers a tag from the pass-1 trace or a category from the pass-2 tally. That's the test of a good intake form: nothing on it that the exceptions didn't ask for, so agents don't give up halfway.

Pass 5: run the new version by hand for two weeks

Before automating anything, check the fixed process holds up with real cases. Measure the same things you counted in pass 2. If nine in ten cases now follow the main route, you're ready.

For the maintenance firm, the fortnight with the new form might end like this (illustrative): 31 requests came in, and 28 went through the main route with no chase, one visit and the invoice sent to the address on the form. That's 90%. The three that didn't were a burst pipe reported by phone at 10pm, an agent who ignored the form and emailed as before, and a leak that needed a plumber and then a plasterer. None of the three is a reason to wait. The emergency gets its own route (phone, then the form filled in by the office next morning), the agent gets a friendly note with the form link, and two-trade jobs are flagged by a tick-box. Compare that with the 38 exception lines from pass 2, and the stable part is obvious: the form-to-booking steps are ready to automate.

A web design studio's content chase, before and after

Take an illustrative six-person web design studio that starts about five new site builds a month. After the design is signed off, the client has to supply page copy, images, logo files and logins. Nothing can launch until they do.

Before. Each project manager emails their own version of a list. Clients reply in pieces, across email, file-transfer links, shared drives and messaging apps. Project managers average seven chase emails per project, content takes a median of five weeks to arrive in full, and around three projects in ten have images too small to use.

The tempting automation. An automatic reminder every three days until "content received" is ticked. It would have sent reminders for items already sent through another channel, irritated clients, and done nothing about images arriving at the wrong size.

The fix-first passes. Mapping three recent projects shows content arriving through five different channels. A two-week tally across ten live projects shows that about 40% of chases were for things the client had already sent somewhere else, and about 25% were for items the client didn't understand ("sitemap", "alt text", "meta description"). So the studio:

• replaces the emailed lists with one content form per project, with a plain-English line explaining each item and an example;
• gives each project a single upload location, with the minimum image size stated next to the upload button;
• agrees the content checklist and due dates on the kick-off call, so the client knows what's coming;
• runs the new version by hand on three projects for two weeks. It holds.

Then the automation, which is now much smaller. A rule-based reminder goes out only for form items still empty five days after their due date. An AI step reads submitted page copy against the page brief and drafts a short note for the project manager listing anything missing, such as a page with no call to action or copy far shorter than the design allows. The project manager reviews the note before it goes to the client. The image size check is a simple rule, not AI.

Illustrative result after two months: chase emails fall from about seven per project to two, and content arrives complete in a median of two and a half weeks rather than five. Most of that improvement came from the form, before a single step was automated.

Which parts to automate once it's fixed

A fixed process usually splits into four kinds of step. Match each to the right handler; AI versus rule-based automation goes into the choice in more depth.

Rules are cheaper, more predictable and easier to check than AI. Use AI only where the step genuinely involves reading or writing language.

If you've already automated a broken process

It happens, and it's recoverable. Work through these in order:

1. Stop anything that sends. Switch message-sending steps to create drafts, or pause the workflow, so no more damage reaches clients while you fix it.
2. Write down what the automation actually does, step by step. Open it and list every step. You'll often find steps nobody remembers adding. An automation audit covers how to do this across all your workflows. In one illustrative case, a small recruitment agency listing its eleven-step candidate workflow found a step that copied every incoming CV into a shared folder owned by a consultant who had left four months earlier.
3. Run the five passes on the process, not the automation. Fix the process on paper first.
4. Rebuild smaller rather than patching. The fixed process usually needs a fraction of the old steps. Patching the old automation keeps its bad assumptions.
5. Run the new version quietly alongside the old before switching over. Piloting in shadow mode explains how to do this without clients seeing either version's mistakes.

Then retire the old version completely, so nothing half-works in the background. A broken process with a failed automation on top is one of the common roots of why AI projects fail in small businesses, and cleaning it up properly is what stops the next attempt going the same way.

More on fixing before automating

How do I know the process is stable enough to automate now?

Run the cleaned-up version by hand for two weeks and count how many cases go through it the same way. If about nine in ten follow the standard route and the rest have a clear place to go, the standard route is ready. If the exceptions keep changing or people still disagree on the steps, give it another fortnight before building anything.

Can AI help me fix the process itself?

Yes, for the analysis. Paste in your exception tally and ask it to group the reasons, or record yourself walking through a real case and ask for a draft process document. It is useful for spotting patterns and writing things up. The decisions about which steps to remove, and what clients are asked to do, still need to be yours.

What if the broken part is what clients send us?

That's common, and it is usually the most valuable thing to fix. Replace open-ended requests with a single form or checklist, explain each item in plain words, give one place to send things, and agree dates at the start. Clients rarely send the wrong thing on purpose; they send what the request allowed.

Further reads

• What Should a Small Business Automate First With AI? — Choose which fixed process to automate first.
• How to Set a Baseline Before You Introduce AI — Measure the cleaned-up process before any automation.
• How to Map Your Customer Journey and Find Where AI Helps — Map the client side of the process as well as yours.
• Reduce Owner Dependency: Use AI to Capture What Only You Know — When the broken part is know-how held by one person.
• Is It Worth Automating a Task You Only Do Once a Week? — Check the fixed process runs often enough to automate.
• Go Paperless Before You Add AI: A Step-by-Step Plan — When the inputs are still on paper.
• Do I Need an AI Consultant? 8 Signs It's Time to Get Help — Eight signs a small business needs outside AI help, each with a test you can run this week, plus the signs that it doesn't need a consultant yet.
• What an AI Consultant Can't Do for You, and What You Must Own — Seven responsibilities that stay with the business when you hire AI help, an ownership card for every automation, and promises no consultant should make.
• Do I Need AI in My Business? A Decision Guide for Owners — A decision guide for owners: the three situations where AI is worth it, when waiting is sensible, a ten-question score and a 30-day test.
• How to Map a Business Process Before You Automate It — A practical process-mapping method for automation: six columns per step, swimlanes drawn with AI help, an exception count and a label for every step.
• Signs Your Business Isn't Ready for AI Yet and What to Fix First — Eleven signs a business isn't ready for AI yet, how each shows up day to day, and the cheap fix to make before paying for any tool or project.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.