Workflow automation for operations teams: the process nobody wrote down

To automate workflows for an operations team, first find the process the team actually follows, then fix what is broken, then automate the version that works for everyone. Ask three people how a process works and you get three answers. The documented version describes what was true two years ago, and the real process lives in habits.

Differences between those habits are where automation goes wrong. The first task is therefore to find out what happens, which is harder than it sounds and decides whether the automation works for everyone 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

Key takeaways

• Watch the process instead of asking about it, because people describe the version they believe they follow.
• Remove pointless steps and fix data-quality problems before automating, since complexity in a process becomes complexity in an automation.
• Exceptions are most of the effort, so categorise them, handle the common ones and route the rest to a person with context.
• Most elapsed time is waiting at handoffs, so track the age of every item in flight.
• Build the visibility layer first: one view of every item, its state, its owner and its age.

Three people, three processes

Three people describe three different processes because documentation records intent and practice diverges from it at once. Five patterns follow:

• Everyone has local optimisations, most of them sensible and undocumented.
• The differences stay invisible until something goes wrong or someone is absent.
• The newest person follows the documentation, which is why their output differs from everyone 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 often encodes something real about different cases.

Finding out what actually happens

To find out what actually happens, watch the work instead of asking people to describe it. Six techniques help:

1. Watch, do not ask. People describe the process they believe they follow.
2. Follow individual items end to end. This exposes the waiting and rework nobody mentions.
3. Count the exceptions as you go. The proportion is always higher than the estimate.
4. Ask what people do when the system is down. This reveals workarounds that have become the process.
5. 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.
6. Map the decisions, not just the steps. Decisions are what automation cannot take over.

What to fix before automating

Fix the process before automating it, because complexity in a process becomes complexity in an automation that is harder to change.

• Remove steps that do nothing. Every long-running process accumulates them.
• Fix the data-quality problem that causes rework. Automating around it makes it permanent.
• Settle disagreements about how the process should work. Automation forces a decision, and a deliberate decision is better.
• Reduce handoffs where you can. Each handoff is a queue.
• Get agreement from the people doing the work. This is practical, and it separates adoption from quiet workarounds.

Building it with CodeWords

To build an operations workflow in CodeWords, tell Cody, the automation builder, the steps, the decisions a person takes and what escalates. CodeWords offers 3,000+ integrations (CodeWords integrations page, 2026), and you connect each once and reuse it.

1. Open CodeWords and start a new automation.
2. Describe in plain language 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 beside the manual process for a fortnight and compare the outputs item by item.

You describe the outcome, and Cody builds it, connects it and deploys it. The Free plan covers light use. Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Exceptions are most of the work

Exceptions are most of the effort even when the normal case is most of the volume. Handle them in five steps:

1. Categorise exceptions instead of treating each as unique. A handful of categories usually covers nearly all of them.
2. Handle the common categories explicitly and route the rest to a person with full context.
3. Do not build a decision tree for everything. A tree that handles forty cases badly is worse than one that handles six well and escalates the rest.
4. Report the distribution. The top exception category is usually fixable upstream, and nobody has counted it.
5. Watch the rate over time. A rising rate means something changed, such as a supplier, a system or a customer mix, and the automation noticed before anyone else did.

Handoffs, where things are lost

Handoffs are where things are lost because every handoff is a queue, and waiting in most operational processes far exceeds working time.

• Make ownership explicit at every point. An item owned by a team is owned by nobody.
• Notify the receiver, not only the queue. That is the difference between a handoff and a hope.
• Track the age of everything in flight. Age surfaces problems before customers do.
• Escalate on age automatically instead of relying on someone noticing.
• Count the handoffs. Removing one usually beats optimising any of them.

Keeping the process visible

Keep the process visible with one place that shows the state of every item, which most operations teams lack and rebuild daily from several systems.

• Show what is stuck, prominently, not buried in a list of everything.
• Show the queue to the people who feed it. Upstream teams change behaviour when they see the effect.
• Alert on the unusual, not the routine, or the alerts become noise.
• Record what happened per item, so a customer question has an answer without an investigation.
• Report daily, not monthly. Operational problems are fixable while they happen and archaeology afterwards.

Measuring an operational process

Measure an operational process with six measures:

• Cycle time end to end, as a distribution and not an average, since the tail is where complaints come from.
• Touch time separate from waiting time. This tells you whether to add people or remove handoffs.
• First-time-right rate. This is the quality measure that matters, and most teams lack it.
• 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, often by someone who does not do that work. How it lands decides whether people use it or work around it.

• Say what happens to the time. The unspoken question is about headcount, and not answering is worse than any answer.
• Build with the people doing the work, not for them. They know the exceptions and you do not.
• Start with the part they dislike. The first automation should remove something everyone complains about, which earns credibility for the rest.
• Leave the override in. People who cannot bypass a process under pressure will route around it permanently.
• Credit the knowledge. The variations you encoded came from someone, and saying so costs nothing.
• Expect quiet resistance if you get this wrong. It shows up as a parallel spreadsheet, not as an objection you can answer.

Making it survive

An operations automation survives when it recovers cleanly:

• Make every step idempotent (safe to run twice), since retries and reruns are the normal recovery.
• Fail into a queue, not into silence. An item that errored should appear where a person looks.
• Handle partial completion, the state most automations reach 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

Five limits apply to operations automation:

• Legacy systems may offer no interface, and a scheduled export is sometimes the only route.
• Physical processes have limits that software does not change, such as a van, a warehouse or a person.
• Seasonality breaks assumptions. A process tuned in a quiet month behaves differently at peak.
• Automating an upstream bottleneck moves the queue downstream, which you see only by measuring end to end.
• Automation does not add capacity to an understaffed team. It changes what the shortfall looks like.

What to build first

Build the visibility layer first: 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, not the step everyone complains about.

Two habits make the difference. Watch the process instead of asking about it, since individual differences 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 counted it.

Frequently asked questions

Why not start by automating the documented process?

Documentation describes intent from some years ago, and everyone has since developed local variations, most of them sensible. Automating the documented 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 the work and follow individual items end to end to expose waiting and rework. Count exceptions as you go, ask what people do when the system is down, and find the spreadsheet, which holds what the official system cannot.

What should be fixed before automating?

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

How much of the work is exceptions?

Exceptions are usually most of the effort even when the normal case is most of the volume. Categorise them, handle the common categories explicitly, route the rest to a person with context, and report the distribution.

Where does operational time actually go?

In most processes, time goes to waiting at handoffs, by a wide margin over working time. Separating touch time from waiting time tells you whether to add people or remove handoffs.

What should an operations dashboard show?

It should show every item in flight with state, owner and age, with anything stuck at the top, not a list of everything. Make the queue visible to the teams that feed it, since upstream behaviour changes when the effect is visible.

Should individual throughput be measured?

No. Individual throughput changes behaviour in ways that damage cycle time and first-time-right rates, which are the measures that reflect how the process performs.

Does automating a bottleneck help?

Only if you measure end to end. Otherwise the queue moves downstream and 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 the team, start with the task everyone dislikes, leave a manual override in, and answer the headcount question directly. Not answering is worse than any answer.

What does resistance look like?

Resistance looks like a parallel spreadsheet, not a stated objection. When the official process cannot handle a real case, people keep their own record, and the automation can be partly bypassed for months before you find it.

Related reading

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