Capacity as a permit condition - how to keep to a limit on the day and prove it afterwards

The permit states a number. What it doesn't state is how you prove, that evening, that you kept to it.

Every larger event has a limit: people present at the same time on the site, in the marquee, in front of the stage. The authority sets it, security is supposed to monitor it, the insurer asks about it, and the sponsor wants to know the next day how many came in total. Four audiences, all wanting the same figure - just in different forms.

This article goes through how a condition in a permit becomes evidence. It builds on From number to action, which covers when a system may raise the alarm on its own, and on What the security questionnaire asks, which covers logs and the audit trail.

A limit has four parts

When people talk about capacity, they usually mean only the number. It becomes reliable only when four things come together:

Most events have the first two. The number is in the permit, and somebody watches a counter. The last two are often missing - and they are exactly what decides whether a condition turns into evidence.

See: one figure for everyone

Event control needs the count at all times, so does security at the gate, and the public ought to see it before they set off. What matters is that everyone sees the same figure. A counter for the control room and an estimate at the gate lead to two different decisions.

In practice that means occupancy against the threshold in a dashboard that refreshes every few seconds, and the same figure as a public full-screen display with a traffic light at the entrance or on the website. How such a display is built - with a key that can be revoked, and a “stale” state instead of a frozen number - is covered in Occupancy is a balance, not a count.

Act: the alert has to reach event control where it is

Nobody on site sits in front of a screen. An alert that only appears in a dashboard is therefore not an alert. It has to go to a phone or into the channel event control already has open - email, SMS, WhatsApp, Slack or Teams.

Three things separate an alert you can rely on during an event from one that only looks good:

• Delivery status per recipient. Not “alert triggered”, but: to whom, over which channel, with what result. That is the difference between a claim and a record.
• A test send before the event. The evening before, every channel is tried once. A mistyped number shows up while it still costs nothing.
• A budget that isn't empty at the wrong moment. SMS and WhatsApp cost money per message. The budget is reserved before each send, so nothing goes out twice and nothing fails silently. How that works in detail is in From number to action.

On top of that comes a threshold that can be changed without touching the installation. If the authority sets a lower limit the day before, that is a change in the software, not a call-out for a technician.

Prove: the evidence the next morning

After the event, everyone wants a figure. The insurer wants to know whether the limit was monitored and what happened each time it was approached, the authority wants the sequence of events, the sponsor wants visitor numbers, the press a headline. Today that is usually assembled from screenshots and spreadsheets, days later.

The form that holds up is a chain of records that support one another:

1. The limit: which threshold applied, since when, and who set or changed it - from the audit log.
2. The monitoring: every alert with trigger value, threshold, time and delivery status per recipient - from the alert history.
3. The crowd: entries and exits per minute, exported as a count series.
4. The report: as PDF, XLSX or CSV, sent automatically to a list of recipients the morning after if you want.

What matters is that the insurer and the authority get the same figure as the sponsor and the press. Two figures for the same weekend invite exactly the question you want to avoid.

Where the crowd gathers

A total count at the entrance tells you how many people are on site. It doesn't tell you whether they are crowding in front of the main stage while the food court is half empty. For that, each area becomes a zone with its own occupancy, dwell time and peak hour - on a one-minute grid, and for multi-day events also as a weekday pattern.

What a zone is and how dwell time is measured is covered in Measuring dwell time. For organisers there is an often underrated benefit on top: dwell time per area is the argument the next time sponsorship and stand space are allocated.

The trade fair stand: measured, not scanned

A trade fair stand easily costs six figures, and the usual measure of success is the number of badges scanned. Which product zone held visitors and which was just a thoroughfare, nobody knows after the fair.

Measured rather than scanned means that every product zone becomes a zone, with dwell time, engagement, the four behaviour stages from passing through to real interest, and the capture rate. Add to that the most common paths across the stand and the entry and exit zones. The result is a trade fair report based on measurement rather than on the stand crew's impression - and at the next fair, the zone nobody reached gets moved. The stages and the capture rate are explained in Measuring dwell time, the paths in The visitors who don't buy.

Long formats and recurring events

Two points affect organisers more than other sectors:

• Formats running for several weeks - Christmas markets, festival grounds, seasonal operations - get a visitor forecast for the next few days once there are two weeks of history, with an uncertainty band and a note on data quality. How to read such a forecast is covered in Finding a pattern is easy.
• Events that come back every year are not set up from scratch every year. A site that has been set up can be cloned - zones with capacity, thresholds, alert recipients and channels, report schedule. The process is described in Comparing sites.

What belongs in the tender

1. Is occupancy shown live against a threshold - in the dashboard and as a public display without sign-in?
2. Can the threshold be changed at short notice, and is every change logged?
3. Over which channels are alerts sent, and is there a delivery status per recipient?
4. Can every channel be test-triggered before the event?
5. How long is the alert history kept, and what does it record for each alert?
6. Can the report be sent automatically the day after, as PDF and as a spreadsheet?
7. Are there zones with their own occupancy and dwell time, and can a configured event be carried over to next year?

How we do it

The ANALYSIT Counting System shows live occupancy per site against the threshold in the dashboard, refreshed every 2 to 5 seconds, and as a public full-screen display with traffic light, ring, count and trend. Access is role-based; standard users see only the sites assigned to them.

Occupancy, restricted-area, trend and anomaly alerts go out over email, SMS, WhatsApp, Slack and Teams, with recipients and channels per site, an atomically reserved credit budget and test sends. The alert history keeps trigger value, threshold, time and delivery status for 395 days, alongside the audit log and 730 days of count data on a one-minute grid. Exports come as server-rendered PDF, XLSX and CSV, and scheduled reports go out by email with a send history.

For each zone, ACS provides live occupancy, visitor-weighted dwell time, engagement, four behaviour stages and peak hours; for trade fair stands it adds capture rate, the top 10 paths and entry and exit zones. Formats with 14 days of history or more get a Holt-Winters forecast with an uncertainty band, and configured sites can be cloned.

If you have an event with a capacity condition coming up, talk to us. Ideally before the permit arrives - so that the application already says how you will prove it.