A video analytics proof of concept (POC) is designed to answer a question that neither a demonstration nor a response to a request for proposal can resolve: whether the solution works with your cameras, under your conditions, and with your teams. A well-defined POC can be completed in six to eight weeks and yields comparable metrics across vendors. A poorly defined POC takes a quarter to complete and ends with nothing more than a vague impression.

The difference comes down to three elements established before starting: a narrow yet representative scope, a real-world scenario defined by the client, and acceptance criteria written down before the first test. Everything else—including the selection of candidates—stems from these three points.

Why a POC rather than a demonstration?

A demonstration is conducted using the vendor’s pre-recorded footage, filmed under conditions chosen by the vendor. It shows what the product does best. This is useful for understanding an interface but useless for predicting an error rate on a real-world site.

The discrepancies observed between a demonstration and an actual deployment rarely stem from the algorithm. They stem from camera angles, the actual resolution available on secondary feeds, nighttime lighting, reflections, and clutter in the areas. These factors cannot be simulated; they must be observed.

A POC therefore addresses the question of on-site feasibility, not the product’s general capabilities.

What should the specifications for a POC include?

Four sections are sufficient. The first describes the selected use cases, formulated in terms of decision-making: detecting a critical density in a specific area to trigger a specific action. A use case formulated in terms of functionality—such as counting people—does not allow for an assessment of the result.

The second section describes the technical scope: number of cameras, specific models, location, lighting conditions, network access, and information system security constraints. Vendors must have this information before committing to the project.

The third describes the evaluation method—that is, how the ground truth is established and how the discrepancy is calculated.

The fourth establishes quantified acceptance criteria and conditions for continuing the project. A POC without exit criteria never truly ends.

How many cameras and how many sites should be selected?

The tendency to choose a single, easy site leads to a successful POC followed by a difficult deployment. The opposite tendency—to cover a wide area—extends timelines without improving the decision-making process.

A reasonable scope includes two sites and about ten cameras: one site representative of the majority of the installed base, and one challenging site—with poor lighting, older cameras, or a cluttered area. If the solution works at the second site, the deployment is predictable. If it fails only at the second site, the buyer at least knows what portion of the fleet needs to be upgraded, which is useful budget information.

Duration is just as important as the number of locations. Four to six weeks of continuous measurement account for variations in foot traffic, including a day of high volume and a period of bad weather. A one-week test provides a snapshot, not a trend.

How do you establish the reality on the ground?

This is the most commonly overlooked aspect, and the one that determines the value of the entire POC. On-site verification involves a manual count conducted by the client using recorded footage to assess a sample of representative time slots.

The sample must include at least one peak-traffic time slot, one off-peak time slot, one nighttime time slot, and one time slot affected by weather conditions or construction. One to two hours per time slot is sufficient if the time slots are chosen carefully.

This count is performed before reviewing the tool’s results. Otherwise, the evaluation will imperceptibly drift toward simply validating the tool’s output. This is more of an organizational constraint than a methodological one, and it should be negotiated with the teams during the scoping phase, not as the project progresses.

What acceptance criteria should be established before starting?

The criteria are expressed as a measured deviation, not as a stated performance metric. For a count, this is the relative deviation from the manual count, calculated per time slot rather than as an average over the period. An average masks errors that cancel each other out.

For event detection, two metrics are required: the percentage of actual events that are effectively detected, and the number of false alarms per camera per day. The second metric alone determines whether teams will continue to process alerts after three months.

Non-functional criteria are also considered: the delay between the event and the alert, service availability over the period, and the time required to add a camera or modify a zone. This last point foreshadows the actual operating cost.

What questions should be asked about scaling up?

A successful POC with ten cameras says nothing about scaling up to two hundred. Three questions deserve to be asked during the POC, not after.

How is a new camera added, by whom, and how long does it take? If each addition requires intervention by the vendor, operating costs will rise as the fleet grows.

How configurations are replicated from one site to another. A multi-site operator needs metrics defined identically across all locations; otherwise, comparing sites is impossible.

How do the metrics exit the system? A documented machine interface allows data to feed into the existing monitoring system and data warehouse. A solution that is accessible only through its web interface traps the operator behind yet another screen.

What is the legal framework for a POC?

A POC processes live data, so the legal framework applies from day one. If the site is open to the public, the video surveillance system falls under the Internal Security Code, and the analysis applied to the video streams does not exempt the operator from obtaining this authorization.

With regard to the GDPR, the software provider acts as a processor, which requires a contract specifying the purposes, retention periods, and security measures. The obligation to inform data subjects applies both during the POC and afterward. And if employees are within the scope of the system, consultation with employee representatives as required by the Labor Code must take place before the project begins, not upon signing the final contract.

One final point, which is often a source of dispute: specify in writing what will happen to the data and trained models at the end of the POC if the project does not proceed.

How can you avoid POCs that lead to no decisions?

Three warning signs point to a fruitless POC. The client’s failure to establish a realistic baseline, which makes any comparison between candidates impossible. The absence of quantifiable exit criteria, which leaves the decision to the final debriefing meeting. And the absence of an identified operational recipient for the metrics produced, which reveals that the need has not yet been clearly defined.

Conversely, a useful POC can be recognized by one thing: at the end, the buyer has a comparison table with the same columns for all candidates, filled in with their own figures. It is this table that justifies the decision, not the quality of the final presentation.