Skip to content

Part 5 of 7 · Product recall tracer series ~5 min read

The customer list you cannot make, and what to do instead

This is the part where a recall system either tells the truth or flatters you. Every sale traced in the last post has to be turned into somebody you can contact, and for most retail businesses the majority cannot be, by design and quite properly.

Key takeaways

  • Report matched and unmatched as one sentence. Never publish just the matched count.
  • A high unmatched share is the trigger for a public notice, not a failure.
  • Contact the wholesale customers first. They multiply.
  • The evidence file is the deliverable that outlives the recall.
  • Do not build a customer identity graph to solve a recall.

From traced sales to people

Four sales channels resolving into matched and unmatched countsFour boxes on the left feed one box on the right. Wholesale orders have a named account and exact quantity and are contacted first. Online orders have an address and email on file. Loyalty or account sales were scanned at the till. Anonymous sales, cash or card with no identity, cannot be contacted. All four converge on Two numbers: two hundred and eight nameable, four hundred and ninety-six not, which feeds a box labelled Both are published, internally and to the regulator. A note says the fourth route is not a gap to be closed but a property of selling things to the public, and the system's job is to size it.Wholesale ordersnamed account,exact quantitycontact firstOnline ordersaddress andemail on filecontactLoyalty or accountscanned at thetillcontactAnonymous salescash or card,no identitycannot contactTwo numbers208 nameable,496 notBoth are publishedinternally and tothe regulatorThe fourth route is not a gap to be closed. It is a property of selling things to the public, and the system's job is to size it.
Fig 1. Four routes, two numbers. Three of them produce a contactable person and the fourth produces a count, which is exactly as useful in the decision that follows.
  • Security & identity
  • Analytics
  • Front-end & mobile
  • People

Why the unmatched number is the useful one

If you can name six hundred and eighty of seven hundred and four buyers, an email does the job. If you can name two hundred and eight, an email reaches under a third of the people holding the product and the rest of the work has to happen somewhere else: a notice at the door, a post, a line to the agency, possibly press. The unmatched count is what makes that call, and it is the number a system optimised to look capable would bury.

It also stops a bad instinct. Faced with a low match rate, the tempting fix is to build an identity graph — join card tokens, match postcodes, infer households — and retrofit names onto anonymous sales. That is a large amount of engineering, a substantial new data protection problem, and it produces probabilistic identifications on which you would then base a safety notice. The notice at the door is better in every dimension.

The evidence file

Assembling a recall evidence file that survives the recallA vertical chain inside an AWS account container, entered from a box on the left labelled Trace complete, three lists produced. Freeze the inputs stores the notice, register and sales exactly as they were. Record the queries keeps them re-runnable with their results. Log the actions records what was quarantined, sent and posted, and by whom. Attach the negatives records the batches checked and not held. Seal and retain keeps it for years, not weeks. A note says everything here is written during the recall, because none of it can be reconstructed afterwards and all of it is what an inspector asks for.AWS ACCOUNTTrace completethree listsproducedFreeze the inputsnotice, register,sales as they wereRecord the queriesre-runnable, withtheir resultsLog the actionsquarantined, sent,posted, by whomAttach the negativesbatches checkedand not heldSeal and retainyears, notweeksEverything here is written during the recall, because none of it can be reconstructed afterwards and all of it is what an inspector asks for.
Fig 2. Five steps, all of them cheap at the time and impossible later. The fourth is the one people leave out and the one that proves you looked.
  • Storage
  • Machine learning
  • Security & identity
  • Management
  • Analytics

What retention actually means here

The stock and sales data behind a trace has its own retention rules and they are usually shorter than the period in which somebody might ask you about a recall. Freezing the inputs at trace time is what resolves that: you are not keeping five years of transactions on the off chance, you are keeping the specific slice that a specific notice caused you to look at.

That slice is small. In the worked example the frozen evidence is a few thousand rows and eleven photographs. It is the cheapest thing in the entire system to store and the most expensive thing to be missing.

The sentence the report has to be able to write

  • We received 2,180 units of the named batches between 4 and 11 March.
  • 61 remain, at three sites, quarantined and confirmed by 17:40 the same day.
  • 704 were sold. 208 buyers are named and have been contacted.
  • 496 cannot be identified, so a notice is at the door and on the website.
  • Two of the four named batches were never received; the query that shows it is attached.

Where this ends

The system does not close the recall, because closing it is a judgement about whether enough has been done and by whom. What it does is make that judgement possible: a bounded scope, a labelled trace, two honest numbers, and a file that will still make sense to somebody who was not there.

The next post prices it, and the one after gives the service names, the tables and the IAM. The interesting thing about the cost is how little of it scales with sales: the model reads deliveries and notices, and both of those are rare compared with the number of things you sell.

All posts