Workflow automation for operations teams: the process nobody wrote down

Ask three people in an operations team how a process works and you get three answers, all of them partly right. The documented version, if it exists, describes something that was true two years ago. The real process lives in habits, and the differences between those habits are exactly where automation goes wrong.

So the first task is not building anything. It is finding out what actually happens, which is harder than it sounds and is the step that determines whether what you build works for everybody or only for the person who described it.

What we'll cover

• Three people, three processes
• Finding out what actually happens
• What to fix before automating
• Building it with CodeWords
• Exceptions are most of the work
• Handoffs, where things are lost
• Keeping the process visible
• Measuring an operational process
• Bringing the team with you
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Three people, three processes

Documentation describes intent, which diverges from practice immediately.

Everybody has local optimisations, most of which are sensible and undocumented.

The differences are invisible until something goes wrong or somebody is absent.

The newest person follows the documentation, which is why their output differs from everybody else's.

Automating one version imposes it on people who were doing something better for reasons they can explain.

Ask why before standardising, since the variation frequently encodes something real about different cases.

Finding out what actually happens

Watch rather than ask. People describe the process they believe they follow.

Follow individual items end to end, which surfaces the waiting and the rework that nobody mentions.

Count the exceptions as you go, since the proportion is always higher than the estimate.

Ask what people do when the system is down, which reveals the workarounds that have become the process.

Find the spreadsheet. There is always one, it holds the state the official system cannot, and it is the clearest statement of what is missing.

Map the decisions, not just the steps, since the decisions are what automation cannot take.

What to fix before automating

Remove the steps that do nothing, which every long-running process accumulates.

Fix the data quality problem that causes the rework, since automating around it makes it permanent.

Settle the disagreement about how it should work, because automation forces a decision and it is better taken deliberately.

Reduce the handoffs where you can, since each one is a queue.

Simplify before encoding, always, because complexity in a process becomes complexity in an automation that is harder to change.

Get agreement from the people doing it, which is both practical and the difference between adoption and quiet workarounds.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the steps, the decisions a person takes, and what escalates.
3. Authorize the connections — the systems the process already touches, and the channel the team works in.
4. Describe the exceptions: a missing field, an item outside normal parameters, an approval not received, a system unavailable.
5. Run it alongside the manual process for a fortnight and compare the outputs item by item.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Exceptions are most of the work

The happy path is the minority of the effort even when it is the majority of the volume.

Categorise exceptions rather than treating each as unique, since a handful of categories usually covers nearly all of them.

Handle the common categories explicitly and route the rest to a person with full context.

Do not build a decision tree for everything. A tree handling forty cases badly is worse than one handling six well and escalating the rest.

Report the distribution, because the top exception category is usually fixable upstream and nobody has counted it.

Watch the rate over time. A rising exception rate means something changed — a supplier, a system, a customer mix — and the automation noticed before anybody else did.

Handoffs, where things are lost

Every handoff is a queue, and the waiting in most operational processes exceeds the working by a wide margin.

Make ownership explicit at every point, since an item owned by a team is owned by nobody.

Notify the receiver, not just the queue, which is the difference between a handoff and a hope.

Track the age of everything in flight, which is the number that surfaces problems before customers do.

Escalate on age, automatically, rather than relying on somebody noticing.

Count the handoffs. Removing one usually beats optimising any of them.

Keeping the process visible

One place showing state, which most operations teams do not have and reconstruct daily from several systems.

Show what is stuck, prominently, rather than burying it in a list of everything.

Make the queue visible to the people who feed it, since upstream teams change behaviour when they can see the effect.

Alert on the unusual, not on the routine, or the alerts become the noise.

Keep a record of what happened per item, so a customer question has an answer without an investigation.

Report daily, not monthly, because operational problems are fixable while they are happening and archaeology afterwards.

Measuring an operational process

Cycle time end to end, distributed rather than averaged, since the tail is where the complaints come from.

Separate touch time from waiting, which is the measurement that tells you whether to add people or to remove handoffs.

First-time-right rate, which is the quality measure that matters and which most teams do not have.

Exception rate by category, over time.

