Tipična situacija 'Samo nam treba automatizacija'

The request usually sounds like this: “We just need to automate X.”

X might be data entry. Moving information between systems. Sending follow-up emails. Generating reports. The specific X varies, but the framing is consistent: there’s a task, it’s repetitive, and automation would make it go away.

Sometimes that’s true. Automate X, problem solved, move on.

But more often, X is a symptom. The actual problem is upstream. And automating X doesn’t fix the problem — it relocates it.

A common pattern

Here’s a situation I see regularly.

A team wants to automate their proposal generation. Currently, someone manually pulls information from multiple sources, formats it, and creates a document. It takes hours. Automation seems obvious.

But when you look closer, you find: the information in those sources isn’t consistent. Fields are named differently across systems. Some data is current, some is stale. The manual process works because a human is interpreting and correcting as they go.

Automate the assembly, and you get fast proposals with inconsistent data. The problem didn’t go away. It moved downstream — now showing up as client confusion, revision requests, or worse, errors that reach contracts.

The actual problem wasn’t slow proposal generation. It was data inconsistency across the sources. The human doing manual work was masking that problem.

Why the request misses the target

When someone asks to automate X, they’re usually describing where they feel the pain. The pain is real. The work is genuinely tedious and repetitive.

But pain location and pain source are different things.

The repetitive data entry exists because the upstream process doesn’t capture information correctly the first time. The manual follow-ups exist because the handoff between teams is unclear. The report generation is painful because the data structure doesn’t match what the report needs to show.

Automation at the pain point treats the symptom. The source keeps producing more symptoms.

The diagnostic value

This is why automation requests are valuable — not because they tell you what to automate, but because they tell you where to look.

Every “automate X” request is pointing at a friction point. Follow that friction upstream, and you usually find one of three things:

Unclear process. No one has defined what should happen, so everyone has their own version. The manual work is reconciliation — making different approaches produce consistent output.

Missing ownership. The task falls between responsibilities. It gets done, but inefficiently, because it’s no one’s primary job to do it well.

Broken handoff. Information loses quality or context when it moves between people or systems. The manual work is restoration — adding back what got lost in transit.

Automating doesn’t fix these. It speeds up the broken process, which often makes things worse.

What happens when you automate first

Automating a broken process produces broken outcomes faster.

The team wanted faster proposals. They got faster proposals with data errors. Now someone needs to quality-check every automated proposal. The time savings evaporated. The errors created client trust issues that manual proposals never caused.

Or: the team automated follow-up emails. But the trigger conditions weren’t quite right, because the underlying process wasn’t clearly defined. Now clients get duplicate messages, or messages at wrong times, or messages for situations that don’t apply to them.

Automation amplifies. Whatever’s there — good or bad — happens more consistently and at higher volume. If what’s there is broken, you get consistent, high-volume breakage.

The sequence that works

When someone says “automate X,” the useful response is: “What happens right before X?”

Then: “What happens before that?”

Usually within two or three steps upstream, you find the actual problem. It’s rarely technical. It’s usually about clarity, ownership, or handoff.

Fix that first. Document what should happen. Assign who’s responsible. Clean up the data where it originates.

Then automate. Now you’re automating a working process, not a broken one.

The return on fixing first

This approach takes longer initially. But the automation you build actually works. It doesn’t create new problems. It doesn’t require constant exception-handling. It doesn’t make someone’s job harder downstream.

The fastest path to good automation is making sure you’re automating something worth automating.

Why Automating a Broken Process Makes Things Worse — The mechanics of how automation amplifies existing problems