How to choose the right process to automate

To choose the right process among several candidates, it is not enough to look at which one repeats the most. Check five things before commissioning anything: that you can gather real examples of the process, odd ones included; that the program where the data ends up accepts it; that there is a person who reviews what is unclear; that you know where that data may live; and who controls access. The candidate that passes all five with the least work goes first. Then you test it with those examples before turning it into a project.

Which processes are candidates we already covered in how to automate processes in a small business: the ones that repeat, follow steps that can be written down and today consist of copying data by hand. This article starts where that one ends, with the list of candidates already made.

Why picking the most annoying one is not enough

The process that takes the most time is usually also the hardest to automate. It is annoying precisely because the data arrives in a mess, because it goes through three programs or because it depends on someone who knows the exceptions by heart. Picking it first means starting with the riskiest part.

What decides whether an automation ends up working is almost never the code. It is everything around it: whether there is something to test it with, where the data goes, who keeps an eye on it and who opens the door to install it. All of that can be found out before spending anything, and it is worth doing for every candidate.

The five checks

There are real examples, odd ones included

A process that cannot be shown with examples is not ready to be automated. The proof that something works is the real documents, not a few clean samples prepared for the demo.

A manufacturer we built an order-reading system for received orders as PDFs, Excel files, Word documents, phone photos and handwritten sheets. The system was technically validated with real orders from its customers, handwritten ones included, because those were exactly the hardest to type. Had it only been tested with the tidy PDFs, the result would have said nothing.

The same goes for the Barcelona importer we are building management software for: every catalogue import is tested with the real spreadsheets from its suppliers, which each factory lays out in its own way.

The useful step is to gather a folder of examples from the last few weeks, without picking: the normal ones, the incomplete ones and the ones nobody can read at first glance. If that folder is hard to put together, that is already information about the candidate.

The destination program accepts the data

Every automation ends up writing somewhere: the management software, the accounting program, a shared spreadsheet. Before choosing a process you need to know how data gets into that program.

In the manufacturer's case, the system puts each order line into a file with the columns its management software already knows how to import. That program did not have to be touched. With the importer, the accounting program they already use keeps doing the accounting and is left alone: the connection to it will come in a later module.

The concrete question for the program's vendor, or for whoever looks after it in the company, is: does it import a file, with which columns and in which format? If the answer is that it accepts nothing from outside, the project grows, and it is better to know that before comparing it with other candidates.

Someone reviews what is unclear

There will always be a part the automation cannot solve on its own: an order with a reference that does not exist, an email that fits no category. Decide beforehand who looks at it and when. If nobody has time to review, the doubtful cases pile up and the system stops being used. A candidate that already has its natural reviewer, the person who does the copying by hand today, starts with an advantage.

You know where the data may live

Some companies do not want their documents to leave their own machines, and others prefer the cloud so they do not have to maintain a server. Both options are reasonable and they change the shape of the system. The manufacturer's system, for example, can run entirely on the company's own computers. What is expensive is discovering that preference once the system is built.

Also, if the examples contain personal data, testing with them already counts as processing it: the EU Court of Justice said so explicitly for software testing (CJEU, case C-683/21, 2023). Before connecting anything to a company's real mailbox or database, the data processing agreement under Article 28 of the GDPR (2016) has to be signed.

It weighs more with some kinds of data. At an accounting and payroll firm we built an email board for, one of the categories is sick leave: that is health data, which Article 9 of the GDPR (2016) treats as a special category. A process with data like that can be a good candidate, but it needs the paperwork in order before the first test.

It is clear who grants access

An automation needs to get into places: a mailbox, a server, a shared folder, the management software. Often that access is not controlled by whoever commissions the project, but by an outside IT technician or the program's vendor.

At the firm, connecting the board to the department's mailbox needs the email credentials, a domain and access to the machine where it is installed, and that part is handled by their outside IT technician. It is as much a part of the project as the code. The system is built and tested; it is waiting to go live at the firm.

So when comparing candidates, note down who has to give permission for each one. The one that depends only on people inside the company usually gets going sooner.

How to compare several candidates

With the list made, run each candidate through the five checks. There is no need for scores with decimals: just see which candidate raises the fewest alarms.

The practical order is this:

List of candidates

Are there real examples?

Does the destination import data?

Test with the examples

First module

no

Sort out the process first

no

Solve how data gets into the program

The first two filters are the ones that rule out the most candidates, and the cheapest to check: a folder and a question to the program's vendor.

A small test before commissioning it

Once the candidate is chosen, the sensible move is to test it with the folder of examples before turning it into a full project. The test is not looking for a number to show off, but for answers to three questions:

• Does it read the odd cases? The handwritten ones, the incomplete ones, the ones in a format only one supplier uses.
• Does it produce what the destination needs? A file the management software imports without touch-ups, not a table someone then has to adapt by hand.
• What is left for the reviewer? If they correct little and understand why the system got it wrong, the process was well chosen. If they correct almost everything, you should have started with another one.

That is what we did with the manufacturer: the system was validated with its real orders before installing it was even discussed. And it is the reason the importer's software is moving forward module by module, starting with the catalogue and testing every import with real spreadsheets.

A test like that is done with examples the company can share without issue, or with the processing agreement already signed. Never "just to see if it works" with personal data and no paperwork.

When not to choose that process yet

Some candidates are better left for later even if they are the most annoying:

• It changes every month. If the rules are still being decided, automating them only locks in the mess.
• Nobody can provide examples. Without a folder of real cases there is no way to test it.
• It depends on a program you are about to replace. Better to wait for the new program than to build the way into the old one.
• It involves sensitive data and the paperwork is missing. First the processing agreement; then the first test.
• Nobody is going to review. An automation with no one looking at the exceptions gets abandoned.

In those cases, the right process to start with is the second one on the list. If you want to see the kind of projects we do, they are in services; if you are wondering whether you can start with a single module or whether you have to drop the program you already use, we answer that in the FAQ.