How to Write an SOP With AI (Interview Method)

Ask an AI to "write a standard operating procedure for onboarding a new client" and you will get something like this:

> 1. Initial Contact. Establish communication with the client and gather preliminary requirements.

> 2. Documentation. Collect all necessary documentation and verify completeness.

> 3. Kickoff. Schedule and conduct a kickoff meeting to align on objectives.

It is well organized, correctly formatted, and completely useless. It describes onboarding in general, not onboarding at your company. Nobody can follow it, because it contains no information they did not already have.

The failure is in the request. You asked a model to invent a process it has never seen. It did the only thing available: produce the statistical average of every onboarding document on the internet.

The process you actually want documented lives in one person's head. The job is extraction, not generation.

Flip the direction: let the AI ask

Instead of asking for a document, ask for an interview.

I want to document how we onboard a new client at my company.
You do not know our process, so do not guess or propose one.

Interview me. Ask one question at a time, starting with what
triggers the process and who is involved. Follow up whenever
an answer is vague, mentions a tool without naming it, or
skips a step. Keep going until you could hand the document to
a new hire who could complete the task without asking anyone.

Do not write the SOP until I say we are done.

Three constraints in there do the work.

One question at a time stops the model from dumping twelve questions you will answer in a paragraph, skipping half. Conversation gets more out of people than a form does.

Follow up on vagueness is where the real value is. You will say "then we set them up in the system," and it will ask which system, who has access, and what happens if that person is away. Those are exactly the details that live in someone's head and never make it into documentation.

Do not write it yet prevents the model from bailing out into generic content early, which it will otherwise do around question four.

Expect fifteen to thirty minutes and twenty-ish questions. That is faster than writing it yourself, and it produces something different in kind, because a good interviewer surfaces steps you would not have thought to mention.

Harvest the exceptions

Once the happy path is captured, run a second pass specifically for what goes wrong. This is the step most SOPs skip and the reason most SOPs get abandoned.

Now ask me only about failure cases and exceptions for this
process: what goes wrong, how often, who handles it, and what
the workaround is. Include anything we do differently for
unusual clients.

The answers are the difference between a document that survives contact with reality and one that gets ignored the first time something unusual happens. Every process has a "except when it is a referral from Dave, then we skip the deposit" rule. Undocumented, that rule is a single point of failure attached to one employee.

Then have it write, and check the check

With the interview transcript in context, ask for the document:

Write the SOP from what I told you. Rules:
- Use only information from this conversation. Do not add
  best-practice steps I did not describe.
- Every step names who does it and in which tool.
- Mark anything I was unclear about as [NEEDS CONFIRMATION].
- Put exceptions in a separate section at the end.

The [NEEDS CONFIRMATION] instruction matters more than it looks. Without it, gaps get filled with plausible invention, and plausible invention in a procedure document is worse than a blank, because nobody knows to question it. This is the ordinary hallucination problem showing up somewhere it does real damage: an invented approval step reads exactly like a real one.

The instruction to use only what you said is the other guard. Models are strongly drawn toward adding sensible-sounding steps nobody asked for, which is a specific case of prompting past generic answers.

Test it on someone who does not know the job

An SOP is correct when a person who has never done the task can complete it from the document alone.

So test it that way. Hand it to someone else and have them attempt the task, with a rule: every time they have to ask a question, they write it down instead of asking. Their list of questions is your revision list, and it is far more reliable than proofreading your own document, where you will read past every gap because you already know the answer.

Feed those questions back in and ask for a revision addressing each one specifically.

Why document this at all

There is a market argument for it, not just a tidiness one.

Census Bureau data shows AI use concentrated among larger firms: its May 2026 analysis found 37 percent of firms with at least 250 employees using AI, against under 20 percent of firms with four or fewer employees, with usage among the smallest firms flat from December 2025 through May 2026.

Part of that gap is budget. A larger part is that automating a process requires the process to be written down, and small firms mostly run on undocumented knowledge held by whoever has been there longest. You cannot hand a task to a tool, a new hire, or an agency while it exists only as habit.

Written procedures are the prerequisite step. They are also what lets you give AI accurate context about how your business works, which is the input every downstream automation depends on. A documented support process is what makes automating customer support a configuration exercise rather than a guess, and the same holds for most of what AI does well for small businesses.

Keeping them alive

SOPs rot. The version that matters is the current one.

Put a date and an owner on every document, and review on a schedule that matches how fast the process changes: quarterly for anything touching software, annually for stable manual work.

The cheap maintenance trick is to update at the moment of friction. When someone hits a step that no longer matches reality, that is the moment the correction is known and free to capture. Paste the document and the discrepancy into a model and ask for a revised version of only the affected section. Ten minutes, not a rewrite project.

Keep one document per process. A combined manual covering nine procedures gets read by nobody and updated by no one.

Frequently asked questions

How long should an SOP be?

As long as the process, and no longer. A five-step task is a five-step document. Length added for completeness makes it less likely to be read, which makes it less likely to be followed.

Can AI write an SOP from a screen recording or transcript?

Yes, and this works well. Record yourself narrating the task as you do it, transcribe it, and hand the transcript over with the same rules about not inventing steps. Narration captures details you skip when describing the process from memory.

What if two people do the same task differently?

Interview both. The differences are the most valuable output of the exercise, because they either reveal an improvement worth standardizing on or a genuine variation the document needs to cover.

Should the SOP name people or roles?

Roles, with names in a separate contact list. Naming people inside the procedure means the document goes stale the moment someone changes jobs.

How do I stop the AI adding steps we do not actually do?

Instruct it explicitly to use only information from the conversation and to mark unknowns rather than filling them. Then read the output against your own knowledge, since this is the one error type that looks identical to correct content.