The failure mode is silence
Counting systems rarely fail loudly. A sensor drops offline, a lens gets obstructed by a seasonal display, a firmware update changes a threshold, and the dashboard keeps producing numbers that look entirely reasonable and are wrong. Weeks later somebody notices a store whose conversion improved suspiciously. Every service term worth negotiating exists to shorten that interval, because a counting system's real availability is not uptime, it is the time to notice that a number stopped being true.
What should a people counting SLA cover?
Six things. Monitoring and alerting on sensor health, with the alert going to you and not only to the vendor. A defined response time for a failed sensor, and a separate, longer one for a suspected accuracy drift, which is the harder case. Data gap handling: whether missing periods are reported as gaps or interpolated, and how the difference is visible in reporting. Calibration cadence and who performs it. Firmware policy, including whether updates that could change counting behavior require notice. And end-of-term terms: data export, hardware ownership, and decommissioning.
Silent-failure detection is the clause that pays
Ask specifically how the system detects that a sensor is producing plausible but wrong numbers, not merely that it went offline. Good answers exist: cross-validation between independent sensing streams, statistical drift alerts against the site's own history, and periodic reference checks. The structural version of the first answer is described in sensor fusion for people counting, where two independent streams measuring the same building disagree when one drifts. A vendor whose only failure detection is a heartbeat has told you your data quality is your problem.
Calibration is a cadence, not an event
Sensors are commissioned accurate and drift with the building around them: displays move into the field of view, doors get propped, entrances get reconfigured for a season. Specify a calibration cadence, an event-driven trigger (any physical change at a monitored entrance), and a verification method so calibration is provable rather than asserted, per people counter calibration and the reference procedure in accuracy test methodology. The recurring cost of all this belongs in the five-year model, per total cost of ownership.
Data gaps and the reporting truth
Decide with the vendor, in writing, what a gap looks like downstream. Interpolated data that is not labeled as interpolated will eventually be used in a board pack, and someone will make a decision on a number a model invented. The defensible default: gaps are reported as gaps in the API and flagged in the interface, with interpolation offered as an explicit, labeled option. The integration consequences are in integration requirements.
End of term, decided at the start
Three questions that are cheap now and expensive later: who owns the hardware when the contract ends, in what format and for how long can the historical data be exported, and who removes and disposes of the sensors. Buyers who leave these to the exit conversation negotiate them from the weakest possible position. The clause set sits alongside the privacy terms in contract privacy clauses.
Ariadne's position on all of the above is that service terms should be written down and testable; the pilot is the right place to test them, per pilot to contract.
---
