Open the next pricing email with a spreadsheet attached.
The short answer
Put one action on each line. Name the screen and the field. State what success looks like. Turn every judgment call into a rule with a number. Route every exception. Mark where a person decides. Cut the history, the tips and "use your judgment."
- One action per line
- Name the field
- Expected result
- Rule with a threshold
- Route exceptions
- Mark human review
Why human SOPs fail agents
Binders are written for people who already know the job. "Update pricing when the customer sends new numbers" works for someone with three years of context. They fill every gap from memory without noticing.
An agent has no memory to fill it from. Every gap becomes a guess, or a failed run.
Six passes from binder to agent-ready
Work through the SOP six times, one job per pass.
- List inputs and outputs. What arrives, from where, in what form. What must exist when the job is done.
- Split into one-action lines. "Open the order, check the price and update it" is three lines.
- Use the screen's names. The app, the screen and the field label as displayed, not the team's nickname.
- State the expected result. What the screen shows when the step worked: a record number, a status, a message.
- Turn judgment into rules or tables. "Big changes" becomes a percentage. "Our usual customers" becomes a list someone maintains.
- Label each line. Action, Decision or Review. Decisions carry their rule. Reviews name who decides.
Before and after
A typical binder entry for customer price updates: "When a customer sends updated pricing, update their price list in the ERP. Check big changes with sales. Watch the units." Every sentence hides a decision.
The agent-ready version says exactly what to do:
Skip backdated prices and unknown part numbers to review, with the reason.
Convert units with the conversion table; no match goes to review.
Changes over 5% go to the account's sales owner.
Enter approved prices, read them back, reply to the customer.
"Watch the units" became a table lookup. "Check big changes" became a number and a named reviewer. No code, just decisions someone had been making silently.
Walk the exceptions
Most exceptions fall into five buckets. Walk the SOP once per bucket and write down what happens.
| Bucket | Examples | Usual handling |
|---|---|---|
| Input | Missing attachment, unreadable scan, duplicate | Review, or ask the sender for a fix |
| Data | Unknown ID, value out of range, documents disagree | Review with the reason |
| Policy | Over an approval limit, new vendor | Named approver reviews |
| System | Session expired, record locked, save failed | Check what saved, retry once, then alert |
| Timing | Waiting on a third party, period closed | Hold with a follow-up date |
What to leave out
None of these lines get skipped, so each extra one is a risk.
One thing must go in: the exceptions everyone "just knows." Unwritten, they become failed runs.
- History and rationale (keep it in a separate reference doc)
- "As appropriate," "if needed," "use your judgment"
- Screen coordinates (name controls by their labels)
- Passwords, codes and personal workarounds
- Speed tips and keyboard shortcuts
Test it on a stranger
Hand the draft to someone who has never done the job and watch where they stop. Every stop is a missing line. When a screen, threshold or table changes, update the SOP and rerun your test cases. Testing Before Production →
How the Studio uses it
Bring your SOP to LaunchAI Studio, or skip it and just talk and show your screen. The Studio asks only the questions that change what the agent does, then performs each step live so you can approve it. Product →
Questions
How detailed should it be?
One action per line, with the expected result. If two readers would click different buttons, the line is not finished.
Rules in the SOP or in a table?
Logic in the SOP, changing values in tables. "Send big changes to the account owner" is a rule. The threshold and the owner list live in a table a manager can edit.
Who should write it?
The person who does the work today. For processes that span several people, write it as a small team.
Keep learning
- Which Workflow First Start with a workflow that is frequent, slow by hand, low in variation, spread across a few systems, cheap to get wrong and rarely off the happy path. Read the guide
- ROI of AI Agents ROI is the cost of the hours an agent gives back, minus the cost of the exceptions, reviews, upkeep and oversight it creates, minus software and model costs, set against one-time build and parallel-run costs. Read the guide
- Human in the Loop Put a person where a wrong action is expensive and hard to undo, and where the agent's evidence is weak. Read the guide
No prompts. No babysitting. No Integrations.