How to Document Your Processes Before Adding AI

Pick one process, watch it done three times, and write down its trigger, each step, the inputs and where they live, every decision with the rule behind it, the exceptions, and the finished output with real examples. AI can only follow what's written, and the unwritten judgement calls are exactly where it goes wrong.

Expect two to four hours per process for a first version, most of it spent watching and asking "why did you do that?" The result is one document that does three jobs: a brief for whoever sets up the AI, a test set to check the AI against, and a training sheet for your next new starter. If you need to see the whole flow as a diagram first, mapping a business process before you automate it covers that; this tutorial is about the written detail an AI needs.

Follow me on Instagram@sagnikteaches

Pick one process and draw its edges

Start with a process that happens at least 20 times a month, arrives as text or data (emails, forms, notes) rather than as a conversation in a van, and has one person who does it most of the time. Frequent processes repay the effort; rare ones rarely do.

Connect on LinkedInSagnik Bhattacharya

Then write two sentences before anything else: where it starts and where it ends. "Starts when a service request arrives by phone, email or web form. Ends when the job is in the calendar and the customer has a confirmation." Anything outside those edges, such as invoicing after the visit, is a different process and gets its own document later. Without edges, process documents sprawl into a description of the whole business and nobody finishes them.

Subscribe on YouTube@codingliquids

Capture it as it's actually done

Ask someone to describe their process and you'll get the tidy version: the one they'd teach, not the one they do. You want the real one, including the sticky note on the monitor and the spreadsheet only they open. Three capture methods work well, and most processes need two of them.

