Skip to main content

In a network of gas stations, the key question isn’t which software can detect a fall, an intrusion, or a vehicle driving the wrong way. Most AI-powered video analytics solutions can do that. The question is what happens to the alert once it’s generated: who receives it, how quickly, with what information to make a decision, and what happens to alerts that no one acts on.

A system is judged by this entire process. Excellent detection that sends alerts to an email inbox checked the next day provides no protection. This article describes the alert processing chain at a gas station, the settings that make it viable, and the metrics used to verify that it’s working. XXII, a French computer vision software company, designs its CORE platform around this workflow—without facial recognition.

Which Alerts Warrant an Immediate Response

Not all detections require the same response. At a gas station, three levels are sufficient to structure operations.

The immediate level includes events where the response time can change the outcome: a person lying on the ground on the fuel island or in the store, an intrusion into a technical area outside of business hours, or unusual tampering with a charging station at night. These alerts are routed to a recipient who is available at all times.

The deferred level covers situations that require verification but not an emergency response: a vehicle that has been stationary on a charging lane for an extended period, a parked vehicle blocking access, or a marked zone being crossed during the day. These alerts are sent to the site operator during business hours.

Finally, the statistical level includes data that is only meaningful when aggregated: lane occupancy, duration of stay, and utilization rates of charging stations. This data does not trigger any alerts and is used to generate a report.

Classifying each detection into one of these three levels is the project’s first decision. It determines everything else and must be established before selecting a vendor.

What must an alert contain to be actionable?

An alert reduced to a description and a time forces the recipient to log in, locate the camera, and review the recording. At three in the morning, this extra effort is enough to cause the alert to be ignored.

Four elements make an alert immediately actionable: the image or short video clip corresponding to the event, which allows the recipient to verify the situation without having to go anywhere or search for the footage; clear identification of the location and the camera, which is essential as soon as the facility has more than a few locations; The precise nature of the detection, along with the rule that triggered it. Finally, a way to classify the response with a single action—whether the alert was justified or not—because it is this classification that will enable the system to be improved.

This last point is often overlooked. Without feedback from operators on the relevance of alerts, no one will know in six months whether the system has deteriorated or improved.

How to Route Alerts Across a Network

Routing depends on three variables: the site, the time, and the alert level. On a network, these three variables combine differently depending on the operational configurations.

A station operating extended hours with on-site staff can handle deferred alerts locally and forward immediate alerts to a monitoring center at night. An unstaffed, automated station forwards everything to the center or to an on-call team. A station operated under a franchise agreement requires routing to the operator, with a copy sent to the network for safety-related events.

Two principles help avoid common deadlocks. Each alert has a single, designated recipient; otherwise, no one will feel responsible. And each routing rule has a fallback rule, in case the recipient does not respond within a defined timeframe.

How to Reduce the Volume of Alerts to a Manageable Level

A system that generates more alerts than the organization can handle will break down on its own: operators learn to ignore them—even the valid ones. Four settings directly affect the volume.

Zone Demarcation

A detection zone that is too large picks up the neighboring street, the adjacent parking lot, and legitimate traffic. A polygon confined to the area that is truly sensitive eliminates a significant portion of the noise without losing useful coverage.

Time windows

An intrusion in a technical zone is only meaningful outside of operating hours and delivery windows. A rule that ignores the fuel delivery schedule will trigger an alarm every time a truck passes through.

Duration thresholds

Requiring a sustained presence for a few seconds before triggering the alarm eliminates quick passes, reflections, and some false triggers caused by weather conditions, without significantly delaying a genuine alert.

Event consolidation

A single situation can generate multiple successive detections. Grouping them into a single event, with a start and end time, reduces the perceived volume without losing any information.

These four settings are configured on a site-by-site basis during commissioning and are then adjusted based on feedback from operators.

Which indicators to monitor to verify that the system is functioning

A detection system is managed like any piece of equipment, with its own metrics. Five are sufficient.

The number of alerts per site per night, which immediately signals a configuration that has become “noisy.” The percentage of qualified, justified alerts, which measures the actual relevance of the settings. The time between detection and response, which measures the human response chain rather than the software. The rate of unqualified alerts, which reveals a loss of operator engagement before the system becomes useless. Finally, the availability of cameras and analytics per site, because a camera that’s out of service produces no alerts and therefore doesn’t attract anyone’s attention.

This last indicator is most often overlooked and the most costly. Across a distributed network, an analysis that has been inactive for several weeks goes unnoticed as long as nothing is explicitly monitoring it.

What obligations must be met with regard to customers and employees?

The GDPR applies whenever personal data is processed, and the image of an identifiable person falls under this category. A solution that does not use facial recognition avoids the biometric data regime set forth in Article 9 of the GDPR, which is reserved for special categories of data.

Three obligations form the framework of the project. Informing individuals through a visible notice at the site entrance stating the existence of the system, its purpose, and the means to exercise their rights. Purpose limitation, which prohibits the reuse of a system installed for security purposes for the individual monitoring of staff. Retention period limitation, defined and documented for each category of data generated, including images attached to alerts.

This last point warrants attention in an alert chain. Images transmitted via email or messaging circulate outside the system and are not subject to the deletion rules. The transmission of alerts must therefore be designed with the same rigor as their storage. When employees are involved, consultation with employee representative bodies is required under the conditions set forth in the Labor Code. The CNIL has published a position paper on so-called “augmented” cameras that helps define the intended purpose.

How to Get Started on a Network

Focus on two immediate-level detections—those whose absence is most costly today—and a single chain of recipients. Deploy the system at a site representative of the network’s typical constraints, not at the best-equipped one. Measure the volume of alerts, their relevance, and the response time for at least two weeks, both day and night.

This framework then serves as a reference for expansion. It provides an objective criterion for deciding whether to add an additional detection, and a justification for refusing to add one when the processing chain is already at capacity. XXII’s CORE platform was designed for this type of gradual scalability on an existing camera fleet.