How to Tell If a Process Is Ready to Automate With AI

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for How to Tell If a Process Is Ready to Automate With AI.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for How to Tell If a Process Is Ready to Automate With AI.

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.

Follow me on Instagram@sagnikteaches

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:

Connect on LinkedInSagnik Bhattacharya
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):

Subscribe on YouTube@codingliquids
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.

Criterion012
1. Steps written downOnly in someone's headRough notes existWritten, current and followed
2. How often it runsMonthly or lessWeeklyDaily or many times a week
3. How inputs arriveAny way: calls, texts, emails, in personMostly one channelOne form or one structured source
4. Definition of done"It depends"Mostly clear, some debateAnyone could check it
5. ExceptionsMore than 1 case in 3 is unusualBetween 1 in 10 and 1 in 3Fewer than 1 in 10
6. Cost of a mistakeHarms a customer, money or a legal duty, and is hard to spotAnnoying, caught within a dayTrivial, spotted straight away
7. Access to the dataPaper, or locked in a system with no exportExports or copying by handThe apps connect directly
8. OwnerNobodyShared or unclearA 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:

CriterionBeforeWhat was going onAfter fixes
Steps written down1A note on the office wall, out of date2
How often it runs2Several times a day2
How inputs arrive0Five channels, some via instructors' personal phones2
Definition of done1Fees were charged inconsistently2
Exceptions0Illness, test days, instructor goodwill, weather1
Cost of a mistake1A wrong fee upsets a pupil, but gets queried quickly1
Access to the data1Booking system exports, no direct link1
Owner1"The office", and sometimes instructors2
Total7Not ready13

The fixes took about three weeks and involved no AI at all:

  1. One channel. Every booking confirmation now includes a link to a short cancellation form. Instructors reply to any cancellation text with the same link.
  2. 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.
  3. 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:

ProcessTypical scoreUsually held back bySensible first move
Chasing unpaid invoices12 to 14Exceptions: disputes and agreed payment plansAutomate reminders from your accounting software; a person handles disputes
Replying to new enquiries8 to 11Inputs arrive on many channels; "done" is loosely definedOne enquiry form and a set of approved answers; AI drafts, a person sends
Weekly social posts10 to 12Definition of done is a matter of tasteAI drafts a week at a time; posts are scheduled only after approval
Onboarding a new client6 to 10Steps aren't written down; ownership is unclearWrite 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

Want a process scored before you automate it?

On a 1:1 call we'll walk through the process you're thinking of automating, score it together, and agree what needs fixing first and which steps AI should handle.

Book a 1:1 call with me