A process is ready to automate when its steps are written down, it runs the same way at least weekly, its inputs arrive in a consistent format, you can say what a correct result looks like, and a mistake is cheap and quick to catch. If two or more of those fail, fix the process first or automate one step only.
That's the short version. Below is an eight-point scorecard you can fill in for any process in about an hour, two automatic vetoes that override the score, and a driving school's cancellation process scored, repaired and scored again. The aim is to avoid the most expensive mistake in small-business automation: building something clever on top of a process that only works because one person quietly fixes it every day.
Walk the process once before you score it (about an hour)
Don't score from memory. Sit with the person who does the work and follow three or four real cases from start to finish. For each one, write down every step, where the information came from, how long it took, and any point where they had to make a judgement or ask someone. A simple capture sheet keeps it consistent:
PROCESS: _______________________ OBSERVED BY: ________ DATE: ______
Case | Arrived via | Steps taken (in order) | Minutes | Judgement calls | Odd?
-----|-------------|------------------------|---------|-----------------|-----
1 | | | | |
2 | | | | |
3 | | | | |
How many of these arrive per week? ______
What does "done correctly" look like? ______________________________
Who fixes it when it goes wrong? ___________________________________
Here's what three rows looked like when the office manager at the driving school described below filled it in on a Monday morning (illustrative):
PROCESS: Lesson cancellations OBSERVED BY: Owner DATE: Mon
Case | Arrived via | Steps taken | Min | Judgement calls | Odd?
-----|--------------------|---------------------------------|-----|----------------------------|-----
1 | Text to instructor | Instructor forwards screenshot; | 11 | Pupil says "ill" at 20 hrs | Yes
| | check diary; check notice; | | notice: charge or waive? |
| | ring pupil; update diary | | Asked the owner |
2 | Email to office | Check notice (3 days); update | 4 | None | No
| | diary; reply to confirm | | |
3 | Phone call | Check notice; pupil wants to | 9 | Reschedule counts as | Yes
| | move, not cancel; find slot | | cancel? Nobody sure |
How many of these arrive per week? About 20
What does "done correctly" look like? Diary updated, fee applied or
waived by the rule, freed slot offered to the waiting list
Who fixes it when it goes wrong? Office manager, or whoever notices
Two of three cases had a judgement call, and neither was really a judgement: both were rules nobody had written down. That's a common finding and a cheap one to fix.
Pay most attention to the "judgement calls" column. Every entry there is either a rule nobody has written down or a genuine decision that needs a person. Both matter, in different ways. If you want a fuller method for this stage, mapping a business process before you automate it goes step by step.
The eight-point readiness scorecard
Score each line 0, 1 or 2. Be honest rather than hopeful; a generous score now becomes a broken automation later.
| Criterion | 0 | 1 | 2 |
|---|---|---|---|
| 1. Steps written down | Only in someone's head | Rough notes exist | Written, current and followed |
| 2. How often it runs | Monthly or less | Weekly | Daily or many times a week |
| 3. How inputs arrive | Any way: calls, texts, emails, in person | Mostly one channel | One form or one structured source |
| 4. Definition of done | "It depends" | Mostly clear, some debate | Anyone could check it |
| 5. Exceptions | More than 1 case in 3 is unusual | Between 1 in 10 and 1 in 3 | Fewer than 1 in 10 |
| 6. Cost of a mistake | Harms a customer, money or a legal duty, and is hard to spot | Annoying, caught within a day | Trivial, spotted straight away |
| 7. Access to the data | Paper, or locked in a system with no export | Exports or copying by hand | The apps connect directly |
| 8. Owner | Nobody | Shared or unclear | A named person who'll fix it when it breaks |
Hopeful scoring usually shows up weeks later, in a place nobody was watching. An illustrative hair salon gave "How inputs arrive" a 2 because "everything goes through the booking app", and switched on automatic reminder texts. No-shows went up rather than down. When the owner looked, about a third of bookings were being taken in social media messages and typed into the diary by hand as blocked time, not as app bookings, so those clients never got a reminder. Walking three real cases would have shown it in ten minutes. The honest score was 1, and the fix was a booking link sent in reply to every message.
Reading your score, and the two vetoes
- 13 to 16: ready. Automate end to end, with monitoring so you notice when it fails.
- 9 to 12: partly ready. Automate the steps that scored well and keep a person at a checkpoint, usually before anything reaches a customer or moves money.
- 8 or below: not ready. Fix the process first. Automating it now bakes the mess in and makes it harder to see. Why automating a broken process backfires explains what tends to happen.
Two lines override the total. A 0 on cost of a mistake means stop, whatever else scored well, because a process that can hurt a customer invisibly needs a person in it until you've fixed that. A 0 on owner also means stop. An automation nobody owns keeps running after it breaks, and you find out from an angry customer.
The vetoes earn their place on processes that look ready on paper. Take an illustrative three-physiotherapist clinic scoring its "send the patient their home exercise sheet after each appointment" process. It runs dozens of times a week (2), comes from one clinical system (2), has written steps (2), a clear definition of done (2), few exceptions (2), a named owner (2) and a system export (1). That's 13 before the last line. But cost of a mistake scored 0: an exercise sheet for a post-surgery shoulder sent to the wrong patient could injure someone, and nobody would know until they did. The clinic kept the physio clicking "send" on each sheet, and automated only the step of assembling the draft email from the sheet they'd already chosen.
The middle band is where most processes land, and it's easy to misread as "nearly ready, so automate it all". An illustrative two-van carpet-cleaning business scored its "send a quote after a site visit" process at 11: written steps (2), several a day (2), a named owner (2), and 1 on everything else, because the technician's notes arrive as a mix of app fields and photos, and prices for stained or delicate carpets still involve judgement. So it automated the draft, not the send. AI turns the technician's notes into a formatted quote with the standard prices filled in and any "stain", "wool" or "pet" mention flagged; the owner checks the flagged lines and the total, then presses send. The checkpoint sits exactly where the 1s were.
Frequency deserves a note too. A score of 0 there doesn't mean "never automate", only that the payback is slow. Whether it's worth automating a task you only do once a week has the arithmetic.
A driving school's lesson cancellations, scored twice
Picture a driving school, illustratively, with seven instructors and one office manager. Pupils cancel lessons in every way imaginable: a text to their instructor, a call to the office, an email, a message on social media. The office manager checks whether the cancellation falls inside the 48-hour notice window, decides whether to charge, updates the diary, and rings round pupils who wanted an earlier slot.
Observation showed about 20 cancellations a week, averaging 8 minutes each, so roughly 2.7 hours a week, plus the cost of slots that went unfilled. The first score:
| Criterion | Before | What was going on | After fixes |
|---|---|---|---|
| Steps written down | 1 | A note on the office wall, out of date | 2 |
| How often it runs | 2 | Several times a day | 2 |
| How inputs arrive | 0 | Five channels, some via instructors' personal phones | 2 |
| Definition of done | 1 | Fees were charged inconsistently | 2 |
| Exceptions | 0 | Illness, test days, instructor goodwill, weather | 1 |
| Cost of a mistake | 1 | A wrong fee upsets a pupil, but gets queried quickly | 1 |
| Access to the data | 1 | Booking system exports, no direct link | 1 |
| Owner | 1 | "The office", and sometimes instructors | 2 |
| Total | 7 | Not ready | 13 |
The fixes took about three weeks and involved no AI at all:
- One channel. Every booking confirmation now includes a link to a short cancellation form. Instructors reply to any cancellation text with the same link.
- Written fee rules. Under 48 hours' notice is charged. Illness is waived once per course. Instructors can no longer waive fees themselves; they flag it to the office.
- A named owner. The office manager owns the process and the form.
Only then did they automate, and only partly, because exceptions still scored 1. The form feeds an automation that applies the fee rule, suggests the diary change, and has AI draft an offer of the freed slot to pupils on the waiting list who can make that time. The office manager approves each offer before it's sent. Handling time fell to about 3 minutes per cancellation, and far more freed slots were refilled because offers went out within the hour rather than once the day's lessons were over. The sum is modest but real: 20 cancellations at 5 minutes saved each is about 100 minutes a week back for the office manager. The refilled slots are worth more. If just three extra slots a week are rebooked at an illustrative $45 a lesson, that's $135 a week of lessons that would otherwise have been lost. For the pupil-facing side of this problem, see whether AI can cut last-minute driving lesson cancellations.
Which steps need AI, and which just need a rule
Notice where AI appears in that example: reading free text and drafting a message. Everything else was a plain rule. That split is worth making explicit for your own process:
- Use a rule when the step depends on dates, amounts, thresholds or yes/no fields. "Less than 48 hours' notice means a fee" is a rule. An AI model applying it adds cost and a small chance of getting it wrong.
- Use AI when the step depends on reading or writing language: working out that "can't make Thursday, got a temperature" means illness, or drafting a friendly, specific offer to a named pupil.
The AI step in the driving school's version is a short, tightly fenced prompt:
Read this cancellation message from a driving pupil. Reply with
three lines only:
REASON: ILLNESS, TEST, WEATHER, WORK, or OTHER
LESSON DATE: the date they're cancelling, or UNKNOWN
WANTS TO REBOOK: YES, NO or UNCLEAR
Don't guess. If the message doesn't say, use UNKNOWN or UNCLEAR.
On three real-looking messages it returned (illustrative):
"can't make thurs, got a temperature, sorry!!"
REASON: ILLNESS | LESSON DATE: UNKNOWN | WANTS TO REBOOK: UNCLEAR
"Hi, need to cancel Tuesday 3pm as my shift's changed, can we do Weds?"
REASON: WORK | LESSON DATE: Tuesday | WANTS TO REBOOK: YES
"my test got moved to the 18th so don't need Friday now"
REASON: TEST | LESSON DATE: Friday | WANTS TO REBOOK: NO
The first two are right; "UNKNOWN" for "thurs" is correct, because the automation matches it against the pupil's next booked lesson, which is a rule. The third looks right but isn't useful: under the school's fee rule, "TEST" meant a lesson on test day, not a test being rescheduled. The office manager added a fourth reason, TEST_MOVED, and one worked example to the prompt. Catching that kind of mismatch is why the week of real examples from the paper trial below is worth keeping.
Most small-business automations are 80% rules and 20% AI. If yours is the other way round, the process probably isn't clear enough yet. AI versus rule-based automation goes into the choice in more depth.
How other common small-business processes tend to score
To calibrate your own scoring, here's where four everyday processes usually land when small firms score them honestly. These are rough patterns rather than measurements, and your version may differ, but they show which criterion typically holds each one back:
| Process | Typical score | Usually held back by | Sensible first move |
|---|---|---|---|
| Chasing unpaid invoices | 12 to 14 | Exceptions: disputes and agreed payment plans | Automate reminders from your accounting software; a person handles disputes |
| Replying to new enquiries | 8 to 11 | Inputs arrive on many channels; "done" is loosely defined | One enquiry form and a set of approved answers; AI drafts, a person sends |
| Weekly social posts | 10 to 12 | Definition of done is a matter of taste | AI drafts a week at a time; posts are scheduled only after approval |
| Onboarding a new client | 6 to 10 | Steps aren't written down; ownership is unclear | Write the checklist first; automate only the welcome email |
The pattern is consistent: the processes that score well are the ones already run from a single system with clear rules, and the ones that score badly are held back by habits rather than by technology. That's good news, because habits are cheaper to fix than software.
Warning signs the scorecard can miss
- It works because of one person. If the process runs smoothly only when a particular person is in, their knowledge is the process. Get it written down first; documenting your processes before adding AI shows how.
- Exceptions hide in private channels. The office sees the tidy cases. The odd ones are sorted out in instructors' text messages and never reach the log. Ask the people at the edges, not just the office.
- Seasonal peaks. A process that scores well in a quiet month can fall apart at your busiest time. Score it based on the peak, not the average.
- The process is about to change. If you're switching booking software next quarter, wait. Automating the old system means building it twice.
- It only exists because something upstream is broken. If you spend hours correcting booking errors, the fix is the booking form, not an automated correction process.
A one-week paper trial before you build anything
For any process scoring 9 or more, run one final test before building. For a week, the person doing the work follows the future rules exactly, by hand, as if they were the automation. No judgement calls, no shortcuts: just the written steps.
Tally every case where the rules didn't fit. If more than about 1 case in 10 breaks the rules, rewrite them and repeat the week. If the rules hold, you have three things you need for building: a tested rulebook, a realistic exception rate, and a week of examples to test the automation against. The driving school's tally for its paper week read: 22 cancellations, 20 handled by the written rules, 2 that didn't fit. One was a parent cancelling for two siblings on a shared account, which needed a line in the form rather than a new rule. The other surfaced a rule nobody had thought of: what to do when a pupil cancels a lesson booked on the day of their driving test. That rule went into the rulebook before a line of automation was built.
Further reads
- What Should a Small Business Automate First With AI? — Which of your ready processes to automate first.
- How to Pilot AI in Shadow Mode Before Customers See It — Run the automation alongside people before it acts for real.
- How to Calculate the ROI of an AI Automation Before You Build It — Put numbers on the saving before you build.
- How to Add Human Approval Steps to AI Automations — Where to put the checkpoint for a 9-to-12 score.
- How to Stop Zapier and Make Automations Breaking Silently — Monitoring for after it goes live.
- How Driving Schools Use AI to Keep Instructor Diaries Full — The next job after cancellations for a driving school.
- How to Brief a Developer on a Custom AI Workflow You Need — The eight parts of a developer brief for an AI workflow, a copyable requirements template, and a worked example from a dog-grooming salon.
- Example AI Roadmap for a 12-Person Business, Month by Month — A 12-person driving school's first AI year, month by month: five workflows, about $30 a month in new tools, one idea postponed and why.
- Generative AI vs Traditional AI: Which Does Each Task Need? — How generative and traditional AI differ in what they need, cost and get wrong, four questions that sort any task, and a print shop's six tasks sorted.
- Signs Your Business Is Ready to Automate Sales Follow-Ups With AI — A 16-point readiness checklist for automating sales follow-ups, each item with how to verify it, plus a filled-in example and a scoring table.
- Should You Hire an Automation Consultant or Build It Yourself? — A five-question test, what DIY really costs in hours, one build that worked and one that didn't, and the hybrid route most small firms should take.
- How to Add AI Steps to Zapier: Classify, Summarise, and Draft — Click-by-click setup for AI by Zapier, with tested prompts for classifying enquiries, summarising threads and drafting replies, plus the task maths behind each.
- How to Build Your First AI Automation in Make, Step by Step — A beginner's build in seven steps: sort website enquiries with Make AI Toolkit, route them with filters, log them to a sheet and keep credit use under control.
- AI Agent vs Chatbot vs Automation: Which Does Your Business Need? — Rules-based automation, a customer chatbot or an AI agent? A decision table, real costs and a worked clinic example to help you choose.
- AI Readiness Checklist: Score Your Business in 20 Minutes — Fifteen statements, scored 0 to 2 with evidence, tell you whether to pilot AI now, fix a few gaps first or do groundwork before spending anything.
- How to Audit Your Workflows for AI Opportunities Yourself — A six-stage AI opportunity audit you can run yourself in about eight hours: inventory, timing, sorting, scoring, desk tests and a ranked register.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.