The pilot that decides nothing
The standard counting pilot: a vendor installs a sensor for a month, sends a dashboard, everyone agrees it looks plausible, and the decision gets made on price anyway. That pilot cost real time and produced no evidence, because nobody wrote down what it was supposed to prove. A pilot is an experiment, and experiments need a hypothesis, a measurement, and a decision rule fixed in advance.
How do you run a people counting pilot that leads to a decision?
Write the decision rule first: the specific results that mean yes, the results that mean no, and who decides. Then design the trial to produce exactly those results: representative sites (including your hardest door, not just the easy one), a ground-truth accuracy test with a written method, a defined duration covering real peak conditions, one integration proven end to end, and a service test (raise a real support ticket and time the response). Everything else in a pilot is decoration.
Choose the sites that can fail
Pilots get run at the flagship, which is the site most likely to succeed and least likely to teach anything. Include at least one genuinely hard case: a wide entrance, a glass frontage in strong sun, a door with heavy group traffic, or the awkward mezzanine everyone avoids discussing. If the system handles your hardest door, the rest of the estate is arithmetic; if it only handles the easy one, you have bought a rollout full of surprises. Site-selection groundwork is covered in the pilot project guide.
The four tests worth running
- Accuracy against ground truth, using a written procedure and the metric definition your specification chose: accuracy test methodology, definitions in people counting specifications.
- Integration end to end. One real data path into a system you actually use, not an export screenshot: integration requirements.
- Operational fit. Can your own team read the dashboard and make one decision with it during the pilot? An unused report is a failed feature regardless of its accuracy.
- Service reality. Open a genuine ticket and record what happens, then compare it to the response times you will be asked to sign: maintenance and SLA.
Convert the pilot into contract terms
The pilot's real output is contract language. The accuracy result becomes the acceptance threshold (acceptance testing). The integration work becomes a delivery milestone. The service experience becomes the SLA you negotiate rather than the one you accept. And the pilot's per-door effort becomes the honest input to the five-year cost model in total cost of ownership, replacing the vendor's rollout estimate with your own measured one. Feeding those numbers into the internal argument is what the business case is for.
When the answer is no
A pilot that ends in no is a success worth budgeting for; the failure mode is a pilot that ends in maybe and drifts into purchase by exhaustion. That is why the decision rule goes in writing before the sensors arrive, with a named decision date. Ariadne would rather be measured against that rule than win by attrition, which is also why the camera-free architecture and the on-site verification both belong in the pilot rather than in the pitch.
---