Volume against capacity, so a growing backlog is visible before it becomes a crisis.

Not individual throughput, which changes behaviour in ways that damage the other measures.

Bringing the team with you

Operations automation is proposed to people whose work it changes, and frequently by somebody who does not do that work. How that lands determines whether it is used or worked around.

Say what happens to the time. The unspoken question is whether this is about headcount, and not answering it is worse than any answer.

Build with the people doing the work, not for them, since they know the exceptions and you do not.

Start with the part they hate. The first automation should remove something everybody complains about, which buys the credibility for the rest.

Leave the override in. A process people cannot bypass under pressure is one they will route around permanently instead.

Credit the knowledge. The variations and workarounds you encoded came from somebody, and saying so costs nothing.

Expect quiet resistance if you get this wrong, which shows up as a parallel spreadsheet rather than as an objection you can answer.

Making it survive

Make every step idempotent, since retries and reruns are the normal recovery.

Fail into a queue, not into silence. An item that errored should appear somewhere a person looks.

Handle partial completion, which is the state most operational automations end up in when something breaks mid-process.

Keep a manual override for every automated step, since operations work has deadlines that cannot wait for a fix.

Report the outcome: items processed, exceptions by category, items aged beyond threshold, and manual interventions.

Limits worth knowing about

Legacy systems may offer no interface, and a scheduled export is sometimes the only route.

Physical processes have limits that software does not change — a van, a warehouse, a person.

Seasonality breaks assumptions, and a process tuned in a quiet month behaves differently at peak.

Automating a bottleneck upstream just moves the queue downstream, which is visible only if you measure end to end.

Automation does not add capacity to a team that is genuinely understaffed; it changes what the shortfall looks like.

What to build first

The visibility layer: one view showing every item in flight, its state, its owner and its age, with anything stuck at the top. It automates no decision and changes no process, and it usually reveals that the problem is a queue nobody could see rather than the step everybody complains about.

Two habits make the difference. Watch the process rather than asking about it, since people describe the version they believe they follow and the differences between individuals are exactly what breaks an automation. And categorise exceptions and report the distribution, because the largest category is almost always fixable upstream and nobody has ever counted it.

Frequently asked questions

Why not start by automating the documented process?

Because the documentation describes intent from some years ago and everybody has since developed local variations, most of which are sensible. Automating one version imposes it on people who were doing something better for reasons they can explain.

How do I find out what the process actually is?

Watch it rather than asking, follow individual items end to end to surface waiting and rework, count exceptions as you go, ask what people do when the system is down, and find the spreadsheet — there is always one, and it holds what the official system cannot.

What should be fixed before automating?

Steps that do nothing, the data quality problem causing rework, the unsettled disagreement about how it should work, and any handoff you can remove. Complexity encoded into an automation is harder to change than complexity in a process.

How much of the work is exceptions?

Usually most of the effort even when the happy path is most of the volume. Categorise them, handle the common categories explicitly, route the rest to a person with context, and report the distribution — the top category is generally fixable upstream.

Where does operational time actually go?

Waiting at handoffs, in most processes by a wide margin over working time. Separating touch time from waiting is the measurement that tells you whether to add people or remove handoffs.

What should an operations dashboard show?

Every item in flight with state, owner and age, with anything stuck at the top — not a list of everything. The queue should also be visible to the teams that feed it, since upstream behaviour changes when the effect is visible.

Should individual throughput be measured?

No. It changes behaviour in ways that damage cycle time and first-time-right rates, which are the measures that actually reflect how the process is performing.

Does automating a bottleneck help?

Only if you measure end to end. Otherwise it moves the queue downstream and the total cycle time is unchanged, which is a common and expensive way to appear to have improved something.

How do I get an operations team to adopt an automation?

Build it with them rather than for them, start with the thing everybody complains about, leave a manual override in, and answer the unspoken headcount question directly — not answering it is worse than any answer.

What does resistance look like?

A parallel spreadsheet rather than a stated objection. When the official process cannot handle a real case, people keep their own record, and by the time you find it the automation has been partly bypassed for months.

Related reading

• Automating order fulfilment
• Automating task assignment
• Workflow automation for supply chain