Home / Operations and admin / KA-010

Write a standard operating procedure from a spoken walkthrough

Turn a screen recording transcript or a spoken walkthrough into a clear, numbered standard operating procedure, then test it with someone new.

Who it suits

Small business owner, operations manager, team lead, freelance virtual assistant

Time saved

About 1 to 2 hours per procedure compared with writing from scratch (estimate)

Level

Medium

Updated

Oct 13, 2026

Why this task

Much of how a small business runs lives in one or two people's heads. When that person is away, tasks stall or get done differently each time. Writing a standard operating procedure (SOP) by hand takes hours that busy staff do not have. An agent can draft one from a short recorded walkthrough, and a test run with a new person shows where it falls short.

You write a standard operating procedure (SOP) for [BUSINESS NAME] from a recorded walkthrough.

Task name: [TASK NAME]
Who will use this SOP: [AUDIENCE, e.g. a new front desk team member]
Tools and systems involved: [TOOLS, e.g. booking system, shared inbox]
How often the task is done: [FREQUENCY]
Task owner who approves the SOP: [OWNER NAME]

Transcript of the walkthrough:
[PASTE TRANSCRIPT]

Write the SOP with these sections:
1. Purpose: one or two sentences on what the task achieves.
2. Before you start: access, files or materials needed. Refer to logins by system name only.
3. Steps: numbered, one action per step, starting with a verb. Name the exact screen, button or field the speaker used. Keep each step under 25 words.
4. Checks: how the person knows each key stage worked.
5. If something goes wrong: the problems the speaker mentioned and what they said to do.
6. Who to ask: [CONTACT ROLE].

Rules:
- Use only what the transcript says. Do not add steps from general knowledge of the tool.
- Where the speaker skipped over something, said "you just know", or was unclear, add it to an Open Questions list instead of guessing.
- Never include passwords, account numbers or customer details, even if they appear in the transcript. Replace them with [REDACTED].
- Use plain words a new starter would understand. Explain any abbreviation the first time.

After the SOP, write a Test Plan. List three things a first time tester should do using only this document. Say what the observer should note.

End with the Open Questions list for [OWNER NAME] to answer.

Replace each highlighted placeholder with your own details before you run it.

Steps

1. Pick one task that is done often and stalls when the usual person is away. Examples: sending month end invoices, or opening the shop.
2. Ask the person who does it best to record themselves doing it once, talking out loud about what they click and why.
3. Pause or blur the recording where passwords, customer details or bank screens appear. Leave those out of the transcript.
4. Transcribe the recording and paste it into the prompt with the task name, the tools used and who the SOP is for.
5. Run the prompt as a one off chat. Read the draft with the original expert and answer every item in the open questions list.
6. Test the SOP: ask someone who has never done the task to follow it while the expert watches without helping.
7. Note every point where the tester got stuck, guessed or asked a question. Feed those notes back to the agent to revise the steps.
8. Have the task owner approve the final version, add an owner and review date, and store it in your shared document or wiki.
9. Review each SOP every six months, or when a tool changes. If your setup lets an agent run on a schedule, it can remind the owner and list SOPs past their review date. The rewrite itself still starts from a fresh walkthrough.

What you get

A numbered SOP with one action per step, checks, a short troubleshooting section and a named contact. A short test plan and an open questions list come with it. After one test run and revision, a new person can complete the task without help.

What can go wrong, and the check for each

Related playbooks