Product Recall Management Software: Can You Stop Selling the Affected Lot Before the Evening News?

The clock starts the moment the notice lands, and your first four hours are spent finding out what you bought

It is 2pm on a Thursday. A supplier notification arrives naming a batch of a product for undeclared allergen. The quality director opens the email, and the first question is the one that should take 30 seconds and instead takes half a day: which of our distribution centres received that lot, which stores did they ship it to, is any of it still on a shelf, and did we sell it to anyone we can contact.

What follows in most retailers is a phone tree. Someone pulls receiving records, someone else exports store transfers, and a third person emails 140 store managers asking them to check a shelf and reply. Meanwhile the product is still scanning at the till, because nothing has told the point of sale to stop, and every transaction after the notification is a sale of recalled product with your name on the receipt.

The tools in play are usually a warehouse management system that knows receipts but not lots, a merchandising system that knows GTINs but not batches, a POS that knows prices, email for the rest, and Rapid Recall Exchange or a supplier portal delivering the notification itself. Sedgwick and Stericycle run capable recall services, and if your problem is consumer contact centres, reverse logistics and regulator liaison, they are the right partners. What no external service can do is reach into your own shipping records to answer where it went, or into your till software to stop the next scan. Those two capabilities decide whether a recall is a controlled event or a news story.

Problem one: lot traceability breaks between the pallet and the shelf

Most retailers can trace one step back and one step forward at the case level, which is what their supplier agreements require and what their systems were built for. The break happens in the middle. A pallet of a lot arrives at a distribution centre, is broken into cases, and those cases ship to 40 stores over nine days on mixed pallets. Nothing in a standard warehouse system records which store received which lot, because the pick was by GTIN and the lot was never carried on the outbound record.

The consequence is that your only honest answer is a date range, so you recall everything shipped in a window. That is expensive twice: you destroy saleable product, and you dilute the message to stores, who start treating recall notices as routine because most of what they pull is fine.

What a custom build does: capture the lot on receipt, carry it through the outbound movement, and record it on the store delivery. If your warehouse system will not hold lot on outbound, capture it at the pick or the load with a scan step rather than trying to change the WMS, which is usually a faster and cheaper route than a core system change. Then a recall query is a single traversal: give it a supplier lot, get the DCs, the stores, the quantities, the delivery dates, and the transactions containing that GTIN in the exposure window. What took four hours takes seconds, and the store list is exact rather than precautionary.

Problem two: the till keeps selling until something stops it

This is the failure that turns an incident into a liability, and it is the most fixable. The recall exists, the product is on the shelf, the till has no idea, and sales continue for hours after you knew.

What a custom build does: the recall record generates a block file that pushes to the POS estate, so an affected GTIN either refuses to scan or forces a supervisor override with a reason. Getting this right takes care, because the block has to be lot-aware where the till can read a lot and GTIN-wide where it cannot, and you must decide in advance which one you will use. Most retailers make GTIN-level blocking the default and accept pulling some unaffected units, because the alternative is depending on a cashier reading a batch code under pressure.

The second half is the store task, because a block stops the sale but does not clear the shelf. The task needs to reach the right department in the right store, name the product with a photograph rather than only a code, ask for the quantity found, and require a photograph of the removed stock in quarantine. The compliance view is then a live map of which stores have confirmed, with escalation automatic at a defined interval rather than dependent on a regional manager remembering. That record is also your effectiveness evidence, because a regulator wants proof, not assurances.

Problem three: telling customers who bought it

If you run a loyalty programme, you can identify a large share of the people who purchased the affected lot, and doing so is both the right thing and a strong defence. The technical requirement is that transaction records carry enough detail to identify the specific product and the store and date, joined to a contactable identity.

The design questions matter more than the code. Whom do you contact, given that GTIN-level identification will include customers who bought unaffected units. What do you say, since a badly worded message causes more harm than the hazard in low-severity cases. Which channel, given that email open rates mean a serious hazard warrants SMS or a phone call for high-risk categories such as infant formula or a product with a choking hazard. And what do you record, because the fact that you attempted contact, through which channel, and whether it was delivered, is part of your evidence pack.

What a custom build does: a notification workflow with severity tiers, message templates approved in advance by legal and quality so nothing is drafted under pressure, channel selection by tier, and a delivery log per customer. Pre-approved templates are the single biggest speed gain available, because in practice the hours lost are almost never technical, they are spent waiting for wording to be agreed.