1. Sit beside them for three real instances (about an hour). Don't interrupt the first time. On the second and third, ask "why?" at every point where they paused, checked something, or chose between options. The pauses are the decisions.
2. Record the screen steps. Click-capture tools such as Scribe or Tango turn clicks in a web browser into a step-by-step guide with screenshots, and both have free plans with limits (Scribe's free plan covers browser apps only). They're good at "which button in which system" and useless at "why this customer got a callback first", so pair them with method one or three. There's more on this route in creating SOPs from screen recordings with AI.
3. Record a talk-through (30 minutes). Have the person talk through two recent real cases aloud while you record, using a phone voice memo or meeting transcription (Google Meet includes transcripts from Business Standard upwards; Teams has its own). Paste the transcript into an AI assistant and ask it to draft numbered steps and list every decision it heard. Then correct the draft together. This is the fastest route from someone's head to paper, and writing SOPs with AI from rough notes has prompts for the drafting stage.

Here's method three on a small scale. A receptionist at an illustrative two-vet practice talks through repeat-medication requests, and this is a slice of the transcript:

"...so I look the pet up, and if the vet hasn't seen it in six
months I can't just do it, it goes in the vet's tray for a check-up
call. Unless it's the flea and worming stuff, that's fine whenever.
Oh, and the diabetic cats, anything insulin, that's always the vet,
even if they were in last week..."

Pasted in with "Draft numbered steps and list every decision you heard", an illustrative reply:

1. Find the patient record.
2. Check the date of the last examination.
3. If the last exam was over 12 months ago, refer to the vet.
4. Otherwise, prepare the medication for collection.
Decisions: whether an examination is needed.

Tidy, and wrong in three places. The threshold is six months, not twelve; the draft slipped in a common figure instead of the one said aloud. The flea-and-worming exemption has vanished. And the insulin rule, the one that matters most clinically, isn't there at all. This is why the draft gets corrected together with the person who spoke: they spot the missing rule in seconds, while you'd only find it when the AI approved an insulin repeat.

The seven things an AI needs written down

A standard operating procedure written for people can skip things, because people fill gaps from experience. Writing for AI means filling those gaps on paper. These seven elements cover it; the right-hand column shows each one for an illustrative heating and air-conditioning installer's service-request process.

Turn judgement into rules an AI can follow

This is the step that decides whether AI works on the process at all. Most process notes contain lines like "the coordinator decides how urgent it is." That's accurate and useless: an AI can't be your coordinator. Sit with the coordinator and a pile of past requests and ask what they actually look at. Usually the "judgement" turns out to be four or five rules plus a small number of genuinely hard cases.

The pattern is the same in any business. From an illustrative eight-person print shop's artwork-checking process, three lines as they were first written, and as rules:

The third row is the honest answer to a real judgement call: the AI doesn't decide whether colour "looks off", it finds the files where the question needs asking.

Back to the HVAC installer. Here's how its urgency decision might read once written as rules:

URGENCY RULES  (service requests)
Smell of gas            -> NOT A BOOKING. Script: tell the caller to
                           contact the gas emergency service now.
                           Coordinator phones back afterwards.
No heating or hot water AND (occupant over 75, infant in the home,
  or a stated medical need)      -> SAME DAY. Callback within 30 min.
Commercial cooling failure (server room, cold store)
                                  -> SAME DAY. Flag to service manager.
No heating or hot water, anyone else   -> NEXT WORKING DAY.
System working but noisy, dripping or showing an error code
                                  -> WITHIN 5 WORKING DAYS.
Annual service or maintenance     -> NEXT ROUTINE SLOT.
Anything not covered above        -> HUMAN DECIDES. AI flags it.

That last line matters. You don't have to reduce every call to a rule. Documenting which cases stay with a person, and what signals mark them out, is just as useful: it tells whoever builds the automation exactly where the AI should stop and hand over. If you find the rules are simple and never need interpretation, you may not need AI at all; AI versus rule-based automation helps you tell.

Watch for rules that exist only because of a workaround. "We ring one engineer with his bookings instead of using the job app, because he never checks it" is a staffing issue, not a process rule. Write it down, but flag it for fixing rather than building it into an automation. Automating a broken process explains why those workarounds get expensive once software is copying them.

Collect real examples, including the messy ones

Alongside the written steps, gather 20 past instances of the process with the outcome that was correct: 15 ordinary ones and 5 that caused trouble. Remove names and contact details. For each, record the input as it arrived and what the right output was.

A few rows from the HVAC installer's set show the level of detail worth keeping (illustrative, names removed):

Keep the input exactly as it arrived, typos and all. An example set cleaned up into neat sentences tests the AI on messages your customers never send.

These examples earn their keep three times. Whoever configures the AI can include a few as samples of good output. The full set becomes your test: run the AI on all 20 and compare. And when a rule in your document is ambiguous, the examples usually show which reading is right.

Worked example: an HVAC installer's service-request triage

Take an illustrative twelve-person HVAC installer that fits heat pumps and air conditioning and services boilers. Its office coordinator handles about 60 service requests a week, spending around 11 minutes on each from first reading to confirmation text: roughly 11 hours a week.

Documenting the process took three and a half hours: an hour sitting with the coordinator, a 30-minute talk-through recording, and two hours writing it up and checking it with the service manager. The talk-through surfaced four rules nobody had written down:

• Warranty status is checked in the manufacturer's portal before booking, because warranty jobs go to engineers accredited for that brand.
• Any customer with an invoice more than 60 days overdue goes to the owner before anything is booked.
• Systems installed in the last 12 months jump the queue, because early faults hurt reviews.
• Certain heat pump error codes can be cleared by a remote reset, so those customers get a phone call before a visit.

About one request in eight was an exception, most often a tenant reporting a fault in a system the landlord owns, which needs the landlord's approval before booking. With the rules and exceptions written down, the firm set up an AI assistant to read each incoming request, draft a summary with a suggested urgency and warranty flag, and list any missing information. The coordinator confirms and books. Average handling time fell to around six minutes, and the service manager's morning review now checks the AI's suggested urgency against the rules. The booking itself stayed human, because the engineer-matching rules had too many exceptions to trust to software yet.

A one-process template you can copy

PROCESS:                         OWNER:
LAST CHECKED:                    CHECKED BY:

STARTS WHEN:
ENDS WHEN:
VOLUME: ___ per week/month       TIME EACH: ___ min

INPUTS (what arrives, format, where stored):
-
STEPS (action / system used):
1.
2.
DECISIONS (fork / rule that settles it):
-
EXCEPTIONS (situation / what we do / how often):
-
HUMAN-ONLY DECISIONS (and the signals that mark them):
-
OUTPUT (what done looks like; attach one real example):

CHECKS (who reviews what, and when):

EXAMPLE SET: folder link, 20 cases (15 normal, 5 awkward)
KNOWN WORKAROUNDS TO FIX (not to automate):
-

Filled in for the vet practice's repeat-medication requests from earlier, after the receptionist corrected the AI's draft, the core of it reads (illustrative):

PROCESS: Repeat-medication requests    OWNER: Senior receptionist
LAST CHECKED: 2 Sep                     CHECKED BY: Lead vet
STARTS WHEN: A request arrives by phone, email or the website form
ENDS WHEN: Medication is ready for collection, or the request is in
           the vet's tray with the owner told what happens next
VOLUME: about 90 a month                TIME EACH: 6 min
DECISIONS:
- Last exam within 6 months       -> prepare for collection
- Last exam over 6 months ago     -> vet's tray, book a check-up call
- Flea and worming products       -> prepare, whatever the exam date
EXCEPTIONS:
- Pet not found under owner's name (about 1 in 15) -> search by pet
  name and address, then phone the owner
HUMAN-ONLY DECISIONS:
- Anything containing insulin: always the vet, even after a recent exam
- Controlled drugs: always the vet
KNOWN WORKAROUNDS TO FIX:
- Requests left on the answerphone are written on paper; move to the form

The insulin rule sits under human-only decisions rather than as one more rule for the AI, and that placement is deliberate. It tells whoever builds the automation that the AI must never act on those requests at all, however confident its reading. The answerphone line is the kind of workaround worth fixing first: paper notes can't feed any automation.

How much detail is enough

A fair test: could a capable temp, on their first morning, do the process from your document without phoning anyone? For people, that's the finish line. For AI, add one more requirement: every decision is named, with either a rule or an explicit "a person decides this".

You don't need keystroke-level detail for systems the AI will never touch. If the booking stays human, "book the slot in the job calendar" is enough; the five lines on which button to press, which drop-down to open and which colour the slot turns add nothing the coordinator doesn't know. Compare the step the AI will actually perform: "read the fault description" is too thin, while "read the fault description and note the equipment type, any error code, and any mention of age, infants or medical need" tells it exactly what to pull out. Spend the detail where the AI will act: on how to read the inputs, on the decisions, and on what a correct output looks like. A two-page document with sharp decision rules beats a twelve-page one that describes every screen and leaves the judgement calls vague.

Test the document before any AI sees it

Give the document and five of your example inputs to someone who doesn't do this job, and ask them to produce the outputs using only what's written. Compare their answers with the real outcomes. Every difference points at a missing rule, an unclear step or an exception you didn't record. Fix those, then try five different examples.

Here's what that test turned up for the HVAC installer's document. The firm's bookkeeper, who had never booked a service call, worked through five past requests and got three right. The first miss was a letting agent passing on a tenant's fault report. The document said tenant reports need the landlord's approval, but not whether a letting agent can give it, so she booked a chargeable visit nobody had authorised. The second was a boiler showing an error code on the remote-reset list, but the list applied to one manufacturer's heat pumps only, and the document didn't say so. Both fixes took one line each. Both would have become AI errors if the document had gone straight into an automation.

When a colleague with no background can get four or five out of five right, the document is ready to brief an AI or a developer. At that point it's also worth checking the wider questions in how to tell if a process is ready to automate, such as whether the inputs are consistent enough and whether you've recorded the current time per case to compare against later.

Keep the finished document in your shared drive next to the example set, with the owner's name and a "last checked" date at the top. Review it whenever the process changes, a new system arrives, or the AI starts making a mistake it didn't make before. That last one is often the first sign that the business changed and the document didn't.

Further reads

• Reduce Owner Dependency: Use AI to Capture What Only You Know — Capture the know-how that only the owner carries.
• How to Build a Company Knowledge Base AI Can Answer From — Turn your process documents into something AI can answer from.
• How to Audit Your Workflows for AI Opportunities Yourself — Choose which process to document first.
• How to Brief a Developer on a Custom AI Workflow You Need — Hand your documentation to a developer as a clear brief.
• How to Set Up Human Review for AI Work Without Slowing Down — Design the checks that sit on top of the documented process.
• How to Set a Baseline Before You Introduce AI — Which numbers to capture before AI arrives, where most of them already live, how to time invisible work, and a baseline sheet that lasts.
• Go Paperless Before You Add AI: A Step-by-Step Plan — Which paper to kill, which to scan and which to leave in the cabinet, so AI tools have clean files to work from. Six steps, about eight weeks.
• AI Use Cases by Department for Small Businesses (With Examples) — 21 practical AI use cases across seven departments, each shown in a small insurance brokerage, with how to start and what to watch.
• What AI Implementation Actually Involves for a Small Business — The six pieces of work behind a small-business AI implementation, with rough hours for each and one workflow followed from baseline to handover.
• How to Stop Retyping Data Between Apps With AI Automation — Find every place your team copies data by hand, match each to the cheapest fix, and use AI extraction only where the source is an email, PDF or free text.
• How Much Does a Fractional Operations Manager Cost? — What published rate guides say fractional COOs charge, how a part-time operations manager or project compares, and a yoga studio's three priced scenarios.
• Signs Your Business Isn't Ready for AI Yet and What to Fix First — Eleven signs a business isn't ready for AI yet, how each shows up day to day, and the cheap fix to make before paying for any tool or project.
• Can AI Sort and File Incoming Documents for Your Business? — When AI can sort and file your incoming paperwork, what it costs in the software you run, and the review pile that stops misfiles.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Scribe and Tango product and pricing pages (free-plan capture features); Google Meet Help, Use Transcripts with Google Meet (supported editions).