Before You Automate a Process, Fix the Process

At 4:42 every afternoon, someone downloads a report, removes four columns, looks up missing account numbers in a second system, emails two supervisors for approval, and uploads the finished file to a third system. The work takes about ninety minutes when nothing goes wrong.

The first automation proposal copies every step. It adds a bot to download, trim, look up, email, wait, and upload. The diagram looks impressive. The process still has duplicate data, an approval nobody uses, and an exception path that lives in one employee's memory.

This is the moment to stop. Software can move bad work faster. It can also make the bad work harder to see.

My book opens Part One with a plumber.

"Imagine a plumber who knows your main water line is corroded and needs replacement. But every few days, another pipe bursts. Every time, he rushes over, fixes the immediate problem, collects his hefty check, and leaves. This continues for months. You're frustrated but grateful for his quick response. What you don't realize: The plumber has built a lucrative business model on your misery."

Automation without process work is the plumber with better tools. It fixes the burst faster, bills for the visit sooner, and leaves the corroded main exactly where it was. Speed applied to a broken process compounds the breakage. Replace the line first. Then automate the house you actually want.

From The 3AM Test by Steve Copeland.

Watch the real work

Do not begin with the written procedure. Sit with the people who perform the work and follow several real cases from trigger to completion.

Record where information arrives, what gets copied, which judgment calls occur, where someone leaves the system to ask a question, and what happens when the normal path fails. The exception is usually where the actual process becomes visible.

Remove before you automate

For every step, ask what decision it supports and what would happen if it disappeared.

Approvals are common targets. Some exist because a real risk requires separation of duties. Others exist because a former manager wanted visibility five years ago. A digital approval is still waste when no decision is being made.

Also look for duplicate entry, reconciliations between systems that should share data, reports nobody reads, and routing rules based on organizational history rather than current work.

Name the standard path and the exceptions

Automation performs best when the normal case is clear and exceptions leave the automated path deliberately.

Define the trigger, required inputs, decision rules, output, owner, service expectation, and completion evidence. Then list the exceptions: incomplete data, conflicting records, high-value transactions, regulated information, customer disputes, and anything requiring judgment.

Do not force exceptions through the standard path to improve an automation percentage. Send them to a named person with enough context to decide.

Fix the source of truth

Many automation projects are data-cleanup projects in disguise. If customer status exists in three systems, a workflow cannot reliably know which one controls. If names and identifiers do not match, integration creates fast duplication.

Choose the system of record for each critical field, establish who may change it, and correct the data before connecting another layer.

Measure the baseline

Capture volume, hands-on time, elapsed time, error or rework rate, exception rate, and business consequence. These numbers tell you whether the process is worth automating and whether the result worked.

Time saved is capacity until the business converts it into faster throughput, avoided hiring, reduced contractor spend, or another named outcome. Measure that conversion rather than multiplying minutes by salary and calling it ROI.

Automate the smallest stable slice

Start with one trigger, one standard path, and one measurable result. Keep a manual escape route. Log what the automation decided and why. Give an operator the ability to pause it.

When the slice works, expand from evidence. When it does not, stop without turning the pilot into permanent infrastructure.

The right first question is not which AI platform to buy. It is which decisions in this process are real, which steps can disappear, and who remains accountable when software performs the work.

A before-and-after example

Take an accounts-payable intake used by a 75-person company. Invoices arrive in a shared mailbox. A coordinator saves each attachment, renames it, enters vendor and amount into a spreadsheet, looks up the purchase request, emails a department manager, waits for approval, retypes the record into accounting, and moves the email into a folder.

About 480 invoices arrive each month. Hands-on time averages eight minutes. Waiting stretches the median cycle to six days. Twelve percent of invoices need rework because the purchase request is missing, the vendor name differs, or approval went to the wrong person.

The first automation design reproduces all of that. It reads the mailbox, renames files, updates the spreadsheet, sends email, and types into accounting through a brittle desktop bot. Estimated cost is $68,000.

Process work changes the picture.

The company removes the spreadsheet because accounting can hold intake status. Purchase requests receive a required vendor identifier. Approval thresholds are rewritten so routine invoices tied to an approved request do not need another manager click. Exceptions route to the controller with the source documents attached.

The simplified process has one intake, one system of record, and three exception types. A $24,000 integration handles the standard path. Average hands-on time falls to two minutes, rework drops, and the controller sees exceptions in one queue.

The savings came from removing decisions before automating movement.

Observe five real cases

Written procedures describe the path people hope the work follows. Sit beside the operator and trace five completed cases, including at least one exception.

Record the trigger, source information, handoffs, systems, decisions, waiting, rework, and completion evidence. Ask the operator to narrate what they are checking. Small comments reveal the hidden rules: "I know this customer uses the old form," or "If the amount is above ten thousand, I message Maria first."

Those rules need a home. Some belong in the process. Some are workarounds for data or policy. Some should disappear.

I pay special attention when someone leaves the official system to ask a question in chat. That usually marks unclear ownership, missing context, or an exception the workflow has never acknowledged.

Challenge every approval

An approval should correspond to a decision and a person with authority to make it. Ask what evidence the approver reviews, what choices exist, and how often the answer changes.

If the approver clicks yes 99 percent of the time and adds no information, the control may be ceremonial. Replace it with a threshold, sampling review, report, or exception rule when risk allows.

