Compiling a shortlist of video analytics platforms for a retail or logistics network in Europe involves narrowing down a highly fragmented market to three truly comparable candidates. The method that works involves a process of elimination: first, define two or three priority use cases, then eliminate candidates based on factual and verifiable criteria before conducting any testing.

The most common mistake is to compare advertised features. They all look the same on paper. The real differences lie in compatibility with the existing camera infrastructure, total cost relative to the number of sites, data localization, and the ability to bring an additional site online without launching a dedicated project.

Start with the need, not the technology

A useful shortlist is built around two or three specific use cases, defined in terms of the decision they are intended to support. Simply measuring foot traffic isn’t enough. However, having a conversion rate by store and by time slot—to adjust weekly schedules—is a actionable need: this defines the expected level of detail, the frequency of reporting, and the recipient.

This formulation then serves as a filter. A vendor whose product brilliantly covers ten use cases but fails to properly address yours is not a good candidate. It’s better to have three use cases covered well than a broad catalog.

What criteria eliminate a candidate without testing

Four checks are performed based on the application materials and are sufficient to significantly narrow down the list.

Compatibility with existing equipment

Provide the actual list of camera models, recorders, and protocols currently in use, then request a written response on a per-stream basis. A candidate that requires significant hardware replacement changes the economic nature of the project and must be handled separately.

Data location and responsibility

Ask where the data is hosted, under which legal entity, which service providers are involved, and in which countries. These details are normally included in the contractual documentation. Their absence, or a vague response, is a red flag in itself.

The Cost Model

Require a comprehensive cost breakdown per site and per year over the projected duration, including hardware, hosting, licenses, support, and updates. A price per camera and a price per site do not yield the same total for a large-scale deployment.

Reversibility

Ask in what format the history of measurements can be exported, and under what conditions. A video analytics project builds up a data asset over several years. Not being able to retrieve it creates a long-term dependency.

How to Assess GDPR Compliance Without Relying Solely on Statements

All vendors claim to be compliant. Verification relies on documentation, not on assertions. Four requests are reasonable at this stage: a description of the processing operations performed and the data actually generated; retention periods by data type; the contract template governing subcontracting; and the technical documentation needed to support an impact assessment when such an assessment is required.

One point deserves special attention: the distinction between flow measurement and biometric processing. Counting people, measuring durations, and detecting situations do not involve identifying anyone. A vendor must be able to clearly explain this distinction and document what its system does not do.

Finally, the European Regulation on Artificial Intelligence introduces documentation and risk management requirements that vary depending on the use case. Asking how the vendor supports its customers in this regard provides insight into its level of maturity.

How to Compare Actual Costs Across a Large Fleet

Pricing comparisons are based on a single scenario applied to all candidates: number of sites, number of cameras per site, contract term, volume of data retained, and expected level of support. Without this common scenario, proposals are not comparable.

Three items are often overlooked:

• Setup at each site: potential travel, zone configuration, and acceptance testing with the operator.
• Integration with existing systems, which often represents a project cost separate from the license fee.
• Day-to-day operations: handling degraded video streams, replacing cameras, and adjusting settings after a layout change.

Explicitly asking who is responsible for each of these items—the vendor, an integrator, or in-house teams—helps avoid a significant discrepancy between the planned budget and the actual budget.

What Evidence to Request Before the Testing Phase

A sales demonstration proves nothing. Three elements are more valuable:

• A performance test conducted on one of your own video streams—even a short one—with the calculation method clearly explained.
• Access to the monitoring console as it is used in production, to assess its readability and the day-to-day work it entails.
• A direct discussion with a client operating a system of comparable size to yours, focusing on the challenges encountered rather than the results.

This third point is the most decisive. A vendor who can easily arrange this discussion generally has solid references.

Three Common Shortlisting Mistakes

The first is shortlisting too many candidates. With more than three, the testing phase becomes unmanageable and the comparison loses depth. The second is eliminating a candidate based on company size rather than demonstrated capability. The third is to launch a test without predefined, quantified acceptance criteria, which turns the evaluation into a subjective assessment.

Defining what constitutes success before the test—for example, a maximum acceptable deviation in a control count and a maximum number of false positives—is what allows for a clear decision afterward without debate.

Where does XXII stand in this type of consultation?

XXII is a French computer vision software provider. Its CORE platform processes video feeds from existing cameras and generates operational metrics and alerts, without facial recognition. Across a network of sites in Europe, the questions facing XXII are the same as those facing any other candidate: compatibility with the existing infrastructure, total cost per site, data hosting, time to deployment, and data delivery terms.

A well-conducted consultation does not seek the absolute best product. It seeks the one that works with your existing infrastructure, within your constraints, for the two or three use cases that justify the project.