Every month, the same cycle. One deck per client, fifteen clients deep. Someone opens Google Ads and starts copying numbers. Someone else pulls Meta. A third person exports GA4 into the spreadsheet that feeds the slides. Days disappear before a single client conversation happens.
That was the reporting month at a digital agency managing a roster of around 15 paid-media clients. Every client needed its own deck, with data pulled by hand from Google Ads, Meta, and GA4, then dropped into slides. Hand-built reporting fails in two ways at once. Quality drifts: deck 14 never gets the care deck 1 did. And silent failures sneak through: an expired token or a changed permission means a chart quietly renders wrong, and nobody notices until the client does. The traditional fix for both is more review time, which is to say more hours spent on the month's least billable work.
We built a pipeline to take that cycle off the team's hands. This post covers what the system does, what a full dry run proved, one bug worth telling on ourselves, and exactly where the project stands.
What reporting costs across the industry
This is not one team being disorganized. The published numbers for marketing agencies are consistent and ugly. Agency teams spend about 14.5 hours a week collecting and managing data (Treasure Data). More than 20% of the working week goes to reporting (Adriel, 2025). And in 78% of agencies, 3 or more people touch each client report before it goes out (Fluent, 2025).
Stack those three numbers and reporting stops looking like a task and starts looking like a department. The hours are usually senior hours, too: the people assembling decks are often the same people who should be running strategy. And it is the rare cost that grows with success, because every client you win adds another deck to the pile. Heavy, recurring, and scaling with the roster: that combination makes reporting one of the highest-yield automation targets an agency has. It is also hard to hire your way out of, because adding a coordinator adds a fourth person to the report chain, not fewer hours.
What the pipeline does
The system replaces the manual cycle with a scheduled, gated pipeline. On each run, a monthly orchestrator takes every client on the roster through the same sequence.
- Aggregates the data. Google Ads, Meta, GA4, and SEO data are pulled per client. Nobody copies a number by hand.
- Generates the deck from one versioned template. The slide set is conditional on each client's channel mix: a Google-only client gets a different deck than a Google-plus-GA4 client.
- Runs a quality gate. A rendered deck only counts as ready when it contains zero unresolved placeholders. If a slot did not get real data, the deck does not ship.
- Fails fast on empty sources. When a required data source comes back empty (an expired token, a revoked permission), the pipeline blocks that client's run instead of shipping a hollow deck.
- Reports on itself. Delivery notices go to Slack and Asana, and a per-client run ledger tracks every deck from draft to ready to delivered.
slides per deck, conditional on each client's channel mix, from one versioned template
Under the hood, orchestration runs on a self-hosted automation platform, with client configuration and run status in Postgres. Decks are generated through the Slides API and verified programmatically before anything counts as deliverable. None of the pieces are exotic; the reliability comes from how they are gated.
The single versioned template matters more than it sounds. When the template improves, every client's next deck improves with it, and quality stops depending on who built which deck in which week. Channel mixes change, too: when a client adds a platform or pauses one, the deck follows their configuration instead of waiting for someone to remember to change the slides. The goal is not speed for its own sake. It is a deck the team can trust without re-checking every number by hand.
The dry run, honestly told
Before the system goes anywhere near a client deliverable, we exercised the entire pipeline in a full dry run across the roster: all 15 clients, end to end, aggregation through rendered deck.
in the full dry run: 13 delivered, 2 correctly blocked on external access
Thirteen decks generated, gated, and delivered, with zero unresolved placeholders on sampled output. Two clients blocked, because the pipeline could not get the account access it needed on the client side. Those two blocks are not a blemish on the run. They are the run working. A pipeline that ships a deck no matter what is a liability with a scheduler attached; this one refuses to ship anything it cannot stand behind. We would rather explain a blocked deck than retract a wrong one.
So here is the status, stated plainly: the system is validated across a full 15-client dry run, gated on per-client configuration. Validated means the full run happened, the gates held, and what remains is per-client account setup rather than open engineering questions. Concretely, that setup is access: each client's ad accounts and analytics properties have to be connected and permissioned before their run can go end to end. The two blocked clients in the dry run are that same gate doing its job.
If you are evaluating reporting automation from anyone, ask for exactly this artifact: a full-roster dry run with the failures in the tally. It tells you more than any demo, because the failure handling is the product. A pipeline that has never been watched failing is a pipeline whose failure mode is your client finding out first.
The bug worth mentioning
One fix from the dry run deserves its own section, because it shows where the real work in reporting automation lives. Early versions hard-blocked any client with an empty data source. Strictly safe, and wrong in practice: a client with healthy organic data and one empty paid source got no deck at all, when a useful deck was sitting right there.
The fix drew a sharper line. Partial-but-valid data (organic present, one paid source empty) now produces a deck built from what is real, while a missing required source still blocks the run. That distinction is judgment, not plumbing. Wiring an API to a slide template is the easy part; deciding what counts as good enough to ship in a client-facing document is the part that earns the automation its place. Expect a handful of these judgment calls in any reporting build; the dry run is where you want to find them.
Why this matters
Add it up from the agency's side of the table:
- Days of manual deck-building come back every month, across the whole roster.
- One versioned template ends quality drift between client 1 and client 15.
- Nothing ships on bad data: a broken source blocks a deck instead of poisoning it.
- The team's job shifts from building decks to reviewing them, and to talking with clients about what the numbers mean.
Reporting quietly eats 20% or more of an agency's week (Adriel, 2025). A gated pipeline hands those hours back without giving up control over what clients see.
If your reporting month looks like the before picture (days of hand-pulled data, drifting deck quality, silent failures you learn about from clients), we can walk you through what this pipeline would look like pointed at your roster. Bring your client list and your current deck. We will show you exactly what a scheduled run replaces. The numbers above came from a roster of 15, but the shape of the problem is the same at 8 clients or 30.