The five-point test
- Frequency. Daily or many times a week. A monthly process rarely pays back the build.
- Writability. Two people, separately, can describe the same steps. If they cannot, you do not have a process yet.
- Digital input. The facts already exist in a form, an email, a file or a system. Paper on a desk is a digitisation project first.
- Cheap errors. Someone can tell, quickly, that the output is wrong, and the cost of being wrong is a correction, not a lawsuit.
- An owner. A named person who will handle the queue of exceptions after go-live.
Four out of five is a conversation. Three or fewer is a “not yet”.
Warning signs you would be encoding a mess
- The real rules live in one person’s head and they are going on leave in June.
- Every case is “a bit special”.
- Two systems of record disagree, and staff already keep a third spreadsheet to reconcile them.
- The requested automation is “do what we do now, but faster”, and nobody has timed what they do now.
In those cases the useful first engagement is not a build. It is writing the process down, or a short systems review, so you do not spend money cementing the workaround.
Score three real requests
Invoice posting from a mailbox you already file. Daily, rules exist, PDFs are digital, errors show in the next reconciliation, finance will own exceptions. Automate. Extract if the PDF is messy; otherwise a straight workflow.
“Make sales faster.” Not a process. No frequency, no rules, no owner. Do not automate. Ask what a salesperson actually does between a lead and an order, time it, then pick one step.
Month-end stock reconciliation across three branches. Monthly, so the payback is slow. Rules exist but the three branches do not follow them. Digital input is a maybe. Owner is “accounts”, which means nobody. Fix the rules and the count first. Automate later, if the count is still painful.
What “not yet” work looks like
A half-day workshop, a one-page process, an agreement on the system of record, and a named owner. Sometimes a systems review when two packages already disagree. That is not delay for its own sake. It is the difference between a four-week build and a four-month argument implemented in code.
What to time before you write a line of code
How often the job happens. How long it takes today, including the chase. How often it goes wrong, and what “wrong” costs — a retype, a customer call, a GST notice. If nobody has timed it, you cannot say the build pays back. “It feels slow” is not a business case. Forty minutes a day across two people is.
Write those numbers on the same page as the five-point test. Bring them to the first vendor meeting. A partner who does not ask for them is selling a tool, not a result.
When AI changes the score — and when it does not
If the input is a PDF or an email, you may still pass the test: frequency, writability of the output, digital files, cheap errors, an owner. The model is then a reader in front of the same workflow. It does not relax the owner rule. It does not make a monthly process worth a six-month build.
If the test fails because nobody can write the rules, a model will not discover the rules for you. It will guess, confidently. Fix the process first. See AI versus automation if a vendor is blurring the two.
A conversation that saves a quote
“This happens about forty times a week. Two of us spend twenty minutes each time, including the chase. The input is already a PDF in this mailbox. A wrong extract is a correction, not a legal event. I will own the exception queue. The rule is: match the PO, draft the bill, stop if the totals disagree.” That paragraph is a yes. “Make the office faster” is a no. Send the paragraph, not the slogan.
If you cannot fill those sentences, the useful spend is a half-day to write them, not a build. We would rather lose a project at that point than encode a mess and get blamed for the mess being faster.
When the answer is “not this year”
The only person who knows the rules is leaving. Two systems of record already disagree and nobody will pick one. The job happens monthly and the build would take a quarter. Those are honest “not yet”s. Digitize, write the process, pick a system of record, time the work. Then come back. Automating in that climate makes the brokenness faster and harder to see — and the vendor still gets paid.
A paid systems review is the usual next step when the blocker is two packages that almost agree. A workshop is the next step when the blocker is two people who do not. Neither is delay for sport. Both are cheaper than a workflow nobody will trust.
If the test already passes, do not widen the first path because the workshop felt productive. One trigger, one system of record, three exceptions, a log, an owner. That is workflow automation, not a platform. You can buy the second path when the first one has a number. Until then, “while we are at it” is how a four-week job becomes a quarter.
If the test passes, start narrow — one path, one system of record, a visible audit trail. That is the shape described in workflow automation. The wider picture is business process automation.
Score a night-shift handover
It happens every weekday. The rules exist if two supervisors can write the same checklist. The input is already a job file, or it is still a WhatsApp dump — if the latter, digitise first. A wrong handover is a correction in the morning, not a lawsuit, if you keep a person in the loop. Someone on days must own the exceptions. Five yeses: automate the checklist into the system of record. Three yeses: write the checklist this month and stop calling it automation.
Do not start with “AI that writes the handover from the chat group”. That is a reader in front of a process you have not agreed. Agree the path. Then, if the file is messy, extract. The test still comes first. If two supervisors still cannot write the same checklist after an hour, you have a management job, not a software one. Book that hour. Do not encode the argument. Bring the timed numbers — frequency, minutes, cost of wrong — to that hour as well. A checklist without a payback story is how you automate a ritual nobody will miss when it breaks. Forty minutes a day across two people is a story. “The night shift is messy” is not. Write the minutes before you write the workflow. If nobody will time it, nobody will own it after go-live either.