Computer vision in stores · FLO Group · 2025 – 2026
From a camera event to the right person's pocket
Store cameras produced useful events, but the events stopped at a dashboard.
In short
Situation: Store cameras with AI analytics generated events (queue build-up, unattended areas, occupancy) that landed on a dashboard. Staff on the shop floor do not work from a dashboard, so the events rarely led to action. Decision: Treat each event as the start of a workflow. Define nine use cases, route each to a named role in the tools store staff already use, and escalate on a clock: ten minutes, thirty minutes, one day. Result: Live in every store of the group, about 600, with escalation rules and reporting in Power BI. The camera vendor sits behind an event layer, so the logic survives a change of vendor. In the six-month, twelve-store pilot reported in the paper, peak checkout waits fell by about 25%, fitting-room abandonment by about 20% and energy use outside staffed hours by about 15%. My role: Product owner: use-case definition, notification design, integration architecture, the open-question list with the vendor.
- My role
- Product owner · IT
- Period
- 2025 – 2026
- Scale
- All group stores (~600) · every format
- Key figure
- 9 use cases · 3-step escalation
Situation and complexity
The cameras were already there, and already clever. They could detect a queue forming at the till, an area left unattended, how many people were in the store. Their output was a vendor dashboard that nobody in a store has time to watch, so all that intelligence produced no action.
The hard part was deciding who should know what, how fast, and what counts as “handled”, across roughly 600 stores of different sizes and staffing.
Options on the table
- Use the vendor's dashboard and alerts as they are
Rejected. Alerts without ownership become noise within a week, and the logic would have belonged to the vendor.
- Build a monitoring centre that watches the cameras
Rejected. It moves the problem to a new team instead of to the person who can act in the store.
- An event layer with routed, escalating notificationsChosen
Events are normalised, matched to a use case, sent to a role through the tools staff already use, and escalated if nobody acts.
The decision and how it was organised
Nine use cases were defined with the operations teams, each with an owner role, a channel and a clock. A notification that is not acknowledged within ten minutes goes to the next role. After thirty minutes it moves further up; after a day it stops being an alert and becomes a report item. Every event ends with someone responsible for it.
The integration was designed to make the camera vendor replaceable. Events were pulled from the vendor's API into an event layer owned by the platform. Notifications went out through the group's existing internal tools, and reporting landed in Power BI. Store identities were matched to SAP, so a store is the same store everywhere.
The open questions with the vendor (rate limits, test environments, credentials, data retention) were kept as a numbered list and closed one by one. An academic write-up of the project, combining computer vision with IoT telemetry and transactional signals, was presented at a scientific congress and published in its proceedings.
Result
Response times were reported per store and use case in Power BI. Pilot figures are as published in the paper: directional and observational, not causal estimates.
What went wrong, what I learned
Intent: Validate everything on a separate test environment before touching live stores.
What went wrong: Setting up a test environment with the vendor was slower than expected, which delayed the start of validation.
What changed afterwards: “What is the test ground?” became a mandatory line in every request-maturation document across the programme.