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.
The bottleneck is real, and so is the fear of removing it
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 knowledge base first
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 data sources vs datasets 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.
Democratise, but keep the overview
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 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 owns what
| 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 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 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. More on how that fails.
Open a channel for charts that worked
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’s missing
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 inputs and outputs: 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 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.
Where to start
- List what exists. Every client, every report, who owns it. An afternoon, and it usually surprises people.
- 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.
Isn’t letting everyone build dashboards risky?
Losing sight of what clients are being shown is the real risk, and it’s solvable without centralising the work: one house template, one list of what exists and who owns it, and a review before a report goes to a new client.
What happens to 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.
What should go in a reporting knowledge base?
How the data sources are set up and whose credentials they use, the house report structure, metric definitions, the charts you reuse and what each is for, and how to fix the five things that break most often. Short screen recordings for anything procedural; written pages for definitions, because people search those.
How do we share reporting ideas across account teams?
Open a channel where anyone can flag a chart that worked with a client and ask whether it should go on the others. No process. The best reporting ideas come from account teams reacting to real client conversations, and they currently die in one report.