the museum that ran on a whiteboard.

They had no shortage of data. What they didn’t have was any way to see it in one place. Retail and tickets lived in one platform, catering in another, footfall in a set of people-counters, and everything else in spreadsheets, none of it joined up. Every report was made by hand - right down to the daily visitor count, which someone on the front-of-house team read off the people-counter each day and wrote on a whiteboard, along with how many visitors crossed into the main galleries. They were good at collecting data. But turning it into the story their board and their funders needed was the bit that beat them, and they’d been hearing the same conclusion from every direction in their business planning: the data infrastructure wasn’t sorted. Fixing it meant answering two questions - which reporting would actually make a difference, and then how to build it. They’d only been asking the second.

They knew their numbers well, but no one had ever had to pick. So before anything got built, we worked it out - a questionnaire to each member of the core team, then a workshop with a deliberately unfair rule: ignore the data you have. What do you need to know, day to day?

Out of that came exact definitions the whole team stood behind: what counts as spend per head, how catering conversion is honestly measured, which of several footfall figures is the one to report. They could have started a dashboard on day one without asking any of this. But it would have been built bottom-up - the easiest data to get at deciding what the insights were. We went top-down instead: decide what would be genuinely useful to know, then work out how to get it out of the data.

Working through their systems also turned up things the manual reports had never seen: a whole stream of revenue flowing through one platform unnoticed, and a set of data-quality traps - event bar-tabs leaking into the catering figures, items with no category - each one flagged with what to do about it. Connecting the systems automatically needed developer access only their own account owners could set up - straightforward, just theirs to do - and the build could start on manual exports in the meantime.

The data is joined once and every report draws on it, rather than each report rebuilding its own version of the truth. The reports sit in Teams, where the team already works, and export cleanly for board papers.

A couple of streams stay manual - cash from the donation boxes arrives as a simple monthly file drop - but the rule throughout was: automatic wherever a system can be connected, and where a person has to be involved, the smallest possible ask.

When it was time to move the reports onto the museum’s own systems, they did the moving - me navigating, their hands on the keyboard: publishing the report, repointing it at their own data, working the credentials through. That mattered, because their systems sit inside a council’s, and the reality of council IT turned up on cue - licences that existed but hadn’t been allocated, settings locked down at the council end, and one authentication bug I’d genuinely never seen before. Some of that I took away and fixed. Some of it only their IT could fix, so I coached them on exactly what to ask for. And when the retail platform’s permissions needed upgrading and the vendor’s own documentation didn’t match what was on the screen, the account owner drove, I navigated, and it was done in minutes.

The whole thing was shaped around the museum’s own team running it. I separated using the reports from maintaining them from developing them, as three honest levels, so nobody felt they had to become a Power BI developer to get value. I built in the dull-but-vital bits: a data dictionary with what to check if something looks wrong, a documented set of targets, an orientation session, and the rule that at least two people should know the maintenance, so it survives someone leaving - because if it’s nobody’s job, it won’t get done, and the reports start losing trust. And I told them to hold off on formal Power BI training until they’d lived with the reports for a few months, rather than selling them a course they didn’t need yet.

The reports are built, live in Teams, and in use. In the first walkthrough, the team did exactly what you’d hope: they interrogated the thing - chased down a spend-per-head spike, spotted a category that wasn’t labelled, caught a bank holiday the date logic was quietly dropping.

After a few weeks of living with it they sent me a long list of tweaks, and I was glad of it: you don’t know how you want a report to work until you’ve seen your own numbers in it. Nearly all of it was tuning, done in the final snagging. Better still is what the list showed. They were debating among themselves how the events page should treat dates, and they were right. One of them was building a board argument straight from the retail numbers. And when a new colleague joined, they brought her along to the next session. Somewhere in that first walkthrough, someone said the reports would save writing the visitor number on the whiteboard every morning - which they do, along with rather a lot else.

This is the sort of work I do embedded with a team, month to month. what working together looks like - shape, rhythm, price ▸