How to report on fifty clients without fifty rebuilds.

The usual agency setup is one dashboard per client, built by copying the last one and pointing it at new accounts. It works, and it makes every client a separate object to maintain.

A platform changes a field and you fix it fifty times. A client asks for a new metric and it exists on their dashboard only. Somebody leaves and takes the knowledge of which of the fifty were built the old way. The effort per client is roughly constant, so the total grows with the roster and nothing you do about individual dashboards changes that.

Separate the two things that got mixed together: the data and the layout.

Model the data once, so every client's numbers live in the same tables with the same column names and a client identifier on every row. Then build the layout once, as a template that takes the client as a parameter.

Adding a client becomes connecting their accounts. The template already knows what to draw, because the shape of the data does not vary by client. This is the whole idea, and everything below follows from it.

Four things, and three of them are decisions rather than work.

• The same metric definitions for everybody

  One definition of a conversion, one currency for reporting, one grain per table. A client who wants their own definition of a metric wants their own template, and that is a decision to make deliberately rather than by accident.

• A client identifier on every row

  Not a table per client. One set of tables with a client column, which is what lets one template serve all of them and one query answer a question about the whole roster.

• A naming convention that holds

  Campaign tags are the join between spend and behaviour, and inconsistent tagging is per-client work that never ends. Fix it once, upstream, for everyone.

• Access per client, enforced

  One set of tables means every client's data is in the same place, so who can see what has to be a permission rather than a convention. This is the part that is genuinely work.

Questions about the roster become answerable. Which clients are underspending, which accounts have not delivered in three days, which sectors are seeing costs rise. None of those can be asked of fifty separate dashboards, and all of them are one query against one set of tables.

Reviews also get shorter, because a number that looks wrong for one client can be checked against the same figure for every other client rather than investigated in isolation.

Every client's platforms land in one warehouse you own, modelled into one set of tables with the client on every row. You assign a template per client, and each client sees only their own data, through a login to your portal or a dashboard you share. There is no second copy of the data per client.

Monitoring runs across the whole roster rather than per dashboard, which is what makes a stalled account something you are told about instead of something a client notices first.