The SOP Builder: Turn Finished Work Into a Process Your Team Can Repeat

Most small businesses do not have a documentation problem because nobody cares about process. They have a documentation problem because documentation feels like a separate job.

The work gets done first. A report is delivered, a customer issue is resolved, a new hire is onboarded, a monthly checklist is finished, or a client packet goes out the door. Then everyone moves on. The person who knows the process keeps the details in their head, in a few old emails, in a spreadsheet tab, in a script nobody else opens, or in a folder full of files with names that made sense at the time.

That works until the process has to be repeated by someone new, covered during vacation, audited, improved, or delegated.

A useful Codex workflow is not simply, "write an SOP." The better version starts with real evidence from the work that already happened. Codex can inspect the folder, scripts, exported files, notes, screenshots, and related messages that were part of the completed workflow, then draft an SOP that reflects reality instead of an idealized version nobody follows.

That difference matters. A generic SOP is usually aspirational. An evidence-based SOP captures how the work actually gets done, where judgment is required, what can go wrong, and where a person still needs to approve the next step.

Start With A Finished Workflow, Not A Blank Page

The best source material is a completed piece of work that the business already trusts.

For example, imagine a monthly reporting process. The team downloads an export, cleans a few columns, checks totals against last month, updates a dashboard, writes a short summary, and sends it to a stakeholder after approval. The process may include a CSV export, a spreadsheet, a small script, a finished dashboard, a note explaining one adjustment, and a sent email.

That is enough raw material for a practical first draft.

A good prompt would be specific about the audience and the expected artifact:

Turn the completed monthly reporting workflow in this folder into a practical SOP for a new operations assistant. Inspect the source files, scripts, generated dashboard, and related notes. Include prerequisites, step-by-step instructions, common failure cases, quality checks, and when to escalate. Add a short "why this matters" section at the top.

The important part is not the wording. It is the operating pattern. Codex is asked to inspect the work environment, reconstruct the process, and produce a useful artifact. That is stronger than asking it to invent documentation from memory.

What Codex Should Inspect

The inputs should match the real workflow. For an SOP builder, that might include:

A project folder with source files, exports, templates, and final deliverables.

Scripts or commands that were run to produce the output.

A README, checklist, meeting note, or internal memo that explains context.

Emails or support messages that show the request, exception, approval, or handoff.

Screenshots of the final dashboard, customer portal state, form result, or completed setup.

A previous version of the SOP, if one exists, even if it is stale.

Codex does not need unlimited access. In fact, the workflow is usually better when access is scoped. Give it the folder, the relevant notes, and the apps or files needed for the task. Keep unrelated customer records, payroll files, legal documents, and private data out of scope unless the SOP truly requires them.

The output should also be structured. A strong SOP draft should include purpose, owner, prerequisites, tools needed, inputs, step-by-step instructions, decision points, quality checks, failure cases, escalation rules, and expected outputs.

The Quality Check Is The Real Value

The first draft is not the finish line. The draft should be reviewed against the actual work.

A useful review pass asks questions like these:

Does the SOP include every input someone needs before starting?

Does it distinguish mechanical steps from judgment calls?

Does it name the places where a human must approve, verify, or escalate?

Does it explain what "done" looks like?

Does it include common failure cases and how to recover from them?

Does it protect sensitive data and customer context?

Does it match the tools and file paths the team actually uses?

These questions matter because a bad SOP can create false confidence. If the document hides judgment, skips an approval gate, or assumes context that only one person has, the process is not ready to delegate.

That is where the human approval gate belongs. Codex can draft, organize, compare, and flag gaps. A person who understands the work should approve the final process before it becomes the team reference.

A Practical SOP Shape

For most business teams, the SOP should be plain and usable. It does not need to read like a compliance manual unless the process requires that level of formality.

A good structure looks like this:

Why this matters: one short explanation of the business outcome the process protects.

When to run it: the trigger, schedule, or event that starts the work.

Who owns it: the role responsible for completing the process and the role responsible for approval.

Inputs needed: files, systems, credentials, customer details, templates, or prior outputs.

Steps: numbered instructions with enough detail for a trained person to follow.

Decision points: places where the operator must choose a path, apply judgment, or ask for help.

Quality checks: totals to reconcile, screenshots to confirm, fields to review, or customer-facing details to verify.

