Before you automate: why the problem usually isn't the tools

When an operation starts running slow, piling up errors or depending on too many hands, the same reaction usually shows up: "we should automate this." It's a reasonable response, and often a premature one. Automating a process that doesn't work doesn't fix it: it runs it faster, with less visibility and more dependency. Before you automate, an uncomfortable question is worth asking: is the problem in the tool, or in the fact that there's no system behind it? This piece is for making that call with criteria: how to tell a tool problem from a system problem, which signs say it isn't time yet, and what order to move in.

"Automate" isn't the same as "get in order"

Automating means handing a machine a process you already understand and that already works. That word — "already" — is the one that usually gets skipped. If a workflow is confusing for the people running it, automating it doesn't clarify anything: it freezes the confusion and repeats it faster, with nobody looking at it.

Getting in order is the work that comes before: understanding what's really happening, why, who decides and with what data. They're two different tasks, and it's worth doing them in that order. Mixing them up is a common cause of automation projects that promise savings and deliver fragility: a lot of speed on foundations nobody has checked.

Why the problem usually isn't just the tool

When something jams, it's tempting to point at the software. Often, looking only at the tool makes us miss what's really costing us: the gap between tools, decisions and data.

Loose tools that don't talk to each other

Picture a common pattern, no names attached: orders arrive by email or WhatsApp, someone copies them into a spreadsheet, they get checked against the CRM, and in the end everything depends on one person who knows how to make it all fit. Each tool in that chain — email, spreadsheet, CRM — does its part. What fails is the chain: the real work is the manual "glue" between one piece and the next, and the judgement living inside one person's head. These are tools that don't work together, not bad tools.

The hidden cost: a missing system, not missing software

That cost never shows up on an invoice. You feel it in the time spent gathering and reconciling, in the errors that creep in from copy-pasting, in decisions delayed because the data doesn't match, and in the risk that one person going on leave — or leaving — stalls everything. Buying another tool to paper over that gap often just adds one more piece to a chain nobody fully understands anymore. What's usually missing isn't software: it's a system — a defined process, an owner, and data you can trust.

Signs it isn't time to automate yet

A few signs that automating might be premature:

• Nobody can explain the whole process end to end without an "it depends."
• The process keeps changing or has more exceptions than rules.
• The input data isn't reliable: duplicates, gaps, or versions that don't match.
• There's no clear owner of the process; each step gets carried by whoever's used to doing it.
• The real motive is "papering over" something broken instead of redesigning it.

If you recognise two or three of these, the next step isn't automating — it's getting in order. And it isn't just a small-business issue: the bigger an organisation gets, the more tools it accumulates and the more expensive those gaps become.

The right order: understand → order → connect → automate

A simple sequence avoids most of the expensive mistakes:

1. Understand. Map how things actually work today — not how they should — with the exceptions and shortcuts included.
2. Order. Define the process, assign an owner, and decide which data rules when two sources disagree.
3. Connect. Get the tools you already have sharing a single source of truth, instead of copying data from one to another by hand. That groundwork — assessment, order and connection — is exactly where we usually start.
4. Automate. Only then, and only what actually pays off.

Seen this way, the question of what to automate first tends to answer itself: whatever is stable, repetitive and rests on reliable data. Everything else isn't ready yet.

When NOT to automate (yet)

Automating a handful of things well beats automating many things badly. It's worth holding off — for now — when:

• the process still changes weekly or lives on exceptions;
• the input data isn't reliable, because you'd just repeat the error at scale;
• nobody owns the process or can explain it end to end;
• the volume is so low that building and maintaining the automation costs more than it saves;
• it would be a way to dodge a redesign the process actually needs;
• it would add one more tool without reducing the ones that already don't talk to each other.

Saying "not yet" in time is part of the job, not a retreat. It's what makes sure that when you do automate, you automate something worth the effort.

Before you automate: five questions

A quick way to decide when to automate a process is to answer five questions honestly:

1. Can someone explain it end to end without "it depends"?
2. Do we trust the data going in?
3. Is there a clear owner?
4. Is it stable and repetitive enough to be worth it?
5. Are we automating the right process, or papering over the broken one?

If the answer to any is "no," that's the groundwork. Automation comes after — and pays off far more.

At Dateliers we'd rather look at the system first: understand where the friction is before connecting or automating anything. If you want to see how we approach it, here's how we work.