Agency SOPs: How to write and test them (free template)

An agency SOP (standard operating procedure) is a short, written procedure for one recurring task, such as onboarding a client, sending the monthly report or handling a scope change. It names what triggers the task, who owns it, the steps in order, what "done" looks like, and what to do when something goes wrong. Its job is to let someone who has never done the task do it correctly without asking the person who usually does.

This guide is about writing one SOP well: how to design the procedure, a filled example you can adapt, a blank template to copy, how to test it before it goes live, and how to version it so it stays accurate. Collecting SOPs into a full operations manual is a separate job, covered in the agency operations manual guide.

In short:

• Write SOPs for tasks that recur, are done by more than one person, and are costly to get wrong.
• A usable SOP fits on one screen. Link templates and recordings instead of pasting them in.
• Test every SOP by having someone who did not write it run it while you watch silently.
• Give each SOP a role-based owner, a version number, a change log and a review date.

Written procedures measurably cut errors in repeat work. When eight hospitals introduced a 19-item surgical checklist, the complication rate fell from 11.0% to 7.0% of patients and deaths from 1.5% to 0.8% (Haynes et al., New England Journal of Medicine, 2009).

SOP vs checklist, playbook and operations manual

Agencies often use these words interchangeably. They are different documents, and mixing them up is why many SOPs end up as long essays nobody follows.

A good rule: if the reader has to make a judgment call, it is a playbook. If they follow steps in order, it is an SOP. If they are checking work already done, it is a checklist.

What SOPs should an agency write first?

Do not try to document everything at once. Most SOP projects stall because the list is too long. Score your recurring tasks instead, and write the top five.

Score each task from 1 to 3 on three questions:

1. Frequency. How often does it happen? (1 = a few times a year, 3 = weekly or more)
2. Cost of error. What happens when it goes wrong? (1 = minor rework, 3 = lost money, a missed deadline or an upset client)
3. Spread. How many people do it, or will need to? (1 = one specialist, 3 = several people or every new hire)

Multiply the three scores and write SOPs for the highest totals first.

The tasks that usually score highest in client-service agencies:

Scope changes are worth an early slot: PMI's 2018 Pulse of the Profession found that 52% of projects completed in the previous 12 months experienced scope creep or uncontrolled scope changes, up from 43% five years earlier.

Your scores may differ. A paid media agency may rank campaign launch QA above status reporting; a web agency may put site launch first. Use the scoring, not the list.

The eight parts of an SOP that gets used

A usable SOP is short and predictable. Every SOP in your agency should have the same eight fields in the same order, so readers know where to look.

1. Title. Specific and searchable: "New client intake," not "Onboarding stuff."
2. Trigger. The event that starts the procedure: "When the contract is countersigned and the deposit invoice is paid." Triggers answer "when am I supposed to do this?"
3. Owner. A role, not a person ("Operations manager," not "Sara"), so ownership survives turnover. The owner keeps the SOP accurate.
4. Inputs. What must exist before you start: signed contract, primary contact, project number. Listing inputs stops people starting a task they cannot finish.
5. Steps. Numbered, one action per step, starting with a verb, naming the exact tool and template.
6. Done when. A short checklist of observable results: "Portal invite sent," "Kickoff on the calendar."
7. Exceptions. The two or three things that most often go wrong, and who to escalate to.
8. Version and change log. Version number, last review date, next review date, and one line per change.

Example: a filled client intake SOP

Here is the structure applied to a common agency procedure. Adjust the tools, templates and timings to match how your agency works. It is about 300 words.

# SOP: New client intake

Version: 2.1
Owner: Operations manager
Approver: Head of client services
Last reviewed: 2026-09-15 | Next review: 2026-12-15

## Trigger
Contract countersigned AND deposit invoice marked paid.

## Inputs
- Signed contract saved in the client folder
- Deposit invoice status = Paid
- Primary client contact: name, email, role
- Account lead assigned (named in the contract handover note)

## Steps
1. Create the client record in the client portal. Add the primary contact and tag the service line.
2. Create the project from project template PT-01. Set the start date to 5 business days from today.
3. Send the portal invite from the portal (not from personal email).
4. Send welcome email template WE-01. Attach the kickoff prep questionnaire.
5. Book the kickoff call within 5 business days. Use calendar template KO-01 so the agenda is included.
6. Write the internal kickoff brief (template KB-01) and post it in the project channel.
7. Add the client to the monthly reporting list.
8. Set the first invoice date for the next billing cycle.

## Done when
- [ ] Client record and contact exist in the portal
- [ ] Project created from PT-01 and assigned
- [ ] Portal invite and welcome email sent
- [ ] Kickoff booked with agenda
- [ ] Kickoff brief posted
- [ ] Client on reporting list and billing schedule

