Skip to content
skill-guide · 2026.06.19

Turn messy notes into SOPs and process docs with AI

by paul thomas·5 min·1,224 wordsSKILL-GUIDE

Most organisations have a version of this problem: one person knows exactly how something works and nobody else does. The knowledge lives in someone's head, in a Slack thread from eight months ago, or in the recording of a call they did when a new hire joined. It gets re-explained every time someone new arrives. Nothing is written down because writing it down properly takes longer than just explaining it again.

AI is good at this job. Not because it knows your process, but because it can take the raw material you already have and shape it into something structured. You still own the knowledge. You're just no longer the bottleneck for getting it into a usable format.

The tool, and how to set it up

Use Claude (claude.ai or the API). You need a tool that handles long pasted text cleanly. Claude's context window is large enough to take a full Slack export, a meeting transcript, or several pages of scattered notes in a single paste.

You do not need any special setup. You are pasting text and asking for a structured document back. If your source material is in a file, paste the text contents directly rather than uploading the file, so you can see exactly what the model is working from.

One thing that matters: paste the raw material first, then give the instruction. Do not summarise or tidy the notes before pasting. The messier the input, the more the model has to work with. Cleaned-up notes tend to lose the detail that makes an SOP actually correct.

How to do it

  1. Gather everything you have. Pull together whatever exists: the Slack thread where you explained it, the notes from the last time you onboarded someone, a transcript from a Loom or Teams recording, bullet points from your own memory. It does not need to be complete or coherent. Paste it all.

  2. Give the model the structure you want. An SOP should have: purpose (one sentence on what this process achieves), when to use it (the trigger or scenario), numbered steps, roles (who does each step), what good looks like at the end, and common mistakes to avoid. If your organisation already has a template, describe it or paste a blank version.

  3. Run the prompt below. Paste your raw material, then follow it with the prompt. The model will produce a first draft.

  4. Read every step out loud. This is not optional. The draft will read well. The failure mode is that it reads well and is wrong in a subtle place. You are the subject matter expert. Go through each step as if you were following it yourself for the first time.

  5. Fill the gaps the model could not know. It will sometimes flag uncertainty with phrases like "confirm the exact step here" or produce steps that are plausible but unspecific. Replace these with the real detail.

  6. Test it cold. Give the draft to someone who has not done this task before and ask them to follow it. Watch where they get stuck or ask a question. Every sticking point is a gap in the doc.

  7. Version it. Date the document and note who reviewed it. An undated SOP will be trusted long after it is out of date.

The prompt

Here is my raw source material about [name the process]:

[PASTE YOUR NOTES, TRANSCRIPT, OR SLACK THREAD HERE]

Using only the information above, draft a structured SOP for this process. Format it as follows:

**Purpose**
One sentence: what does this process achieve?

**When to use this**
The trigger or scenario that tells someone it is time to follow this process.

**Roles**
List each person or role involved and their part in brief.

**Steps**
Numbered, in order. Each step should include:
- What to do (specific action, not a category)
- Who does it (name or role)
- Any tool, system or form used
- What you should see or have at the end of this step (the check)

**What good looks like**
How you know the process is complete and correct.

**Common mistakes**
Up to five things people get wrong, based only on what is in the source material.

Flag any step where the source material is unclear or missing information. Mark these [NEEDS CONFIRMATION] rather than inventing detail.

Do not add steps, tools or information that are not in the source material I provided. If something is missing, flag it.

How to QA it

The typical failure is a document that looks professional and is subtly wrong. AI models write confidently. A missed step, an incorrect order, or a detail from a process that has since changed will not announce itself. It will just sit there, waiting for someone to follow the doc and make a mistake.

Check these things specifically:

  • Order. Can you follow the steps top to bottom with nothing missing? Is there a step that requires you to have done something that comes later?
  • Roles. Is it clear at each step who is responsible? "The team" or "someone" is not an answer.
  • The step everyone forgets. Every process has one. It is usually the thing so obvious to the person who built it that they never mention it. Look for assumed knowledge.
  • The [NEEDS CONFIRMATION] flags. The model will mark gaps. Do not leave these in a published doc.
  • The cold test. Ask a capable colleague to follow the SOP without your help. What do they ask? What do they guess? That is your revision list.

How to stay safe

A confident wrong SOP is worse than no SOP at all. People follow documented processes without checking, especially in high-pressure moments. A doc with an error in it will be trusted.

Specific risks for this task:

Old process in the source material. If your notes include how you used to do something, the model cannot tell which version is current. If your raw material spans more than a few months, check whether any step reflects a process that has since changed.

Credentials and client data. Do not paste Slack threads or transcripts that include passwords, API keys, client names, or personal information into any AI tool, particularly consumer ones. If the source material contains sensitive detail, strip it before pasting and add a note to the draft about what should go there.

The "looks right" trap. If you are not the subject matter expert for the process you are documenting, you will not catch errors by reading the draft. Get someone who has done the task to review it before it becomes the official version.

Do not publish before review. A first draft is a working document. Label it as such. "Draft, not yet approved" in the header prevents someone from following it before it has been signed off.

The doc you produce should be reviewed by at least one person who has actually done the task, every time.


Pick one process you have explained more than three times this year. Find the Slack thread or write ten minutes of notes. Paste it into Claude with the prompt above and see what comes back. The review pass is the work. The draft gets you to the review pass in twenty minutes instead of two hours.

// subscribe
One post like this a week.
Free. Unsubscribe in one click.