In most agencies, one person can really build dashboards, and everybody else raises a ticket. That person is usually the head of data, they usually built the reporting structure themselves, and they usually want out — not because they mind the work, but because being the bottleneck for forty client reports is a bad use of the only person who can do the hard version.
This is about the operating model rather than any one report: who owns the dashboards, how to spread the skill without losing control of what clients see, and what to build first.
Why one person ends up building every dashboard in an agency
The instinct is right — the specialists who know the accounts should own the reports for them. It’s a more effective use of everyone, and the person nearest the work writes better commentary than the person nearest the tool.
The fear is also right. If everyone builds their own dashboards, the analytics lead loses any overview of what’s going out to clients — and you do want that overview. Not to approve every chart, but because “what are we telling clients” is a question somebody has to be able to answer.
So the goal isn’t decentralisation. It’s decentralisation with a spine.
Build the reporting knowledge base before delegating anything
Before delegating anything, build the repository. This is the least enjoyable item on the list and the one that determines whether the rest works — you’ll answer the same eleven questions forever otherwise.
What goes in it:
- How our data sources are set up — which connectors, whose credentials, what’s blended and why. See the difference between a data source and a dataset for the distinction that matters most here.
- The house report structure — which pages, in what order, and what belongs on each.
- Metric definitions — what we mean by a qualified lead, which conversion we report, how we treat brand versus non-brand.
- The charts we reuse, and what each is for.
- How to fix the five things that break most often.
Format matters less than existence. Short screen recordings work well for anything procedural — they’re faster to make than documentation and people actually watch them. Written pages are better for definitions, because people need to search those.
And if the gap is skill rather than knowledge, buying the team a course is cheaper than the head of data teaching Data Studio one person at a time.
Three mechanisms that decentralise reporting without losing oversight
Three mechanisms, none of them heavy:
A house template. Everyone starts from the same report structure, so the summary page, the naming and the layout are consistent without anyone policing them. Copying and reusing a Data Studio template covers the mechanics — and use embedded data sources in anything meant to be copied, or the copies break.
One place that lists what exists. A sheet is enough: client, report link, who owns it, when it was last reviewed. Most agencies can’t currently answer “which of our clients has a dashboard and who maintains it”, and that’s the actual problem behind the bottleneck.
A review before a report goes to a new client, not before every change. Light enough to survive contact with a deadline.
Who should own which part of the reporting stack
Split it by blast radius rather than by seniority. Editing one shared data source changes forty reports; editing a chart title changes one, and treating those two as the same category of change is what creates the ticket queue in the first place.
| Thing | Owner | Why |
|---|---|---|
| The report for a client | The account specialist | They know what happened and why. Commentary written by anyone else is guesswork. |
| The house template | The analytics lead | One structure, changed deliberately. |
| Reusable data sources and blends | The analytics lead | Editing one changes every report using it — that blast radius needs a single owner. |
| Metric definitions | The analytics lead, agreed with account leads | Definitions drifting between clients is how two reports contradict each other. |
| Data source credentials | A role, not a person | See below. |
The reporting credentials problem nobody plans for
Two things break quietly when somebody leaves.
A scheduled email runs under the credentials of whoever last saved it — so when that person’s account is deactivated, the schedule fails silently, often weeks later. And a data source on owner’s credentials stops working when the owner loses access.
Both are documented rather than folklore. Google’s own note on scheduled delivery states it directly: schedules run using the credentials and permissions of the user who last saved the schedule, and if that account becomes inactive or loses permissions, the schedule fails. The documented repair is equally mechanical — an active user with edit access opens the report, goes to Share → Schedule delivery, edits the failing schedule and saves it, which re-saves it under their own credentials.
Both are avoidable with one habit: own reporting assets with an account that will still exist next year, and audit scheduled reports as part of offboarding. Most agencies discover this when a client asks why the monthly report stopped arriving. The mechanics are in how sharing and scheduling a Data Studio report works.
The review step that survives contact with a deadline
Every agency that decentralises reporting invents a review process, and most of them die within two months because they were designed for a quiet week. The version that lasts has three properties, and none of them is thoroughness.
It triggers rarely. Review a report before it goes to a new client, and after a structural change — a new data source, a new page, a redefined metric. Not before every monthly send. A gate that fires twelve times a year per client will be routed around by March.
It has a fixed, short list. Does every scorecard have a comparison? Is the summary page first and free of filter controls? Is every metric on it defined the same way as on the other clients’ reports? Is the data source a shared one rather than a personal copy? Whose credentials is it running on? Five questions, five minutes.
It produces a decision, not a discussion. Ship, or ship with a named fix and a date. A review that can end in “let us think about it” is a review that blocks a send.
The point of the gate isn’t quality control on individual charts — the account specialist is better placed to judge those than the analytics lead is. It’s to catch the four things that are expensive to unwind later: an inconsistent metric definition, a personal-account data source, a missing summary page, and a report built outside the house template.
Knowing whether any of this worked
Reporting operations is an internal project, which means it competes with billable work and will be quietly deprioritised unless somebody can say what changed. Four numbers are enough, and all four are countable without a system.
How many people have edited a client report this quarter. If the answer is one, nothing has changed regardless of how much documentation exists.
How many reporting requests reach the analytics lead per week, and what share of them are last-mile changes — a title, a date range, a text box — versus genuine architecture. The goal isn’t fewer requests; it is that the remaining ones are all hard.
How many clients have a report at all, and how many of those have a named owner. Most agencies can’t answer this, and the gap between the two numbers is usually the actual problem.
How long it takes to produce a report for a brand-new client. This is the number the house template exists to move, and it’s the easiest one to put in front of a managing director.
Open a channel for charts that worked with a client
The highest-value, lowest-effort thing on this list.
A channel where anyone can say: “I added this chart to a client report, it landed really well, should we put it on the others?” That’s it. No process, no approval.
It works because the best reporting ideas come from account teams reacting to real client conversations, and those ideas currently die in one report. One person finding that a wasted-spend flag changes the tone of a monthly call is worth propagating to thirty accounts, and there’s usually no route for that to happen.
Run a session on what the dashboards don’t currently show
Once or twice a year, get the account teams and the analytics lead in a room and ask what the dashboards don’t currently show.
Structure it around the input and output metric map: for each client outcome, what work drives it, and is that work visible in the report? Most gaps turn out to be input metrics nobody thought to track — technical fixes shipped, content published, links earned — which are exactly the things that let you show progress before results exist.
Then decide together who builds what, based on who has the knowledge, the skill and — realistically — the time. It’s an agency; capacity is the binding constraint and pretending otherwise produces a list nobody actions.
Nobody should be the only person who can edit a client report
The target isn’t everyone becoming an analyst. It’s that every account person can edit a report without asking — change a date range, add a text box, fix a chart title, write the commentary.
That’s a low bar and it removes most of the tickets. The genuinely hard things — blends, calculated fields, data source architecture, anything with a blast radius — stay with the person who should be doing them.
Which is the actual answer to the delegation question: don’t hand over the dashboards, hand over the last mile of them. The analytics lead keeps the plumbing and stops being asked to change a title.
Six things to do first when reporting is bottlenecked
- List what exists. Every client, every report, who owns it. An afternoon, and it usually surprises people. While you are in each report, paste a measurement ID into it — tracking which of your reports anyone actually opens turns the next version of this list into evidence rather than a guess.
- Fix the credentials. Anything owned by a leaver or a personal account, reassign now.
- Write the five definitions that get asked about most.
- Build one house template and move the next new client onto it.
- Open the chart-sharing channel. Costs nothing.
- Record three short videos covering the three most common requests you get.
The repository is the big one, and it’s the one that keeps getting postponed because it isn’t billable. It’s also the only item that compounds.
Frequently asked questions
Who should own client dashboards in an agency?
The account specialist owns the report for their client, because they know what happened and why. The analytics lead owns the house template, reusable data sources, blends and metric definitions — the things with a blast radius. Split it that way and most requests stop needing the analytics lead at all.
How do I stop being the only person who can build dashboards?
Build the knowledge base first, then hand over the last mile rather than the whole thing. Every account person should be able to change a date range, add a text box and write commentary without asking. Blends, calculated fields and data architecture stay with you.
What happens to Data Studio reports when someone leaves the agency?
Two things break quietly. Scheduled emails run under the credentials of whoever last saved them, so they fail when that account is deactivated. And data sources on owner’s credentials stop working when the owner loses access. Own reporting assets with an account that will outlive the individual, and audit schedules during offboarding.
Where to go next on agency reporting operations
- Data storytelling for marketers: the full guide
- Presenting a Data Studio report to a client
- Metrics that tell a story, and the ones that do not
- How to build an executive summary page in Data Studio
- Data sources versus datasets in Data Studio
- How to copy and reuse a Data Studio template
- How to track who actually uses your Data Studio reports