How to automate processes without stopping the business

Most companies know perfectly well they're losing hours to repetitive work. What stops them isn't a lack of awareness — it's the memory of the last time somebody said "we're changing the system" and six months of chaos followed.

The good news is that isn't the only way to do it. Automation done properly is incremental, runs alongside what you already use, and can be switched off if it goes wrong.

Step 1 — Map the real process, not the documented one

This is the step most often skipped and the one that decides everything. The documented process and the real process are two different things in 100% of the companies we've walked into.

What to look for:

• Where the same data gets entered twice.
• What gets copied and pasted between spreadsheets.
• What gets retyped because the format doesn't match.
• Which step depends on one specific person being available.
• Which checks are done "from memory" because the system doesn't do them.

Talk to the people doing the work, not only the ones directing it. Management describes the process as it should be; the person entering delivery notes describes the one that exists. The second map is the useful one.

One practical detail: use a stopwatch. "This takes a while" is useless for prioritising. "This takes forty minutes, three times a day, across two people" is a number that turns into a decision.

Step 2 — Prioritise by impact and effort, and pick exactly one

With the map on the table, fifteen candidates appear. The temptation is to start with the most ambitious. That's a mistake.

Plot each candidate on two axes — hours recovered and technical difficulty — and pick from the high-impact, low-effort corner. It's almost always repetitive data entry: delivery notes, invoices, orders, customer onboarding.

Pick one. Not three. One that can be finished in weeks and that changes the day of a specific, named person. That person will be your best ally when it's time to convince everyone else.

Step 3 — Build on what already exists

You don't need to replace the ERP to automate document entry. Most systems you already run expose some way in and out: an API, a scheduled export, a database you can query, a folder where files land.

This matters for two reasons. The obvious one: it's faster and cheaper. The less obvious one: if it goes wrong, you switch it off and everything keeps working as before. A project that can be reversed is a project that can be attempted. One that demands migrating everything before you see a single result is a bet — and bets get postponed forever.

Step 4 — Run in parallel before you replace

For two or three weeks, the old process and the new one run side by side. Yes, that's double work, and yes, it's worth it.

It's the only honest way to answer the question everyone is silently asking: does the new system produce the same numbers as the old one? If they match for three weeks, trust is earned and switching off the old process meets no resistance. If they don't match, you've found a case you failed to map — which is exactly what this stage is for.

One tip: define the shutdown criterion in advance. "When the totals match three weeks running" is a criterion. "When we feel comfortable" is not, and it guarantees the old process survives another year.

Step 5 — Measure in hours, not impressions

Before starting, write down how long the process takes today. After it goes live, measure again.

It sounds obvious and almost nobody does it. Without that number, two bad things happen: you can't justify the next automation, and the organisation remembers the project by its cost instead of its return.

The three mistakes we see every time

Automating a broken process. If the current process has three steps that exist only because the previous system demanded them, automating it crystallises the problem and makes it faster. First ask why each step exists; then automate what's still standing.

Starting with the hardest case. The rare exception, the customer with their own rules, month-end close. That case has to be solved — in version two. Made first, the project stalls before showing a single result.

Not naming an owner. Every automated process needs one person responsible for watching it, understanding what it does, and deciding when something changes. Without an owner, six months later nobody knows why the system does what it does, and the organisation drifts quietly back to the spreadsheet.

What AI changed

What couldn't be automated before was anything that required reading. A scanned invoice, an email with an order written in prose, a voice note from a salesperson.

That's solvable now, and it's why processes written off three years ago are back on the table. But the order didn't change: map, prioritise, build on what exists, run in parallel, measure. AI widens what can be automated; it doesn't replace the method.

If you'd like us to look at your operation and hand you a prioritised map — regardless of who builds it afterwards — that's exactly what a diagnosis is.