Which Processes Are Worth Automating, and How to Spot Them

Four questions with which you can sift your own day-to-day work: whether it is a chain with an outcome, whether the machine receives data or a picture, whether a step decides something about a person, and whether the process already has an external deadline.

The question “what should we automate” is usually asked too late, because it assumes the answer is a list of tools. In practice most failed automation projects have started with the right tool laid on top of a wrongly chosen piece of work, and it was the choice, not the tool, that decided the result.

This article does not try to define what business process automation is, because a definition does not decide anything; instead it gives four questions with which you can sift your own day-to-day work, and after each question it shows what a case that passes looks like, and what a case that fails looks like. The sifting costs nothing and takes one afternoon, but it saves considerably more than any comparison of tools, because it answers the earlier question in the chain.

The first question: is it a chain with an outcome, or a string of clicks

This is the boundary that decides the most, and it is worth drawing precisely: a process is a chain of actions that has input data, an outcome and an owner: raising an invoice from an order, taking on a new employee, the path of a customer enquiry from a form to a reply. A procedure, or a single action, is how a particular step is done: where to click, what to copy, which field to put a number in.

You can automate both, but the return differs several times over, and that is why the order matters: if you automate a chain, you change the outcome — the document arrives in the accounts by itself, and nobody retypes it any longer. If you automate a string of clicks, you speed up one step in a chain whose remainder stays the same, and the gain is exactly as large as that one step’s share of the work.

The practical way to recognise this is simply to ask what happens to the result afterwards, and the answer usually says everything: if it is “then someone picks up this file and puts it into another system”, the chain continues, and automating one step means moving the bottleneck, not removing it. If the answer is “then the work is finished and the result is in the system”, you have a process with a clear end point, and those are the ones worth taking first.

Take one typical chain and follow it all the way through, because following it through is what shows where the gain actually sits: a customer fills in a form on the website, the enquiry arrives by email, someone retypes it into the customer records system, someone else prepares a proposal, and after it is approved someone else still raises the invoice in the accounting software. Here there is one process with a clear outcome (from enquiry to invoice), and in it there are at least three places where the same data is retyped from scratch, each time with a chance to get it wrong.

If from this chain you automate only the retyping of the enquiry into the records system, the gain is real, but small, because the other two retypings remain. If you automate the whole chain, the character of the work itself changes: the person no longer retypes, but checks and takes decisions where they are actually needed. That is why the boundaries of the chain are worth drawing before any conversation about tools, because they determine how large the possible gain is.

The chain also has an owner, and that is a question that tends to go unasked. If no particular person can say how the process runs from start to finish, the automation will be a string of assumptions about how it probably runs, and the first real case will break those assumptions. Finding the owner usually takes one conversation, but it saves several weeks, so it is the cheapest part of the project.

The second question: does the machine receive data or a picture

This is the most important technical distinction in the whole of automation, and in the United Kingdom it now has a regulatory side as well. If the system receives structured data (XML, JSON, a record in a database), it can process it without guessing. If it receives a picture, that is, a PDF file or a scanned page, then before anything can be processed someone has to guess what is written there, and it is exactly that guessing that creates the errors someone later corrects by hand.

The invoice example shows this best, because there both possibilities sit side by side and are called almost the same thing. A structured electronic invoice, in everyday language also called an e-invoice, is a machine-readable document in a set format — in public contracts in the United Kingdom that form is BS EN 16931-1:2017, the semantic model named in the Procurement Act 2023. The recipient’s system can book it without a person taking part, and that is why it is this format, not a PDF, that a coming duty to issue e-invoices would actually attach to.

A PDF invoice that the customer has agreed to receive electronically is also a valid document: VAT Notice 700/63 allows an electronic VAT invoice, including in PDF, provided the authenticity of origin, the integrity of the data and the legibility of the content can be ensured, and provided the customer agrees to receive invoices electronically. But it is valid as a VAT invoice, not as an e-invoice, and to the machine it is still a picture.