Problem four: the regulator report and the effectiveness check

Reporting obligations depend on the product and the jurisdiction, so take your specific duties from regulatory counsel. The shape is well known: consumer product hazards in the United States carry a duty to report to the Consumer Product Safety Commission framed in hours rather than weeks, food presenting a reasonable probability of serious health consequences brings the FDA Reportable Food Registry into play with a short window, and FDA recalls are classified by severity with Class I the most serious. Separately, the FDA food traceability rule under FSMA 204 sets record requirements for foods on the Food Traceability List with a compliance date in July 2028.

The operational point is independent of any particular rule. Regulators ask for the same things: what the product is, how much was involved, where it went, what you did, when you did it, and how you know it worked. The last one is the effectiveness check, and it is where retailers struggle, because proving that product was actually removed from 140 stores requires the store confirmations you either collected or did not.

What a custom build does: the report is generated from the event record rather than assembled afterwards. Quantities affected, distribution list, dates of notification, store confirmation rate over time, quantity recovered, disposition of recovered stock, and customer notification counts all come out of the system that ran the recall. That turns a week of evidence assembly into a document review.

Problem five: the money, the supplier and the disposition

The part nobody plans for. Recovered product has to be quarantined, counted, and then destroyed, returned to the supplier or reworked, each with its own evidence requirement. Then someone has to claim the cost back: the product value, the labour to remove it, the disposal cost, the customer refunds, and sometimes the lost margin. Most retailers under-claim substantially because the costs sit in five places and the claim is assembled from memory weeks later.

What a custom build does: store confirmations carry quantities, so recovered volume is real rather than estimated. Disposal certificates attach to the event. Refunds issued at service desks are tagged to the recall and aggregate automatically. Removal labour is captured as task time. The supplier claim then produces itself with evidence attached, and you claim what it actually cost you.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape here is fairly predictable. A first release covering lot capture through the supply chain, the trace query, POS block file generation, store tasks with photographic confirmation and a live compliance dashboard runs $60,000 to $130,000 and ships in 10 to 14 weeks. A full platform adding regulator report generation, tiered customer notification through loyalty data, disposition tracking, supplier claim assembly and effectiveness reporting runs $150,000 to $350,000 phased over 6 to 12 months.

What drives cost up: the POS estate, because pushing a block file to a modern cloud till is a morning's work and doing it to an older mixed estate across franchises can be months. Whether your warehouse system carries lot on outbound movements at all, since if it does not you are adding a scan step in a live operation. Multi-jurisdiction reporting, as each regulator wants its own format. And franchise or wholesale distribution, where you are notifying independent operators you do not control and need acknowledgement rather than compliance.

What keeps cost down: corporate stores only, one country, one product category in release one. Lot trace plus till block plus store confirmation is most of the risk reduction for about a third of the cost.

When a recall service is enough

Buy, or rather retain, if you run under about 20 stores with a simple supplier base, or if what you actually lack is consumer contact centre capacity, reverse logistics and regulator relationships. Sedgwick and Stericycle do those things well and you should not build a call centre. Rapid Recall Exchange is worth being on regardless, because it standardises how notifications reach you in the first place, and a documented manual procedure that your team has rehearsed beats a half-built system nobody trusts.

Build when two or more of these are true. You cannot answer which stores received a lot without a phone tree. Your tills keep selling after you know. You have loyalty data you are not using for customer notification. Your last recall took more than a week to evidence. Or you distribute to franchises or wholesale customers and your notification currently ends at an email nobody acknowledged. The test is simple: run a mock recall on a Tuesday afternoon with no warning and time it. Whatever that number is, it is your real capability, and everyone in the room will know within an hour whether you need to build.

How to choose a developer for recall management software

Ask them to trace a lot on a whiteboard from supplier receipt to a customer transaction. A team that has done this will identify the outbound movement as the break point and will ask how your warehouse system handles lots before quoting anything. A team that starts with a notification workflow has built a ticketing tool.

Ask specifically how the POS block reaches the tills, by name and version of your till software, and what happens to a store that is offline when the block is issued. If there is no answer for the offline case, the block is not real.

Ask how effectiveness evidence is captured. Photographic confirmation with a timestamp, a store user and a quantity is the standard that survives a regulator conversation. A checkbox is not.

Ask who owns the code and the data and settle it before kickoff. Your traceability records are evidence, and evidence should never live in a supplier's account. At Digital Heroes the client owns the repository from the first commit.