In this article
Most companies that ask us about automation have a long list of processes they would like to improve and no clear idea which one to start with. The first choice carries more weight than it seems. A good first project pays for itself within months and makes the case for the next one. A bad first project, usually an ambitious attempt to automate the most complex workflow in the company, stalls and sets automation back a year. These are the workflows we recommend starting with, and the ones to leave for later.
What makes a process worth automating first
The best early candidates share four properties. The process is frequent, so savings accumulate. It follows rules that someone can write down, even if there are exceptions. The inputs already exist in digital form, or can easily be made digital. And the people who do the work today are frustrated by it, which means they will help you design the replacement rather than resist it.
Processes that fail these tests, such as rare, judgement-heavy work that depends on paper and tacit knowledge, are not impossible to automate. They are simply bad first projects.
Five workflows that usually qualify
1. Document intake and data entry
Invoices, delivery notes, applications, forms and contracts arrive as PDFs, scans and photos, and someone retypes the contents into a system. This is the highest-return starting point we know. OCR combined with a language model and strict validation extracts the fields, routes confident results straight through, and sends uncertain ones to a person. We describe the architecture in our article on document pipelines. The staff who used to type now review exceptions, and the backlog disappears.
2. Approval chains
Purchase requests, leave requests, expense claims and discount approvals travel by email, get lost, and are chased by hand. A workflow engine with defined steps, deadlines, escalation and a full record of who approved what removes the chasing and gives managers a queue instead of an inbox. The rules are usually already written in a policy document, which makes this a well-defined project.
3. Reporting that is assembled by hand
Someone spends the first two days of every month pulling numbers from four systems into a spreadsheet. The automated version connects to those systems, applies the same calculations, and produces the report on schedule, with the person now checking it rather than building it. This project also exposes data quality problems that were previously hidden inside the spreadsheet.
4. Customer and supplier communications
Order confirmations, status updates, reminders, renewal notices and routine answers to common questions follow templates that depend on data the business already holds. Automating these improves response time and consistency, and frees the people who sent them for the conversations that need a person. For inbound questions, an assistant grounded in your own documents can answer a large share without inventing anything, provided it is built with the safeguards we describe in our article on retrieval systems.
5. Onboarding and offboarding
A new employee, customer or supplier triggers a checklist across several systems: accounts, permissions, equipment, documents, introductions. The same list runs in reverse when they leave, and missed steps on the way out are a security problem. Automating the checklist, with the right people notified at the right moment, is a contained project with a visible result.
Workflows to leave for later
Core transaction processing in a legacy system is usually better handled by modernising the system than by automating around it. Processes with no agreed rules, where every case is negotiated, need a process design exercise before they need software. And anything that requires replacing a system people depend on daily should wait until the team has a few smaller wins behind it.
How we run an automation project
We begin with a short discovery that maps the process as it is really performed, which is often different from the documented version. We then agree on what the automated version will handle on its own and what it will hand to a person, because the handover rules determine both the risk and the design. The first release handles the common cases and routes everything else to people. Later releases widen the automated share as confidence grows. Every release reports how much work it has taken on, so the return is measured rather than assumed.
Our business process automation and AI automation pages describe the work in more detail. If you have a process in mind, tell us how it runs today and we will tell you whether it is a good first project.