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
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
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.