When not to.
When not to automate a process — and what to fix first.
Automation is not right for every process — here are the seven most common cases where something else needs fixing first, rather than writing a system.
Automation is not for every process.
Not every process benefits from automation. There are situations where it will cost money without returning anything — or will automate a problem instead of solving it. The honest sections are the ones where a company says "not now," not the ones that promise everything. Below are the seven most common cases where automation fails, and what to do instead.
What the seven have in common is one thing: automation takes something that already works reliably and makes it faster and more consistent. If there is no stable, clarified process underneath, automation has nothing to build on — it simply speeds up the confusion.
Our own AI audit sometimes reaches exactly this conclusion — that the company is not ready for automation of a particular process just yet. That is not a failure of the conversation; it is the very result the card is meant to show honestly.
When to wait.
The process changes every month
If the way of working has not yet settled, automation will chase a moving target — you will reconfigure the system as often as the process itself changes. Stabilise the way of working for a few cycles first, then automate.
Under ~5 hours monthly
If the task takes little time, the automation cost is hard to pay back within a reasonable period. Check the actual hours before deciding — not the impression of them, which usually overstates how long something unpleasant takes.
No one agrees on the "right" answer
If even the people on the team disagree on what the correct result should look like — which price is right, which format is the standard — the system will not invent it for you. It will automate the disagreement, not the answer. Clarify the rule first.
The data lives in one person's head
If the knowledge is not written down anywhere — in a spreadsheet, in software, even in a plain notebook — there is nowhere for the system to take it from. Write it down before automating access to it; this alone already reduces risk, even without automation.
The software cannot be read
A closed system with no files, no export, and no access is hard or impossible to connect to. Check in advance what can actually come out of it — a list, a file, at least a screen printout — before planning automation around it.
You want "something with AI" without a problem
Automation with no concrete process behind it usually stays a demo — interesting to show, but with no effect on the working day. Start from the problem, not the technology, and automation will come naturally as a solution, not as a goal in itself.
The team does not agree
If the people who do the work today do not support the change, resistance will stop the implementation in practice, even if the technical solution is fully ready. Clarify agreement first — explain exactly what will change in their working day and why.
What to do before automating.
The common fix in all seven cases is the same: clarify the process before automating it. That means agreeing on what the right result is, writing down knowledge that lives only in someone's head, and checking the actual hours rather than the impression of them. Only then does automation have something to work with.
This work takes days or weeks, not months, and usually happens naturally while you decide how to organise the process better even without technology. Automation follows as a next, easier step, not as the first solution to a still-unclarified problem.
If you are not sure which camp your case falls into, the AI audit is a way to check it on a concrete example instead of in theory — see the audit. For who we are and how we work, see About. For a real example of what a stabilised, automated process looks like, see invoice automation step by step.
What people usually ask.
If the process changes often, does that mean it can never be automated?
Not forever — it means it first needs to be stabilised. Once the process repeats the same way for a few cycles, automation becomes possible.
How do I check the actual hours, not the impression?
Record for two or three weeks how much time the task actually takes, instead of relying on a rough estimate. The AI audit also includes such a calculation.
What if only I know how the process is done?
The first step is to write it down — even in a plain spreadsheet. Without written knowledge, there is nowhere for automation to take it from.
Is an audit worth it if I am not sure I am ready?
Yes — the audit is exactly a way to check readiness on a concrete example, before deciding whether and what to automate.