Data that cannot leave is data that cannot be used
A counting system earns its budget when its numbers reach the places decisions get made: the BI stack the executive team reads, the scheduling system that sets shifts, the tenant reports, the open-data portal. A system whose numbers live only in its own dashboard produces interesting screenshots and no change in behavior. Integration is therefore not a technical footnote in the specification; it is the clause that determines whether the purchase does anything.
What integration requirements should a people counting RFP include?
Five, specified concretely. An API with documented endpoints, authentication, rate limits, and historical access (not just the current period). Bulk export in a documented format for the full retention window. A named path into your BI or warehouse layer. Named integrations with the operational systems you actually run, workforce management in particular. And webhook or push capability if any workflow depends on near-real-time values, such as occupancy limits or queue alerts.
The requirements buyers forget until it hurts
- Historical access via API, not just live values. Analysts need to backfill; a dashboard-only history means every analysis starts over when the tool changes.
- Granularity in the API matching the granularity in the dashboard. Vendors occasionally expose daily totals through the API while showing hourly curves in their own interface, which quietly blocks exactly the staffing work the data was bought for.
- Zone and site metadata, so your systems can join counting data to your own hierarchy (region, store, door) without a manual mapping spreadsheet that rots.
- Identity of the data, not of the people. The integration should carry site and zone identifiers, never visitor identifiers, which is both a privacy property and an architectural simplification. The clause language is in contract privacy clauses.
Workforce systems are the highest-value integration
The counting integration with the fastest payback is usually into scheduling, because traffic curves translate directly into shift decisions and labor cost. The mechanics of that connection are covered in WFM integration APIs, the demand logic in demand-based scheduling, and the short-horizon forecasting in the 4-hour traffic forecast. Specify it as a named requirement with your actual WFM product in the sentence; "integrates with major systems" is not a requirement, it is a brochure line.
Ask for the failure modes too
Three questions separate a real integration from a demo: what happens when a sensor goes offline (does the API report a gap or silently interpolate, and can you tell the difference), how are late-arriving corrections handled (a recount that changes yesterday's number must be visible downstream), and what is the versioning policy for breaking API changes. Buyers who ask these get better systems; buyers who do not, discover the answers during their first quarter-end reconciliation.
Where Ariadne fits
Ariadne is built to be read by other systems: counts, dwell, and zone paths available for the BI and operational stack, with site and zone identifiers and no visitor identifiers anywhere in the payload, because none are captured. The wider question set for the specification is in the RFP template, and the downstream-feed pattern for media use cases in feeding footfall data to DSPs.
# Program 3, Cluster 5 (Procurement / specs / RFP) EN drafts: Part C (rows 252-254)
Status: EN drafts for review. Not pushed to CMS. No images, no DE yet.
Author: Govarthan.
---
