← Back to Blog

Short answer: Dictate SOPs by narrating each step out loud while you actually perform the task, then edit the transcript into a numbered procedure. Speak the explanations and decision rules; type the exact values, file paths, and settings, because a wrong number in a procedure reads as correct.

Every organisation has a shelf of procedures that exist as a title and nothing else. "Month-end close process." "New client onboarding." "How to handle a chargeback." Someone created the page, wrote a heading, and never came back. Meanwhile the actual procedure lives in one person's head and gets transmitted by tapping them on the shoulder.

The usual explanation is that nobody has time. That is true but incomplete. The more precise version is that documenting a process costs roughly forty times what performing it costs to describe. You can explain the whole refund workflow to a colleague in ninety seconds. Writing that same explanation down, as a clean numbered procedure, takes forty minutes. That ratio is what kills SOPs, and it is an input problem before it is a discipline problem.

An average adult types around 40 words per minute. Conversational speech runs 130 to 150. When the artifact you need to produce is mostly explanatory prose, and an SOP is mostly explanatory prose, the gap between those two numbers is the entire reason the page is still empty.

The core method: narrate the procedure while you do it

The single biggest change is not "dictate instead of type." It is when you dictate. Most people try to write an SOP from memory, at a desk, days after the last time they ran the process. That is the hardest possible version of the task, because you are simultaneously trying to recall the steps and phrase them well.

Do it the other way round. The next time you actually perform the procedure, perform it slowly and talk through it as you go. Hold your dictation hotkey, say the step, release, do the step, and continue. You are not writing a document at this stage. You are producing a raw transcript of a real run of the process, with the screen in front of you as your outline.

This method fixes the failure mode that ruins most SOPs: missing steps. Documents written from memory skip the things the author does automatically. Documents narrated during a live run cannot skip them, because you have to actually do each one. The invisible step where you check whether the customer is on the legacy plan before you issue the credit gets captured, because you had to check it.

The result is messy. That is fine. A messy transcript of a complete process is worth more than a beautifully formatted document with three steps missing, because editing prose is fast and reconstructing forgotten steps is slow.

The two passes

  1. Capture pass. Run the process, narrate every action, do not stop to fix wording. Say things like "and then you have to wait for the sync to finish, it usually takes about a minute, if it takes longer than five something is wrong." All of that is useful and none of it needs to be pretty yet.
  2. Shape pass. At your desk, turn the transcript into a numbered procedure. Cut the throat-clearing, promote the "if it takes longer than five" line into a troubleshooting note, and add the exact values by hand. This pass is mostly deleting, which is the fastest kind of editing.

Two passes sound like more work than one. In practice the capture pass takes as long as the process takes, which you were spending anyway, and the shape pass takes ten to fifteen minutes. The one-pass approach takes forty minutes and produces an incomplete document.

Setting up on a Mac

Nothing gets installed into your documentation tool. Voice Keyboard Pro lives in the menu bar and types at the cursor in whatever app has focus, so the same setup works in Notion, Confluence, Google Docs, a wiki, a Word file, or a plain text editor. Hold the hotkey, speak, release, and the text appears where you were already typing.

Two setup notes worth getting right before your first capture session:

If you are documenting a process that lives inside a browser tool, a second window or a second display makes the alt-tabbing much less annoying. Narrate into a scratch document, not into the tool itself.

Speak the reasoning, type the values

This is the rule that separates a usable procedure from a dangerous one, and it comes down to how errors present themselves.

Prose defends itself. If a sentence comes out garbled, any reader can see it is garbled and will work out the intent or ask. Data does not defend itself. If a procedure says to set the threshold to 30 when it should be 13, that line reads as perfectly correct. Nobody proofreads their way to catching it, and the person following the SOP six months from now has no way of knowing.

Speak: the purpose of the procedure, what each step accomplishes, why a step exists, what to do when something looks wrong, who to escalate to, what "done" looks like, and the judgement calls that a checklist cannot capture.

