When we talk to companies about automation, the first suggestion is almost always the same: start with the biggest problem. The order handling everyone complains about. The pricing sheet three departments depend on. Understandable, and usually the wrong entry point. The biggest problem is almost always the most complicated one, with the most exceptions and the most stakeholders. Start there and you will spend four months in alignment meetings with nothing running. The better first process looks different, and a few sober criteria will point you to it.

Why the biggest pain is the wrong start

A complex core process has many edge cases, and every edge case is a discussion. What happens when the customer changes the order afterwards? When two discounts apply at once? When the colleague in purchasing handles it differently than the one in sales? Before the first line of software gets written, the company has to answer these questions for itself. That is valuable work, but it takes time, and as a very first project it is frustrating.

There is also the risk factor. If your first automation touches the most important process and something goes wrong, trust across the team is damaged. The second automation then faces a much steeper hill. A small, unspectacular process that runs reliably after six weeks is the better foundation.

Official statistics show how much ground small companies in particular still have to cover. According to Statistik Austria (2025), only 71 percent of small companies with 10 to 49 employees are at least basically digitalized, meaning they use at least four of twelve surveyed digital technologies. Among large companies with 250 or more employees, the figure is 98 percent. The most realistic way to shrink that gap is a first project that holds up.

How to recognize a good first candidate

The ideal starter process is frequent, boring, and rule-based. Frequent, so the effort pays off: a task that happens ten times a day yields more than one that happens twice a month. Boring, because nobody will fight over it. And rule-based, because the logic can be written down without anyone having to say “it depends”.

The task happens at least daily, ideally several times a day
One person can explain the rules in ten minutes without hesitating
The exceptions are known and countable, not “somehow always different”
A mistake would be annoying, but not threatening to the business
The process touches few systems, ideally two

An example: supplier invoices in a trading company

Picture a trading company with fifteen employees. Every week, around forty supplier invoices arrive as PDF attachments. One employee opens each invoice, types the amount, supplier, and invoice number into the accounting software, files the PDF in the right folder, and forwards it for approval. Five to ten minutes per invoice, adding up to half a working day per week.

This process ticks every box. It is frequent, the rules are clear, the exceptions are known: invoices without a purchase order go to purchasing, anything above €5,000 goes to management. After automation, the software reads the PDFs, checks them against the order data, files the documents, and routes the approval to the right person. The employee only reviews the cases where something does not add up.

Clarify first: does the process even exist?

An uncomfortable truth from practice: some workflows people want to automate do not actually exist as a process. Three people do the same task in three different ways, and each way sort of works. Software forces a decision here, and that decision should be made by the company, not by the developer.

Our advice: before talking to a provider, have the person who does the task every day write it down step by step, including the cases where they deviate from the rule. That single page saves weeks later, and it often shows on its own whether the process is ready for automation.

What a first automation step costs

A well-defined process like the invoice example typically costs between €5,000 and €15,000 to build, depending on how well the systems involved expose their data. Add running costs for hosting and maintenance, realistically €50 to €200 a month. If you save half a working day per week, you recover that within one to two years at normal fully loaded labor cost.

The counter-check matters just as much: a process that only costs one hour a week barely pays for itself at those development costs. Then the honest answer is that it should stay manual. We say that out loud, too.

What not to automate first

Anything customer-facing that could damage your reputation does not belong in round one. Neither do processes currently in flux: if a new ERP arrives next year, any automation built around the old system is built on sand. And processes where half the cases are judgment calls are not automation problems, they are organizational ones.

The core process with all the exceptions still gets its turn, just as the second or third project. By then, company and provider know each other, the exceptions from the first project are documented, and the team’s skepticism has given way to the experience that this kind of thing can work.