Most head offices get a rollup by accident. Someone exports the completion data, someone else builds a sheet on top of it, a chart gets added because charts look decisive, and within a quarter there is a monthly deck that nobody can quite explain. It reports. It does not instrument anything.
This guide is about the design decision that comes before any of that: what the reporting layer is for, what it should hold, and at what level of detail. It is deliberately separate from our guide on tracking training completion across 50 locations, which covers the operational practice of getting a reliable status out of many sites in the first place. Assume here that you have the data. The question is what you build on top of it.
The obligation the rollup is instrumentation for
Start with why a head office needs a network view at all, because the answer shapes everything downstream.
In the Netherlands, Arbowet art. 8 lid 4 requires the employer to supervise compliance with the instructions and rules that have been given. Not to give them. To supervise that they are followed. That is a continuing duty with no end date, and it is the only part of art. 8 that cannot be discharged by an event. You can deliver an induction and be done with it. You cannot supervise once.
Read as a specification, art. 8 lid 4 asks for three things a reporting layer has to be able to produce: a current state rather than a historical one, a state you can resolve down to a named person, and evidence that when the state was wrong somebody acted. A dashboard that shows a network percentage and nothing else satisfies none of them.
The Arbowet prescribes no form for any of this. That is genuinely useful: nobody can tell you your rollup is the wrong shape. It also means the burden of design is yours, and a vague design produces a vague claim.
One question per view, decided in advance
The discipline that separates a working rollup from a deck is boring and absolute. Before a view is built, write down the single question it answers and the action it triggers when the answer is bad. If you cannot write the action, do not build the view.
Applied honestly, this kills most of what ends up on these screens. Time on platform answers no question. Average score across the network answers no question. A count of logins answers a question nobody in operations has ever asked.
What survives tends to be small. Which units are behind, and by how much. Who is past a deadline right now. Whether new starters are being instructed before they work or after. Whether the recurring topics you committed to are actually running at the interval you set. Each of those has an owner and a next step attached.
Write the question in the view's title if you can. A panel headed "Sites below threshold, this week" is self-documenting in a way that a panel headed "Compliance overview" never becomes.
Granularity is a design choice, not a default
The second decision is what a row means. Most rollups default to location because location is what the source system happens to key on, and then quietly fail for anyone whose operation is not organised that way.
There are four cuts worth considering, and you should choose deliberately rather than take all of them.
By unit. The site, store, property or depot. This is the right default when the intervention is a conversation with one manager.
By role. Cooks against front of house, drivers against warehouse floor. This is the cut that exposes a gap the unit view hides completely: a site can sit at a healthy overall figure while one role inside it has been assigned nothing at all.
By cohort. Everyone who started in the same month, or everyone assigned in the same wave. This is how you tell whether an induction process works, because a starter's first weeks are only interpretable against other starters, not against the tenured population.
By content version. Which revision of the procedure a person completed. This is the cut nobody builds until the first time it is needed, at which point it cannot be reconstructed backwards.
Pick the cuts your interventions actually use. A cut that produces a number you would never act on is a cut that dilutes attention on the screen.
Three audiences, and the temptation to give them one screen
A rollup serves at least three people and they want different things. An operations director wants the network state and the exceptions. A regional manager wants their own ten or fifteen units ranked against each other. A site manager wants their own people, by name, with the overdue ones at the top.
The tempting shortcut is one screen filtered by permission. It works structurally and fails behaviourally. The site manager opening a network-shaped view has to do the work of finding themselves in it, and most will not bother twice.
The better model is one data layer and three deliberately different framings. The network view is exception-first: show what is wrong, hide what is fine. The regional view is comparative: rank the units against each other, because that is the only comparison a regional manager can act on. The site view is a list of people, because that is the only object a site manager can act on.
Scope follows the same logic. A site manager sees their own location and owns it. They do not edit centrally owned assignments and they do not move deadlines on compliance content. Giving someone a number they cannot influence produces resignation; giving them a number they can influence, next to their peers, produces movement without a chase email.
Freshness is part of the specification
A rollup has a half-life. If the numbers on it are a week old, every conversation held over it starts with somebody questioning whether the numbers are current, and that argument consumes the meeting.
Decide the refresh interval per view rather than globally. Overdue counts want to be live, because the action is today. Ramp time for new starters is a trailing average and is fine at daily. Refresher coverage moves slowly and is fine at weekly.
The related decision is what "as of" means on the screen. Put the timestamp on the view. It costs one line and it removes an entire category of unproductive discussion.
What a rollup should refuse to display
Some numbers are worse than no number, because they look like measurements.
Averages across units of different sizes, where a fifteen-person site and a two-hundred-person site count the same. Percentages with no denominator visible, which cannot be sanity-checked. Any figure that requires a paragraph of definition before it can be read, because that paragraph will not travel with the screenshot. Comparisons against an external benchmark, which we deal with separately and at some length, because the borrowed number tells you nothing about your own operation.
Quality signals and learner feedback are real and worth having. They belong on a different view, owned by whoever writes the content, not on the screen an operations director opens on Monday morning.
Wiring the rollup in Aristotl
The completion view holds status by site, group and role, per course and per version, and each row resolves down to learner level. That gives you the four cuts without building a reporting layer on top of a generic schema.
Site managers get the same underlying data scoped to their own location and their own people, with no access to central content. Participants are reminded before and at the deadline, and anything running late escalates on its own: the site manager after an hour, the regional manager after four, org admins after a day. A weekly digest carries the same picture to whoever owns the network.
The export carries person, location, role, course, version, timestamp and knowledge-check result, which is the layer underneath the dashboard rather than a replacement for it. Export belongs at the end, when somebody external asks for a file, not in the middle of your own weekly review.
Write the three questions first
Before you look at any tool, write down the three questions you want answered on a Monday morning and the action each triggers. Bring that list to a demo and we will build the views against it, and tell you honestly which of the three the data cannot answer yet.