Six-question scorecard for choosing which business process to automate first
Automate first the process that runs often, arrives in a predictable shape, follows rules someone can write down, and has a low cost when a result is wrong. For many teams we talk to, that is not the process that annoys them most. It is the boring one with high volume and a clear owner.
The six questions below turn that into a score. Use them on your shortlist before you talk to any vendor, including us. It takes one short session with the person who does the work today.
The scorecard
Score each question from 1 to 3. The maximum is 18.
15 to 18: a good first candidate.
12 to 14: a second project, with a review step.
Below 12: park it.
One rule overrides the total. A score of 1 on question 4 or question 6 rules a process out as a first project, however well it scores elsewhere.
Volume. How often does it happen? 1: a few times a month. 2: a few times a week. 3: every day, many times.
Shape of the input. What arrives? 1: free text, phone calls, handwritten notes. 2: PDFs and emails with a familiar layout. 3: forms, CSV exports or an API.
Rule clarity. Can the person who does it today write the decision on one page? 1: "it depends, I just know". 2: clear rules with a few known exceptions. 3: clear rules, exceptions are rare.
Cost of a wrong result (higher score = safer). If the automation gets one case wrong, what happens? 1: money leaves the company or a customer sees it. 2: an internal record is wrong until someone fixes it. 3: someone catches it at the next step anyway.
System access. Can the target system take the result? 1: no API, no import, only screen entry. 2: a file import or a limited API. 3: a documented API.
An owner. Is there one person who knows the process and will check the results for the first weeks? 1: no. 2: yes, part time. 3: yes, and they want this.
Question 4 is the one teams skip. A process can score high everywhere else and still be a bad first project if one wrong output reaches a customer.
Related Services
Send Us Your Site, Repo or Idea. Our Engineers Reply in Writing.
We reply as soon as we can, usually within a few days, and tell you what we would change first.
What we shipped, what broke and what we would do differently. No news roundups.
A worked example
Here is how four common candidates could score at a 50-person distribution company. This illustrates the method. It is not data from a client, and your scores will differ.
Inbox triage (sort incoming mail to the right person or queue): volume 3, input 2, rules 2, cost of error 3, access 3, owner 2. Total 15. A misrouted email gets forwarded. Low risk, fast feedback.
Supplier invoice entry (read the PDF, fill the accounting record): volume 3, input 2, rules 3, cost of error 2, access 2, owner 3. Total 15. Good, as long as a person approves before anything is paid.
Order entry from emailed purchase orders: volume 3, input 2, rules 2, cost of error 1, access 2, owner 2. Total 12. A wrong quantity ships, so the gate rules it out as a first project. Do it second, with a review step.
Quote drafting: volume 2, input 1, rules 1, cost of error 1, access 2, owner 2. Total 9. Pricing logic lives in someone's head. Write the rules down first and automate later.
Two things stand out. The process with the most pain (quotes) scores lowest. And the two winners both have a cheap way to catch mistakes.
What it costs to run
The build is a one-off. The running cost decides whether the project still makes sense in year two. It has four parts.
Hosting. The workflow engine needs a server. Self-host n8n in the EU or on your own servers, so the data stays where your data protection officer expects it.
AI calls per run. If a step reads a document with a language model, each run is billed by the amount of text the model reads and writes. So the cost is roughly pages per document times documents per month. Put a limit in front of the model call, such as a maximum page count or a token cap per run, so one unusual 80-page PDF cannot eat a month's budget.
Human review time. The cases the automation flags as uncertain go to a person. Budget for that time. It is the price of not letting the uncertain cases through.
Maintenance. APIs change, suppliers change their invoice layout, model providers release new versions. Someone has to notice and adjust. This is the cost that is easiest to leave out of a proposal.
Keep the workflow independent of a single AI provider. If a provider raises prices or changes a model, switching should be a configuration change, not a rebuild.
What breaks once it is live
A failed run is the easy case. In n8n you point each workflow's Error Workflow setting at one workflow that starts with an Error Trigger node, and someone gets a message. The hard cases are runs that look successful.
We learned this on our own systems. In September 2026 we found that one of our internal lead workflows had a data-mapping bug that had produced wrong output for seven days. Every run finished green. Nobody was told, because nothing technically failed. We now route every workflow's failures to one shared alert, and we check outputs, not only errors.
In the same month we found an older alert relay of ours had gone quiet. The receiving endpoint returned an HTTP 404, and the JavaScript fetch() call that sent the alert does not treat a 404 as an error by itself. Every alert vanished without a trace until we found it while working on something else.
A third risk is duplicate runs. In an n8n issue on GitHub, open as of November 2026 (#31837, github.com/n8n-io/n8n/issues/31837), a single request to a webhook trigger produced several executions with the same event ID. For inbox triage that means a duplicate ticket. For invoice entry it means a duplicate booking. Any step that creates money-relevant records should store each event ID in a database table with a unique constraint and skip the run if the ID is already there.
So the check for "is it still working" has three lines, not one:
Did it fail? The error alert answers that.
Did it run at all? A daily check answers that, for example an alert when today's run count falls below half of the usual daily count.
Is the output right? A weekly sample answers that, for example five outputs compared against answers you already know.
How you know the AI got it right
Not from the run log. A green execution only tells you the calls returned.
Before launch, collect a test set from your own real cases, with the correct answer known for each. Score the output field by field, with an exact match required on the fields that matter, such as amount, date and IBAN. Rerun the same set after every model update. Have each AI answer show its source: which page and which line of the invoice the amount came from. And keep a person approving the risky step, such as a payment or a customer-facing message, until the test results give you a reason to relax it.
We described this test in detail in our earlier post, "How to Verify an AI Workflow Read the Invoice Correctly".
Where to start
Pick the two highest scores from your shortlist. Build the one with the cheaper mistakes first. Run it for a month with review on and the three checks above in place. Then decide on the second with real numbers instead of estimates.
If you want a second opinion, send us a short description of the process and we will score it with you against these six questions. Our page explains how we scope a first workflow, including the test set and the approval step.
