The sentence to start from
- things retyped by hand from each invoice
- 4
- for one invoice when nothing is odd
- 6 minutes
“A supplier invoice reaches the inbox. The system reads the fields, checks them against the order, updates the CRM and routes mismatches to a person for approval.”
Those two sentences are a complete description of an automation.
Right now the same job looks like this: someone opens the PDF, finds the order number, the net amount, the VAT and the due date, alt-tabs into the system, types those four things again, opens a second tab to check they match the order, then drags the email into a folder called done. It takes six minutes when nothing is odd, and it happens dozens of times a week.
If you can describe anything in your company that way, you have a candidate and you have a brief. If you cannot yet, the rest of this piece shows how to get there.
How to choose a process to automate: four questions
- counting repeats on paper
- 5 days
- cases a one page instruction should get right
- 8 in 10
Does it repeat? Put a number on it: how many times a week. Count it for five days, on paper. The number almost always turns out different from what everybody assumed, and sometimes it turns out smaller.
Does it have a clear start? Something sets it off: an email lands, a customer submits a form, an order flips to paid, it is eight o’clock on Monday. If you cannot say what starts the job, you are probably describing somebody’s habit, and an automation has nothing to react to.
Can the rules be written down? Try this: could you write a new hire one page of A4 that gets them to the right answer eight times out of ten? Eight will do. The remaining two are where the difficulty lives, and I come back to them below.
Would anybody notice if it stopped? Name the stake: time, volume, the cost of an error, or the customer’s experience. If the process could sit still for a month and nobody would ask, automating it is buying yourself something to do.
Four out of four and the conversation is worth having. Three out of four works too, as long as the missing one is the last and you know why.
When not to automate a process
It happens twice a year. Then even a flawless automation saves two afternoons annually, and somebody has to keep it alive for the twelve months between runs. The second run will fail anyway, because the file format on the other side changed in March.
Every case is different. If “it depends” comes up three times while you describe it, and it depends on something different each time, the repetition is not there.
The real problem is a disagreement between two departments. This one is the most common and the most expensive. Sales thinks finance checks the prices, finance thinks the opposite, and the invoices sit for a week. Software will not settle that. It will only do the badly arranged thing faster, and hand both sides a fresh argument about who configured it wrong.
An aside: calling it an AI project
Companies come to me saying they want to implement AI, then describe a process where a model is of no use whatsoever. If the rule is “when the subject line contains an order number, file the attachment in the client folder and notify the account manager”, that is a rule, and it costs what a rule costs. Calling it an AI project changes three things at once: the budget, who from your side attends the meeting, and what eventually gets built.
A model is worth paying for where the data is unstructured or something has to be judged: reading an amount off an invoice in a layout nobody has seen before, summarising a ticket, deciding whether an email is a complaint or a request for a quote. The rest of your flow is usually conditions and connections between tools you already pay for. Better to know that before the conversation than after the quote.
What to write down before asking for a quote
Describe the process under four headings before anyone says a word about technology.
- Data. What comes in, and in what shape. PDFs from five suppliers, one of whom prints and scans, so it arrives as an image. How much of it per week, and whether the number spikes at month end.
- Tools. Where it goes, by name. Whether that system has an API or whether somebody clicks through it in a browser. Who has the password.
- Decisions. Every moment a person judges something. “I check whether it matches” is a decision even though it does not sound like one, and it is usually the important one.
- Exceptions. Everything that breaks the three points above.
The best description comes from sitting at the desk of the person who does the work, ideally with the screen recording through one full run while they talk. A description from the person doing the job is worth many times one from their manager, because the manager will describe the version in the procedure, which tends to hold on handover day and fall apart in week two.
The exceptions are the work
Building the main path takes an afternoon: the invoice lands, the fields get read, the numbers match, the CRM updates. It makes a lovely demo and accounts for a small share of the work.
An invoice with no order number. A supplier who redesigned the document, so the net amount now sits where the VAT used to be. An amount that differs by two zloty because somebody rounded the other way. The same invoice arriving a second time, this time with “reminder” in the subject. A credit note against a document from last month. An invoice in euro and the question of which day’s exchange rate. An order fulfilled in part. A supplier not in the database yet. An attachment that is a zip with eight files in it. An attachment that is a phone photo, taken at an angle, with a thumb in the corner.
Each of those needs one of three answers, and you have to pick: the system handles it by rule, stops and asks a person, or sets it aside and does nothing. The third answer is fine on one condition: a named person can see that queue and has been told how often to work through it. Without that, cases pile up in a folder nobody opens.
Four more catch out even people with ten years of running operations behind them.
The same email twice. A connection drops, a step runs again. If that step is “create a record”, the retry creates a duplicate, and a duplicate in the accounts is worse than a missing entry, because somebody notices a missing entry. You need a key by which a case recognises itself: invoice number plus supplier tax number. I check it before the write. The check itself is five lines; deciding what the key is takes half a day with your team, because it will turn out two suppliers number their invoices identically.
Failure halfway through. Step three of five succeeded, step four fell over. The CRM is updated, the payment is not prepared, and the email to the supplier already went out. You settle this in advance and the answer is boring: irreversible steps, meaning sending a message, releasing a payment, issuing a document, go last, and everything before them has to be safe to repeat.
Silent failure. A model that reads an amount and is forty percent sure writes the number down exactly the way it does when it is ninety-nine percent sure. With no confidence threshold, and no escalation below the threshold, you get errors that surface months later, usually during an audit.
Change on the other side. Nobody will tell you a supplier has moved to new invoicing software. You will find out because the share of cases going to a human jumped from five percent to thirty. An alert on that single number is the cheapest thing you can build here, and it warns you earlier than your accountant will.
The exceptions conversation is dull and everyone wants to cut it short. Give it the time: it is the part of the project where you decide how your company operates, and probably the first time in years anyone has written that down.
A person stays on anything with a consequence
Payments, messages to customers, price changes, deletions, anything you cannot undo with one click: a person approves it. Software makes mistakes less often than people do, but in runs. A person misfiles one invoice; a badly written rule misfiles four hundred before anyone looks.
Approval has to be cheap. One screen, document on the left, order data on the right, differences highlighted, two buttons. If approving takes as long as doing the job by hand, the whole saving disappears.
Before launch, plan how many cases will reach approval. The queue has to stay short enough that somebody reads it: at two hundred items a day, anyone starts clicking approve without looking within a fortnight. That leaves you the worst arrangement available: unsupervised software plus a human who is formally responsible for it. When the queue grows, tighten the rules so fewer cases reach it.
Test on what already happened
Take a hundred cases from last quarter, ideally from the folder marked “to sort out”. Run them through the finished flow and compare the result with what the person did at the time.
The differences come in two kinds: the automation got it wrong, or the human did. The second kind shows up more often than anybody likes to admit, and on its own it repays the exercise.
On new cases you have nothing to compare against. You find out something is broken at the same moment your supplier does.
Decide the quality measure before you build. Two numbers will do: how many cases went through without a person, and how many went through wrong. The second matters more. A flow that handles ninety percent by itself and gets two of them wrong is worse than one that handles sixty and gets none wrong.
The first one should be boring
Keep the first flow to five parts: what comes in, the context it needs, one action, a person at the decision and a quality measure. Extend it only once that base works on real traffic.
Boring means that if it falls over on Tuesday afternoon, nobody loses a customer, and somebody does the job by hand for two days the way they used to.
For small jobs n8n, Zapier and Make are enough, and moving a form into a CRM needs no code. Code arrives when the job outgrows those tools: when the logic stops fitting into conditions, when the volume gets serious, or when the data is not allowed to leave your own infrastructure.
If your first automation needs six integrations, a model trained on your data and board approval, put it down. Start with something you could switch off on Friday without anyone noticing until Monday.
What the first month after an automation goes live is like
The savings take a few weeks to arrive. For the first fortnight far more cases reach a human than you expected, because the rules are deliberately cautious and reality is richer than any description of it. Then that share falls, as you add rules for the exceptions that turn out to repeat. After a month you know more about that process than you learned in the previous three years, which is a side effect nobody plans for and usually the most valuable thing in the box.
Your processes will keep changing, and the automation will not follow them on its own. Somebody has to keep it on the list of things they review, the way somebody keeps the hosting contract on that list.
Where you go from here depends on how far you got with your own process.
You have your own two sentences. Send them through the brief or the contact page, and list every exception you already know about.
You cannot write them yet, which is useful to know too. Write anyway. Choosing which process deserves the first attempt is the cheaper part of the job and the one that shapes everything after it. There is more about how that check runs in the piece on when AI has no business being in your company. What I automate, and what it is built with, is on the process automation page.
Frequently asked questions
How do I choose a process for a first automation?
Four questions. Does it repeat, counted on paper over five days. Does it have a clear start, something that sets it off. Can the rules be written down, tested by whether a one page instruction gets a new person to do it correctly eight times out of ten. And would anybody notice if it stopped. Four out of four and the conversation is worth having.
When should a process be left alone?
When it happens twice a year, so a flawless automation saves two afternoons and somebody maintains it for the twelve months in between. When every case is different and the description keeps returning to “it depends”. And when the real problem is a disagreement between two departments: an automation will not settle it, it will only do the badly arranged thing faster.
What should I write down before asking for a quote?
Four categories. Data: what comes in, in what form, and how much of it there is per week. Tools: where it goes, named, and whether the system has an API. Decisions: every moment a person judges something. Exceptions: everything that breaks the other three. The best description is written at the desk of the person who does the work, with their screen in front of you.
Is a first automation an AI project?
Usually not. A model is useful where the data is unstructured or something has to be judged. The rest of the flow is conditions and connections between tools you already pay for. Calling it an AI implementation changes three things at once: the budget, who sits in the meeting, and what gets built in the end.
