When is Automation worth it?

A common mistake is to start with a technology and look for something to do with it.

• We want to use AI.

• We should automate this.

• Could we build an agent for that?

These can lead to interesting ideas, but they don't tell you whether there is a useful project behind them.

We prefer to start one step earlier.

What is happening today? Who is doing the work? How often? How long does it take? Where do mistakes occur? What happens when the process doesn't work as expected?

Often, this conversation reveals opportunities that are considerably less spectacular than the original AI idea, but much more valuable.

It can also reveal that there isn't much of a problem to solve.

That's useful information too.

Frequency is one of the simplest filters.

Imagine a manual task that takes an employee 20 minutes. Automating it could reduce that to almost zero.

That sounds promising.

If the task happens 50 times every day, it probably deserves a closer look. If it happens four times a year, building an integration, testing it, maintaining it and dealing with exceptions may never pay for itself.

This sounds obvious, but it is surprisingly easy to overlook once a technically interesting solution is on the table.

The relevant number isn't only the time saved per execution. It's the accumulated effort over months and years compared with the cost of implementing and operating the solution.

Sometimes 20 minutes of manual work is perfectly acceptable.

Frequency alone isn't enough.

Some processes occur thousands of times but already require very little human intervention. Others happen only a few times per day but occupy several people for hours.

The more useful question is therefore how much actual human effort the process consumes.

This includes the obvious work, but also the less visible parts: moving information between systems, checking whether data is complete, correcting errors, waiting for approvals or repeatedly investigating the same exceptions.

This is where automation can become particularly valuable.

A process that looks like a five-minute task on paper might involve considerably more work once all the steps around it are included.

There is another question we ask quite early:

If we automate the process today, will it still look roughly the same six months from now?

Automating an unstable process often means automating its problems.

If responsibilities change constantly, exceptions are poorly understood or people perform the same task differently every time, technology doesn't necessarily fix the situation. It can simply make an unclear process harder to change.

In those cases, it may be better to standardise the process first.

This distinction becomes even more important with AI.

Traditional automation works particularly well when inputs, rules and outputs are predictable. AI can handle much more variability and can make automation possible in areas that previously required human judgement.

But that doesn't remove the need to understand the process.

It just changes what can reasonably be automated.

Not every automation problem is an AI problem either.

If a task follows a handful of clear rules, conventional software or a simple workflow may be the most reliable and economical solution.

Machine learning becomes interesting when decisions depend on patterns in data that are difficult to describe with fixed rules. That is why applications such as visual inspection, anomaly detection or predictive maintenance are good examples.

And AI agents become relevant when a process involves several steps, systems and decisions: retrieving information, interpreting it and deciding what should happen next.

We've written separately about how AI agents can extend traditional industrial automation when workflows require more flexibility and autonomous decision-making. craftworks already describes applications including predictive maintenance, incident follow-up, process optimisation, quality control and energy management in that context.

The point isn't to use the most advanced technology available.

It's to use the simplest technology that solves the problem well.

The happy path is usually easy to automate.

Real processes aren't made entirely of happy paths.

A supplier changes the format of a file. A sensor stops providing data. Someone enters an unexpected value. A production order doesn't match the usual pattern. An API is temporarily unavailable.

Someone still needs to decide what happens next.

Before automating a process, we therefore look at its exceptions as closely as its normal flow.

How often do they occur?

Can they be detected reliably?

Can the system handle them, or does a person need to take over?

And most importantly: what are the consequences if the automation makes the wrong decision?

For some processes, an occasional manual intervention is perfectly fine. For others, a wrong automated decision can stop production or create a quality problem.

That difference matters when deciding how much autonomy to give a system.

This question should be answered before implementation, not afterwards.

What does success look like?

Less manual work might be the obvious answer. But depending on the process, the relevant measure could also be fewer errors, shorter lead times, reduced downtime, lower scrap rates, better forecasting accuracy or higher production output.

If there is no way to measure the current process, demonstrating that automation improved it becomes difficult.

This is one reason we define success criteria early in our projects.

A good automation project should leave you with more than functioning software. You should be able to show what changed.

When we look at a potential automation project, we therefore try to understand a few fairly mundane things first.

Does the process happen often enough to matter? Does it consume meaningful human effort? Is it sufficiently stable? Are the necessary data and interfaces available? Can exceptions be handled safely? And is there an outcome we can measure?

You don't need a sophisticated AI strategy to answer these questions.

You need a reasonably good understanding of the process.

If the answers point in the right direction, the next step is to determine what kind of automation makes sense. That might be a conventional workflow, an optimisation model, machine learning or an AI agent.

And sometimes the result of the assessment is that nothing needs to be built.

We like automation. We build a lot of it.

But technology has an implementation cost and, more importantly, an operating cost.

Every automated process becomes something that needs to be understood, maintained and adapted when the surrounding organisation changes.

For high-volume, repetitive or data-intensive processes, that investment can pay off very quickly.

For a task somebody performs twice a month in a spreadsheet, it might not.

Knowing the difference is more valuable than automating everything you can.

We can look at the process, available data and existing systems with you and determine whether automation is likely to create enough value to justify the effort.

If it does, we can build and test the solution against real operational data before you commit to a larger implementation.

TALK TO US ABOUT YOUR USE CASE