← The Operations Station ~ dish 05 of 10 · the operations station

Process Documentation Drafting

Someone runs a process. It gets done. The steps live in their head. When they leave or get promoted, those steps disappear. The station exists to observe the workflow and document it as you run it. The leverage is examples. You need SOPs in your house format and voice.

The job

A processor handles accounts receivable. They read the invoice. They match it to the PO. They check the budget. They approve payment. They generate the check. They file it. They send the reminder. Every step is procedural. Repeatable. The processor has never written it down. When they’re promoted, the next person spends three weeks re-learning the workflow.

The dish observes the workflow. It sees the invoice arrive. It watches the matching to the PO. The budget check. The approval. The check generation. It produces a structured SOP: title, overview, step-by-step, decision points, edge cases. The SOP is in the same format and voice as the three SOPs the team wrote by hand.

Plated well, this looks like: every process is documented the moment someone runs it. New team members onboard onto documented workflows instead of shadowing for weeks. Edge cases are called out. The process improves because it’s visible.

The recipe

All seven ingredients still apply. The leverage is Examples (Ingredient #4). The station needs to see three SOPs you wrote yourself, in your voice, in your format. That’s the training set. It learns the structure you use.

Training (Ingredient #1) is consistency. Titles are always “[Role]: [Process Name].” Overviews are always three sentences. Steps are numbered. Edge cases are marked with a warning. The station learns your house standard.

Context (Ingredient #2) is the second lever. The station needs to know what counts as a process. Invoice approval is a process. Hiring is a process. You defining the boundary tells the station what to document.

How to build it

  1. Identify one process to document. Something repeatable. Happens the same way every time. Accounts payable approval. Customer onboarding. New hire checklist. Not one-off projects. Repeatable workflows.

  2. Watch someone run it. Don’t interrupt. Let them work. The station is observing the steps in order. The decisions they make. The edge cases they handle.

  3. Write three SOPs by hand in your format. Take three processes someone runs regularly. Document them the way you want documentation to look. Title format. Section format. Style. Voice. This is your template.

  4. Define the SOP structure. Overview (three sentences). Prerequisites. Step-by-step (numbered). Decision points (if/then). Edge cases (marked with warning). Summary.

  5. Have the station draft the SOP while you observe the workflow. You’re watching. The station is documenting. It should match what you saw.

  6. Review the draft. Is the structure right. Are the steps accurate. Does the edge case handling match what you observed.

  7. Update the station’s training if needed. If the edge case wasn’t captured, show the station where to look for it. If the voice is off, provide a corrected version. The feedback sharpens the recipe.

  8. Publish the SOP. Now the process is documented. When someone new runs it, they read the SOP first. The processor is no longer a single point of knowledge.

What breaks it

  • Examples are too generic. You give the station three SOPs from a template library. They’re written in corporate voice. Your house voice is different. The drafted SOP doesn’t match.

  • The workflow is too complex. You try to document a process with fifteen decision points and five edge cases in one pass. The station captures part of it. You’re missing documentation for the tricky parts.

  • Examples are perfect. You wrote three SOPs without the messy reality. The actual workflow has variance. The processor sometimes skips a step. Sometimes they go back and redo it. The station trained on the ideal doesn’t see the real.

  • No feedback mechanism. The drafted SOP is missing an edge case. Someone points it out. The SOP never gets updated. The station doesn’t learn that this edge case matters.

When it’s working

By week one, the station has drafted an SOP. It’s eighty percent right. You’re adding the remaining twenty percent. By week two, the SOP is published and new team members are using it to onboard. By week three, you’ve documented three processes this way. By week four, whenever someone runs a workflow, the ops person can have the station draft the SOP. The process is documented as it happens. The institutional knowledge stops living in one person’s head.

The signal that the recipe is sharp: someone runs the process for the first time using the documented SOP and doesn’t need to ask questions because the steps are clear and the edge cases are called out.

Monday Move

Pick a process you run weekly. Do it once while the station watches. Have it draft the SOP. Compare it to how you’d have written it. Show the station the differences. Have it draft the next person’s workflow. That’s the test cycle.

Dish 5 of 10 on the Operations Station. Build-note leverage: Examples (Ingredient #4).