BusinessAI Lunch & Learn
Lunch & Learn

Record it, write it, publish it

SOPs are the most boring subject in business and the one that quietly costs you the most. Here's the framework we use internally to build them in minutes instead of months.

01

Loom

Capture it

02

Claude

Structure it

03

Lovable

Publish it

John MayersPresented byJohn Mayers · Director of Consulting

Watch the recording

Watch the full session and follow along with the prompts below

Thirty three minutes, recorded live, including the demo where the whole SOP is built from a single recording.

In this session

From screen recording to a trusted SOP

Capture the process

Record the real task in Loom and narrate every click, choice and exception.

Build the SOP

Use Claude to turn the transcript into a consistent nine-part procedure.

Test the instructions

Find assumptions, missing context and weak steps before your team relies on it.

Publish the library

Use Lovable to make every approved SOP searchable and easy to maintain.

Book an introduction to BusinessAIOpen recording in YouTube

The workflow

Three steps from knowledge to action

10 min

To capture one SOP

A short Loom of you doing the task normally. That's the whole input. Everything after it is Claude's job, not yours.

9 parts

In the framework

Purpose, trigger, owner, prerequisites, steps, decision points, quality check, common mistakes, escalation. Same shape every time.

5 SOPs

Is a real start

The five tasks that cause the most interruptions. Five that get used beat forty that sit in a shared drive unopened.

6 months

Between reviews

Every SOP carries an owner and a review date. Without both, it quietly goes out of date and the team stops trusting the library.

Step one — Loom

Stop writing SOPs. Record them instead.

The reason most SOPs never get written is that writing them is miserable. So don't. Open Loom, hit record, and do the task exactly the way you normally do it while talking through what you're clicking and why. Five to ten minutes of you actually doing the job captures more detail than an hour of trying to remember it at a keyboard. The recording is not the SOP, it is the raw material. Loom gives you a transcript, and that transcript is what every step after this one feeds on.

Record it this way if

  • You'd struggle to write the steps down but you could do the task in your sleep
  • The task has fiddly bits, which button, which tab, which field, that only show up when you watch someone do it
  • Someone new is starting and you'd otherwise sit next to them for an hour
  • It's the third time you've explained the same process to a different person

Setup: Loom open, screen share on, mic on. Talk the whole way through, silence gives the transcript nothing to work with.

Narration checklistprompt
Say these out loud as you go, in this order:

One, what the task is and what triggers it. "This is how we raise an invoice, we do it every Friday afternoon."

Two, what you need in front of you before you start. The logins, the files, the template.

Three, every click, by name. "I'm opening the client tab, not the leads tab, this matters because the numbers differ."

Four, the judgement calls. Whenever you'd pause and think, say what you're weighing up and how you decide.

Five, the mistakes. "This is where people usually get it wrong, they skip the GST line."

Six, what done looks like. Show the finished result and say how you know it's correct.

Keep it under ten minutes. If it runs longer, that's two SOPs, not one.

Why this helps: the transcript ends up containing the reasoning, not just the clicks, which is the part written SOPs always lose.

Have this ready

  • Loom installed and the right screen shared, not your whole desktop
  • A real example to work through, ideally with dummy or test data
  • A quiet ten minutes with notifications off
  • The task chosen in advance, not decided while recording

Common mistakes

  • Recording in silence, so the transcript has nothing but mouse movements
  • Narrating what you're clicking but never why you're clicking it
  • Doing an idealised version instead of the way you actually do it
  • One giant forty minute recording covering five different tasks

Other things worth recording

The monthly reconciliation nobody else has ever seen. The quote build with all its exceptions. How you handle an angry customer call. The handover you do before leave. Anything that currently lives only in one person's head is a recording waiting to happen.

How to tell it is working

You finish the recording in less time than it would have taken to write the first three steps, and the transcript already mentions two exceptions you'd have forgotten at a keyboard.

Before you build

Six things worth thinking about first

None of this is technical. It is the difference between an SOP library the team trusts a year from now and a folder of documents nobody has opened since the day they were written.

Record the real version, not the tidy one

The value is in the messy bits, the workaround you always use, the tab you check first, the thing you'd never think to write down. If you perform a polished version for the camera, you document a process nobody actually follows.

The transcript is the input, not the output

Never hand someone a Loom link and call it an SOP. Recordings can't be searched mid-task, skimmed, or updated in one line. The recording feeds the document, the document is what the team uses.

One SOP, one job

If your recording runs past ten minutes you've got two procedures tangled together. Split them and link one to the other. Long SOPs get abandoned halfway through on the first read.

You're still the expert

Claude structures, orders and formats. It cannot know that the second Tuesday of the month is different, or that one client is billed differently. Always read the draft and correct it before it goes near anyone else.

Strip anything sensitive

Before you paste a transcript, check it for customer names, card details, passwords and anything under contract. Record with a test account or dummy data where you can, and blur what you can't.

Name an owner or don't publish

An SOP without a named owner role and a review date will be wrong within a year, and one wrong SOP makes people distrust all of them. The owner is the person who updates it the day the process changes.

Session library

Previous webinars and learning pages

Every Lunch & Learn leaves behind a page you can revisit, with the prompts, steps and examples from the session.

Questions & answers

Common SOP questions

The practical answers to the questions that come up when teams start documenting their work.

Do I need to write the SOP before I use Claude?

No. Record yourself completing the real task in Loom, then give Claude the transcript. Your job is to review the result and fill any gaps, not start with a blank page.

How long should one recording be?

Aim for five to ten minutes. If the recording runs longer, it probably contains more than one process and should become separate SOPs.

Can I use meeting notes instead of a Loom transcript?

Yes. A transcript, rough notes, or an existing draft can all work. The stronger the source detail, especially decisions and exceptions, the stronger the finished SOP.

Should the finished SOP include screenshots?

Include screenshots where the exact screen, button, or field matters. Keep the written steps complete enough that the process still makes sense when an interface changes.

Who should approve an AI-written SOP?

The person who currently owns or performs the process should check every step before publishing. Claude structures the knowledge; your team remains responsible for accuracy.

How often should we review SOPs?

Set an owner and a review date six months ahead. Review sooner whenever the tool, policy, pricing, or process changes.

Book an introduction to BusinessAI today

Book your call