Agency Dashboards and the Reporting Stack for Owners

Search for an agency dashboard and most of what comes back is template galleries and software marketing dressed as advice. Neither answers the question an owner is actually asking, which is not what should my dashboard look like, but what should I be able to see on a Monday morning without having to ask anyone.

I have spent twelve years running delivery operations for digital marketing agencies, across 79 completed engagements with a 4.9 out of 5 client rating. I work inside ClickUp, Asana, Monday.com, Airtable and Notion, and I automate across them with n8n. I have no reseller relationship with any of them, which is worth saying early, because a lot of dashboard advice is written by people who get paid when you buy the platform underneath it.

Which agency dashboard are we talking about?

An agency has two of them, and treating them as one is the first mistake. The client-facing dashboard reports campaign performance to the people paying for it: traffic, rankings, leads, spend. The internal one reports the state of your delivery: what shipped, what is slipping, who is overloaded, what the work earned. They share a name and very little else. Different reader, different cadence, different consequence when a number is wrong.

This article is about the internal one. It is the harder of the two to build, because the client dashboard has an obvious audience who will complain when it is missing, and the internal one has an audience of one or two people who can always ask someone instead. That asymmetry is why plenty of agencies run a polished client reporting stack on top of an operation nobody can see.

What four questions should an agency dashboard answer?

Four. If something on the screen does not serve one of them, it is decoration, and decoration is what makes a dashboard tiring to read.

• What shipped. Completed work in the period, at a level of detail leadership recognises, which usually means per client rather than per task. This is the only tile that will make anyone feel good, and it is also the one most agencies leave out.
• What is at risk. Not what is late. Late is history, and it needs no dashboard because a client has usually told you already. At risk means work whose promised date is still in the future and is no longer credible. Surfacing that early is the entire reason the view exists.
• Where the hours went. Time against clients and against types of work, including the work nobody scoped. Every agency I have worked inside has a category of unbilled effort nobody has named, and it shows up in the hours long before it shows up in the money.
• What it earned. Revenue against delivery cost per client, at whatever accuracy your time data can honestly support. This is the tile that turns an operations view into a leadership one, and the tile most likely to be quietly dropped when the hours data is weak.

Those four are the design brief for the entire stack. Everything underneath exists to answer them. The specific measures I watch inside each question are set out in my agency operations guide, and I am not going to repeat them here.

Why does an agency dashboard get built and then ignored?

This is the normal outcome rather than the exception. I have watched dashboards built with real effort go unopened inside a quarter. The causes repeat:

• It was built from what the tool exports. The available fields decided the layout, so the view answers questions nobody asked and misses at least one of the four that matter.
• It needs a person to update it. Anything that depends on a Friday afternoon of copying goes stale in the first genuinely busy week, and a stale dashboard is worse than none, because people act on it before they check the date.
• Too many tiles. A screen carrying thirty numbers has no priority, so the reader supplies their own and looks at whichever number is reassuring.
• No decision is attached to it. If nothing is ever done differently because of what it showed, it is a report, and reports get read once.
• Nobody owns it. Definitions drift, a status gets renamed, one feed breaks, and the numbers stop matching what the team knows to be true.

The last one decides the others. A dashboard runs on trust, and it only has to be visibly wrong once in front of the team before everyone goes back to asking the account manager instead. Give it a named owner with time in their week, or do not build it.

What are the layers of an agency reporting stack?

Three. They get built in the wrong order almost every time. Design top down, starting from the four questions. Build bottom up, starting from the data.

Layer one: the source data

Where the work is actually recorded: your project tool, your time entries, your invoices. This layer sets the ceiling for everything above it. If a stage has no written exit condition, nothing higher up can tell you whether an item is genuinely done or simply dragged across a board. If time is entered from memory on a Friday, the hours question has no honest answer available anywhere in the stack.

Layer two: the rollup

The aggregation between raw records and the view: definitions applied, records joined across tools, the period fixed. This is where automation earns its fee, and it is the layer agencies skip, wiring a chart directly onto a task list and then wondering why two views of the same week disagree. It is ordinary rule-based automation rather than anything clever: scheduled pulls, somewhere to hold the result, and one written definition per number.

One warning for anyone starting here. Do not automate a definition that is still moving. If the team is still arguing about what counts as delivered, an automated rollup gets rebuilt every time the argument settles differently. Fix the definitions by hand first, even if that costs you a manual month.

Layer three: the one view leadership opens

One screen, no scrolling, four to six tiles, answering the four questions and nothing else. It should be readable in under a minute by someone who sat in none of the meetings behind the numbers. Everything else lives one click deeper, for the person who needs to investigate rather than the person who needs to decide.

Can a dashboard be more honest than the data underneath it?

No. That is the sentence I would hang above every reporting project. A dashboard inherits the honesty of the data beneath it and then presents it with more confidence than it has earned.

The failure modes are behavioural rather than technical. Tasks marked complete to clear a board before the work is finished. Due dates moved instead of missed, which makes on-time delivery look excellent while clients experience something else. Hours logged in round numbers three days late. None of that is dishonesty in any meaningful sense. It is a team responding to what the system rewards. Run it through a well-built dashboard and it comes out the other side looking like measurement.

Automation makes this worse before it makes it better, because it removes the person who used to notice that a number looked wrong while assembling the report by hand. So the order matters: fix the recording behaviour, then automate the rollup. Working out which of your inputs can currently be trusted is the first thing I do in an Agency Ops Audit, and it is usually the finding that changes the most.

Who opens it, and how often?

A dashboard nobody is required to open on a schedule decays, however well it was built. Attach it to something that already happens. What is at risk belongs to a weekly delivery conversation, because a risk surfaced monthly is a post-mortem. Where the hours went and what it earned belong to a monthly review, because they move too slowly to mean anything week to week and provoke bad decisions when read as noise.

Whoever opens it has to be able to act on it. Giving the risk view to someone who cannot move a deadline, reassign a person or call a client produces awareness without recourse, which is a reliable way to make a good dashboard feel useless.

So should an agency build a dashboard or buy one?

My verdict: build the thinnest possible version inside the tool your work already lives in, look at it every week for a month, and buy nothing until the definitions have stopped moving. Buying first means buying a presentation layer for data that was not ready to be presented.

Buying is right in a narrower set of cases than the market implies: when your data genuinely lives in several systems that are not going to be consolidated, when someone internal owns the result and has time in their week for it, or when the money question needs finance-grade accuracy rather than an operational estimate. Those cases are real. They are not the situation of most agencies between five and fifty people, where the binding constraint is that delivery is not recorded consistently enough to be summarised, and no purchase repairs that.

So the smallest honest version is four questions, one screen, whatever your existing tool can already display, updated by hand until it earns the effort of automating. If it changes one decision in the first month, it has earned the rollup layer. If it changes nothing, more tooling will not rescue it, and the problem sits upstream in how the work is recorded.

Where to start

The sequence: agree the four questions with whoever will read the view, check which of them your current data can honestly answer, build one screen for those, then automate the rollup for the ones that survived. The questions your data cannot answer yet are not dashboard problems. They are process problems in a dashboard costume, and they are usually the most valuable thing the exercise finds.

If you would rather not sort that out alone, it is what the Agency Ops Audit is for: $1,500 fixed, two weeks, a written 90-day roadmap and a 60-minute readout covering what your operation can measure today, what it cannot, and what to fix first. If the answer turns out to be four tiles and a Monday meeting rather than a platform, that is what the readout will say.