Set advertising approval service levels without turning silence into consent

An approval coverage table

Build a service-level table by decision class. Useful classes include routine bounded changes, time-sensitive operational corrections and high-uncertainty experiments. For each, name the primary reviewer, authorized backup, evidence required, acknowledgement window, decision window and escalation destination. The windows should reflect actual coverage and business consequences. Do not publish a universal number of minutes: a team with weekend coverage has a different operating boundary from one available only during local working hours.

In a teaching example, a promotion ends tomorrow and a specialist requests a budget increase. The request arrives while the primary reviewer is unavailable. The process first checks whether a named backup has both client context and permission. If not, the status becomes awaiting an authorized reviewer; it does not become approved. The request records the last useful decision time and the consequence of delay, such as continuing the existing allocation. These are planning facts, not a forecast of lost revenue.

Keep response time separate from proposal validity. A reviewer can respond within the team's target and still face an outdated starting state. AdAce Ads checks changes against current state and client controls; its policy may require human review or allow eligible automatic actions. Therefore the service-level table must describe which requests actually need a person and which policy path is in force. It cannot promise that creating any proposal is harmless or that every change necessarily waits for manual approval.

Distinguish response from authorization

• Measure acknowledgement time and decision time independently. A quick message saying received does not resolve the request. Track requests returned for missing evidence separately from those waiting on reviewer availability.
• Define a no-response outcome in advance: maintain the current authorized state, defer the experiment or escalate to the named backup. Choose it for the decision class instead of inventing a default after the deadline passes.
• A backup is a qualified decision maker, not merely a reachable colleague. They need the relevant authority, evidence and client limits. Escalation must not temporarily promote a person or share another reviewer's credentials.

Build and measure the review process

1. Map recent requests by complexity and urgency. Identify where delays came from: missing information, unclear ownership, time-zone gaps or stale data. Solve the recurring cause before adopting an aggressive response target that the team cannot meet.
2. Define a complete request: client and account, object, current state, intended state, rationale, bounded risk, validity condition and review deadline. Include what happens if no decision arrives. A reviewer should not need to reconstruct the proposal from chat fragments.
3. Agree coverage hours and escalation order with named owners. For absences, confirm the backup before the absence begins. If coverage is unavailable, record it visibly and adjust scheduling rather than imply uninterrupted approval support.
4. At review time, check current state and policy again. If the request has become stale, refresh its evidence and follow the existing proposal process. Meeting a response target does not justify applying an obsolete budget or status.
5. Review the service-level log periodically: submitted, acknowledged, information requested, decided and completed timestamps. Compare delays with consequences, then change coverage or request quality. Use the log to improve coordination, not to reward rushed approvals.

Deadlines do not override safeguards

Sources and further reading

• AdAce Ads approval controls
• AdAce Ads write policies
• AdAce Ads stale proposals