“Approved” is useful only when everyone knows what it covers. A client might approve an image while the agency assumes the budget, landing page, and launch date are also cleared. An AI operator can inherit the same ambiguity and act on it faster.
An approval service-level agreement should make the review object and response expectation concrete. It should also show what happens when the client is late, the agency revises the work, or the advertising platform takes longer than expected.
Define the object of approval
Package the exact creative version, copy, offer terms, destination, intended audience or geography, budget scope, and schedule where those are part of the decision. Identify elements already covered by standing authority so the reviewer is not repeatedly asked to approve unchanged operating rules.
Give the package a stable version or request ID. “The latest video” is unreliable when a designer uploads another export during review. A client should be able to see precisely what will run and which decisions remain outside this request.
For multiple ads, specify whether approval is all-or-nothing or item by item. If one headline is rejected, the remaining assets should not silently inherit a different combination that the client never reviewed.
Start the clock when the package is complete
An agency cannot fairly begin a review deadline while the landing page is missing or the client lacks access to the preview. Define submission completeness: accessible assets, required context, clear requested decision, and a named reviewer.
Use business hours and a timezone. A request delivered Friday evening should not unexpectedly consume a weekend deadline if the agreement assumes weekday availability. List holiday handling and the backup reviewer for absences.
The deadline is a response expectation, not a quality guarantee. If the package requires factual or specialized review, allow the reviewer to identify the missing evidence and reset the relevant portion of the timeline transparently.
Separate the three clocks
Most launch plans contain at least three different intervals.
| Clock | Controlled mainly by | Completion evidence |
|---|---|---|
| Agency preparation and QA | Agency | Complete versioned approval package |
| Client review | Named client reviewer | Explicit decision on that package |
| Platform review and delivery readiness | Advertising platform and account conditions | Current platform status and launch checks |
Google's ad review guidance says most reviews finish within one business day, with complex reviews potentially taking longer. It also notes that edits can restart review. Treat this as provider guidance, not an agency-controlled deadline or a guarantee that an approved ad will immediately deliver.
Build launch plans backward from the desired date with room for these dependencies. Do not sell a client a guaranteed platform review turnaround that the agency cannot control.
Use explicit decision states
Useful states are approved, approved within stated limits, changes requested, rejected, and waiting for evidence. Each should have a clear operational meaning.
“Approved if legal is okay” remains waiting for that named review. “Looks good, but change the price” requires a revised version and the agreed reapproval process. A reaction emoji in an unrelated message may be insufficient to identify what was approved.
For recurring routine work, a standing authorization can define permitted variations. Record the boundaries and expiration. It should not expand by implication every time the agency produces another asset.
Decide what happens after a missed deadline
The least confusing default for a request requiring approval is to hold it and communicate the revised launch implication. Do not invent consent because a reminder went unanswered.
If the parties deliberately agree to a different process, document it in the service arrangement and make it visible in each relevant workflow. The software and staff must implement that actual agreement; a hidden automation rule should not change it.
Escalation should name the next person and the decision needed. Repeated reminders sent to the same unavailable reviewer do not resolve ownership. For time-sensitive promotions, identify the latest useful approval time after which the offer must be rescheduled or canceled.
Make revisions invalidate the right approval
A factual change to pricing, a new destination, or an expanded budget can materially change the approved package. Return those changes for the required review. A purely technical export correction might stay within standing authority if the agreement defines it that way.
Record which version superseded which and why. Do not keep an old approval badge on an asset whose visible promise has changed. An agency change request can carry the exact before-and-after values.
AI-generated variants deserve the same treatment as human variants. The fact that a model produced them from an approved concept does not establish that every resulting claim, crop, or combination was approved.
Test the SLA with a real calendar example
Consider an illustrative Monday promotion. The agency needs a complete package Wednesday, client review Thursday, and time Friday to resolve revisions and inspect platform status. If the client changes the offer on Friday afternoon, the Monday launch may no longer be supportable.
Write the response plainly: the offer changed, a new version needs review, and the team will confirm the launch date after the outstanding checks. Avoid presenting the delay as a mysterious algorithm problem when the dependency is known.
Review the SLA after several launches. Measure incomplete submissions, response time, revision cycles, and missed launch dependencies separately. A shorter headline approval time is not an improvement if the number of wrong-version launches increases.
The agreement should make the next action obvious to the client, buyer, designer, and any automated operator. That clarity is what makes faster approvals useful.