## Exceptions
- Deposit unpaid after 5 business days: tell the account lead. Do not start work.
- Client cannot attend a kickoff within 10 business days: escalate to the head of client services.
- Brand assets missing at kickoff: log what is missing and agree a date. Do not start design work.

## Change log
- 2.1 (2026-09-15): Added step 8 after two clients were invoiced late.
- 2.0 (2026-06-02): Moved client records from the CRM to the portal.
- 1.0 (2026-02-10): First version.

Notice what is not in it: no explanation of why onboarding matters, no screenshots, no pasted email text. The email copy lives in template WE-01. If the email changes, the SOP does not.

Blank SOP template (copy and edit)

Copy this into your documentation tool and fill in the brackets. Keep the headings even if a section is short; consistency is what makes SOPs quick to scan.

# SOP: [Task name]

Version: [1.0]
Owner: [Role responsible for keeping this accurate]
Approver: [Role that signs off on changes]
Last reviewed: [YYYY-MM-DD] | Next review: [YYYY-MM-DD]

## Trigger
[The event that starts this procedure]

## Inputs
- [What must exist or be true before you start]
- [ ]

## Steps
1. [Verb first. One action. Name the tool and template.]
2. [If X, do Y. Otherwise go to step N.]
3. [ ]

## Done when
- [ ] [Observable result]
- [ ] [Observable result]

## Exceptions
- [What commonly goes wrong]: [what to do, who to tell]
- [ ]

## Related
- Templates: [links]
- Upstream SOP: [link] | Downstream SOP: [link]
- Walkthrough video: [link, optional]

## Change log
- [1.0] ([YYYY-MM-DD]): First version. Tested by [role].

How to design the procedure before you write it

Most bad SOPs describe how the task should work. Good ones describe how it actually works, then fix it. Design comes before writing.

Capture the real process

Watch or record the person who does the task best while they do it for real. A screen recording with narration is enough. Note every tool they open, every decision they make, and every time they ask someone else for something.

Find the decisions and handoffs

Mark the points where the task branches ("if the client is on a retainer...") and the points where work passes to another person. Handoffs are where tasks get dropped, so each one needs a named next owner and a clear signal that it has happened.

Remove steps before you document them

Ask of each step: does anyone use the output? Can a template, form or automation do it? Documenting a pointless step makes it permanent.

Write the steps

• One action per step, starting with a verb: "Send," "Create," "Book."
• Name the exact tool, folder and template: "Send welcome email WE-01," not "send the welcome email."
• Write decisions as conditions: "If the deposit is unpaid after 5 business days, tell the account lead."
• Write for someone who joined yesterday. Senior people skip steps "everyone knows"; new hires do not know them.
• Link long content (email copy, screenshots, how to use a tool) instead of pasting it.

How to test an SOP before it goes live

An untested SOP is a draft. The author always knows the unwritten steps, so the author cannot test it.

1. Cold run. Give the SOP to someone who has not done the task (ideally the newest person on the team). They run it on real or realistic work.
2. Watch silently. Sit with them or watch a recording. Do not help. Write down every pause, question and wrong turn.
3. Fix the gaps. Every question they asked is a missing or unclear step. Every wrong turn is an ambiguous instruction.
4. Test the exceptions. Walk through each exception scenario on paper: does the SOP say what to do and who to tell?
5. Second run. Have a different person run the revised version. If they finish without asking anything, publish it as version 1.0.

Keep a short test log so you know who validated each version:

The rows above are an illustration of the format, not data from a real agency.

SOP version control: keeping procedures current

SOPs go stale quietly. A tool changes, a template moves, a step gets skipped because it no longer matters, and nobody updates the document. Then the team stops trusting all of them. Version control is how you prevent that.

Number versions

Use a simple two-part number. A minor change (1.0 to 1.1) fixes wording or a link without changing what people do. A major change (1.1 to 2.0) changes steps, owners or tools, and should be announced to everyone who runs the SOP.

Keep one source of truth

Each SOP lives in one place. Never paste copies into project templates or onboarding docs; link to it. When you replace a version, archive the old one in a separate folder so it does not show up in search.

Log every change

One line per change: version, date, what changed, and why. The "why" is what helps the next owner understand the step and not remove it by accident.

Review on a schedule and on triggers

• Scheduled: the owner reviews each SOP at a set interval. Quarterly works for SOPs that touch clients or money; twice a year is enough for stable internal tasks.
• Triggered: review immediately when a tool changes, when an incident or client complaint involved the task, or when someone asks the same question about it twice.

The review asks three questions: Is this still what we do? Has any tool, template or role it mentions changed? Did anything go wrong last period that the SOP should have prevented?

Retire what is no longer used

