Agency processes: the guide that treats your SOPs as build specs

Every agency has processes. In most, they live in three heads, two ancient Notion pages and one person called whenever the invoice run breaks. The standard advice is: document everything. It is good advice with a flaw nobody mentions: documentation written for a binder gets read once and rots.

This guide takes the next step. What agency processes actually are, why documentation keeps failing, how to map processes as they really run, and the reframe that changes the exercise: in 2026, a properly documented process is not an archive. It is a build specification, and part of your delivery can be built from it.

What are agency processes?

Agency processes are the repeatable ways your agency turns inputs into outcomes: how a lead becomes a client, a brief becomes a campaign, a month of work becomes a report and an invoice. Processes are the what; workflows are the how, the step-by-step sequence inside a process.

There is now a third state the standard guides stop before: the system. A process starts as habit (it lives in someone's head), matures into documentation (written down, followable), and can end as a system (executed by software, with humans at chosen control points). Habit, document, system: each state is cheaper to run and more fragile to lose than the last is to build.

Why process documentation keeps failing in agencies

Answer first: because it is written for compliance, not for execution. An SOP written to prove a process exists reads like a policy; nobody consults a policy at 5pm on deadline. The document fails its only test, being faster than asking the person who knows.

• The knowledge holder never wrote it. The person who actually resolves the weird cases is too busy resolving them, so the doc describes the happy path and the exceptions stay in their head. The doc is a map of the country's motorways with none of the junctions.
• It rots quietly. Practice moves with every new client and tool; the doc does not. Six months in, following it produces wrong work, so people stop, and stop trusting all the other docs too.
• Onboarding happens by shadowing anyway. The real transfer mechanism in most agencies is sitting next to someone for a fortnight, which caps how fast you can grow and turns every departure into an amputation.
• It is written at the wrong altitude. Either so abstract it cannot be executed ('ensure quality') or so granular nobody reads it (forty screenshots of a login flow). The useful altitude is decision rules: what to do, when, and what decides.

None of this is a discipline failure. It is a purpose failure: a document with no executable consequence has no force keeping it true. That is exactly what changes when documentation becomes a spec.

The audit: map processes as they actually run

Before improving or automating anything, map the real process, not the official one. Take one process end to end and answer four questions, per step:

• What triggers it, and what does it produce? A closed deal, a month-end date, an inbound email; a report, an invoice, a project space. If trigger or output is fuzzy, you have found the first problem.
• Who touches it, and where does it wait? The elapsed time of most agency processes is queue time between people, not work time. Handoffs are where hours die.
• Which tools does it cross? Every crossing (CRM to sheet to email to PM tool) is a retyping point and an error point. Count them honestly.
• What are the exceptions, and who resolves them? This is the question the official version never answers, and the most valuable one. The exceptions ARE the expertise.

Watch for the shadow process

Every agency runs two versions of each process: the official one and the one people actually follow. The trick to surfacing the real one is not to ask how does onboarding work (you will get the official version); ask the person who did it last to narrate the most recent real instance, step by step, including the workaround they are slightly embarrassed about. The workaround is the process. Map that one.

Do this for your five or six core delivery processes and rank them by hours consumed. The result usually surprises founders: reporting, onboarding and internal chasing outrank creative work by a distance.

A documented process is a build specification

Here is the reframe this guide exists for. Written one way, an SOP is a compliance artifact. Written another way, with no extra effort, the same document is the specification a system can be built from. The difference is precision about seven things:

A document with these seven elements does double duty. A new hire can follow it tomorrow. And a builder can turn it into a system next month, because trigger, inputs, rules and exceptions are precisely what code needs. You wrote it once; it works for both audiences.

A spec in the wild: client onboarding, one page

What this looks like written out. Trigger: deal marked closed-won in the CRM. Inputs: the signed proposal, the client's account list from the sales notes. Steps: create the project space from the template, generate the access-request list per account, run the tracking checklist, draft the kickoff agenda from the proposal, book the recurring calls. Decision rules: which template per service line; access chased after three days.

Exceptions: client procurement requires their own access process, route to the account director. Output: a ready workspace, a sent kickoff email, a checklist report of what came back green. Control level: scaffolding runs automatically; the kickoff email requires a human paragraph and a human send. One page, and a builder could start Monday.

The exercise also has a diagnostic side effect: any step where you cannot write the decision rule is a step that runs on judgment. That is not a documentation failure, it is a discovery. You have just found the part of the process that stays human, and drawn the automation boundary in exactly the right place.

From process to system: which ones make the jump

Not every documented process should become a system. The filter is the same three tests we apply to every build: the process repeats reliably, its inputs are structured, and its output can be verified at a glance. The delivery layer passes (reporting, pacing, onboarding, brief capture); we walk those candidates one by one in the agency workflows guide.

The strategic decision around it, whether to buy tools, hire, or build owned systems, is its own question with its own guide: AI for marketing agencies. The short version: buy for individual productivity, hire for judgment, build for the repetitive layer your spec-grade SOPs now describe.

Control levels: the part that keeps clients safe

A process that becomes a system does not become unsupervised. Each step gets a control level, written into the spec: runs automatically (conforming work executes), exception review only (humans see what breaks pattern), approval required (nothing ships unsigned). Trust is granted per step and can be tightened any time. The system executes the process; the agency still governs it.

One naming rule saves more approval standstills than any framework: every output gets exactly one named approver. Two approvers is zero approvers; the work waits for whoever thinks the other one has it.

What stays process, what becomes system

The honest split, because turning everything into software is neither possible nor desirable:

• Becomes a system: the repetitive delivery layer. Reporting, pacing checks, onboarding scaffolding, brief extraction, research packs. Structured inputs, verifiable outputs, weekly rhythms.
• Stays a documented process for humans: sales conversations, creative direction, pricing, escalations, the client relationship. Judgment work, where the doc's job is consistency of approach, not execution.
• Stays a habit, deliberately: the genuinely rare cases. Documenting a process that runs twice a year costs more than it returns. Write down where the knowledge lives and move on.

And the objection worth retiring: process does not kill creativity; retyping does. Every hour the spec-and-system layer recovers from reporting and admin is an hour that can go to the work clients actually hired you for. The agencies most resistant to process are usually the ones whose creatives spend Friday afternoons in spreadsheets.

The trap to avoid is the inverse split: agencies that automate the judgment (templated strategy, generated client emails nobody reviews) while humans keep retyping numbers between tools. That is backwards, and clients can tell.

Which state should each process be in? It depends on your size

The ladder is not a race to systematise everything; the right state depends on how often the process runs, which tracks headcount:

• At 2-5 people, habit is mostly fine and documentation is expensive relative to its use. Write specs only for the two processes that touch every client (usually reporting and onboarding), because those are also your first builds.
• At 6-15 people, the habit state starts failing visibly: the founder is the bottleneck, onboarding is shadowing, and one departure hurts. This is the window where spec-grade documentation pays fastest, and where the first systems change the growth curve.
• At 15+, undocumented process is an unpriced risk on the balance sheet, and the question flips from should we systematise to why is this still manual. Delivery consistency across pods becomes the differentiator clients feel.

Keeping processes alive: the exception loop

Documentation rots because updating it is a chore scheduled for a quarterly review that never happens. Systems change the maintenance model: the update happens at the moment of the exception, because the exception physically stops in front of a human.

Concretely: a client asks for a rush turnaround the process does not cover. The account lead decides: accepted, with a surcharge and a scope note. In the old model that decision evaporates by Friday. In the exception loop it becomes a line in the spec (rush requests: accept if X, surcharge Y, flag in the monthly summary), and the next rush request does not need the account lead at all.

The loop also solves adoption, the thing process rollouts usually die of. People resist rules handed down; they follow rules they authored. In the exception loop, the person who resolved the case writes the rule, so the spec is the team's accumulated judgment, not a policy from above.

A weird case arrives; a human resolves it; the resolution becomes a new decision rule in the spec, and, if the process is a system, a new rule in the system. Resolved once, applied every time after. The process gets truer with every exception instead of staler with every month. That loop, not any tool, is what makes operational knowledge compound instead of evaporate.

Three anti-patterns to catch early

• The tool-first reflex: buying an agency operating system and expecting processes to appear. Tools host processes; they do not create them. A vague process in good software is a vague process with a subscription.
• The big-bang documentation sprint: a fortnight of writing everything down, followed by eighteen months of nothing. Specs written outside real use are guesses. One process, specced properly, run in anger, beats a wiki of untested pages.
• The perfection stall: waiting for the process to be tidy before writing it down. Spec the messy reality first; the act of writing the decision rules is what tidies it. The spec is the improvement tool, not its reward.

How this connects to what clients feel

Process talk sounds internal, but every element above surfaces in the client experience. The onboarding spec decides whether week one feels organised or chaotic. The reporting spec's decision rules decide whether the numbers a client sees are consistent month to month. The exception loop decides whether the same mistake happens twice.

Agencies compete on creativity, but they churn on operations. A client rarely leaves because the ideas got worse; they leave because the report was late twice, the new account manager knew nothing, and the invoice was wrong. Those are process failures, and they are the preventable kind.

Where to start, practically

• Pick one process, the one that eats the most hours (the audit above tells you). Map it as it actually runs, exceptions included.
• Rewrite its SOP as a spec: the seven elements, one page. You now have better documentation than most agencies regardless of what happens next.
• Decide its future state: stays human, or becomes a system. If it is the second, that spec is the brief. Mapping this with founders is literally what our free 30-minute mapping call does: where the hours go, which process to spec first, what a system would replace. The deepest version of the discipline is the Apshan platform, where resolved exceptions become reusable rules at data-platform scale.