How do you set a client approval SLA?

An approval SLA is a written agreement, made at kickoff, that answers four questions: who approves each type of asset, how long they have to do it, what happens when that window expires, and what specific action counts as approval. Two business days is the standard window for a single email, three when legal reviews the copy. The one rule that matters more than the numbers: silence never counts as approval, and neither does a thumbs-up emoji.

Most teams already have deadlines. What they lack is agreement on what happens when one passes. That gap is where launch dates slip and where disputes start, and where a dedicated campaign approval software turns the SLA from a document into an enforced workflow.

Why does "no reply = approved" always end badly?

Thursday, 9:04 a.m. The Black Friday email goes to 180,000 contacts. Subject line: "Up to 60% off. Everything must go." At 9:20 the client's commercial director forwards it to your account manager: "Who approved 60%?"

You start digging. You find a Slack message from Javier Peña saying "looks great, go ahead," sent Tuesday at 6:48 p.m. You find a WhatsApp voice note where he mentions the discount but not the number. No dated record connects a named person to a specific version. Javier approved something on Tuesday. What shipped was v4, revised Wednesday after merchandising moved the ceiling from 40% to 60%.

The real problem is not the mistake. Mistakes happen on every campaign. The problem is that this one is unattributable, so it becomes a negotiation about memory. Two competent people remember two different conversations, both honestly, and the relationship pays for it.

The quieter failure mode is more common. Nobody replies. The send date is tomorrow. Someone on your team decides, alone and at 5:40 p.m., that no reply means go. That is not a policy. That is one person absorbing risk nobody assigned to them.

An SLA does not prevent late feedback. It decides in advance who absorbs the cost.

What are the four components of an approval SLA?

1. Named approvers, per asset type

Not "the client." Not "marketing." A person, per asset type, with an email address. Email copy and subject lines: Javier Peña. Legal and disclaimer copy: Nadia Ortiz. Landing page and form fields: whoever owns the site, often a different person in a different department.

One approver per asset, two at most. Three approvers on a subject line produces three opinions and zero decisions: the same dynamic, scaled up, that turns one round of client review into four; see how to cut campaign review rounds from four to one for how to consolidate it. Agree on a named substitute for each, because August will happen. This mapping belongs in the campaign brief, and it is one of the eight fields covered in how to write an email campaign brief. If you want the owner-per-asset mapping as a ready grid, our campaign RACI template lays out one accountable owner per asset, with every stage dated back from the send.

Channels with an external gate get their own line. A WhatsApp template has to clear Meta review before use, so approval of that copy closes earlier than the email copy.

2. A response window, counted in business hours

Two business days for a standard email. Three when legal or compliance is in the loop. One for changes already discussed on a call.

Two details decide whether the window is real. It starts when the reviewable version is delivered, not when you asked for the review. And it counts business hours in the reviewer's time zone, so a version sent Friday at 6 p.m. to a client in Chicago is not overdue Monday morning.

Write the same window for yourself. If Javier requests a change, he gets the revised version within one business day. An SLA that only binds the client will be read as a policy, and treated like one.

3. An escalation path with an actual consequence

At the timeout, one of two agreed things happens: the request escalates to a named senior contact on the client side, or the launch date moves.

A workable sequence: reminder at 24 hours, escalation at 48, written notice that the send date has moved at 72. What never happens is "we assume approval." That is the thing the SLA exists to eliminate, so it cannot sit inside it as a fallback.

Moving the date reads as aggressive on paper. In practice it is the only consequence that changes behavior, because it puts the cost where the delay happened.

4. An explicit approval action

Define what approval looks like, and what it does not.

Approval is a click on an Approve button tied to a specific version, or an email that names the version. "Approving v4 of the Black Friday email" is approval. Everything else is feedback. Naming the version is how you record the verdict against a version rather than against a memory two people will later recall differently. And approving an asset is not the same as approving the campaign it belongs to: asset approval vs campaign approval are two separate decisions.

Not approval: silence, a thumbs-up reaction in Slack, "nice one" in a WhatsApp reply, a nod on a call, approval of the previous version, or approval from someone who is not the named approver. That last one catches teams constantly. A senior person on the client side says yes on a call, you ship, and the named approver never saw v4.

How do you introduce it without sounding bureaucratic?

Do not send a policy document. Nobody has ever read one.

Put it in the kickoff, on one slide, ninety seconds. Frame it as what it is: the mechanism that protects the client's launch dates. Their dates, not yours. They care about the December 1 send going out on December 1, not about your process. So talk about the date.

Say the cost in days. "Last quarter we lost four send days waiting on approvals with no owner. Here is how we get those days back." A number from your own history beats any argument about process.

Then send the agreement in an email short enough to answer from a phone.

Two things make it work: it proposes instead of announcing, and it ends on a question, which is what gets it answered.

What should you log for every approval?

Three fields, per asset, per version.

Who. The named person and their email address. Not "client approved."

What. The asset, its version number, and the rendered version they actually looked at. "v4 approved" is useful only if v4 can still be opened nine months later.

When. A timestamp with a time zone.

Keep the change requests that came before it. The comment thread explains why v4 says 60% when the brief said 40%, and in a dispute that context is worth more than the approval line.

Where the record lives matters more than teams expect. In an account manager's inbox, it leaves when they do. On your project board you hit a structural limit: the client is not a user in your project tool, so their approval gets transcribed by someone on your team instead of recorded directly. That is a copy of an approval, and it is one of the gaps worth knowing about if you are running campaign production in Asana or Monday.

The last check before scheduling is always the same: the version scheduled matches the version approved. It sits on the pre-send checklist because it catches the Black Friday scenario at 4:55 p.m. rather than at 9:20 the next morning.

This is exactly the workflow LaunchSign is built to automate: named approvers per asset, response windows with escalation, client review through a guest link that needs no account, and an approval record tied to a version, not a memory.

FAQ