Loss Prevention

What a loss-prevention alert actually is

An alert is a ranked candidate for review — a moment where what the camera saw and what the till recorded do not agree. It is not a finding, and it is not an accusation. The useful question is never “did the system catch someone” but “does this pair of records need a human to look at it before anything else happens”.

The pairing is the product

Most retailers already have both halves of the evidence and cannot join them. The POS writes an exception — a void, a refund, a no-sale, a manual price override. The camera writes video. Finding the video for a specific till exception by hand means scrubbing a timeline, which is why exception reports go unreviewed. Attaching the frames from the same second to the exception record is what turns a report nobody opens into a queue somebody can work through.

Which exceptions are worth pairing, what each one legitimately means, and what none of them prove on their own is set out in our POS exception taxonomy — eleven event types with their common innocent explanations.

What an alert does not prove

• An unscanned item is not theft. Barcodes fail, heavy items stay in the trolley, and self-checkout confuses people who are trying to pay. The scan simply did not register; intent is a separate question a person has to answer.
• A refund with no customer in frame is not fraud. Refunds are processed after the customer leaves, over the phone, and at shift end. It raises review priority; it settles nothing.
• A cluster on one operator is not a case. It can equally be the busiest lane, the newest hire, or the terminal that jams. Check the distribution before you check the person.
• One event is never enough. Anything with employment consequences needs corroboration, an alternative explanation ruled out, and review by a human — not a screenshot.

What it needs from your stores

• Cameras that see the transaction area — the scanner, the bagging area and the hands. Ceiling domes aimed down an aisle for general security were positioned to record people, not to read a scan.
• POS data with usable timestamps. The join is temporal. If the till clock and the recorder clock drift, the pairing degrades, and clock sync is the unglamorous step that decides whether any of this works.
• Somebody whose job is to review the queue. A detection nobody opens is not a control. This is the constraint far more often than detection is.
• A written policy on what happens next. Who reviews, what threshold escalates, who may speak to an employee, and what gets recorded. Loss prevention without that is a surveillance programme with no procedure attached.

Where the alert actually goes

Routing is a design decision, not a setting, and it is where most detection projects quietly fail. Three questions decide it, and they are worth answering before anyone looks at a product:

• Who is expected to act, and are they holding a phone? A floor supervisor mid-shift and a regional LP manager at a desk need different channels. An alert sent where nobody is looking is the same as no alert.
• Does this need a response now, or a review later? Most exceptions are review-later, and treating them as urgent trains people to ignore the channel. Reserve interruption for the few cases where someone can still do something about it.
• What happens when nobody responds? If there is no escalation path and no record of an unreviewed alert, the queue silently becomes a log nobody reads — which is the state most exception reports are already in.

Alert fatigue is the failure mode to design against. A system that flags too much gets muted, and a muted system is worse than none because it creates the impression of coverage. Fewer, better-targeted alerts with a named owner beat comprehensive detection nobody triages.

Privacy boundaries

Detection is behaviour-based and does not identify individuals — no facial recognition, no biometric matching. Monitoring staff carries disclosure and proportionality obligations, and handling a suspected incident belongs with HR and legal rather than with a shift manager or a system. Nothing on this page is legal advice.

Where to start

Before evaluating any system, measure the gap you actually have. Our shrink calculator works out the variance between book and counted inventory and — more importantly — how much of it is already explained by documented breakage and approved adjustments. Only the unexplained remainder is something detection can act on, and that number is the honest basis for judging whether any of this is worth doing.

How a till exception becomes a reviewable event

Most retailers already generate exception data. The POS records every void, refund, no-sale, price override and manual discount, and most chains have years of it. The reason it rarely changes anything is that an exception line on its own cannot distinguish a keying error from a deliberate act — and reviewing each one against CCTV by hand costs more than the loss it might find.

Pairing the two closes that gap. Each exception carries a timestamp; so does the video. Presenting them together turns a review that took ten minutes of scrubbing into one that takes seconds, which is what makes reviewing a meaningful share of exceptions possible at all.

What the system needs to work

• A POS or transaction log it can read, with per-transaction timestamps and operator identifiers. Without an operator ID you can find the event but not attribute it to a lane or a shift.
• Cameras that see the transaction area — the scanner, the bagging area and the customer side. A ceiling dome aimed for general security will often not show whether an item passed the scan zone.
• Clocks that agree. If the POS and the recorder drift apart, the pairing points at the wrong moment. This is the single most common reason a deployment produces unusable results.
• Someone whose job is to review the queue. Detection without review capacity moves the bottleneck rather than removing it.

What a flagged event does not prove

This matters more than the detection itself, because the cost of getting it wrong lands on a person:

• A void is not a theft. Keying errors, customers changing their mind, jammed terminals and changed procedures all produce the same record.
• A refund with no customer in frame is not proof. Refunds are routinely processed after the customer leaves, or by phone.
• An unscanned item is an exception, not an intent. Damaged barcodes, heavy items left in the trolley and failed reads are ordinary.
• A statistical outlier is a place to start looking, not a finding. A cashier on the busiest lane will generate more exceptions than one on the quietest, and that is arithmetic rather than behaviour.

A flag is a triage signal. Attribution requires the till record matched to video from the same second, an alternative explanation actively ruled out, more than one occurrence, and review by a person. Anything short of that is a suspicion, and acting on suspicion is how these systems damage the people they are pointed at.

Where to start measuring

Before evaluating any system, two numbers are worth having, because they decide whether detection is even your constraint:

• Your unexplained inventory variance. Total variance minus what documented breakage, expiry and approved adjustments already account for. Only the remainder is addressable. Our shrink calculator works this out from your own figures, in your browser.
• Exceptions generated versus exceptions actually reviewed. If almost none are reviewed today, more detection will not help until review capacity does. The POS exception reference defines each event type and what evidence it needs.

We publish no detection rate or recovery figure for this product. Performance depends on camera placement, lighting, lane layout, clock accuracy and which events you care about — it is measured per deployment against events you have confirmed independently, not quoted from a brochure.