The Workflow Worked Perfectly. So Why Did Everything Get Worse?

I used to think I was pretty good at workflow automation.

Not world class. Not some automation sorcerer with dashboards and lights and 30 integrated systems. Good enough to know what I was doing. I knew the tools. I could link forms to spreadsheets, send notifications, approvals, automate away at menial tasks. I’d mapped out a few automations and I felt like I was on top of it.

That was the mistake.

For quite some time I believed the challenge was the software. Figuring out triggers. Choosing the right nodes. Writing conditions that did not break at the worst possible moment. If it ran without crashing, I was happy.

Then I made one that worked flawlessly.

And made everything worse.

That was the day I learned to automate.

The sequence was simple. Fast. Reliable. It took requests from a form and put them into a queue, classified them, assigned them to an owner and sent status updates into Slack. It was a thing of beauty. The kind of process that gets the approving nod when you explain it.

I got the nod.

Then I got the complaints.

Request were still getting stuck. Ownership was still unclear. I had to follow up on half the tickets because the form was asking the wrong questions. The automation wasn’t broken. The process underneath it was.

There was the rub.

I had automated chaos.

And when you automate chaos, you don’t get order. It becomes faster chaos.

When I realised this, I stopped asking, “How do I automate this process?”, and began asking, “Should this process be automated at all?”

That’s how I saved myself time.

The uncomfortable truth automation hides

Here is the shortest way to put it.

Automation multiplies whatever is already there.

If it is simple, automation makes it simpler.

If the process is confused, automation makes the confusion more apparent and more difficult to resolve.

I did not like this realization because my early successes were not as great as I had thought. Some of them worked because there wasn’t much volume. Some worked because someone was there to put the bandages on. Some worked because the stakes were so low that no-one cared.

Then the stakes went up.

That’s when designing processes stopped being theoretical.

I thought the workflow is the product. It was not.

I was missing the obvious.

The workflow is only the delivery mechanism.

The product is the process.

That includes:

What starts the work
What information gets collected
Who takes the next step
What is “done”
What exceptions are always there
When we still need judgment

When I didn’t ask these questions, I automated things that looked great but didn’t do what was actually needed.

A true story: I once automated requests for content for an internal team. My previous approach was tool first. Build the form. Route the request. Notify the team. Track the status. Easy.

Now I start with the process. We reviewed the incoming requests and found three issues:

The same form was used for urgent projects and ideas for the future
The required fields did not help the team estimate effort
There was no agreement on approval

No node could fix that on its own.

So before that automation, we made two out of one form. One for urgent execution. One for early stage ideas. We added useful fields, such as reason for deadline, audience, source files and final approval. Then we modified the process.

Then the automation began to feel smart.

Not because the tool got better.

Because the process did.

The old way felt productive. The new way felt annoyingly slow. At first.

This was the surprising part.

Slowing down to fix the process is slower. It is less satisfying. You are not dragging nodes around. You are asking annoying questions in meetings. You are challenging assumptions that haven’t been noticed for half a year.

It can feel like friction.

It is really design.

My old approach looked like this:

Hear a complaint
Open the automation tool
Build something quickly
Patch issues later

Now I do this:

See it in the flesh
Where people pause, improvise and seek help
Simplify the steps
Remove unnecessary handoffs
Standardize the input
Then automate what remains

This was a game changer for me.

Because now I am not just moving work faster.

I am making it sensical first.

One little process tweak can set the workflow free

This is hindsight, but I didn’t understand this until I experienced it.

Little process bugs can lead to big automation bugs

I see the following frequently:

One team thinks the other team approves
A field has three different meanings
Exceptions are common but undocumented
Priority levels are subjective
A task is there because “we have always done it”

I witnessed this with a lead routing process for a small sales organisation. The original request was simple: route incoming leads by region and automatically send follow ups.

The automation worked.

The outcomes did not.

Why? Because the real routing rule wasn’t “region”. The region rule was a bizarre combination of geography, product, account size and existing business. The reps were actually moving leads around all day, and there was no rule on paper.

So we shelved the build and did something embarrassingly simple.

We mapped how leads were really being assigned.

Not the official version.

The real version.