From that follows a conclusion that saves a great deal of money: recognising PDF invoices with optical character recognition (OCR) is not the introduction of e-invoicing. It is a separate action that people reasonably automate, because it reduces retyping, yet it does not create a structured document and does not discharge a duty to issue one. A company that treats OCR as the answer to a regulatory requirement discovers after a couple of years that it has automated the wrong end, and then the project has to be started again with the system that issues the invoices, not the one that receives them.

The practical check here is simple: ask in what format the system can put data out and take data in. If the answer is “it can export CSV”, that is already structured data, only incompletely automated. If the answer is “it can print” or “it can save a PDF”, then a picture is the only output, and the work beyond that either needs an API or will remain guessing.

It is also worth knowing that the answer is often better than the company thinks, because many accounting and warehouse programs do have an application programming interface, only nobody has ever asked for it, because day-to-day work gets by with an export. One question to the supplier about whether the system has an API and what can be done with it often decides whether the project is worth starting at all.

The third question: does the step decide something about a person

Most automation is the moving of numbers between systems, and no particular legal question arises there. There is, however, one group of steps that has to be recognised separately: the steps that decide something about a particular person — whether to hire them, whether to grant credit, whether to dismiss them, whether to award a benefit.

Articles 22A to 22D of the UK GDPR cover automated individual decision-making, including profiling: a significant decision based solely on automated processing, meaning there is no meaningful human involvement in taking it. Where that kind of decision is made, the person must be told, must be able to make representations and contest it, and must be able to obtain human intervention. The Information Commissioner’s guidance adds an important nuance: human involvement has to be meaningful, and a formal approve button that someone presses without looking at the substance does not take the process out of those articles.

That is not a ban on automating, but an instruction about what exactly in such a process is automatable: you can automate the preparatory work (gathering data, checking it, preparing a recommendation), but the decision itself stays with the person who actually takes it. In practice that changes the scope of the project, so it is worth noticing before development, not after.

Beside that it is worth knowing one date that has not yet arrived, but which affects long-term plans: the Information Commissioner now has a statutory duty to prepare a code of practice on artificial intelligence and automated decision-making, and that code is not expected to take effect until 2027. That means the choice is freer today, but a system you are building for the long term needs that year in the plan.

The fourth question: does the process already have an external deadline

For some processes the deadline is set not by the company’s priorities but by an external duty, and those automatically move to the top of the list, because the question is no longer whether to do them, but only when and how. In the United Kingdom the clearest example is again invoices, and there are three different things people tend to mix up.

First, a supplier who invoices a contracting authority can already send a structured electronic invoice in BS EN 16931-1:2017 form, and the authority must accept and process it — that duty has been in force since 2019 for central bodies and since 2020 for the rest, and it is now an implied term of every public contract. Second, Making Tax Digital for VAT is already required, and it is about digital records and digital returns, not about sending a structured invoice, invoice by invoice, to the customer or to HMRC. Third, the duty to issue VAT invoices as e-invoices to another VAT-registered business is announced from 2029, and until the government publishes the roadmap the format itself is not settled; in the meantime a PDF the customer has agreed to receive remains a valid VAT invoice, and is still not an e-invoice.

It is this third date that is most often wrong in public circulation, and the reason is simple: the consultation ran in 2025, the announcement came at Budget 2025, and some secondary articles treat a consultation as a duty that has already begun. For a company planning a budget, the difference between a duty that is in force and a duty announced for 2029 is large, so the date is worth checking at the source, not in a retelling.

There are external deadlines elsewhere as well: working time has to be recorded, accounting documents have retention periods, and contracts often carry reporting dates. What they have in common is that these deadlines are not negotiable, and a process that has one gives a clear justification for the work — unlike a process that is automated because it seems modern.

What a process worth taking first looks like

If you put all four questions together, you get a fairly concrete portrait that you can hold up against any list: the most valuable first candidate is a chain with a clear outcome, in which the data already exists in structured form or can become so, in which no step decides anything about a person, and which has an external deadline or at least a measurable volume.

In practice that usually looks like this: an order from the shop arrives in the accounting system without retyping; an approval chain in which the request goes to the right person and comes back with a mark; a data synchronisation between the warehouse and the website, where a person currently exports a file twice a day. All three have one feature in common — between two systems today a person walks with a file.

