Put Your Ad Ops on Coordinator Duty: What Publisher Teams Should Steal from Engineering's On-Call Playbook
"Coordinator duty" is ad ops borrowing the best idea engineering ever operationalized: at any given time, one named person is on call, they carry a pager that only fires on real signal, a runbook tells them exactly what to do when it does, and everyone else gets to do deep work in peace. The rotation distributes the load, the pager does the watching, the runbook transfers the judgment, and the system - not heroic vigilance - provides the coverage.
Publisher ad ops has the same underlying problem engineering had: revenue-critical systems that don't respect business hours, watched by teams that do. Campaigns deliver on weekends. Demand shifts overnight. Ad units break whenever the dev team ships. But where engineering built machinery, most ad ops teams still run on the pre-pager model - everyone vaguely responsible for watching everything, detection depending on who happens to look, and coverage collapsing whenever someone's away. This article maps the four pieces of the on-call playbook onto ad ops, and shows how a daily coordinator - the pager of this model - turns whole-network GAM coverage into something one person can carry at a time.
Ad Ops Has Engineering's Old Problem
Before on-call culture, software teams ran the way most ad ops teams run today. Systems that could fail at any hour, watched informally by whoever felt responsible. Outages discovered by users - or in ad ops terms, by advertisers and month-end reports. The most conscientious person quietly checking everything, burning out, and becoming a single point of failure. Coverage that existed as a vibe rather than a design.
Engineering didn't fix this with more diligence. It fixed it with structure - and the structure has four pieces, each of which translates cleanly to a publisher ad ops team running Google Ad Manager. The premise underneath all four: watching is a system's job; judging is a person's job; and exactly one person needs to be judging at a time.
The Four Pieces of the On-Call Playbook, Translated
The rotation. In engineering, on-call passes weekly - one named engineer owns response, everyone else ships in peace. The ad ops translation: one named person is the coordinator this week. They work the flagged list, make the calls, escalate what qualifies. Everyone else does deep work - yield, campaigns, advertiser projects - without the ambient guilt of "should I also be watching?" The rotation is also the vacation-proofing: coverage is a role that rotates, not a person who can't leave.
The pager. The piece most ad ops teams are missing entirely. Engineering's pager works because of what it doesn't do: it doesn't forward every log line - it fires on real, prioritized signal, because a pager that cries wolf gets ignored. The ad ops equivalent is a daily coordinator that checks the whole GAM network every morning - campaigns, revenue, inventory - against baselines, seven days a week, and hands the on-call person a short list, worst-first, by 8 AM. Not dashboards (a dashboard is a log file you have to remember to read). Not raw scheduled reports (data without judgment). A short list of what actually needs a human today. That's ProOps Ads Tracker's entire job description, and why we call it the daily coordinator rather than a reporting tool.
The runbook. Engineering's insight: response quality shouldn't depend on who's responding. The runbook encodes thresholds, procedures, and escalation so the newest engineer at 3 AM acts like the veteran. The ad ops version is the handover doc built properly: thresholds as numbers ("under 90% pace with under 10 days left = rebalance now"), the escalation map ("anything touching these two advertisers - call me, any hour"), and the currently-weird list of known issues to leave alone. Pager plus runbook is what makes the rotation real - it's how whoever's on call is effective on day one, not just your most senior person.
The postmortem. Engineering reviews incidents to fix systems, not to assign blame - and tracks one metric above most: time to detect. The ad ops translation: when something does slip through, ask "when did this start, when did we know, and what would have caught it sooner?" - then tune the thresholds or the runbook. Detection delay is the most expensive variable in every GAM incident; it's also the most improvable one.
The Short-List Morning: What Coordinator Duty Feels Like
Here's the model running, on an ordinary Tuesday. The coordinator opens the sidepanel inside GAM at 8:30. The short list has four items: one red (a direct-sold line item pacing 82% with 11 days left - the runbook says rebalance today), two oranges (an eCPM dip on one demand source approaching threshold; an ad unit's fill drifting), one informational. They action the red, note the oranges for tomorrow's comparison, and are done judging by 8:50. The other three people on the team never looked at a report. The senior person spent the morning on the Q4 packaging proposal.
Compare that to the pre-pager version of the same Tuesday: three people each spending 60-90 minutes pulling reports and scanning pacing columns - mostly confirming things are fine - with the line item's drift noticed (or not) depending on whether anyone happened to sort that column. Same team, same network, same Tuesday. The difference is the model: teams on coordinator duty report the morning review dropping from 60-90 minutes to under 10, and 4-6 hours per person coming back every week - because the watching moved to the system and only the judging stayed human.
And the model's stress test is the one every team eventually runs: someone's out. In the old model that's a coverage hole; in this one, the rotation just skips them - whoever's on call gets the same short list, backed by the same runbook. One publisher's system paid for itself on day two of their free trial, when the short list included an $8,500 under-delivery that manual checking hadn't surfaced.
Implementing Coordinator Duty on Your Team
The sequence, honestly sized - this is a light lift, not a reorg:
1. Name the rotation. A weekly coordinator schedule in whatever calendar you already use. Cost: one conversation. (Two-person teams: alternate weeks. Even a team of one benefits from the rest of the model - the "rotation" is just you, with real vacation coverage finally possible.)
2. Stand up the pager. This is the build-or-buy step. The requirements are strict because the pager only works if it's trusted: whole-network daily coverage, baseline-aware, worst-first ranked, seven days a week, delivered before the workday. You can build toward it with GAM's native notifications and scheduled reports - honest first step, judgment stays manual - or put Ads Tracker on coordinator duty: read-only service account (the only integration step), setup under an hour, first short list the next morning, USD $249/month with a 30-day free trial that's long enough to run the whole model before paying anything. (The first-30-days roadmap maps that trial week by week.)
3. Write the runbook. One page: thresholds, escalation map, currently-weird list. The handover-doc structure linked above is exactly this - most teams draft it in an afternoon and improve it every rotation.
4. Review detection, monthly. Fifteen minutes: what slipped through, what fired that shouldn't have, tune accordingly. This is the step that compounds - the model gets quieter and sharper every cycle.
The whole implementation is a calendar entry, an hour of setup, an afternoon of writing, and a monthly review. What it buys is the thing engineering teams have had for twenty years and ad ops teams have been white-knuckling without: coverage as a property of the system, and mornings that start at the short list.
Stop running GAM checks by hand. Put it on coordinator duty: start the 30-day free trial.
FAQ - Coordinator Duty for Ad Ops
What is coordinator duty in ad ops?
An operating model borrowed from engineering's on-call practice: one named person per week owns GAM response, a daily monitoring system (the "pager") checks the whole network against baselines and hands them a worst-first short list each morning, a one-page runbook encodes thresholds and escalation so anyone can cover effectively, and a monthly review tunes detection. Everyone else on the team does deep work instead of ambient watching.
Why borrow the on-call model from engineering?
Because engineering already solved the identical problem: revenue-critical systems that fail at any hour, watched by humans who work business hours. Their answer - watching is a system's job, judging is a person's job, and exactly one person judges at a time - took software from heroic vigilance to calm coverage. Ad ops runs the same risk profile (campaigns deliver seven days a week) and mostly still runs the pre-pager model.
Does coordinator duty work for a two-person or one-person team?
Yes - arguably best. Two-person teams alternate weeks, which formalizes the coverage they were improvising and makes vacations real. A team of one keeps every piece except the rotation: the pager does the daily watching, the runbook makes a colleague or manager a viable backup, and time off stops meaning either checking from the beach or hoping.
What makes a good "pager" for GAM monitoring?
The same property that makes engineering pagers work: signal, not noise. Requirements: whole-network daily coverage across campaigns, revenue, and inventory; baseline-aware evaluation (not raw data delivery); worst-first ranking; seven-day operation; delivery before the workday starts; and read-only access. Dashboards fail the test because they require someone remembering to look; raw scheduled reports fail it because they deliver data without judgment.
How long does it take to implement coordinator duty?
The rotation is one conversation; the pager is under an hour of setup if you use a monitoring tool (via a read-only service account, with first alerts the next morning); the runbook is an afternoon using the handover-doc structure; and the detection review is fifteen minutes a month. A 30-day free trial is long enough to run the entire model - rotation, short-list mornings, runbook, and one review cycle - before paying anything.