This gave us better rules, cleaner handoff and fewer exceptions to the rules. Only then did the workflow begin to save time (not cleanup).

Why this matters

Because a bad process can hide in a slick automation for a while.

They think the computer is smarter. They feel stupid when it’s clumsy. They work around the friction. They gradually stop believing in the process.

That is dangerous.

By addressing the process first, you establish trust. The automation seems intuitive because it’s based on how the work should be done, not how the data happens to flow.

What I look for now before I automate anything

These are my questions now, nearly always:

What is the real purpose here?
What adds value, and what does not?
Where do people get confused?
What never exists at the beginning?
What is common enough to automate?
Which edge cases happen often enough to deserve their own path?
What would be the first to snap if volume doubled next month?

These questions sound simple.

They are not.

They force honesty.

And truth usually leads to betterment.

A mini case study that humbled me

A team wanted a process to onboard partner requests. The initial ask was all about speed. They wanted to fill out a form, generate documents, assign tasks, get reminders and see the status.

Very reasonable.

But on closer inspection, there were issues with the process:

Different departments had different meanings of “partner approved”
Legal review could be first or last
Not all deals required the same documents, but the form didn’t know that
Slack messages filled in information that didn’t get captured

If I’d helped automate this as asked, I’d have baked in inconsistency.

Instead, we first streamlined the request and approval process. We defined three types of requests, with different fields and review flows. We added a decision point before generating the document. We defined what “approved” means.

Then we built the workflow.

The result was not magical. It was better than magical.

It was understandable.

They knew what would happen next.

That’s better than magic.

The drawbacks people don’t talk about

I love automation. I really do. But this is where I wish we could hear more.

Fixing the process first is not glamorous.

It can expose unpleasant realities, such as:

A team does not actually agree on ownership
A manager wants visibility more than efficiency
There’s a step to make up for a lack of training
The workflow request is really a policy problem in disguise

It also takes discipline. Some want a quick workflow for the sake of doing something. And to be sure, sometimes a crude automation is enough. Not all processes need to be re-invented.

But if your workflow is part of a process that’s about customer experience, approvals, finance, compliance or handoffs, you should care a lot about process quality.

A bad workflow is annoying.

A bad workflow and a bad process is costly.

Should you care?

If you are any of these people, yes, you should care a lot:

Operations leads trying to reduce bottlenecks
Founders cleaning up messy internal systems
No code devs who are frequently told to “just automate it”
Team leads frustrated by handoffs
Anyone who uses n8n, or Zapier or Make or custom-built workflow software

If you spend your time copying and pasting information from one place to another, sorting work to the right people, getting approvals, or streamlining repeated tasks, this lesson will save you pain.

Not theoretical pain.

Real pain.

The kind that results in missed deadlines, team confusion, wasted effort and the random exception that occurs every Tuesday.

Where this is going next

I predict the next frontier of automation is not more capable tools.

It is process literacy.

They are becoming more efficient at building processes quickly. Some can suggest logic. Some can draft from natural language. That is useful. But it also means we can shortcut automation of poor systems.

So the skill that matters more now is not only tool fluency.

It is process judgment.

The most successful builders will be those who will look at a complex workflow request and say, “Let’s not automate this. Let’s fix it first”.

This isn’t being resistant.

That is maturity.

What I would do if I had another day

If you are about to build a workflow, here are the next steps I would take:

Observe the current process three times
Record all handoffs and confusion points
Ask what is always missing from upstream
Tease apart the easy cases and the edge cases
Take out one step before you automate
Make success criteria really easy to understand
Create the simplest version that works for the new process
Wait until the first week of use before you do more

This final point is more important than you think

Because a workflow is never really done when you publish it.

It’s real only when it’s used.

The lesson I learned the hard way

I still like building workflows. Perhaps even more now.

But I do it with a lot less ego.

I don’t take an automation that works to be a good one. I no longer equate energy with success. And I no longer believe a slick workflow until I’ve seen the process.

It changed how I build.

It also changed how I think.

Great automation is not always the most elegant.

It is the one that sits on a process that works.

That was the lesson for me.

A little annoying.

A little humbling.

Very useful.

What about you? Have you ever automated something that seemed like a good idea and then revealed a process flaw?

The Hackers Magazine