How to write SOPs an AI agent can actually follow

Most businesses run on knowledge that lives in people's heads. The senior support executive knows which customers get a goodwill refund. The operations lead knows which courier to avoid in monsoon season. None of it is written down properly, and it mostly works, until someone new joins or you want an AI agent to take on part of the job.

An AI agent is only as good as the instructions it works from. Give it a vague policy and it will make vague decisions. Give it clear rules, real examples and a list of exceptions, and it can handle routine work reliably and hand over the rest. The good news is that writing SOPs for an agent is mostly the same skill as writing them for a sharp new hire. It just has to be done more carefully.

Start with the job, not the policy document

Many companies already have a policy PDF somewhere. It is usually written for customers or auditors, not for the person doing the work. It says what the rule is, but not how to apply it on a busy Monday with a frustrated customer and an order stuck in transit.

So begin with one specific job the agent will do, such as handling return requests or answering order status questions. Then write down, step by step, what a good team member actually does today. Sit with the people who handle it well and ask them to talk through a few recent cases. You will quickly find steps that aren't in any document.

• What triggers the task: a new ticket, a WhatsApp message, a form, a status change.
• What information is needed before deciding anything, and where it lives.
• The decision itself, and the options available.
• What gets done in each system once the decision is made.
• What the customer or colleague is told, and in what tone.

Turn judgement into rules you can check

Phrases like "use your discretion" or "refund if reasonable" work for experienced people because they share context. An agent doesn't have that context, so the judgement has to be spelled out. The test is simple: could two different people read the rule and reach the same answer on the same case?

Instead of "offer a replacement for damaged items where appropriate", write something closer to this: if the customer reports damage within the return window and includes a photo, offer a replacement if the item is in stock, otherwise offer a refund to the original payment method. If there is no photo, ask for one before doing anything else.

Rules don't have to cover everything. They have to be clear about what they cover, and clear about what happens when a case falls outside them.

Show examples, including the awkward ones

Rules tell the agent what to do. Examples show it what good looks like. For each SOP, collect a handful of real cases from your inbox or CRM, remove personal details, and write down the right outcome and a good reply for each.

The most useful examples are not the easy ones. Include the customer who asks two things in one message, the order that was partly delivered, the request that arrives one day after the window closes, and the polite message that is actually a complaint. These edge cases are where agents, and new staff, tend to go wrong.

A good habit: whenever your team handles a case and thinks "that was a tricky one", save it. Over a few weeks you build the best training material you could ask for, drawn from your own business.

Write the exceptions and the hand-over points

Every SOP needs a clear section on what the agent should not handle. This protects your customers and your team, and it is what lets you trust the agent with the routine work. Typical exceptions include:

• Amounts above a set limit, which need a person to approve.
• Customers who are angry, mention legal action or ask for a manager.
• Anything involving health, safety or a possible fraud signal.
• Situations the rules don't cover, where the agent should ask rather than guess.
• VIP or wholesale accounts that your team prefers to handle personally.

For each hand-over, say who it goes to and what the agent should pass along. A good hand-over includes a short summary, what the customer wants, what has already been checked and what the agent recommends. Nobody should have to read a long thread to understand the situation.

Keep SOPs short, versioned and owned

Long documents get skimmed by people and are harder to test with an agent. Aim for one SOP per job, written in plain language, with rules, examples and exceptions in clearly separated sections. If a document is growing out of control, it is often two jobs pretending to be one.

Give every SOP an owner, usually the person who runs that process day to day, and keep a simple change history. When your returns policy changes before a sale or a new courier comes on board, the owner updates the SOP and the agent works from the new version. Your team should be reading the same document, so everyone stays aligned.

Test before you trust

Once an SOP is written, run it against real past cases before the agent goes live. Compare the agent's decisions and replies with what your best people would have done. Where they disagree, the problem is usually in the SOP rather than the agent: a missing rule, an ambiguous phrase or an exception nobody wrote down.

After launch, keep reviewing a sample of conversations for the first few weeks, and feed what you learn back into the document. SOPs written this way tend to improve the whole operation, not just the agent, because they make the way you work visible and easier to teach.

This is the part of our discovery work that clients often find most valuable. A typical first agent goes from discovery to production in about three to five weeks, depending on system access, and pilots start from ₹40,000, with the final price depending on the systems and work involved.

If your processes live mostly in people's heads and you'd like to see which ones an agent could take on, book a call with us. We'll help you pick the right first job and turn it into instructions that work.