Writing standard operating procedures with AI

How the bot works

Nine steps. The transcription, the template, the citation trail and the version history are ordinary code and cost almost nothing to run; the model is only used to turn what somebody did and said into numbered steps.

1. It starts from what you can actually show it. A screen recording with somebody talking over it, a walkthrough call, the document that got half written in 2024, the checklist in a spreadsheet, the email where somebody explained it properly once. Whatever exists.

2. It writes into your template, not its own. Your headings, your numbering, your house words — purpose, scope, who does it, what they need, the steps, the exceptions, the revision history. One action per step, in the order it actually happens.

3. Every step names where it came from. The minute of the recording, the line of the old document, the person who said it on the call. A reviewer can check any step against its source without watching the whole thing again.

4. What nobody said becomes a question, not a sentence. What happens when the card is declined. Who gets told if the part is out of stock. Which folder the signed copy goes in. These come back as a list of open questions, and in the first pass that list is the most valuable thing in the document.

5. It writes what it saw, not what is usual. No industry-standard step the recording never contained, no tidy reorganization of the order, no best practice nobody asked for. A model that fills a gap with something plausible writes a procedure that fails the first time a new starter follows it.

6. It keeps a procedure, a policy and a reference article apart. A procedure tells the person doing the job what to do next. A policy says what the rule is. An article answers somebody else's question later. Mixing them is why nobody reads any of the three, so each one is scoped before a word is written.

7. Screens come from the recording, cropped to the step. The actual screen the actual person used, at the moment they used it, with whatever has to be masked masked. Not an illustration of a system, and not a screenshot somebody takes again in six months.

8. The approver follows it rather than reads it. The review step is a run-through: the person who does the job does it once from the draft. Everything they trip over is a comment, every comment is an edit, and the sign-off is recorded against that version. Reading a procedure proves nothing.

9. It keeps them alive after the first week. A new recording after a system changes becomes a diff against the approved version — what moved, what disappeared, what is new — with the owner and the review date tracked. A procedure nobody updates is worse than none, because people follow it.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your template

The headings, the numbering, the front matter, the revision table, the tone — and whether a procedure is one page or twelve.

Your words

What your team calls the thing: the job, the ticket, the file, the system, the customer. A procedure in somebody else's vocabulary gets rewritten by hand.

Your level of detail

Click by click for a new starter, or outcome-level for somebody who has done it before. Both, from the same source, for different readers.

Your roles

Who does each step, who checks it, who is told — named as roles rather than people so the document survives somebody leaving.

Your approvers and review cycle

Who signs a procedure off, how often each one is revisited, what triggers a review out of cycle, and which ones need a second approver.

Your sources

What it may read — recordings, call transcripts, the old document folder, the wiki, the ticket history — and what is out of bounds.

Your storage and naming

Where documents live, how they are named and numbered, how versions work, and what happens to the superseded one.

Your exception style

How far into the unusual cases a procedure should go before it becomes unreadable, and where the rest of them go instead.

Your release switches

Which procedures may be drafted from a recording alone, which require an interview first, and which may never be drafted without a named qualified approver.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every step cites the source and the moment it came from, every open question says what was missing, and every version says who approved it and what changed. A procedure can be audited against the recording it came from rather than taken on trust.

Versioned prompts you can tune yourself

The template, the terminology, the level of detail and the prompts behind turning a recording into steps are yours to tune. A change is a reviewable diff, replayed against procedures you have already approved so you can see exactly what it would have written differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Transcribing, drafting, citing and diffing are automatic. Deciding what the process should be, resolving the open questions, approving a procedure and publishing it are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per draft and one per version: the sources, the steps and their citations, the open questions, who approved it, what changed since the last version — plus token usage and cost for that run.

It can be configured to run in any business. The template and the rules are yours: your headings, your words, your level of detail, your approvers, your storage, your review cycle. The documentation wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This writes into the document system you already use. We're not selling you a documentation platform, and the procedures stay yours in a format you can read without us.

• Google Drive, SharePoint or Dropbox
• Notion or Confluence
• Microsoft 365 and Word
• Google Workspace and Docs
• A training or LMS tool
• A PSA or professional services tool
• Asana, Jira, ClickUp or Monday
• Zoom, Teams or Meet recordings
• A screen recording somebody made
• A folder of half-written documents

Works well for