Once a year, archive SOPs for services you no longer sell, tools you no longer use and tasks that are now automated. Outdated SOPs confuse new hires and lower trust in the current ones.

Can ChatGPT or other AI tools write SOPs?

AI tools are good at drafting an SOP from raw material, and poor at knowing your process. A workable method:

1. Record someone doing the task and get a transcript (most meeting and screen-recording tools produce one).
2. Ask the AI tool to turn the transcript into the eight-part template above, with numbered single-action steps.
3. Edit the draft against what actually happens: tool names, template codes, timings, owners.
4. Run the cold-run test. AI drafts tend to sound complete while missing the decisions and handoffs, which the test catches.

Do not paste client data or contracts into an AI tool unless your agency's AI policy and the client contract allow it.

Where to store agency SOPs

The best tool is the one your team already opens every day. Pick based on size and how much structure you need.

Whatever you choose, link SOPs from the place the work starts: project templates, the onboarding checklist, the team wiki home page. An SOP that takes three clicks to find will not be used. The knowledge management guide covers how SOPs fit with client playbooks, brand libraries and other agency documentation.

How to tell whether your SOPs are working

The number of SOPs you have is not a useful measure. Measure what they are meant to change, and take a baseline before you start.

• Repeat questions. For two weeks, have your operations lead or most-asked senior person tally the "how do I..." questions they get. Repeat after SOPs launch.
• Errors on documented tasks. Count late invoices, missed kickoff steps or QA misses per month.
• Time to independence for new hires. How many weeks until a new hire runs the task without help?
• Client onboarding cycle time. Days from signed contract to kickoff call.
• Adherence. Spot-check a few completed tasks a month against the "done when" list.

If a metric does not move after two months, the SOP is either not being used or not solving the real problem. Ask the people who run it which.

Common SOP mistakes

• Documenting the ideal process. If the SOP does not match reality, people ignore it and do what they always did.
• Too long. Anything over one screen usually needs splitting or needs its reference material moved to linked templates.
• No owner or review date. An SOP without an owner is accurate only until the next tool change.
• Skipping the test. The author's SOP always works for the author.
• Leadership working around it. If founders skip the steps, everyone does.
• Writing SOPs for judgment calls. Creative direction, pricing negotiations and difficult client conversations need playbooks and principles, not numbered steps.

When an SOP is not the right fix

• You are a team of one or two. A shared checklist is usually enough until someone else needs to do the task.
• The task changes every month. Document it once it stabilizes, or you will spend more time updating than doing.
• The real problem is a missing tool or role. If a step keeps failing because nobody owns it, assign an owner before you write the SOP.
• Software can enforce it. If a status workflow, form or automation can make the step impossible to skip, set that up and keep the SOP short.

Where AgencyPro fits

AgencyPro is not a documentation tool, so keep your SOPs in Notion, Google Docs or similar. It can enforce parts of a procedure inside the client workflow, which means fewer steps to remember:

• Custom request statuses with allowed transitions define which status can follow which, so work moves through your review stages in order.
• Client onboarding runs a welcome flow with your steps and downloadable documents when a client first logs into the client portal (all plans).
• Ticket reply templates, auto-assign requests and recurring auto-requests are included on the Pro plan, for consistent replies, routing and repeat work.

See pricing for what each plan includes, or book a demo to see how a client intake SOP maps onto the portal.

Frequently asked questions

What is an SOP for an agency?

An SOP is a written, step-by-step procedure for one recurring agency task, such as client intake, status reporting or invoicing. It states the trigger, owner, inputs, steps, completion criteria and exceptions, so anyone on the team can run the task the same way.

What are the most common agency SOPs?

Client intake and kickoff, status reporting, invoicing and overdue follow-up, scope change requests, deliverable QA, new hire onboarding, staff tool access and offboarding, and client offboarding. Rank your own by frequency, cost of error and how many people do the task.

How many SOPs does an agency need?

Start with the five tasks that score highest, test them, and add more as problems show up. There is no correct total. A small agency might run well on a dozen; a larger one with several service lines will need more. Too many unmaintained SOPs is worse than a few accurate ones.

How long should an SOP be?

Short enough to fit on one screen: usually a few hundred words. If it is longer, split it into two SOPs at a handoff point, or move reference material (email copy, screenshots, tool instructions) into linked templates and recordings.

How often should SOPs be reviewed?

Review client-facing and billing SOPs quarterly and stable internal ones twice a year. Also review immediately after a tool change, an incident involving the task, or when the same question about it comes up twice.

Do SOPs slow down a creative agency?

Not if they cover the operational work around the creative work: intake, scheduling, review rounds and delivery. Keep creative judgment out of SOPs and in briefs, principles and playbooks.