The pre show countdown dashboard for the final week

Eight days out. The operations lead asks in the stand-up whether the exhibitor manual chase is finished, and three people give three different answers, all of them from different systems and none of them from that morning.

The number existed. It was in the onboarding portal, in a view somebody would have to log into and filter. By the time anyone looked it up the conversation had moved on and the decision it would have informed, which was whether to put two more people on the phones, got made on a hunch.

A pre show countdown dashboard exists to stop that specific waste. It is a different artefact from the weekly report the rest of the year, it has a life of about ten days, and the design constraint that governs everything else is that in the final week nobody scrolls.

What the final week can still change

Start by throwing out everything the week cannot affect. Prior edition comparisons, verified attendance, exhibitor satisfaction, revenue against annual budget. All real, all worth reporting, none of them actionable on the Tuesday before doors.

What survives is four things.

Pace against the registration target. Where the number is against where it needs to be, with the remaining gap in absolute terms rather than as a percentage, because the gap is what gets divided among the channels still running. Reading that pace properly against the show's own history is a method the audience acquisition cluster owns, and the countdown page should display the result rather than re-derive it.

Registrations at risk. Registrations that exist but are incomplete: unverified email addresses, unpaid paid-registrations, approval-pending trade applications, badges not yet collected where collection is required in advance. Each of these is a registration that will not become an attendee unless somebody chases it, and the final week is when chasing works.

Exhibitor deadline completion. Certificates of insurance, booth services orders, stand plans, whatever your show gates on. Expressed as a count of accounts with something outstanding rather than a completion percentage, because a person can call thirty accounts and cannot call 94 per cent.

Staffing against plan. Registration desk shifts filled against shifts needed, by day and by session. This is the one most often missing, and it is the one where finding the gap on the Tuesday rather than the Sunday is worth the most.

Four subjects, six tiles once you split pace into current and gap, and split risk into count and value. One filter, for the edition, if you run more than one show at a time. No second filter, because a filter the reader has to set is a filter that will be set wrong at eight in the morning by somebody holding a coffee.

Can you really refresh it hourly?

Probably not, and the answer depends on a platform limit most teams discover the week they need it.

Microsoft's data refresh documentation for Power BI, on Microsoft Learn and dated September 2025, states that "Power BI limits semantic models on shared capacity to eight scheduled daily semantic model refreshes". On a Premium, Premium Per User or Fabric capacity the ceiling rises: "you can schedule up to 48 refreshes per day". The same page notes that on shared capacity a refresh must complete in under two hours or it fails.

So the honest options are eight refreshes a day, or one every thirty minutes if somebody is paying for dedicated capacity. Hourly sits between the two and is available only on the paid tier, where it is well inside the limit.

Live refresh is a separate mechanism with its own constraint. Microsoft's automatic page refresh documentation, dated December 2025, is explicit that the feature works only against DirectQuery sources and that in a shared capacity workspace "automatic page refresh has a minimum interval of 30 minutes", with change detection unavailable entirely. On dedicated capacity the floor drops to one second, though the capacity administrator sets a minimum that defaults to five minutes. If your model is in import mode, which most event reporting models are, the page refresh option does not appear at all.

The design consequence is worth stating plainly. Decide the refresh cadence before you design the page, because a page built to look live and refreshed twice a day is a page that will be quoted wrongly.

Placing eight refreshes where they matter

If eight a day is what you have, spacing them evenly across twenty-four hours gives one every three hours, which is the worst available choice. Overnight refreshes serve nobody and consume half the quota.

Place them across the working day instead. Six in the morning, then eight, ten, twelve, two, four, six and eight in the evening gives eight refreshes covering fourteen hours at two hour intervals. The first lands before anyone arrives, so the page is current at the start of the day, and the last lands after the evening registration surge that most B2B shows see in the final week.

Weigh them if the day is uneven. A show whose exhibitor chase happens in the morning and whose registration surge happens after five could run four refreshes between seven and eleven, then two at midday and two in the evening. That gives hourly freshness in the window where a stale number costs something, and four-hourly freshness the rest of the time, out of the same quota of eight.

The arithmetic is trivial and almost nobody does it. The default schedule most teams accept is two refreshes, at six in the morning and six in the evening, which is a quarter of the quota they already pay for.

The timestamp is part of the tile

Put the refresh time on the page, in the reader's local time zone, at a size somebody can read without leaning in.

Two reasons. The first is that a figure with a known age can be reasoned about and a figure without one cannot: an exhibitor completion count from two hours ago is fine for a stand-up and useless for a decision about tonight's call list. The second is that a visible timestamp is the fastest way to find a broken refresh, because the person who notices is the reader rather than the owner.

There is a version of this that goes further and is worth the effort on a countdown page. Stamp each tile with the age of its own source rather than stamping the page once. On a page pulling registration from one system, exhibitor documents from another and staffing from a rota spreadsheet, the three feeds have different lag, and a single page-level timestamp claims a freshness the slowest feed does not have. Whether a stale figure should show its age or refuse to render is a judgement about your readers, and I would show the age and colour it once it passes a threshold, because a blank tile makes people assume the number is zero.

What about a live board in the operations room?

Different artefact, and the temptation to make the countdown page do both is strong because the tiles overlap.

A wall board is read from four metres by people walking past, which means two or three numbers at most and type large enough to read across a room. It is watched during the hours the desks are open, so it wants the fastest refresh the platform allows and it is the one case where paying for dedicated capacity to get a thirty second interval can be justified. It carries operational figures rather than commercial ones: queue length, scans in the last fifteen minutes, hall occupancy.

The countdown dashboard is read at a desk by four or five named people making decisions about the next twenty-four hours. Build both if you need both, and resist merging them, because the merged version is a wall board nobody can read from four metres and a working page cluttered with numbers that change every minute. On-site operational measurement during show days is a subject in its own right and sits outside this page entirely.

Where this stops

The countdown dashboard is only as good as the systems feeding it, and the exhibitor deadline tile is where that bites.

Registration data lives in one platform with an API and arrives reliably. Exhibitor document status often lives in a portal whose export is manual, or worse, in the head of the person running the chase. A tile fed by a spreadsheet someone updates when they remember will be wrong on exactly the morning it matters, and it will be wrong in the reassuring direction, because the person forgot to add the new problems rather than forgetting to remove the solved ones.

If you cannot get that feed automated before show week, my view is to leave the tile off rather than show a figure whose provenance is a memory. An absent tile prompts somebody to ask. A stale tile stops them asking. The general problem of proving where a displayed number came from, and being able to open the rows behind it when somebody disputes the count, is worth solving properly before the next edition rather than during this one.

The second limit is that six tiles is a budget rather than a law, and the reasoning behind that particular ceiling applies to a page somebody scans. A countdown page in the last three days gets opened fifteen times a day by the same four people, who learn it fast, so seven or eight tiles is survivable there in a way it is not on the weekly report.

Set up the refresh schedule this week, before you touch the layout. Open the semantic model settings, count how many of your eight daily slots are actually in use, and move them onto the hours your team is working. It takes ten minutes and it is the highest return change available to any event business intelligence team in the fortnight before doors.