How to write support SOPs your team will follow

Support SOPs often fail in one of two ways. Some are never written, so each agent handles a refund or an escalation in their own way. Others are written once, by one person, in one afternoon, and nobody opens them again. This guide is about the work around the document: which procedures to write first, how to get the real steps out of the people who do them, how to test a draft, and how to tell whether the team uses it.

Choose which SOPs to write first

You cannot write every procedure at once, and you do not need to. Score each repeated process on two questions, from 1 (low) to 3 (high): how often does it happen, and how much does a mistake cost? Multiply the two numbers and start at the top.

In this example the refund exception and the address change come first. Both happen often enough to matter, and a mistake costs money or a lost parcel. The password reset happens more often, but a mistake is cheap and easy to fix, so a short checklist is enough. The bug report from a large customer is rare but costly: it needs an SOP too, because the rare cases are the ones nobody remembers how to handle.

Get the real steps from the people who do the work

The person who knows the process is often not the person who writes the SOP. A team lead who writes from memory describes how the process should work. The agent who does it twenty times a week knows how it does work, including the tool that is slow, the field that is easy to miss and the exception that comes up every Friday.

1. Watch it done. Sit with an agent while they handle three or four real cases. Write down every click, every check and every place where they stop to think.
2. Mark the decisions. Each place where the agent stops to think is a decision. Ask what they look at to decide, and what they do in each case.
3. Ask what goes wrong. "When did this last go badly?" finds the steps that need a warning.
4. Collect the exceptions. Ask for the cases that do not fit. List them, and decide which ones the SOP covers and which ones go to a lead.

Paste those notes into the SOP generator to get a first draft in the usual sections. It marks missing details with a placeholder instead of guessing, which shows you the questions you still need to ask.

Write decisions as a table

Many support mistakes happen at a decision, not at a step. A paragraph of policy hides the decision. A small table shows it. Here is the decision at the center of a delivery address change:

Every cell is an action an agent can take without asking anyone. If a cell needs judgment, it is not finished: either decide the rule now, or write "ask the team lead" in it.

A complete example

This is the address change written as a short SOP. It fits on one screen, which is the right length for a task that agents do several times a day.

• Purpose: change a delivery address without losing or misdirecting the parcel.
• Scope: orders placed on the website. Marketplace orders follow the marketplace's own process.
• Before you start: access to the order system and the carrier portal.

1. Confirm the request comes from the email address on the order. If it does not, ask the customer to write from that address.
2. Open the order and check its status.
3. Find the status and the new country in the decision table, and do what the cell says.
4. Reply to the customer with what you changed, or why you could not, and the next step for them.
5. Add the tag "address-change" and a one-line note on the order.

• Escalation: if the parcel is high value or the customer reports that the order was not theirs, stop and pass it to the team lead.
• Owner and review: the support lead, every six months or when the carrier changes.

Note what the SOP leaves out: the policy reasons, the history of the process and the cases that happen once a year. Those belong in a linked page or with the team lead.

Test it with a cold read

Give the draft to someone who has never done the task, such as a new hire or a person from another team. Ask them to follow it on a real or test case while you watch, without helping. Write down every question they ask. Each question is a missing step, a missing decision or a name that does not match the screen. Fix those, and run the test again with someone else. The SOP is ready when the second person finishes without a question.

Check that the team uses it

• Link it where the task starts. A link in the help desk macro or the ticket form gets opened. A link in a wiki page that nobody visits does not.
• Review a few cases each month. Pick a small sample of tickets with the SOP's tag and check them against the steps. When agents skip a step, ask why before you correct them. Often the step is wrong.
• Make changes easy to suggest. Name one owner per SOP and give agents one place to send changes.

Keep internal steps out of customer content

An SOP mixes two kinds of information. Some of it is for customers: the return window, which countries you ship to, how long a change takes. Some of it is internal: how you check identity, the refund limit an agent can approve alone, the fraud signals. When you turn an SOP into a help article, copy only the first kind.

This matters even more for a chatbot. Paperlink AI answers only from the documents you upload and the website pages you import, so it will quote whatever you give it. Give it the customer-facing help article, not the internal SOP. The SOP stays with the team, and the article answers customers. When the policy changes, update both on the same day.

Signs an SOP is out of date

• Agents ask the same question in team chat that the SOP is supposed to answer.
• A button or page name in the steps no longer matches the tool.
• The review date has passed.
• An incident happened while someone followed the SOP correctly.

Any one of these is a reason to review the SOP that week. If you rewrite it from scratch, start from the SOP template and generator and the notes from a new round of watching the task done.