Common failures: missing source file, stale export, invalid row, broken login, failed script, mismatched totals, unclear customer request, or unexpected result.

Escalation rules: who to contact, what evidence to include, and when to stop rather than guess.

Expected output: the final file, sent message, updated record, completed dashboard, or handoff note.

That structure turns documentation into an operating asset. It helps a new person run the process, helps a manager review the work, and helps the business notice which parts are ready for automation later.

Where The Human Stays In The Loop

An SOP builder should not quietly turn everything into automation.

Some steps should stay human because they involve risk, judgment, or accountability. Examples include approving a customer-facing email, interpreting an unusual financial variance, deciding whether a support issue needs escalation, confirming that a legal or compliance requirement applies, or approving a final report before it is sent.

The SOP should name those gates clearly.

For example:

Do not send the stakeholder email until the manager approves the summary.

Stop if the total revenue differs from the accounting export by more than 1 percent.

Escalate if customer data appears in the wrong account folder.

Ask the owner before changing the template or adding a new metric.

These gates make the process safer. They also make future automation easier, because the boundaries are explicit. Codex can later run the mechanical checks and prepare the draft, while the business keeps approval where it belongs.

From SOP To Skill

Once a team trusts the SOP, the next step is to make it reusable.

OpenAI's Codex skills documentation describes skills as task-specific packages with instructions, resources, and optional scripts that help Codex follow a workflow reliably: https://developers.openai.com/codex/skills. That maps naturally to an SOP. The final SOP can become the instruction layer. Supporting templates, examples, checklists, screenshots, or helper scripts can live alongside it.

That does not mean every SOP should become a skill immediately. The better sequence is:

Run the work manually once.

Use Codex to draft the SOP from the real artifacts.

Have the process owner review and correct it.

Run the process again using the SOP.

Identify repeatable checks, scripts, and templates.

Package those repeatable pieces into a skill when the workflow is stable.

This progression keeps the business from automating a process it does not yet understand. It also keeps Codex useful in the middle stage, where the work is repeatable but still needs human judgment.

From Skill To Automation

Some SOPs eventually become scheduled checks or recurring operating routines.

OpenAI's Codex automations documentation says automations can run recurring tasks in the background, report findings to the inbox, and combine with skills for more complex tasks: https://developers.openai.com/codex/app/automations. That is a good fit for processes like weekly client health checks, monthly reporting prep, daily exception review, content QA, or recurring data cleanup.

The key is to automate the right part.

A monthly reporting automation might check whether the source file is fresh, validate required tabs, run the cleanup script, generate the draft dashboard, and prepare a summary. It should still stop for approval before sending the report if the business depends on that judgment.

A customer support escalation automation might review new tagged issues, group likely causes, and draft a handoff memo. It should still let a human decide how to respond to a sensitive customer.

The SOP becomes the map. The skill becomes the repeatable method. The automation becomes the scheduled execution for the pieces that are safe to run without someone typing the same prompt every time.

A Simple First Implementation

Choose one process that has already happened in the last two weeks. Do not start with the hardest, most sensitive workflow. Pick something useful but contained: a monthly report, a lead intake checklist, a customer onboarding packet, a social publishing routine, or a support escalation process.

Collect the source material into one folder. Include the final output, the input files, any scripts or templates, and a short note explaining the business purpose. Remove anything private that the SOP does not need.

Then ask Codex for a draft SOP with a clear audience. For example, write it for a new operations assistant, a project manager, a client success coordinator, or the business owner covering the process while someone is out.

Review the draft with the person who currently owns the work. Correct the steps. Add the real failure cases. Mark the approval gates. Remove anything that sounds plausible but does not match reality.

Then use the SOP the next time the process runs. That second run is where the documentation becomes real. If the SOP helps someone complete the process with fewer questions, it is working. If it creates confusion, revise it before turning it into a skill or automation.

The goal is not documentation for its own sake. The goal is to make work transferable, reviewable, and easier to improve.

Leaf Lane's view is that this is where practical AI support becomes useful for small teams. It does not replace the person who understands the business. It helps turn scattered work into a process the business can run, review, and eventually improve with confidence.

Useful source links:

OpenAI Codex Skills: https://developers.openai.com/codex/skills

OpenAI Codex Automations: https://developers.openai.com/codex/app/automations