Why Automating a Broken Process Just Makes It Fail Faster

A 70-person company connects its quoting tool to its invoicing system, and for three weeks everything looks fine. Then finance notices that 40 invoices went out with the wrong payment terms. Nobody made a typing error. The quote form never had a required field for terms, so the sales team had always filled them in by hand or mentioned them in email, and the finance team had always caught the gaps by eye. The automation removed the eye.

This is the most common way automation projects disappoint. The technology works exactly as configured. The process underneath it was never as clean as everyone assumed, and a person had been quietly absorbing the mess.

What people were doing that nobody wrote down

Every manual process has two versions: the one on paper (or in someone's head) and the one that actually runs. The gap between them is filled by human judgment. An assistant notices that a customer name is spelled two ways and fixes it. A controller knows that one vendor always submits invoices without a PO number and approves them anyway. A project manager remembers that a certain client needs a different contract template.

None of that is documented, because none of it feels like a step. It feels like doing the job well.

Automation cannot do the job well. It does the job as specified. When the specification leaves out the unwritten fixes, three things happen:

Exceptions become failures. A missing field that a person once worked around now stops the workflow or, worse, passes bad data downstream without a flag.
Errors repeat at machine speed. A person who makes a mistake once a week creates a cleanup problem of a few records. A workflow with the same flaw can create hundreds before anyone looks.
Ownership gets fuzzy. When a person ran the process, someone knew who to ask. When a tool runs it, nobody is sure who is responsible for the outcome.

The Deloitte Global RPA Survey published in 2018 found that only 3 percent of organizations had scaled robotic process automation to 100 or more bots, and that respondents named process fragmentation as the biggest barrier to scaling, at 32 percent. The same survey found that 63 percent of organizations said their expectations for how long implementation would take were not met. Those numbers are several years old and reflect large enterprises, but the pattern they describe holds at a 50-person company: the tool is rarely the hard part. The process it inherits is.

Why the problem is bigger than it looks

Most growth-stage companies carry more process friction than leadership realizes. Asana's Anatomy of Work Global Index, a 2023 survey of more than 9,600 knowledge workers across six countries, found that 58 percent of the average workday goes to "work about work": status updates, chasing information, and duplicated effort (Asana Anatomy of Work Global Index 2023).

That number explains why automation is so tempting. It also explains the trap. A lot of that "work about work" exists because the underlying process is unclear: people chase information because nobody defined who owns it, and they duplicate effort because two teams handle the same handoff differently. Automating the chasing does not remove the reason for the chasing. You get a faster, quieter version of the same confusion.

Here is a concrete way to size the risk. Suppose a 60-person company has an approval process that touches 200 requests a month, and 5 percent of them hit an exception a person currently resolves in ten minutes. That is 10 exceptions and under two hours of work each month, invisible in anyone's workload. If an automated version handles those 10 exceptions incorrectly and each one takes an hour to detect and unwind, the same process now consumes ten hours of cleanup. In addition, some of those errors reach customers, vendors, or auditors before they are found. The automation did not save time. It moved the cost from a place nobody measured to a place everybody notices.

The four signs a process is not ready

Before scoping any automation, check the process against these four signs. One is a warning. Two or more means stop and fix the process first.

Two people describe it differently. Ask the two people closest to the process to explain it independently. If the answers differ on who does what or in what order, the process is not standardized enough to encode.
Exceptions are handled by memory. If someone says "except when the client is X" or "unless it's the end of the quarter," that rule lives in a head, not a document.
Nobody can say what done looks like. A process needs a clear finish condition and an owner who confirms it. If the answer to "how do we know it worked?" is "we would hear about it," the process has no measurement.
The inputs are inconsistent. If the data feeding the process arrives in different formats, from different sources, with different levels of completeness, automation will either reject it or pass along the inconsistency.

None of these signs mean automation is a bad idea. They mean the order of operations is wrong.

A six-step check to run before you automate

This is the sequence Elevaire recommends to growth-stage clients, and it works without special software. A whiteboard, a shared document, and an hour with the people who actually do the work are enough for most processes.

Step 1: Write down the process as it actually runs

Do not start with the process as it is supposed to run. Sit with the person who does the work and have them narrate one real instance from start to finish, including every check, workaround, and message they send. Write it as a numbered list. Include the steps that feel too small to mention. Those are usually the ones the automation will miss.

Step 2: List every exception

For each step, ask what can go wrong and what the person does when it does. Record the trigger and the response. If the same exception appears more than a few times a quarter, it is part of the process, not an edge case.

Step 3: Assign an owner and a finish line

Name one person accountable for the outcome, not the tool. Define what a successful run looks like in a sentence that anyone could verify: "Invoice sent with correct terms and matching PO within two business days of approval."

Step 4: Simplify before you automate

Look at the numbered list and remove steps that exist only because of old habits, duplicate approvals, or workarounds for a system you replaced. Merge steps that one person handles back to back. Fix the input problems at the source, for example by making a field required in the form rather than checking for it later. The simpler the process, the cheaper and safer the automation.

Step 5: Establish a baseline

Measure how long the process takes today, how many runs happen per month, and how often something needs correcting. Without these three numbers, you cannot tell whether the automation improved anything. This is also where you find out whether the process is worth automating at all. A process that runs six times a year rarely repays the effort.

Step 6: Automate one narrow slice and keep a human in the loop

Start with the part of the process that is frequent, rule-based, and fully documented. Keep a person reviewing the output for the first full cycle, usually a month. When the exceptions the automation misses show up, and they will, add them to the documentation and adjust the logic. Expand only after a clean cycle.

Where this fits with your existing IT support

The steps above are not technical work, and they do not require replacing anything. Your managed service provider or internal IT generalist keeps systems running, handles support tickets, and maintains devices. That work continues as it is.

What is usually missing is someone with the standing to ask, before a tool gets purchased, whether the process it will run is ready. In a 25 to 200 person company, that role often has no owner. Department heads buy tools that solve their own pain, and nobody looks across the whole workflow. Fractional IT leadership fills that gap. A fractional CIO sits above day-to-day support and owns the prioritization: which processes to fix first, which to automate, which to leave alone, and how the pieces connect. Our related post on what to automate first when you don't have an IT team covers how to rank candidates once they are ready.

What to do this month

If your company has an automation project under way or planned, three actions take a few hours and cost nothing:

Pick the process and have two people describe it independently. Compare the answers.
List the five most recent exceptions and how each was resolved. If the resolutions were improvised, that is your documentation gap.
Write the finish line and the owner in one sentence each. If you cannot, the process is not ready.

If the process passes, automate it with confidence. If it does not, the hours spent documenting and simplifying are not a delay. They are the cheapest part of the project, and they determine whether the rest of the spend pays back.

Frequently Asked Questions

Should we document every process before we automate anything?

No. Document only the process you plan to automate next. Trying to map everything at once stalls the effort and produces documents nobody reads. Start with the single candidate that scores highest on frequency and cost of error, finish it, and use what you learned on the next one.

How long does it take to document a process well enough to automate it?

For a typical approval, onboarding, or invoicing process, expect a few hours of interviews and a week or two of review to confirm the exceptions. Processes that span several departments or depend heavily on individual judgment take longer, and that extra time is itself useful information about how risky automation will be.

What if the process is messy but the pain is urgent?

Fix the input problems first, since those are usually quick. Required fields, standard templates, and a single intake point often remove most of the pain without any automation. Then automate the narrow, stable part and leave the judgment-heavy steps to people.

How does this work alongside our existing MSP or internal IT person?

It sits above them. Your provider or IT generalist continues handling support, security tooling, and maintenance. Process review and automation prioritization are strategic questions that fractional IT leadership owns, and the two roles share information rather than overlapping. Nothing about the current support arrangement needs to change.

How much does it cost to fix a process before automating it?

The direct cost is mostly staff time: a few hours per process from the people who run it, plus someone to facilitate and write it up. That is typically a small fraction of the cost of the automation itself and far less than unwinding a failed rollout. The larger risk is skipping the step and paying for the same work twice.

How do we get started?

Choose one process with a clear owner, run the six-step check above, and record the baseline numbers before touching any tools. If you want an outside view on which process to start with, a short conversation with a fractional IT leader can rank your candidates by impact and readiness in an afternoon.