People counting RFP template: the questions that make vendors comparable

Why a structured RFP is the only way to compare counters

Two people-counting vendors can both reply to a vague request with "yes, we do that," and still ship systems that count differently, store different data, and bill on different terms. The gap is not in the products; it is in the question. Ask "how accurate is your counter?" and you get a headline number with no conditions attached. Ask "what is your mean error and its range across a four-hour test at a 3-metre entrance with a high group mix?" and the answers stop being comparable marketing and start being comparable engineering. A request for proposal works when every vendor answers the same precise question in the same units, so you can lay the responses side by side and see real differences instead of differences in confidence.

This is a vendor-neutral template you can paste into your own document. Each section below gives the requirement and the exact questions to put in writing. Use it for retail, malls, airports, or smart-building tenders; the sections do not change, only the entry geometry and the volume do. There is no file to download here, and you do not need one: copy the headings and questions straight into your RFP.

The RFP sections, with the questions to ask

1. Accuracy, with test conditions

Accuracy is the section most often answered with a single number and no context. A counter can be 99 percent accurate on quiet, single-file traffic and far worse at a busy wide entrance. Demand the conditions, not just the figure, and require the same units from every bidder. The companion people-counter accuracy test methodology explains why an unconditioned percentage is unfalsifiable and how to run the test yourself.

• State your published accuracy as a mean error and a range, not a single number. What test produced it?
• Under what conditions was that number measured: entry width, footfall density, lighting, group mix, and the length of the test window?
• Which sensor model and firmware version produced the figure, and is it the same hardware and firmware we would be buying?
• Will you support an on-site acceptance test on our busiest door, against a manual ground-truth count, before sign-off?
• How does accuracy change between quiet hours and peak hours at our entry width?

2. Bidirectional counting

A counter that reads inward traffic well can still drift over a trading day if it handles exits and re-entries poorly, because errors accumulate in both directions. For occupancy and conversion you need separate in and out counts that stay coherent across a full day.

• Do you count entries and exits separately, and report both?
• How are re-entries handled when the same visitor leaves and returns within a short window?
• What is the accuracy of your live occupancy figure across a full trading day, and how does directional error accumulate?
• Can the system flag tailgating or two people crossing abreast in opposite directions at once?

3. Group resolution

Families and pairs entering together are the single biggest swing factor for a naive counter, because a group that crosses the threshold together can collapse into one count. A door with a high family mix will expose group blindness that a solo-heavy door hides, so the question belongs in writing.

• Does the system resolve distinct people within a group, or does a family entering together count as one?
• What is the measured accuracy specifically at high group mix, separate from the overall figure?
• How does group resolution behave as density rises and bodies overlap at the entrance?

4. Privacy, no PII, and GDPR

For a European deployment the data the sensor captures is a buying criterion, not a footnote. The strongest position is identifier-free counting: no images, no faces, no MAC address by default. Ask precisely what is captured, where it is processed, and what the legal basis is, so the answer is verifiable rather than reassuring.

• What personal data does the sensor capture, if any: images, faces, MAC addresses, device identifiers, biometric data?
• If you sense phone signals, is any identifier stored by default, or only on explicit opt-in?
• Where is data processed and stored, and in which region?
• What is the GDPR legal basis, and can you provide a data processing agreement and a record of processing activities?
• Does the system perform any demographic or biometric profiling? If so, how do you address the EU AI Act?

5. Coverage and mounting

An accuracy number means nothing if the sensor cannot physically cover your opening. Wide entrances, high ceilings, glass facades, and skylights all affect what a sensor can see, so coverage and mounting need explicit answers per site.

• What entry width does a single unit cover, and how many units do our entrances need?
• What mounting height and position does each sensor require, and is overhead mounting available?
• How does the sensor handle direct sun, glare off a glass entrance, and low evening light?
• What is the field of view, and does it cover the full opening including the outer margins where people skirt the detection zone?
• What power and network connection does each unit need?

6. Integration and API

Counts that live only in a vendor dashboard are worth far less than counts you can join to sales, staffing, and your own reporting. Ask how data leaves the system before you are locked into a closed portal.

