Will Automation Pay Off? Check This First

The story is always the same. A company decides to automate something. The demo looks good. Six months and a serious invoice later, the team is still doing most of the work by hand - only now they also have software to keep an eye on.

It is almost never the software's fault. The problem is that the demo ran the easy version of the job, and the company never checked how often the easy version actually happens.

There is one number that tells you this in advance. It takes a week and a spreadsheet to find, and it costs nothing.

Meet the workshop

Let's follow one company through the whole thing. A sheet metal workshop: it cuts, bends and drills parts to order. Around 200 orders a week. The owner is considering software to handle order intake, because the two people doing it are drowning.

The numbers in this walkthrough are made up so you can follow the method. The real client project comes at the end, and those numbers are published.

Here is a normal order at this workshop. The customer sends a drawing in a clean file. The part is a shape the machines already cut. The material is in stock. The delivery date is a working day. Nobody has to ask anybody anything. The order goes from inbox to the shop floor in a few minutes.

And here is a special case. The customer sends a drawing that the software cannot open properly. Or the material is not in stock this week. Or the sales rep promised a price that is not in the price list. Or the delivery date lands on a public holiday. Every one of these stops the order and puts a person in the middle of it.

That share - special cases as a percentage of all orders - is the number. Call it the exception rate.

Two different kinds of "not normal"

Before counting, separate two things, because they need opposite fixes.

A special case is when there is a rule, and this order follows a different part of it. The workshop has agreed 60-day payment terms with three big customers. That is not a mistake. It is a rule, written down somewhere, that applies sometimes.

A patch is when there is no rule and someone invents one on the spot. The order clerk phones the shop foreman to ask whether a shape can be cut, because nobody ever wrote down what the machines can and cannot do. Nobody decided this should be a phone call. It became a phone call because information was missing.

Special cases can be built into software. Patches cannot - there is nothing to build, because no rule exists yet. If you mix them together in your count, you end up paying a developer to make your missing information permanent.

Count it for one week

No tool, no project, no meeting. One process, five working days, one sheet.

Every time an order comes in, write one line: the order number, the date, whether it was normal or a special case, why if it was not normal, who made the decision, and roughly how many extra minutes it took.

Three of those matter more than the rest. The reason has to be in plain words - "customer sent an old drawing", not "file issue". Who decided shows you where the real knowledge sits, which is often not where the job titles say. And the minutes are a guess, not a measurement; within five minutes either way is good enough.

Write it down as the orders happen. Filling the sheet in from memory on Friday gives you a number that looks tidy and means nothing.

One more rule: when nobody can agree whether an order was normal or special, mark it with a question mark and move on. Those question marks are not a problem with your sheet. They are the most useful thing you will find all week. If your own team cannot tell the standard job from the special one, there is no rule for software to follow yet.

What the workshop found

At the end of the week: 200 orders, 48 of them special cases. Just under one in four.

Then the owner sorted those 48 by reason:

• 19 orders - the customer's drawing file was messy or incomplete
• 11 orders - the material was not in stock
• 8 orders - the delivery date fell on a public holiday
• 10 orders - one-offs, each different, nothing repeating

So three reasons explain 38 of the 48. Around eighty percent of the problem sits in three places.

Why this is good news, and when it would be bad news

One in four sounds high. It is not, because of how it is spread.

The workshop is not facing 48 problems. It is facing three. Three reasons can be fixed, or written into a rule, or given to a specific person to handle. That is a normal, finishable piece of work.

Now imagine the same 48 special cases spread across 38 different reasons, none happening more than twice. Same percentage, completely different situation. There is nothing repeating, so there is no rule to write. Software built for that would need 38 branches, and nobody would trust any of them.

So the real question is not "is one in four too much". It is: how many rules would I have to write to cover most of what actually happens? Three or four, and you are ready to build something. Thirty, and your project is not a software project yet.

Now add up the minutes

Here is where the minutes column pays off. The workshop totals the minutes for each reason instead of counting how often it happened:

• messy drawing files: 19 orders × about 20 minutes = 380 minutes
• delivery date on a holiday: 8 orders × about 25 minutes = 200 minutes
• one-offs: 10 orders × about 15 minutes = 150 minutes
• material not in stock: 11 orders × about 5 minutes = 55 minutes

Notice what changed. By frequency, the stock problem looked like the second biggest headache. By time, it is the smallest thing on the list. The drawing files cost almost seven times more.

Fix things in order of minutes, not in order of how often people complain about them.

