Every agency has a story about an approval that wasn't.
The client said yes on a call. The campaign launched. Three weeks later, there's a dispute about copy that was "never approved." Or the design they signed off on "wasn't what they expected." Or the offer in the email is different from what they meant when they said the email "looked good."
These situations aren't usually about bad faith. They're about the fundamental weakness of how most agencies capture approvals: informally, asynchronously, and without version control.
This guide covers what a defensible approval process looks like, and why the mechanics matter as much as the intent. If you're weighing whether your project management tool already covers this, see why campaign production needs a dedicated approval layer.
Why informal approvals fail
Most agency approvals happen in one of three ways, all of which are problematic:
Email approval. The agency sends a PDF or a link. The client replies "looks good" or "approved." The email sits in someone's inbox. There is no link between the approval and the specific version of the content that was approved.
Call approval. The client gives verbal approval on a Zoom call. Someone takes a note. The note doesn't specify exactly which version was reviewed. There's no record the client can later produce.
Comment-based approval. The client reviews in Figma or a shared doc and leaves comments. Some comments are addressed, some aren't. At some point the process stops. Nobody formally marks it as approved.
All three get worse when the feedback itself is scattered, so the first structural fix is usually to centralize campaign feedback before tightening how approvals are captured.
The common failure in all three: version ambiguity. The client approves "the email," but which version? Version 3 with the discount corrected, or version 2 before that change? When a dispute arises, this question can't be answered.
The second failure: no authorized approver verification. The person who replied "looks good" may not be the person with authority to approve marketing spend at their company. This is especially common in enterprise accounts where the day-to-day contact and the budget owner are different people.
What a defensible approval looks like
A defensible approval has four properties:
1. Version-specific. The approval is linked to a specific, immutable version of the content. Not "the email was approved" but "version 3.2 of the email, as it existed on December 3rd at 14:22, was approved."
2. Authorized. The approval comes from someone who has been explicitly designated as an approver, preferably confirmed in writing at the start of the project.
3. Timestamped. The approval has a reliable timestamp that you can produce if questioned.
4. Contextual. If the approval came with conditions ("approved pending the link correction"), those conditions are attached to the approval record, not in a separate Slack thread.
This is exactly the shape of approval record a dedicated campaign approval software captures automatically: version, approver, timestamp, and conditions, without anyone having to reconstruct it later. For how that plays out in an agency specifically (a workspace per client, guest review by link, an audit trail per account) see campaign approval software for agencies.
Setting up the approver list at project start
Most approval disputes could be avoided if agencies spent fifteen minutes at project kickoff establishing two things:
- Who is authorized to give final approval for each type of content?
- What does "approved" mean: is it approval to proceed to the next phase, or final approval to deploy?
Get this in writing. Even an email confirmation from the client that specifies "María García is authorized to approve all creative assets for this campaign" protects you enormously later.
For campaigns with multiple types of content (email, landing page, paid social), consider whether the same person needs to approve all types, or whether approval is split by discipline.
This is easiest to get right when it's decided at the brief stage, not improvised at kickoff. See our guide on how to write an email campaign brief for the named-approver field and the seven others that go with it.
The review cycle structure
Each review cycle should have:
- A clear start (the client receives the content for review, with a deadline)
- A clear scope (exactly what they are reviewing, what version)
- A clear end (they either approve or provide specific feedback: "looks good" isn't feedback, "the headline should say X instead" is)
For campaigns that go through multiple review cycles, number them explicitly. "Review round 3: email copy." This prevents the common confusion where the client gives feedback on a version they already approved. If you're routinely seeing three or four rounds, the fix usually isn't stricter numbering. It's consolidating who reviews and when; see how to cut campaign review rounds from four to one.
Set a reasonable review deadline and state it explicitly: "Please review and respond by December 10th. If we don't hear from you by then, we'll proceed with the current version." This is not a pressure tactic. It's logistics. Campaigns have launch dates.
For the full agreement behind that deadline (named approvers, response windows, escalation, and what counts as approval), see our guide on setting a client approval SLA.
How to handle feedback that changes the scope
Client feedback sometimes goes beyond what was agreed to be reviewed.
"While you have it, could you also change the footer?" is a classic example.
Handle this explicitly, not by ignoring it or by absorbing it silently:
- Acknowledge the request.
- Confirm whether it's in scope for the current review or constitutes a new change request.
- If it's a change request, document it as such.
This isn't about being rigid with clients. It's about being clear. Vague scope leads to vague approvals, which lead to disputes. Clear scope leads to clean sign-off.
The final sign-off
The final sign-off is the approval that authorizes launch.
It's different from intermediate approvals ("this draft is ready to move to production") and should be treated differently.
At final sign-off:
- The content being approved should be the final, production-ready version
- The approver should have explicitly confirmed that they are reviewing the final version, not a draft
- The approval record should specify that this is a launch authorization, not a review milestone
Content sign-off isn't the same gate as technical pre-send QA. A client approving the copy doesn't catch a staging link or a broken personalization fallback. See our pre-send checklist for the ten checks that catch those before send.
For regulated industries (financial services, pharma, healthcare) or high-stakes campaigns, consider a formal sign-off document: a brief summary of what was approved, at what version, by whom, with a digital signature or written confirmation from the client.
When something goes wrong anyway
Even with good processes, disputes happen.
When they do, the quality of your approval documentation determines how quickly you can resolve them.
If you have a version-specific, timestamped approval from the right person, a dispute about whether content was approved is usually resolvable in one conversation. You show the record. The client sees it. The conversation shifts from "did we approve this" to "what do we do now."
If you don't have that record, you're in a much harder position, trying to reconstruct what happened from email threads and calendar invites, with both sides interpreting the evidence in their favor.
The approval process isn't bureaucracy. It's protection, for your agency and for your client relationship.
FAQ
What counts as a defensible client approval?
An approval tied to a specific, immutable version, from a named and authorized approver, with a timestamp and any conditions attached. A "looks good" reply in an inbox is none of those things.
Is a signed PDF enough to prove approval?
It's better than a verbal yes, but on its own it doesn't bind the approval to the exact version that shipped. Version ambiguity, approving "the email" without pinning which draft, is what most disputes turn on.
Who should be allowed to give final sign-off?
A named, authorized approver agreed in writing at kickoff, ideally the person who owns the budget, not only the day-to-day contact. Split it by discipline (copy, design, legal) when different people own different assets.
What do you do when a client approves late or not at all?
Set a response window and a stated default before production starts, in the brief or an approval SLA. Silence is a policy you should have written down, not an emergency you improvise on send day.
