Rolling out a counting system - from the decision to the first figure that holds

The first figure arrives on day one. The first statement you can base a decision on arrives later - and how much later can be said in advance.

Between deciding on a counting system and the moment it gives a reliable answer lie three things: installation, configuration and time. Everyone plans the first two. The third is almost always underestimated, because nobody says which analysis needs how many days. A week in, someone is looking at an empty forecast and asking whether something is broken.

This article is the calendar for that: the phases of a rollout, who is responsible for what, what has to be settled before day one - and which capability becomes available on which day.

Seven phases, in this order

The order isn't a matter of taste. Each phase depends on the one before it, and a mistake made early costs effort to fix later.

Two phases deserve particular attention. The third, because it settles a detail that looks like a formality. And the fifth, because it decides whether anyone will believe the figures later.

The names are the contract

On the sensor, every counting line and every zone gets a name. That sounds like tidiness, but it is more than that: the names are the contract between sensor and software. They tell the platform whether a line counts visitors, passengers or customers at a checkout, and whether a zone is an ordinary area or a restricted one that should raise an alert on every entry.

So naming belongs in the planning, not at the end of the installation. Leave it to the installer without settling it first and you get names like “Line 3” - and later someone has to explain which door that was. One simple rule helps: the names on the floor plan are the names on the sensor, and they are the names in every report afterwards.

How a movement under the sensor becomes a stored figure, link by link, is covered in From movement to figure.

Calibration: the phase that builds trust

A counting system nobody trusts costs more than no system at all. Trust is built in the fifth phase, through a comparison that looks unremarkable: someone counts by hand, at the same time and the same door, and the two figures are compared.

Three details go with it that are easy to overlook, because they have nothing to do with the sensor:

• Country and time zone per site. Every daily and hourly total is built in the site's own time zone, and holiday calendars and country reporting depend on the country. Why that matters when sites span time zones is explained in Occupancy is a balance, not a count.
• Opening hours. A weekly grid with opening and closing times per day, plus dated exceptions. Without them there is no way to say whether the opening hours fit the demand.
• Capacities and thresholds. Maximum occupancy per site and zone, with warning and critical levels. The defaults are 80 and 100 per cent of capacity, and 5 and 10 minutes for queues. They are a starting point, not a recommendation - they get sharpened in the review.

Who is responsible for what

A rollout has five roles. Three exist in the software and two outside it - and it's the two outside that project plans tend to forget.

The first row matters most. What the installer names on the sensor decides what the software can analyse later. So the installer belongs at the table when the counting lines are planned - not once they're mounted. How roles and access are separated in operation is covered in What the security questionnaire asks.

Which capability from which day

This is the part that never appears in a quote and belongs in every project plan. Some analyses are there on day one; others need a history before they can say anything. That isn't a quirk of any particular software, it's statistics: a weekly pattern needs weeks, and a correlation needs days that vary.

Below each threshold, a good platform shows a named empty state: “not enough data yet” rather than an estimated zero or a forecast built on three days. That feels unsatisfying at first, but it's exactly what you want later - a figure that appears is a figure that holds.

Why the history should start early

One practical rule follows from that table: measurement starts on the first day data arrives. Whatever came before can't be produced after the fact, and rightly so - a visitor figure estimated in hindsight would be exactly the kind of figure The blind spot describes as the most expensive.

So if you know a refit, a campaign or new opening hours are coming in spring, install in winter. Then there's a before on the day it happens, and the forecast has matured by then. Install together with the change and you only ever measure the after.

The same goes for weather history: it's loaded for each new site, and that takes time. How much, and why it belongs in the project plan, is in Context: weather, holidays and staffing.

The three reviews

The seventh phase is the one most often skipped, because the system is running. Yet the first two months are when fine-tuning pays off most.

• After 14 days: forecasts and anomaly detection become available for the first time. Now you can see whether thresholds fire too early or too late, and which alert channels nobody reads.
• After 28 days: the weekly pattern is stable enough for planning conversations, and the best time to visit has enough history. A good moment to hold staff planning up against the figures for the first time.
• After 60 days: key drivers are solid and outliers no longer dominate. Only now is a statement about the trend worth making.

How a system raises alerts without alerting too often or too late is covered in Alerting: when a system may raise the alarm.

What belongs in the tender

1. Who names counting lines and zones on the sensor, and to what scheme?
2. How is the count checked against a manual count at go-live, and who documents the result?
3. Which analysis is available from which day, and what does the platform show while the data isn't yet sufficient?
4. What does the operator have to provide before the start - country, time zone, opening hours, capacities?
5. Which roles are there, and how is access restricted per site?
6. Are post-launch reviews part of the project, and when?

How we do it

Rolling out the ANALYSIT Counting System takes seven phases. Site survey, installation and sensor configuration sit with the installer; connection, calibration, go-live and review are shared between you and ANALYSIT. To connect, the site is created in ACS and the target address with its key is entered on the sensor; the first transmission creates the zones automatically.

Live figures and hourly and daily curves are there from the first transmission, because minute values are written atomically on receipt. Every further analysis has a server-enforced threshold and shows a named empty state below it rather than an estimated zero. The operator maintains capacities, thresholds, opening hours, country and time zone per site; recipients and channels for alerts, up to five per channel, are stored with AES-256-GCM encryption.

The roles on the platform separate the rights: the administrator manages sites, zones, alert rules, keys and users within your own tenant, and business users see only the sites assigned to them. After 14, 28 and 60 days we go through statistics, forecasts and key drivers together and sharpen the thresholds.

If you're planning a rollout and want to know when each statement will hold, talk to us. You get the calendar before the first cable is laid.