That is the feature that is easiest to notice and hardest to forget, so it is worth starting the inventory with it. Write down where in your company someone exports, pastes or retypes, how often and for how long. This list is usually shorter than expected, and on it there is almost always one entry that stands out.

A second feature that singles a candidate out is the cost of an error, and calculations usually leave it out: if a retyping error in this chain means a wrong invoice to a customer, a wrong stock figure in the warehouse or a missed deadline, then the gain from automation is not only the hours saved, but also the errors prevented, and that is usually the larger of the two numbers. A process in which an error is invisible and harmless is, in this respect, a less valuable candidate, even if it takes just as much time.

The third feature is how the volume changes with the company, and it is the most important of the three: work that grows with the company, because more orders mean more retyping, becomes more expensive over time, and that is where automation pays twice: it frees time today and removes a cost that would otherwise grow. Work whose volume stays the same regardless of turnover does not give this second gain.

One more thing is worth adding to the portrait about sequence, because companies get this wrong more often than they get the choice of tool wrong: the first process to automate should not be chosen as the largest or the most painful, but as the one that is best understood and fastest to finish, because the first project teaches the company how projects of this kind actually happen — how to describe exceptions, how to test and how to handle errors. That lesson is much cheaper to take on simple work than on work the cash flow depends on.

What a process not worth taking first looks like

It is just as useful to recognise a good candidate as to recognise the one that looks attractive but pays back poorly, and there are four such cases. The first is work that happens rarely (once a quarter or once a year), because the development cost stays the same, but the saving is divided by four or by one.

The second is a process whose way of working is still changing, and that is the case in which haste costs the most: if that way of working has been revised three times in the last six months, the automation will lock in the version that will change anyway, and maintenance will eat the gain. Here the right sequence is to agree how it should work first and only then automate it, even though in practice the opposite often happens.

The third is work in which every case is an exception, and there the boundary sits in the nature of the task itself, because automation handles the frequent and the predictable well, but handles poorly a situation in which ten cases have ten different paths; there a person’s judgement is the work itself, and replacing it with a tree of rules usually creates more exceptions than it removes.

These three cases share one feature: in them automation locks in something that is not yet ready to be locked in. Rare work has not been practised enough to be worth capturing; a changing process is still looking for its shape; exception-work is, by its nature, judgement. In all three the right action is to wait or to tidy first, not to automate sooner.

The fourth is the case in which the screen is being imitated because the system has no interface. That is sometimes the only possible path, but it is also the most fragile: a change on the screen is enough, and the work stops. If the system has an API, or one can be requested, that is almost always a better choice than imitating the screen.

What happens to the people whose work is automated

Automation proposals usually step around this question, even though in the company it is asked on the first day, and left unanswered it becomes a quiet resistance that can stop the project more reliably than any technical problem. The honest answer in most small and medium-sized companies is that automation frees time, not a person: retyping is the part of the work nobody wants, and its disappearance usually means that the same person can finally do what there was not enough time for before.

From that follows a practical recommendation that sounds soft, but is a pure project-management question: the person who does the work today has to be brought into the project as the most knowledgeable source, not informed about the result. They know the exceptions that nobody has written down, and it is the exceptions that break automation. A project in which this conversation happens at the start costs less than one in which it happens after the first error.

It is also honest to say the other side, because the opposite would be pretending: if in the company someone’s work consists entirely of moving data between two systems, then automation really does replace that work, and that is a conversation about a change of role, which the company’s management leads, not the supplier. A proposal that does not ask this question at all is not being delicate — it is simply not thought through to the end.

How to calculate your own number

The calculation that the decision needs fits on one page and requires neither a consultant nor a study. Four figures are needed: how many times a week this work happens, how many minutes it takes each time, what an hour costs for the person who does it, and how often an error arises in it that someone then has to correct.