Some approvals must remain for separation of duties, safety, legal, financial, clinical, employment, or customer commitments. Design those moments so the human receives the facts, options, and consequence. A bare "Approve?" button invites habit.

Measure approval wait separately from review time. A two-minute decision that sits for four days is a routing and priority problem.

Define exceptions before writing automation

List what can leave the standard path: missing data, conflicting records, large values, new vendors, customer disputes, unusual terms, regulated information, low model confidence, and integration failure.

For each exception, name the owner, context required, response target, and path back into the workflow. Decide which exceptions pause one case and which pause the automation.

Do not make the standard path absorb every edge case. A clear 80 percent automation with a strong exception desk often beats a fragile attempt at 100 percent.

The exception rate is also a process measure. If 35 percent of cases leave the path, improve the source or rules before expanding automation.

Establish the source of truth

Choose where each critical field is created and who may change it. Customer status may belong to the CRM. Payment terms may belong to accounting. Employee status may belong to HR. The automation can read or write across systems, but it needs one authority for each fact.

Match records with stable identifiers rather than names whenever possible. "Acme Inc." and "ACME, LLC" look close to a person and different to a machine. An identifier prevents duplicate customers and misrouted work.

Clean the active data needed for the first slice. Avoid turning a focused project into an endless enterprise cleanup. Document the quality rule and owner so the improvement lasts.

Set a baseline that survives scrutiny

Capture monthly volume, hands-on minutes, elapsed time, error and rework, exception rate, backlog, and business consequence. Use a sample when measurement is difficult and state the limits.

Separate labor capacity from cash savings. Removing 100 hours a month creates capacity. It becomes cash when the company avoids a hire, reduces overtime or contractor spend, or increases throughput with the same team.

For the invoice example, 480 cases times six minutes saved equals 48 hours monthly. At $45 loaded cost, the capacity value is $25,920 a year. If the integration costs $24,000 plus $6,000 annual support, labor alone does not justify year one. Faster close, fewer late fees, cleaner approvals, and avoided headcount may complete the case.

Write the math so leadership can challenge it.

Start with one stable slice

Choose a narrow trigger and common case. Use a limited user group or transaction type. Keep a manual path. Log inputs, decisions, outputs, errors, and overrides. Give an operator a visible pause control.

Run the slice long enough to see normal volume and exceptions. Compare the baseline. Interview the people receiving the result. A workflow can be technically correct and still create worse work downstream.

Expand only when the measure and operator experience agree.

Where AI belongs

Deterministic rules remain better for exact, repeatable choices. AI can help classify unstructured requests, extract fields, summarize context, draft communication, and suggest a next action.

Use confidence thresholds and human review where the consequence matters. Keep source material available to the reviewer. Record the model, prompt or instruction, output, approval, and correction where practical.

An AI step should have the same owner and failure path as any other step. Calling it intelligent does not remove the need for operations.

The review after launch

Thirty days after launch, compare volume, time, delay, errors, exceptions, and overrides. Look for employees creating side paths. Review access and logs. Confirm that the old spreadsheet, mailbox rule, service account, or manual report was actually retired.

Ninety days later, measure the business result. Did invoices close faster? Did backlog fall? Was a hire avoided? Did customer response improve? Which exception now deserves process work?

I consider an automation successful when the people doing the work can explain it, pause it, recover from failure, and show the changed result. A flashy demo is optional. A supportable process is the product.

Questions for the process owner

What event starts the work? What must be true before it begins? Which output proves completion? Who owns the result? Which decisions require judgment or authority? Where does work wait? Which errors create a customer, financial, legal, or safety consequence?

Ask what changed since the process was designed. An approval, report, or handoff may serve a manager or system that no longer exists.

Ask the operator which step they would remove tomorrow. Then ask what risk that step was meant to control. The answer often separates useful skepticism from a hidden obligation.

Design the support model before launch

Name who watches failures, who receives alerts, who can pause the workflow, who corrects data, who approves a restart, and who communicates with affected users. Set a response expectation based on business consequence.

Document dependencies and credentials. Use managed identities or service accounts with narrow access. Keep secrets out of desktop scripts and personal accounts. Review access when employees change roles or leave.

Create a runbook for common failures. Test one. A workflow that saves 50 hours a month can also create a 50-hour backlog when it stops.

Watch for displaced work

Automation may save time in one team and create review or correction in another. Measure the full path.

A drafting assistant can reduce writer time while doubling manager review. An intake bot can speed submission while sending incomplete cases downstream. A customer portal can reduce calls and increase data cleanup.

Interview the receiver. Count returned work. Compare total elapsed time and hands-on time across teams.

Preserve human authority where it matters

Money movement, access, contracts, clinical care, safety, hiring, discipline, and legal commitments need explicit authority. AI can prepare context and suggest an action. The accountable person should know what they are approving and have a practical way to disagree.

Record the decision and source evidence. Avoid interfaces that encourage automatic approval. Random sampling and second review may be appropriate even when the model performs well.

Know when to stop

Stop a pilot when the source data cannot support the decision, exceptions overwhelm the standard path, users create workarounds, the operating owner disappears, or measured value does not justify the lifecycle cost.

Stopping early is a successful use of a pilot. It protects the company from permanent infrastructure built around a weak assumption.

The best automation program is selective. It improves a stable process, keeps the exception visible, and leaves a person clearly responsible for the result.