AGINE Academy
September 18, 2026 · 5 min read · AGINE team

How to write a standard operating procedure with Claude

A step-by-step way to pull a work process out of your head and turn it into a clear SOP in one evening: interview, structure, and a newcomer test.

You keep the whole business in your head: how to take an order, how to handle a return, how to pull the monthly report. That works while the team is small. Then a new person joins, and you explain the same thing for the tenth time, and they still do it their own way. A standard operating procedure is how you get a process out of your head and onto paper, so an employee can open the document and do the job without you. Writing one by hand is dull, which is why most owners never do it. Claude, the AI assistant (artificial intelligence) from Anthropic, removes the boredom: you talk through how things work, and it turns your words into structure.

Why does a small business need an SOP if things already work?

An SOP (Standard Operating Procedure) is a step-by-step description of one repeating task: how to take an incoming lead, how to issue an invoice, how to answer a complaint. As long as everything runs through you, the company stops the day you get sick or travel. A written procedure gives you three things. A new hire reaches the right result in days instead of months. Mistakes drop, because people read instead of guessing. And you stop being the only person who holds the knowledge, which means the business can be handed to a manager or scaled to a second location.

One key point: an SOP is not a thick book. A good one fits on a page or two and covers exactly one process. Do not try to describe the whole business at once. Take the single task that eats the most of your explaining time.

How do you start pulling a process out of your head?

The most common mistake is to sit down and try to write polished official prose right away. You will stall on the first paragraph. Do the opposite: dump a rough draft in your own words, messy and out of order. Open Claude, dictate by voice or jot down a list of thoughts, and let it do the sorting. Paste in this prompt (a ready command for the model):

You are helping me write a work procedure. I will describe the process in my own words, messy and out of order. Ask me one clarifying question at a time until you have gathered everything: who is involved, what is needed to start, the steps in order, what counts as a finished result, and where people most often make mistakes. Do not write the procedure until I say stop asking.

Claude turns into an interviewer and pulls out the details you would forget: which email template to use, who the lead goes to next, what to do if the client goes silent. Answer briefly, by voice if you like. This is the most valuable part of the work, because the questions expose the gaps that feel obvious in your head but are unclear to a newcomer.

How do you turn the story into a finished procedure?

When you have answered everything, say stop asking and request the document. Second prompt:

Assemble a procedure from my answers using this structure: process name, why it matters, who is responsible, what to prepare before starting, numbered steps in order, the criterion for a finished result, and common mistakes with how to avoid them. Write short lines in the imperative: open, check, send. No filler. The reader is a new employee on their first day.

The imperative voice and the stated reader level are the two conditions without which the procedure comes out vague. If Claude still writes long, ask it to cut each step to a single line. Want a table instead of a list, just say so: step, who does it, result.

How do you check that a newcomer will understand it?

The test is simple: will the document produce a result for someone seeing the process for the first time. You are a poor tester, because you already know everything. So ask Claude to play the newcomer:

You are a new employee on your first day with no experience in this field. Read the procedure below and flag every place where you, as a beginner, would not know what to do or where a specific detail is missing. Do not rewrite the text, just give a list of the questions that came up.

You get an honest list of gaps: it does not say where to get the template, it is unclear how long to wait for the client. Answer those questions and fold the answers into the procedure. Two or three rounds of this, and the document becomes bulletproof. That is cheaper than catching mistakes on live customers.

How do you keep the procedure alive?

A procedure written once and forgotten goes stale in a couple of months and turns into a harmful lie. Keep all of them in one place. Claude has Projects (shared workspaces that remember your files and rules): create a project called Company Procedures, upload the finished documents, and when a process changes, just tell Claude what changed and ask it to update the right step. We covered projects in detail in a separate piece on Claude Projects for business.

The output is a working artifact: a document in .md format or a table of steps you can print, drop on a shared drive, or pin in the team chat. One evening with Claude, and a process that lived only in your head now runs without you.

You can practice this hands-on, with guidance, in our free materials: the AGINE Academy guides and the first interactive lesson, Meet UNIT, where you build your first working result yourself.

AGINE Academy is an independent product, not affiliated with Anthropic. Claude belongs to Anthropic.

Questions

How long does it take to write one SOP with Claude?

One process is realistic in 30 minutes to an hour. Most of the time goes not into the text but into answering Claude's clarifying questions and a couple of rounds of the newcomer test. The document itself is assembled in seconds.

Do I need a paid Claude plan to write procedures?

No, the basic flow works on free access at claude.ai. A paid plan gives you more daily volume and the Projects feature, which is handy once you have many procedures and want to keep them in one workspace.

Won't the model invent steps I don't actually have?

It can, if you give it too little input. That is why the first prompt tells Claude to ask questions and not write the procedure until you have answered. Then the document is built from your words, not its imagination. Still read the final text yourself: you are responsible for what you hand the team.

Does this work for a complex process with branches?

Yes, but split it. Describe the main path as one procedure and move rare exceptions into a separate what-if block. Claude helps you spot the branches when it plays the newcomer and asks what happens if the client says no.

Start the free lessonSee the full programAll articles