Type: exact field values, dollar amounts, thresholds, dates, file paths, URLs, account numbers, config keys, version numbers, and anything a reader is expected to copy character for character.

In practice this means your capture pass produces sentences with holes in them: "set the retry limit to the value in the config sheet, I will fill that in." Then during the shape pass you fill the holes with your hands. It feels slightly awkward for a day and then becomes automatic. Our post on dictating addresses and other low-redundancy data makes the same argument in more detail, and the reasoning applies to every procedure that contains a number someone will act on.

The five parts of an SOP worth dictating

1. The purpose paragraph

Almost every weak SOP starts at step one. The strong ones open with two or three sentences explaining what this procedure is for, when it applies, and when it does not. This is the part most likely to be skipped when writing by hand, because it feels like preamble, and it is the part that most often prevents someone from following the wrong procedure entirely. It is also pure prose, so it is the cheapest thing you will ever dictate. Say it in one breath: "This procedure covers refunds under two hundred dollars for customers on a current plan. Refunds above that amount, or on legacy plans, go through the finance approval process instead."

2. The steps themselves

Narrate one step per dictation. Hold, speak the step, release, perform it. Keeping one dictation to one step gives you clean boundaries to edit against later, and it stops you from producing a single wall of text that has to be broken apart by hand.

Speak in the imperative as much as you can manage. "Open the billing tab" edits into a step faster than "so what I do here is I go to the billing tab." You will not be consistent about this during a live run and that is fine, but the closer your speech is to the final voice, the shorter the shape pass.

3. The exceptions and the failure paths

This is where dictation pays for itself twice over. Exception handling is the highest-value and least-documented part of any procedure, precisely because it is the most expensive to write. Each exception is a conditional sentence: if this happens, do that, unless this other thing is also true. Those are slow to type and quick to say.

During the capture pass, whenever you catch yourself thinking "and if it fails here, you have to...", say it out loud immediately. Do not promise yourself you will add it later. Later is the thing that never happens.

4. The definition of done

What should be true when the procedure is complete? Which system shows what state? Who needs to be notified? A procedure without a completion check produces work that looks finished and is not. Again, prose, again, cheap to speak.

5. Everything around the SOP

Procedures do not live alone. There is the announcement to the team that the process changed, the note in the ticket saying which version of the procedure was followed, the review comments when someone else's draft comes to you, and the reply to the person who asks a question the SOP did not answer. That last one is worth watching: if you find yourself typing a long answer to a question, you have just written an SOP section. Dictate the answer properly, then paste it into the document.

Capturing an expert's process

The hardest SOPs to write are the ones for a process you do not personally run. The knowledge lives with a colleague who is busy, and the traditional approach is to interview them and type notes, which means you are typing at 40 words per minute while they talk at 140. You miss most of it and you interrupt constantly to catch up.

Meeting Mode on the Mac app is built for exactly this shape of problem. It captures the conversation with speaker detection and produces AI notes, and calendar meeting detection means a scheduled walkthrough can start capture without you remembering to. Sit with the person, ask them to run the process while narrating, and stop typing entirely. Your job during that session is to ask the follow-up questions a future reader would ask, which you cannot do while transcribing.

Two boundaries matter here. First, say out loud that you are capturing the session. Consent is not a formality and the norms in your organisation may be stricter than the law. Second, treat the output as raw material, not as a deliverable. A captured walkthrough is a transcript with the steps buried in it. It still needs the shape pass, and it still needs the expert to check it before anyone follows it.

Smart Vocabulary is what keeps you from quitting

Here is the pattern that causes people to abandon dictation for internal documentation after two days: general-purpose transcription has never heard of your internal tooling. Your ticketing system, your three-letter internal project codes, the name of the vendor portal, the abbreviation your finance team uses for the reconciliation file. Those come out wrong, every time, and correcting the same four words in every paragraph is genuinely more annoying than typing.

Smart Vocabulary is a personal dictionary with replacement rules. The right way to build it is not to sit down and imagine what you will need. It is to dictate normally for two days, notice which words you correct repeatedly, and add exactly those. For most people it converges at twenty to thirty entries and then stops needing attention.