• Manufacturers — Work instructions live at the machine, and the operator who wrote them has already moved on.
• Restaurants and food service — Opening, closing and prep have to read the same way in every location.
• Property management companies — Turnovers, inspections and maintenance calls follow a routine nobody has written down.
• Dental and medical practices — Front-desk and sterilization routines are taught by watching, and then they drift.
• Franchises — A new location needs the same procedure in the same words, or it is not the same business.

How a rollout works

Nothing is published on day one. The first milestone is one procedure you already have, written again from a recording and compared with the document you are using now.

1. 01Discovery

   The quote call, then a working session. We go through your template, your words, the level of detail each reader needs, who approves what, where documents live, what may be read, and which procedures need a qualified approver. You get the template, the source list and a written scope.

2. 02Dry run

   One process, recorded once, written up twice: by the bot and by whoever usually writes them. Nothing is published. You compare the steps, the citations and the open questions — and the open questions are where the work is, because the holes in a procedure stay invisible until somebody has to follow it.

3. 03Assisted mode

   Live on a backlog you choose. The bot drafts, the person who does the job runs the draft and signs it off, and the writer edits instead of starting from a blank page. Who owns the process does not change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of procedure types you name, drafted and filed from a recording automatically, still unapproved until somebody follows them, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No time-saved claim, no documents-per-week figure, no "procedures in minutes". We haven't written yours. What the first one takes comes out of the dry run, and it will be your number.
• No customer claims on this page. No names, no case studies, no logos.
• It cannot supply the context nobody recorded. A model can fix grammar, structure and order. It cannot know the reason behind the step that looks pointless, or the customer you always call first. That knowledge is in somebody's head, and the only way out is to ask them — which is what the open questions are for.
• A written procedure is not a compliant one. It is not an audit, a certification or a controls opinion, and it does not make you ready for an inspection. Safety, clinical, financial-control and regulated procedures need a qualified person to own them, and the design routes them there instead of pretending.
• Documentation nobody maintains is a liability. The honest part of this build is the review cycle, not the first draft. If nothing is going to trigger a re-read when the system changes, a folder of confident procedures is worse than the folder you have now.

Questions people ask

Can AI write our standard operating procedures?

Yes, from something real. Record somebody doing the job with the sound on, or sit on a walkthrough call, and an agent can turn that into numbered steps in your own template, with each step citing the minute it came from. What it will not do is fill the gaps: anything the recording did not cover comes back as an open question, because a plausible step is the one that breaks when a new starter follows it.

What do you need from us to start?

One process and one person who does it. A narrated screen recording is the easiest thing to produce and the best source to work from; a walkthrough call works; an existing half-written document, a checklist or the email where somebody explained it properly all help. The less we have to invent, the shorter the open-questions list, and the open-questions list is the part that needs a human anyway.

What stops it from inventing steps?

A rule rather than good intentions: every step has to cite the source and the moment it came from, and anything without one is an open question instead of a sentence. It also does not add the industry-standard step the recording never contained, and it does not reorder the process to look tidier - the order is evidence too.

Who approves a procedure?

The person who does the job, and they approve it by following it rather than reading it. That is the whole review step: do the task once from the draft, and everything you trip over becomes an edit. Reading a procedure proves only that it reads well, which is the failure mode this kind of document invites.

Can it keep them up to date?

That is the part worth paying for. When a system or a step changes, a new recording becomes a diff against the approved version - what moved, what is gone, what is new - with the owner and the review date tracked. A folder of confident procedures nobody has updated is worse than no folder, because people follow them.

Is a procedure the same as a knowledge base article?

No, and keeping them apart is one of the configuration decisions. A procedure tells the person doing the work what to do next, in order. An article answers somebody else's question later, out of order. A policy says what the rule is. The same source material can produce all three, but a document that tries to be all three gets read by nobody.

Can we use these for an audit or a certification?

You can use them as your documents; we make no claim about what any standard, auditor or inspector will accept. Writing a process down does not make it compliant. Safety, clinical, financial-control and regulated procedures are flagged as needing a named qualified approver, and anything about what a regulation requires goes to the person who owns that in your business.

Does it replace the person who knows how the work gets done?

No - it depends on them. The bot removes the typing, the formatting, the screenshots and the restructuring, which is the work that keeps a procedure from being written at all. The knowledge, the judgment and the reasons behind the odd steps come from your people, and the open questions exist to get those out of their heads and into the document.

Is there a record of what changed and who approved it?

Yes, per version: the sources it was written from, every step with its citation, the open questions and how they were answered, who approved it and when, and a diff against the previous version. Superseded versions are kept rather than overwritten, so you can see what the procedure said at the time somebody followed it.