The whole week comes to about 785 minutes - a bit over 13 hours. At a loaded cost of €20 an hour, that is roughly €260 a week, or around €1,100 a month, spent on orders that did not follow the standard path. That is a number the owner calculated from his own workshop in one week. It is worth more than any figure in a vendor's brochure.

Three ways to fix a reason

Each repeating reason gets exactly one treatment.

Remove the cause. The material stock problem is not really an order problem. It is a purchasing problem showing up at order intake. Fix stock levels for the ten most common materials and the reason mostly disappears. No software needed. This is the cheapest fix and the one companies skip most often, because it belongs to a different department.

Write it into a rule. The public holiday problem is a perfect candidate. The rule already exists and never changes: if the delivery date is not a working day, move it to the next one. A person should never have to think about this again.

Send it to a person, properly. Some things genuinely need a human decision - a special price for a long-standing customer, for example. "Properly" means it goes into a named queue with one owner and an agreed response time, not into a shared inbox where it waits until someone notices.

Most companies try to turn all three into software. That is why their automation ends up fragile. Gartner's own advice points the same way. In its June 2025 press release predicting (opens in new tab) that over 40% of agentic AI projects will be cancelled by the end of 2027, analyst Anushree Verma splits the work up exactly like this: agents "when decisions are needed, automation for routine workflows and assistants for simple retrieval". You can only make that split if you have separated your reasons first.

What happened in the real project

The workshop above is an illustration. The drawing file problem is not.

In our sheet metal quoting project (opens in new tab), a real and predictable share of customers submitted incomplete or messy CAD files - files that would break a normal converter. That is a cluster: one reason, happening again and again, with a rule behind it. Instead of sending every one of those to a person, our developers built automatic preprocessing that handles imperfect uploads.

The published results for that system: quoting time down from days to minutes, ordering 2x faster, a 5x increase in custom orders and 50% less administrative work.

The 5x is the part worth pausing on. Handling the annoying cluster properly is what made all those extra custom orders possible. The workshop did not grow because it automated the easy orders. It grew because the hard ones stopped being hard.

Why not just measure hours saved

Because hours saved is a guess until the system exists.

If your exception rate is high, the hours do not disappear when you automate - they move. Your team stops doing the work and starts supervising software doing the work, and fixing what it got wrong. That is often worse, because the old job could be planned and the new one interrupts you all day.

This is about order, not about one metric beating another. Hours saved is the right measure after you deploy, to check that you got what you paid for - and if you cannot show real numbers thirty days in, something is wrong. Exception rate is the right measure before you decide, when nothing has been spent and the only honest question is whether this process can be automated at all.

The industry numbers point the same way. In February 2025 Gartner predicted that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data (opens in new tab), and noted that 63% of organisations either do not have the right data practices or are not sure whether they do. These projects mostly do not fail on technology. They fail because the process underneath was never stable enough to automate.

If your number comes back bad

Suppose you count and it is a third of your orders, spread across dozens of unrelated reasons. That is not bad news. That is the cheapest useful finding of your year - you have just avoided buying something that would have disappointed everybody.

What to do then is unglamorous and it works. Remove the causes you can. Write down the rules that currently live in one person's head. Close the gaps where people are patching missing information by phone. Then count again in three months. When the same week produces fewer special cases and fewer distinct reasons, you have an automation project instead of a gamble.

We have seen that order of operations pay off. In our steel manufacturing ERP project (opens in new tab), production had been tracked in Excel with no live view; once the standard path was made real and visible, the published results were 15% higher output, material picking and dispatch 35% faster, and about three hours a day back for each production manager. In a quality control system for a bicycle manufacturer (opens in new tab), making the checks explicit instead of habitual gave 100% traceability with digital audit trails, 80% less manual documentation and 65% fewer quality deviations. In both, the software came last.

We have written about that groundwork in Business Process Documentation Before You Automate (opens in new tab) and Process Automation Starts After Process Repair (opens in new tab) - this article is the missing "how" behind the advice in that second one to review your exception rate regularly.

Start with the week, not the vendor

You do not need a budget to find out whether automation will work in your company. You need one process, one sheet, and five days of writing things down as they happen.

At the end you will know how many of your orders are special cases, how few reasons cause most of them, where the decisions are really being made, what it costs you per month, and which three things to fix first. That is more than most automation projects know when they start.

If you would rather have someone else look, try our free three-minute diagnostic (opens in new tab). And if the honest answer for your business is "fix the stock levels, not the software", we will tell you that - it is usually cheaper, and sometimes it is the only thing that works.

If you want a second pair of eyes on your count, get in touch (opens in new tab).