Turn messy notes and voice memos into SOPs and checklists with an LLM

What you will be able to do

By the end of this guide, you will turn a pile of sticky notes, chat dumps, or a voice memo into a one-page SOP and a short checklist your team can follow without calling you mid-job.

Why messy procedural knowledge stays unretrieved in owners’ heads

In dental offices, med spas, HVAC shops, and trade businesses, the “how we do it here” lives in the owner’s head, a senior tech’s habits, and half-finished texts. When that person is out, quality slips.

A language model is good at sorting and naming steps. It is not good at inventing how your shop actually works. Your job is to feed it raw truth, then verify.

Step 1: Capture raw source material without cleaning it

Record or put whatever you have:

• Voice memo after a job (“Here’s how we commission a new install…”)
• Photos of whiteboard steps
• Chat thread where you explained a process to a new hire
• Bullet notes from a team huddle

Tell the model: “Do not invent steps. Organize only what I provide. Mark gaps as [NEED].”

Cleaning too early makes you drop edge cases you still need in the SOP.

Step 2: Name the procedure with three labels

Before asking for a full SOP, define:

1. Role — who runs this (front desk, lead tech, assistant)
2. Trigger — when it starts (new patient booked, truck leaves yard, machine alarms)
3. Done — what “finished” looks like (chart updated, customer signed, unit tested)

Prompt example:

“Turn these notes into an SOP for [role]. Trigger: [trigger]. Done when: [done]. Use numbered steps. Keep tools and materials in a short list at the top.”

Step 3: Ask for an SOP, then a phone-friendly field checklist

First output: a readable SOP (purpose, tools, steps, exceptions).

Second output in the same chat:

“Compress this into a checklist the [role] can tick on a phone. Max 12 items. Action verbs only. No essays.”

Teams run checklists. They skim SOPs when something breaks. You need both.

Step 4: Add exceptions and safety lines deliberately

Prompt for a third pass:

“List exceptions and stop-points only. If a step can harm a person, damage equipment, or break a regulation, mark it STOP and say who to call.”

Do not let the model invent safety rules. Provide your real rules and ask it to place them next to the right steps.

Step 5: Verify with one real run

Hand the draft to the person who already does the job well. Ask them to mark:

• Missing steps
• Wrong order
• Words nobody on the team uses
• Steps that only apply in special cases

Update the doc from their markup. The language model did the sorting; the floor owns accuracy.

Step 6: Publish where Monday work actually happens

Put the checklist where the work happens:

• Printed in the truck binder
• Pinned in the ops chat topic
• Linked from the scheduling board
• Saved next to the machine or treatment room

Name files with a date: closing-checklist-2026-09-20.md. Retire old copies so nobody follows last year’s process.

A simple weekly habit

Each Friday, pick one messy process that caused a callback, delay, or “ask the owner” moment. Spend 20 minutes:

1. Voice-memo the real steps
2. Run the SOP + checklist recipe
3. Verify with one lead
4. Publish before Monday

In a month you will have a small library of runbooks instead of another pile of notes.

What the language model should not own

Do not use the model as the source of truth for licensed clinical protocols, electrical code, or warranty terms. Use it to organize your documented practice, then confirm against the official source your business already follows.

Short close

Raw notes in, verified checklist out—that is the useful job.