The first three give the direct time cost per year, and this figure is usually smaller than expected — that is exactly why a project often fails if it is justified by that alone. The fourth figure is the one that mostly decides, because the cost of an error is rarely only the time spent correcting it: a wrong invoice means correspondence with the customer, a wrong stock figure means either goods that stay unsold or an order for goods that are no longer in the warehouse, and a missed deadline sometimes means a penalty.

Against these figures you set the development cost and the maintenance, and it is the maintenance that is forgotten. An automation that connects two systems is alive only for as long as both APIs are alive, so the plan has to have room for changes that someone else will demand. If the calculation pays back only when the maintenance cost is left out, then it does not actually pay back at all.

One more thing worth establishing before the conversation is how often the systems change. A cloud service that updates itself can change an API without warning, whereas software installed on your own premises stays unchanged for years, but its upgrade will at some point require everything to be checked again from scratch. Neither variant is worse, but they need a different maintenance plan, and a quote that does not reflect that will be too cheap in exactly the place where the costs will later appear.

Why you should not trust percentages from studies

In automation proposals a figure almost always appears: that half the work can be automated, that projects fail in a third of cases, that someone saved tens of thousands of hours. These figures exist and can be quoted, but they almost never describe the company they are being shown to, and that is exactly what makes them a poor basis for a decision.

The widely cited indicator that a large share of activities can be automated is a calculation about activities in the wage bill of a particular country in a particular year, with that year’s technologies, and it was published by a consultancy that sells this same service. The indicator about project failures comes from a consultant’s experience with clients who called them in after the first failures, so the sample is distorted by definition. The figure about hours saved describes a particular accounts department of forty people in another country several years ago.

From that it does not follow that automation does not pay, but that the right number is your own: how many times a week this work happens, how long it takes and what an hour costs. You can make this calculation on one page, it describes your company specifically, and it is the only one on which it is worth taking a decision.

What you need to know about the systems before you ask for a quote

Once the candidate is chosen, the next step is not asking for a quote, but five minutes of research into the systems themselves, because that is what decides whether the conversation with the contractor will be about a solution or about whether it is possible at all. Find out whether each system involved has an application programming interface, whether it is available at your licence level, and whether the supplier charges separately for it, because all three answers tend to differ.

The second question is who stores the data and who is allowed to change it. If two systems hold the same information, for example a customer’s details or a product’s stock figure, then before they are connected you have to decide which of them is the master, because otherwise the automation will start overwriting both of them in both directions and the result will be worse than before. This decision is free if you take it at the start, and expensive if you discover it during testing.

The third is the question of what happens when something fails. In every automation there are cases that do not go through (a field is missing, a system does not respond, the data conflicts), and they need a place to land, and a person who looks at them. Automation without error handling works for as long as everything is fine, and that is never long.

It is also worth deciding in advance how you will judge whether it worked, because without that the project never ends, it simply breaks off. The measure can be quite simple: how many times a month someone still retypes data by hand, how many errors were corrected last month, and how long an enquiry takes from the form to a reply. This figure is worth measuring once before the work starts, so that later there is something to compare with. Companies that do not take this measurement argue after six months about whether anything changed at all.

Finally it is worth remembering that automation is not a one-off piece of work, but something that remains in the company and needs an owner just as any other system does. Once the process is connected, someone has to know where to look if it stops, and someone has to have the authority to halt it if the result looks wrong. In companies where this role is not named, the automation quietly stops working, and it is noticed only after a month, when someone is looking for a missing document.

Where to start in practice

The start is neither the choice of a tool nor the asking for a quote, but one week in which it is written down what happens: which work repeats, how often, for how long, and where in it a person moves data between systems. Then ask each entry the four questions in this article, and most of the list will fall away after the first two.

What usually remains is one or two candidates, and that is good, because that is also how many are worth starting at once: two finished pieces of work give more than six begun. Once the candidate is chosen, the next step is to find out whether the systems involved have APIs, because that decides both the price and how robust the solution will be.

If at this point it is clear which process is yours, but not how to connect it, that can be discussed with us: business process automation as we deliver it is integrations and workflows between the systems you already have. If you first want to understand how the different approaches and groups of tools differ, write to us or send us your list — often the answer is that one connection is enough, not a platform.