Client Onboarding SOP for Marketing Agencies

The client onboarding process covers what actually happens between a signed contract and a working relationship, and where it breaks. The agency SOP guide covers why a procedure library matters and which five processes to document first, and the craft of writing one covers how to turn any task into a document a stranger can follow without pinging you on Slack. This piece is those three applied to the single highest-value case: the client onboarding SOP itself, written as what the document has to contain rather than as advice about documents in general. If you have already read the other pieces, skip the theory and go straight to the procedure.

One honest note before the stages. There is no downloadable template attached to this article, and there will not be one. A template built for a generic agency assumes a generic CRM, a generic project tool, and a generic handover process, and none of those exist at your agency specifically. A document that names the wrong field in your actual project tool is worse than no document, because it looks authoritative while quietly being wrong. What follows is the skeleton every version of this SOP needs, built from twelve years of running delivery operations for marketing agencies and 92 completed engagements. Fill it with your own tool names and your own people.

What should trigger the client onboarding SOP?

Not a stage in the sales pipeline. An event. “New client signed” is a heading, and headings do not tell anyone when to start. The trigger that holds up in practice is narrower: a signed contract lands in the CRM. That event is specific enough that a person can watch for it, and specific enough that a workflow tool can watch for it too, once the procedure has proven itself running by hand a few times first. Write the trigger at the top of the document as that event, not as the phrase “client onboarding,” and the question of who starts the clock stops being a judgment call.

Who owns the SOP, by name, not by department?

The document needs one named owner, written at the top next to the trigger, not “sales and delivery coordinate.” A shared owner is no owner, and onboarding sits in the gap between two departments measured on different things. Name a title, not “sales and delivery coordinate,” and give that title explicit authority over both halves of onboarding: pulling the handover fields out of sales and confirming the information-gathering fields before the kickoff call. A shared owner is no owner, because a document that answers to two departments answers to neither when the fields go unfilled. If no existing role at your agency fits, the SOP should name the gap and route ownership to whoever holds operations, rather than leave the line blank until someone volunteers. A document with no named owner reverts to the folder of half finished checklists it was meant to replace.

What stages does the document actually need to define?

Four, in this order, each one a section in the SOP with its own owner and its own definition of done.

• Sales handover. The point where what was sold becomes what delivery is told.
• Information and access gathering. The point where the client’s assets, accounts, and stakeholders actually reach the people doing the work.
• Kickoff call. The point where cadence, format, and the first deliverable date get said out loud with the client present.
• First deliverable. The point where the client finds out whether what was promised matches what actually arrives.

Each of those is a heading in the document, not a paragraph explaining the philosophy behind it. The philosophy is covered in the process piece linked above. The document itself just needs the steps.

What fields does each stage require?

This is where most SOPs go vague, because “gather the client’s information” sounds like a step and is actually a category. Written as fields, not sentiment:

Sales handover

• What was promised, in what timeframe, in the client’s own words where possible.
• What was explicitly excluded from scope during the pitch.
• Who the actual decision maker is, versus who sat on the sales calls.
• Any commitment on price, timeline, or deliverable made outside the contract’s plain language.
• What the client is expecting to see first.

Information and access gathering

• A named checklist of accounts and platforms the work touches, with a status column, not a paragraph.
• The single tool of record for this account, I work across ClickUp, Asana, Monday.com, Airtable, and Notion, decided once and written down, not improvised per project.
• A resourcing confirmation field: one line, dated, from whoever assigns the team, stating that capacity exists for this account at the volume just sold.
• The internal brief itself, a separate artifact from the contract, written for the people who were not on the sales calls.

Kickoff call

• Cadence: how often the client hears from you.
• Format: what that contact looks like, call, email, shared dashboard.
• Routing: who the client contacts for what, by name.
• The first deliverable’s date and format, confirmed out loud on the call, not assumed from the proposal.

First deliverable

• Promised date and format, pulled from the kickoff call notes, not memory.
• Actual date and format the deliverable shipped.
• One line on whether the two matched, because that comparison is the actual output of the onboarding SOP.

What checkpoints keep the document from being a checklist nobody checks?

A checkpoint is a moment where the document forces a comparison before the next stage starts, and it needs a named branch for what happens when the comparison fails. Two matter most in onboarding.

Before the kickoff call: the checkpoint is a field-by-field verification pass against the information-gathering stage, not a status check-in. Every field from that stage gets marked confirmed or not-confirmed against source, and any field still not-confirmed blocks the kickoff call from being scheduled. The output is binary, not a conversation.

During information gathering: if the client has not granted access by a set day, the branch names who follows up and what they send, rather than leaving it to whoever notices next. Write it as: if access is not granted by day three, send the follow up template and flag the account lead, with the account lead named as the decision maker if the delay continues. An exception with no named decision maker gets escalated to whoever is nearest, which is how the same judgment call gets made three different ways in the same quarter.

What review date does the document need, and why does it matter?

Every SOP needs a review date written on it, not left implicit. For client onboarding specifically, two things make the document stale faster than most: the tool of record can change, and the person named as owner can leave. A review date tied only to the calendar, once a year, misses both. The more useful version is dual: review on a fixed schedule, and review the moment either the tool stack or the named owner changes, whichever comes first. Write both triggers on the document itself, next to the owner’s name, so the next person to touch it knows exactly when it stopped being current.

So what does the client onboarding SOP actually need to contain?

A trigger written as an event, not a phrase. One named owner. Four stages, each with its own fields written as fields, not paragraphs. Two checkpoints with named branches for when the comparison fails. A review date tied to a schedule and to the two things most likely to make the document stale. That is the whole shape of it, and it holds for any agency regardless of which tool sits at the center, because the fields describe what has to be known, not which software knows it.

If your agency does not have this written down anywhere right now, that is not evidence delivery is failing, it is evidence the documentation step got skipped, and it is usually the cheapest fix sitting inside the most expensive looking problem. I built the SOP consulting engagement around exactly this kind of gap, writing the procedure from your actual work rather than a template, and onboarding is the first place I look because a weak first month erodes trust in every report that follows it. If you are not sure onboarding is even the right place to start, the Agency Ops Audit answers that first: a $1,500 fixed fee, two weeks, a written 90-day roadmap, and a 60-minute readout call that tells you which process is worth the afternoon before you write a single field.