Automation has a storytelling problem. It is presented as a technology decision (which tool to adopt), when it is almost always an organisational decision: which part of the work deserves to be described precisely enough for a system to carry it out.
That distinction has practical consequences. Automating a process that works badly does not fix it. It makes mistakes faster and harder to correct. The work therefore begins before the tools, by examining how things are done today.
Automation means describing, not just connecting
Many people think of automation as linking two applications. That is partly true, but the difficult part comes first: deciding what should happen in every possible case.
What happens if a form arrives without a telephone number? If the customer already exists in the management system with a differently formatted address, should it be updated or duplicated? If an external service does not respond for three minutes, should the flow retry, discard the request or alert someone?
As long as those answers exist only in the head of the person doing the work manually, the process is not automatable; it is simply habitual. The most useful stage of an automation project is when these questions are asked and receive written answers.
What is almost always worth automating
Some categories consistently repay the effort because they are frequent, predictable and low in ambiguity.
Moving data between systems. This is the most common and underestimated case. A website enquiry manually copied into a CRM, an order re-entered in a management system, or a spreadsheet updated every Monday with data that already exists elsewhere. Copying adds no value and introduces errors, so it is the first place to look.
Notifications tied to clear conditions. A quote unchanged for ten days, an approaching deadline, stock below a threshold or an unreconciled payment. These are simple rules that nobody can monitor consistently, so they are often checked only after something has gone wrong.
Qualifying and routing requests. The aim is not to decide in a person’s place, but to prepare the decision: collect the request, check that it is complete, assign it correctly and attach information already available about the customer.
Following up a request. An immediate confirmation, a reminder after a few days and another message if no response arrives. Follow-up is the first thing dropped during busy periods and one of the things that matters most commercially.
Generating recurring documents. Quotes, confirmations, monthly summaries and standard contractual attachments: anything assembled from the same template while changing a handful of fields.
Periodic closing tasks. Exports, reconciliations and reports that somebody prepares each month by spending the same half-day on them.
The common thread is not the technology. These tasks are repeated, can be described completely and have limited consequences if one execution fails.
What is better left to people
There are situations where automation makes matters worse, and recognising them in advance saves more time than the automation itself could.
Processes that are not yet stable. If the way of working changes every two months because the business is growing or still finding its shape, a workflow built today will soon need rebuilding. Wait for the process to settle, or automate only the part that certainly will not change.
Decisions that require judgement. Granting an exception, assessing a sensitive complaint or deciding on a discount for an important negotiation. A system can gather and organise the facts, but the decision remains with a person who is responsible for it.
Frequent exceptions. If half of all cases end with “it depends”, the main flow covers half the work and the other half becomes a more complicated manual process because there is now a system to accommodate as well.
Tasks that happen five times per year. Automation has a construction cost and a maintenance cost. A rare task, however tedious, often does not repay either.
The useful question is not “can it be automated?”. Almost anything can. The question is: how often does it happen, how stable is it and what happens when it breaks?
The cost nobody puts in the quote
Automation is software, and all software needs maintenance. APIs change, providers update their tools, credentials expire and data formats are altered by somebody who did not know a connected process existed.
A fragile automation is worse than the manual task it replaced because it can fail silently. When manual work stops, the person doing it notices. An automated flow can remain broken for weeks, and the problem is discovered through what went missing: enquiries that stopped arriving or reminders that were never sent.
The least visible part of an automation project is therefore the most important: error handling, retries where appropriate, a record of what ran and an alert to a real person when something fails. A system that only works when everything goes well is not finished.
People inside the flow, not outside it
The idea of automation replacing people is usually wrong. In business processes, the opposite arrangement tends to work better: the system prepares and the person confirms.
An automatically generated quote sent without review is a risk. The same quote generated in thirty seconds, presented complete and waiting for one click, removes tedious work while retaining control where it matters. The time saved is almost the same; the risk is very different.
Approval belongs where the consequences of an error are high: external communications, amounts, contractual data and deletions. Where an error is recoverable, approval is merely an obstacle.
Start small, for a precise reason
The most effective starting point is one measurable, tedious process, taken all the way to completion. Not merely because it is cautious, but because the first project reveals how the company really works: what data exists, how clean it is, who decides what, which tools are in use and which were bought but never adopted.
This information does not emerge from a meeting. It emerges when a process is described with the precision required for a machine to perform it. The second project then costs much less than the first.
The criterion in one line
Look at the process first, then decide what to automate. Reverse the order and you get elegant flows solving problems nobody had, while the work that actually weighs on the business continues to be done by hand.
Go deeperAI & Automation
