Start with the work as it happens
A standard operating procedure, or SOP, should help someone complete a repeatable task without having to guess what comes next. Before opening an AI tool or choosing a template, define the workflow’s boundaries. What starts the task? What outcome marks it as complete? Who performs it, and who receives the result? A focused scope, such as “prepare and send a new client’s welcome materials,” is easier to document than “manage clients.”
Ask the people who do the work to walk through a recent, ordinary example. Observe the task if practical, or have them describe each handoff while looking at the tools they use. Capture inputs, decisions, approvals, outputs, and places where work commonly pauses. Note variations separately: the usual path should not disappear beneath a list of exceptions. If team members describe different approaches, record the difference rather than silently choosing one.
Gather existing checklists, forms, templates, and instructions, but treat them as evidence to check against current practice. A document may describe the intended process without reflecting how the team handles a missing input or a rejected approval. Before sharing material with an AI tool, remove information it does not need, especially personal details, credentials, and confidential customer content.
Turn observations into a clear process map
Write a rough sequence before drafting polished instructions. For each step, identify the person responsible, the action they take, the information or tool they need, and the result that allows the next step to begin. Mark decision points explicitly: if an intake form is incomplete, does the owner request clarification, return the request, or proceed with a partial record? “Handle issues as needed” is too vague to help a new team member.
Separate actions from standards. “Review the request” is an action; the criteria for accepting or returning it are the standard that makes the action repeatable. If the team has not agreed on a criterion, label it as an open question. An SOP can document an established workflow, but drafting one does not resolve an unsettled policy.
Use AI to structure the first draft, not invent the process
An AI assistant can help turn rough notes into an organized draft. Give it the workflow’s scope, the verified sequence, role names, decision points, and intended reader. Ask for a consistent format: purpose, trigger, prerequisites, numbered actions, exception paths, completion check, and document owner. Tell it to preserve uncertainties as questions rather than fill gaps with plausible-sounding steps.
A useful request might be: “Draft an SOP for a new team member using only the process notes below. Use plain language and assign an owner to each step. Put missing information and conflicting instructions in a separate ‘Questions to resolve’ section. Do not add tools, approval rules, or deadlines that are not in the notes.” You can then ask the assistant to shorten repetitive wording or identify steps that lack an input or an expected output.
Treat the result as an editing aid, not an authoritative record. AI may reorder steps incorrectly, merge distinct roles, or present an inferred rule as if the team approved it. Compare every instruction with the process map and source material. Keep a visible list of unresolved questions for the people who own the workflow.
Test the SOP with the people who will use it
Have an experienced team member check whether the draft matches current practice. Then ask someone less familiar with the workflow to follow it in a safe test scenario, or to explain what they would do at each step. Watch for moments when they need to ask a question, find an undocumented file, or guess who has authority to decide. Those moments show where the SOP needs more detail.
Check especially for handoffs and exceptions. Does the receiving person know where to find the completed work? Can the reader tell what to do when an input is missing or a tool is unavailable? If a rare situation requires judgment, say who should make the decision rather than trying to script every possibility. Revise the document after the test and get approval from the workflow owner before treating it as the team’s standard.
Make the procedure easy to maintain
Publish the SOP where the team already looks for operational guidance, with a clear title and a named owner. Include links or references to required templates and related procedures when your publishing system supports them. Avoid copying long instructions into several documents; duplicated steps can drift apart when one version changes.
Set a review trigger as well as a regular review interval. A changed tool, role, approval rule, or recurring point of confusion should prompt an update. Invite users to flag unclear steps, and record meaningful changes so readers know what was revised. The goal is not a perfect document on day one. It is a reliable guide that remains close to the work the team actually performs.