For procedure writing specifically, the entries worth adding are:

That last point matters more than it sounds. Documentation is searched, not read. If the same system appears as three different spellings across your SOP library, search silently fails for two of them, and a procedure nobody can find is a procedure that does not exist.

Capturing on the floor with your phone

Plenty of procedures do not happen in front of a Mac. Warehouse receiving, equipment maintenance, a clinic intake process, a kitchen open or close, a site inspection. For those, the iPhone keyboard is the capture tool. It is a custom keyboard with a built-in mic button, so it works in whatever app you already use for notes, and you can dictate a step while standing in front of the thing you are describing.

Two features earn their keep here. Voice Edit lets you speak a change to text you already have, which is far less painful than placing a cursor precisely on a phone while wearing gloves or holding a clipboard. And two-way translation across 24 languages matters for the reasonably common case where the person who knows the process best is not most comfortable in the language the SOP is written in. Let them narrate the process in their own language and produce a first-draft translation, then have it reviewed by a human before it becomes the official document. For a procedure that people will follow literally, machine translation is a starting point and not a final answer.

What voice does not do here

Being honest about the boundaries saves you from expecting the wrong thing:

On privacy, since internal procedures often contain things you would rather not scatter: our servers store only operational pings. No audio and no transcript content is retained. Your history stays on your device. If you work under a confidentiality agreement or a compliance regime, read our policy yourself and check it against your obligations rather than taking a blog post's word for it. And remember the simpler exposure: anyone within earshot hears the procedure you are narrating.

Where the documents live

Because dictation types at the cursor, the tool you keep SOPs in does not change the method. It changes only the formatting friction. A few practical notes:

If your procedures are technical enough that they blur into product documentation, our post on dictation for technical writing goes deeper on the prose-versus-syntax boundary.

A realistic first week

Do not try to document everything. Pick the one procedure that gets explained most often by tapping someone on the shoulder. That is your highest-value target by definition, because the cost of it being undocumented is already being paid weekly.

Then add the corrections you kept making to Smart Vocabulary and start the next procedure. The second one goes noticeably faster, because the vocabulary is loaded and the two-pass rhythm is familiar.

Frequently asked questions

Is dictating an SOP actually faster than typing one?

For the prose parts, substantially. Speech runs three times faster than average typing, and an SOP is mostly explanation. The bigger effect is not raw speed though. It is that narrating during a live run produces a complete procedure, and writing from memory produces an incomplete one. Completeness is worth more than speed here.

Will the document sound like someone talking?

The raw transcript will. That is what the shape pass is for. Cutting spoken filler and tightening sentences is fast work compared to composing them from nothing. If anything, procedures written from speech tend to read more clearly than ones written from scratch, because you naturally explain a process to a person rather than describing it abstractly.

Can I dictate the whole thing on my phone?

You can capture the whole thing on your phone, which is the right approach for any process that does not happen at a desk. The shaping and formatting is much easier on a Mac. Capture wide on mobile, shape at the desk.

What about processes with a lot of numbers?

Speak the surrounding sentence and type the numbers. Do not compromise on this for financial, clinical, safety, or configuration procedures. A transcription error in a sentence is visible. A transcription error in a threshold is invisible until it causes harm.

Does it work with the tool we already use?

If the tool accepts typed text on a Mac, dictation works in it, because the text arrives at the cursor exactly as though it had been typed. There is no integration and nothing to install into the tool, which is also why it survives locked-down IT environments that block plugins and browser extensions.

The procedure you have been meaning to write

There is one specific document you have been putting off. You know which one. It is the process that only you know, the one you get interrupted about, the one that would take an afternoon to write properly and so has taken zero afternoons for two years.

The next time you run it, run it slowly and talk. You will have a complete transcript by the time you finish the task you were doing anyway, and a real procedure by the end of the week. Voice Keyboard Pro has a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year if you want it unmetered. Start with the one procedure that people keep asking you about.

Keep reading