What is an agent SOP?
An agent SOP is a written, step-by-step procedure that defines how a support agent, human or AI, must handle one specific request type. It fixes the order of checks, the conditions that gate each action, the action itself, and the record left behind. Anything the procedure does not authorise stays out of the agent's hands.
A refund SOP is the canonical shape: verify the order exists, confirm it falls inside the 30-day window, check that no prior refund was issued, refund to the original payment method, then post a note to the ticket. Five steps, each one gating the next.
How agent SOPs work
Every agent SOP resolves into four layers: a trigger, a set of preconditions, an ordered action sequence, and a record. The trigger is the classification step, deciding that this contact is a refund request and this procedure applies. Preconditions are the checks that must return true before anything irreversible happens, and they are the layer humans skip first under queue pressure.
The action sequence is where an AI agent reaches outside its own text. Tool calling turns a written step such as "refund to the original payment method" into a real call against the payment system, while AI guardrails hold the agent inside the authorised set, so a refund procedure cannot issue a credit it was never scoped to issue. Agents built on the ReAct agent pattern interleave a reasoning step with each call, checking what came back before moving to the next step.
The record closes the loop. The note posted to the ticket is what makes the procedure auditable weeks later, when someone asks why a customer was refunded twice.
Types of agent SOPs
Most support organisations run four kinds, and each one decays differently.
Transactional SOPs: Ordered procedures for actions with a system of record behind them, such as refunds, cancellations, address changes, and plan downgrades, which makes them the first candidates for automation.
Diagnostic SOPs: Branching procedures that narrow a reported symptom to a cause before prescribing a fix, common in hardware, connectivity, and billing disputes, where branch depth is the real maintenance cost.
Escalation SOPs: Rules for when the agent stops working a case and who receives it, including what context must travel with the handoff.
Compliance SOPs: Procedures that exist because a regulator, a card network, or a legal team demands a specific disclosure or record, which leaves them the least tolerance for improvisation.
Agent SOP vs runbook vs macro vs knowledge base article
Support teams file these four in the same folder and then wonder why nobody follows any of them. A runbook documents how an engineer restores a system that has broken. A macro inserts pre-written reply text and field updates into a ticket in one click. A knowledge base article explains a policy to whoever happens to read it. An agent SOP sits above all three: it decides which of them applies, in what sequence, and under what conditions the agent may act at all.
What it holds | Ownership | Who reads it | AI-retrievable | Choose it when | |
|---|---|---|---|---|---|
Agent SOP | Ordered steps, conditions, authorised actions | Support ops, named reviewer | Human and AI agents | Yes, written for execution | One request type must resolve identically every time |
Runbook | Recovery procedures for a system failure | Engineering or SRE | Engineers on call | Partly, context is internal | The thing that broke is infrastructure |
Macro | Saved reply text and ticket field updates | Team leads or individual agents | The agent clicking it | Only as canned text | The wording is the whole job |
Knowledge base article | Policy and explanation for a reader | Content or support team | Customers and agents | Yes, by design | Someone needs to understand a rule |
If the answer varies by who picks up the ticket, you need the agent SOP. If only the wording varies, a macro covers it. If the reader needs to understand a policy, the article does. Most teams need all four, each scoped tightly.
Why agent SOPs matter for customer experience
When no SOP exists for a request type, every agent writes one silently. Two customers with the same duplicate charge get different outcomes in the same hour, and the one who got less either escalates or leaves. Volume compounds it: the more agents you add, the more private variants of the procedure exist.
An AI agent raises the stakes because it is fluent. Given a gap in the procedure it produces a confident answer anyway, and a hallucination delivered in the tone of settled policy is harder for a customer to question than a human agent's visible hesitation.
The tradeoff is rigidity. A procedure written tightly enough to execute will refuse cases a good agent would have solved, so the exception path deserves as much design attention as the happy path.
How is agent SOP performance measured?
Three numbers describe a procedure in production. Adherence is the share of eligible contacts where every gating step actually ran in order, which is only measurable if each step writes a record. Completion is the share of contacts the procedure carried to resolution without a human taking over. Exception rate is how often the agent met a case the procedure never covered, and it is the most useful of the three because it names the next SOP to write.
Sampling gives you adherence honestly, and AI agent testing replays known cases against a revised procedure before it ships, catching a broken step earlier than a customer would.
Cost gives the numbers meaning: the U.S. Bureau of Labor Statistics puts median pay for customer service representatives at USD 42,830 a year, or USD 20.59 an hour in 2024 data, which prices a minute of handle time at roughly USD 0.34 in direct wages and a thirty-to-ninety-second adherence swing at USD 0.17 to USD 0.51 per contact.
How AI agents change agent SOPs
For a human agent an SOP was advisory, a reference consulted when memory failed, and it could tolerate a vague step because the reader quietly filled the gap. An AI agent executes the text as written, so every ambiguity becomes live behaviour. A step reading "use judgement on partial refunds" produces a different amount on every attempt.
That pushes SOP writing toward specification. Conditions acquire thresholds, actions name a system and a field, and the escape hatch gets an explicit trigger. Teams doing this well separate lookup from execution, the distinction drawn in retrieval versus structured execution: finding what the policy says is one capability, carrying five gated steps across three systems is another.
The consequence is speed of feedback. Procedure quality now shows up in production behaviour within hours, where it used to surface in a quarterly QA review.
How to write an agent SOP, step by step
Writing one is a five-step job, and the order matters more than the format.
Bound one request type. Pull real transcripts for a single contact reason and write down where they diverge. The divergence points are the steps.
List preconditions before actions. Every check that must pass goes above the first irreversible move, with the failure behaviour stated for each.
Name the system and the field. "Refund the customer" is unexecutable; "issue a refund against the original charge ID in the payment processor" is.
Define the exception trigger. State the exact condition that stops the procedure and hands the case to a person, with the context that travels along.
Test, then widen. Run it against sampled traffic, read the exceptions, and only then apply it to the full contact type.
What to look for in agent SOP tooling
Coverage comes first: can the tool hold conditional logic and multi-system actions, or does it flatten everything into prose an agent has to interpret. Integration surface is next, because a procedure that names a CRM field is worthless if the platform cannot read that field. Platforms differ sharply here, and FAQ and SOP ingestion is where existing documents either import cleanly or get rewritten from scratch.
Governance decides whether the procedure survives its author. Regulated buyers ask how a change is evidenced, so version history, approver identity, and a per-revision timestamp matter more than the editing experience. SOC 2 Type II and ISO 42001 come up by name in those conversations; the thing to test is whether the platform can show who changed step three, and when, on request.
The constraint teams underestimate is coupling. An SOP references fields and endpoints owned by other teams, so a renamed CRM field breaks a step silently and nobody learns about it until an agent stalls mid-procedure.
Agent SOPs and the knowledge base
An agent SOP and a knowledge base hold different halves of one answer. The knowledge base states what the refund policy is; the SOP states which checks run, in what order, and what the agent is permitted to do about it. Teams that publish the policy and skip the procedure end up with every agent inventing the sequence.
Retrieval binds the two together. AI grounding ties the agent's reply to the passage it actually retrieved, and the SOP decides whether that passage authorises the action about to be taken.
What does an agent SOP mean in plain terms?
SOP stands for standard operating procedure, and the full form is worth keeping in mind: an agent SOP is that manufacturing idea narrowed to a single kind of customer request. Think of it as the pre-flight checklist for a support case. The pilot already knows how to fly; the checklist exists so the same handful of things get confirmed on the calm day and the terrible one.
Without it, the agent of four years handles a duplicate charge one way and the agent in week two handles it another, and both believe they did right by the customer. The company now has two policies it never wrote down and cannot defend either.
The tradeoff is real. A checklist covering every case grows too long to follow, and a short one leaves judgement calls in the open. Most teams cover the top request types and accept improvisation on the tail.
Common agent SOP mistakes
Writing from the process diagram is the first failure. Procedures drafted from how the flow was designed miss the branches that actually consume agent time, because those branches only appear in transcripts of cases that went wrong.
Leaving steps unbounded is the second. A step containing "as appropriate" or "use judgement" delegates the decision back to the reader, which was survivable when the reader was a person with context and is not survivable when the reader executes literally.
Letting procedures duplicate is the third. Two SOPs covering overlapping request types will eventually contradict each other, and the agent, human or model, follows whichever one surfaced first.
Treating escalation as a dumping ground is the fourth. When the exception path has no entry criteria, it absorbs every case the author found hard to think about, and the automation rate quietly collapses toward zero.
What is an agent SOP in customer support?
An agent SOP in customer support is a written procedure covering one request type: the checks that must pass, the actions permitted, the order they run in, and the record left behind. It applies to human agents and AI agents equally, which is why the wording has to be precise enough to execute.
What is the difference between an agent SOP and a macro?
An agent SOP defines the entire procedure for a request type, including the checks that gate each action and the systems touched. A macro is a saved block of reply text and field updates. A macro can be one step inside an SOP; it cannot decide whether the refund should be issued at all.
Agent SOP vs runbook: what is the difference?
An agent SOP and a runbook are both ordered procedures aimed at different audiences. The SOP covers a customer request type and is executed by support agents, human or AI. A runbook covers a system failure and is executed by engineers on call. Escalation SOPs often end exactly where a runbook begins.
How do you write an agent SOP an AI agent can follow?
Writing an agent SOP for AI execution means removing every step a person would have quietly interpreted. Bound the request type, list preconditions above actions, name the exact system and field for each action, set an explicit exception trigger, and test the procedure against real transcripts before it takes live traffic.
What does SOP stand for?
SOP stands for standard operating procedure, a term borrowed from manufacturing and aviation. In support, an agent SOP narrows that idea to one customer request type. The full form signals the intent behind it: a procedure that produces the same outcome regardless of who, or what, happens to be running it.
How many agent SOPs should a support team have?
Agent SOPs should cover the request types carrying real volume or real risk, which is usually a shorter list than teams expect. Tag a quarter of tickets by contact reason, rank them, and write procedures down the ranking until the tail becomes one-off cases better served by judgement and escalation.