• Do you provide a documented API for raw and aggregated counts, and at what interval?
• What export formats are available, and can data be pushed to our data warehouse or BI tool?
• Do you support webhooks or a real-time feed for live occupancy?
• What integrations exist with point-of-sale, staffing, or building-management systems?
• Who owns the data, and can we export the full history if we leave?

7. Reporting

Reporting is where most of your team will actually meet the system, so judge it on the metrics you run the business on, not on the number of charts.

• Which metrics are reported out of the box: entries, exits, occupancy, conversion, dwell, peak hour?
• Can reports be segmented by door, zone, store, and time period?
• How granular is the data: per minute, per 15 minutes, hourly?
• Can we build custom dashboards and scheduled exports, and how many user seats are included?

8. Support and SLA

A counter that drifts unnoticed quietly corrupts every decision downstream, so support and uptime commitments belong in the contract, not the sales call.

• What is the uptime commitment, and how is sensor health monitored and alerted?
• What is the response time for a faulty unit, and who handles replacement?
• What is the support model: hours, channels, and escalation path?
• How and how often is firmware updated, and does an update risk changing the count baseline?
• What is the hardware warranty period?

9. Pricing

Compare total cost over the term, not the headline per-sensor price. Hardware, software, installation, and renewal can sit in different columns for different vendors, which is exactly why you require a single broken-down format from all of them.

• Break the price into hardware, software or licence, installation, and any one-off setup, per unit and per site.
• Is software billed per sensor, per site, or per user, and how does it scale as we add doors?
• What does the price look like over a three-year term, including renewal?
• Are firmware updates, support, and replacements included, or billed separately?
• What are the contract term, notice period, and any early-exit cost?

How to score the responses

Once every vendor answers the same questions, score them rather than reading impressions. A simple weighted matrix keeps the decision honest and auditable. Set the weights before you read the responses, so a polished answer does not quietly inflate its own importance.

1. List the requirements as rows. One row per question above, grouped by section, so nothing is decided on a single dimension.
2. Weight each section to your use. A conversion-driven retailer weights accuracy, group resolution, and integration highest; a compliance-driven estate weights privacy and GDPR highest. Decide the weights first.
3. Score each answer on a fixed scale. For example 0 for no answer, 1 for a vague claim, 2 for a specific answer, 3 for a specific answer plus evidence or an acceptance test you can run.
4. Penalise missing conditions. An accuracy figure with no test conditions scores as a vague claim, not a specific answer, however high the percentage.
5. Multiply, sum, and compare. Weight times score per row, summed per vendor, gives a comparable total and shows exactly where each bidder is strong or thin.
6. Verify the top scorer on site. Run the acceptance test on your busiest door before signing, because the responses narrow the field but your own door decides the purchase.

How Ariadne answers these questions

Ariadne is one vendor you might put this RFP to, so here is how the method answers the hardest sections rather than a headline to take on faith. Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.

Mapped onto the RFP sections, that means accuracy holds across entry width and density because two independent feeds are cross-checked centrally rather than one feed merging overlapping bodies; group resolution works because the patented signal sensing resolves distinct people in a group while Time-of-Flight adds a device-independent body count, so a family does not collapse into one; bidirectional counting does not drift because each visit is followed as a single trajectory; and the privacy section is answered by design, since the streams carry no MAC address, no device identifier, and no biometric data, with identifiers stored only on explicit opt-in. You can confirm the models, mounting, and field of view against the Ariadne sensor lineup before a trial, and read the wider people-counting platform overview for reporting and integration detail.

A category review of people-counting systems is a useful way to build the shortlist you send the RFP to, but the scored responses and your own on-site test are what should decide the purchase.

FAQ

What should a people-counting RFP always include?

Accuracy with its test conditions, bidirectional counting, group resolution, privacy and GDPR, coverage and mounting, integration and API, reporting, support and SLA, and a broken-down price. The point is that every vendor answers the same precise questions in the same units, so the responses are comparable.

How do I make accuracy claims comparable?

Require each vendor to state accuracy as a mean error and a range, tied to a stated entry width, density, lighting, group mix, and window length, on the same hardware and firmware you would buy. An unconditioned percentage scores as a vague claim, and an on-site acceptance test on your busiest door is the figure that should decide it.

Do you need cameras to count accurately?

No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.