The short answer: the fastest way to write a procedure with AI is not to ask it to write one. Have the person who does the job talk it through, give that transcript to the tool along with a fixed structure to fill, then have someone who has never done the job follow the draft. The tool removes the blank page, which was the part stopping it from happening.
Ask any owner which job would stop if one person were away for a fortnight and they'll answer immediately. Ask whether it's written down and the answer is usually a document from three years ago that describes a version of the job nobody does anymore.
Why procedures don't get written
It isn't laziness, and it isn't that people can't write. Four things get in the way, and they're the same in a bookkeeping practice, a property management office and a trades business.
- The person who knows is the busiest person. That's why they know.
- It feels like a project. A procedure competes with today's work and loses every time.
- First attempts are the wrong length. Either three lines nobody could follow, or six pages nobody will read.
- The important part is invisible to the person doing it. "You just check the dates line up" is a step only if you already know which dates, and why.
AI is useful against all four, but only if you use it to capture and structure, not to invent.
Four steps from someone's head to a document
1. Capture it by talking, not writing
Have the person record themselves explaining the job while they do it, or talk it through for fifteen minutes with someone asking "and then what?". Talking is faster than writing for almost everyone, and it surfaces the asides — "except at end of month" — that never make it into a typed draft. A phone voice memo is enough; the route from voice note to finished draft is covered in voice note to finished draft.
One caution. If the job involves client files or personal information, describe the steps without reading out the records. Your never list applies to a transcript exactly as it applies to a pasted document.
2. Give the tool a structure, not a request
"Write an SOP for this" produces a generic one. Instead, give it the transcript and the headings you want filled: what the job is for; when it runs; who does it; what you need before you start; the steps, one action each; what "done" looks like; the two or three things that usually go wrong and what to do about them; and who to ask.
Then add two instructions. Keep the speaker's own words for any judgement call. And where something is unclear or missing, write [ASK] rather than filling it in. Finally, ask it to list the questions it would need answered to make the procedure complete. That list is where the invisible knowledge is hiding — take it back to the person who does the job.
3. Test it on someone who has never done the job
This is the step that makes the document real, and the one most often skipped. Hand the draft to someone who has never done the task and watch them follow it. Every point where they stop, guess or ask is a missing step. Feed the corrections back in and regenerate. Two rounds is usually enough.
4. Give it an owner and a review date
A named person keeps it current, and the document carries the date it was last checked. Store it where people already look when they're stuck, not in a folder created for the purpose.
A procedure is ready when
- Someone new could complete the job without asking anyone
- Each step is a single action
- "Done" is described, so finishing is obvious
- The common problems have written answers
- It has a named owner and a review date
Make the second one take half the time
Once the structure works for one procedure, save it as a reusable setup: the headings, the two instructions, and the finished procedure as an example of the standard you want. The next person pastes in their transcript and gets a draft in your house format, not the tool's. In Claude that's a Project; in ChatGPT it's a custom setup. The reasoning behind setups rather than saved prompts is in the team that saves nothing relearns everything, and the module is building reusable setups.
As for which tool: long transcripts and a consistent house voice suit one, quick voice capture on a phone suits the other, and either will do the job. The rule of thumb explains how to choose.
If you'd rather build the first procedure with someone than from an article, a done-with-you workflow build does exactly this, on your own job.
See the workflow buildWhich job to start with
Pick the one that stops when someone is away, runs at least monthly, and is mostly steps rather than judgement. Some that come up in almost every industry:
- Month-end routines in an accounting or bookkeeping practice
- Vacate and routine-inspection processes in property management
- Site induction and job-close-out in trades and field services
- New-client onboarding, in any business that has more than one person doing it differently
If you're torn between several, how to pick the one job to fix first applies just as well to documentation.
What stays out of the procedure
A procedure can say "refer to the principal" or "the licensed person signs off here". It shouldn't try to encode the decision itself where that decision belongs to a qualified person — a tax position, a clinical judgement, a safety sign-off. And once the draft exists, it gets checked like anything else that came out of a tool; the five-minute check covers how.
