The SOP an AI agent can follow

By Luba Inz ·

An SOP is ready for AI when it names the trigger, each decision point, the limit on each decision and who takes the exception. Most SOPs I open at owner-led companies name none of those.

They're checklists. Open the ticket. Check the order. Reply to the customer. Close the ticket. A new hire could do each step on day one. None of those steps asks them to decide anything.

The decisions are the work. Is this refund fair? Can this order ship before the payment clears? A checklist skips those questions because the person who wrote it makes the calls without thinking. Usually the owner.

That's where most AI pilots I see get stuck. The instructions stop where the judgment starts. If the work can't go to a good operator without explaining it every time, it can't go to AI either.

The seven parts

An SOP an agent can follow has seven parts. Every one belongs on the page.

  1. Trigger. The event that starts the process. "A customer asks for a refund" is a trigger. "Handle refunds" is a wish.
  2. Inputs. What the person or agent needs before acting: the order, payment record, customer history and policy.
  3. Decision points. Every place the work can go two ways, written as a question with a yes path and a no path.
  4. Authority limit. How far each decision can go without asking anyone. A dollar amount, a count or a number of days.
  5. Escalation. What happens past the limit, and which role gets it. A role, not "management."
  6. Owner. One role that answers for the process and fixes it when it breaks. Not a team.
  7. Measure. One number that shows each week whether the process worked.

The limit is what lets an agent act

SOPs that mention decisions often stop at "use judgment" or "check with your manager." A person can walk over and ask. An agent can't. Tell it "use judgment" and it will guess, and it will sound very confident doing that. Or it will ask every time, and nothing gets automated.

The authority limit settles it. Under the line, the agent acts. Over it, the agent stops and a person decides. Every agent runs until it hits a gate a person still owns. The limit shows where that gate is.

A new customer service rep gets the same kind of guidance. Nobody hands them a refund policy that says "be reasonable." They get a number: up to this, go ahead. Past it, ask the lead.

A refund request, written out

This is an illustration. The numbers are made up. Every company sets its own.

  • Trigger: a customer asks for a refund by email or through the support form.
  • Inputs: the order, payment, delivery status and the customer's refunds over the last 12 months.
  • Decision point 1: is the request inside the 30-day return window? No goes to escalation.
  • Decision point 2: is this the customer's first refund this year? No goes to escalation.
  • Authority limit: up to $200, the agent approves and issues the refund, then replies to the customer.
  • Escalation: over $200, outside the window or a repeat request goes to the customer service lead with the order and history attached. The lead decides within one business day.
  • Owner: the customer service lead.
  • Measure: refund dollars as a share of weekly sales. If it climbs, the lead looks at the limit.

The business owner doesn't appear in that SOP. The lead takes the exceptions, and the lead has a limit too.

Start where the money is

Don't write SOPs for everything at once. Start with the five processes that touch cash or customers. At most owner-led companies, that means some version of quoting, invoicing, collections, refunds and complaints. A wrong call there costs money. That's where the owner gets pulled in most.

Collections shows it well. In one engagement, $1.2M of $1.4M in overdue receivables was collected in three months once one person owned receivables.

For each process, ask three questions. Could someone new run it from what's written down today? Is one named person allowed to decide the exceptions? Does one trusted number show every week whether it worked? Every no points to the next thing to write.

In SCOPE™ by Efficiency Sprint, this is Codify: make the recipe clear. It comes before Engine, where AI acts within guardrails. The guardrails are the limits you wrote down.

Efficiency Sprint makes companies operationally ready for AI. Most of that work is finding decisions nobody wrote down and giving each one an owner and a limit.

Write down who decides, and up to what amount. Until that's on paper, the agent will wait for the owner like everyone else.

Luba Inz is the founder of Efficiency Sprint, which makes companies operationally ready for AI through consulting and the EfficiOS subscription.