Product & DesignFree
Product Bug Notice for Affected Customers
Rebuild the affected set from what actually triggered the defect, then split it by whether the wrong output already left your product.
River starts from the trigger conditions rather than the release number. A defect fires only when several things are true at once, and an account on the release that never met all of them was never touched. At the fictional Ravensmere, 4,182 accounts ran the affected release and 1,340 had a saved view configured the wrong way. Only 470 of those ran one inside the window against a record the defect could drop. The other 3,712 were about to be emailed about something that never happened to them.
The 470 then split by whether the wrong figure ever left the product. 199 saw it on a screen and nowhere else, so the correction can be quiet. For 271 it was exported, mailed out on a schedule, or read by a connected integration, which means a wrong number is already sitting in somebody else's inbox. Adding the three routes gives 352 and double counts 81 accounts, so the call list has to be built from distinct accounts rather than from channel totals.
Every date the notice mentions becomes a row with an owner and the accounts told it, so a slipped date arrives with its own call list instead of an apology. Send the defect, whatever account and export data you hold, and what is already fixed. If it surfaced in a controlled trial the affected list already exists in the programme's own tracking. If the fix is a removal rather than a repair, stage it as a sunset. If the notice also shows up in the product, it joins everything else you already send.
Every template on page one leaves the hard part blank
Search the phrase and page one is status page vendors and agency blog posts. They propose the same sequence every time. Acknowledge inside fifteen minutes, post to a status page, hold a cadence, publish a review afterwards. It is sound advice for an outage, where the affected set is obvious because the service is down for everyone. Then every template on those pages hands you a bracket that reads who is affected, and not one of them tells you how to work that out.
Silent defects are the harder case and the more common one. Nothing errors, nothing goes down, and a number is quietly wrong for three weeks. Ravensmere shipped the filter on 4 February and found the fault on 27 February. Across the 470 accounts that hit it the median under-count was 4.3% and the worst was 41.3%, with 68 accounts off by a tenth or more. One blanket email cannot carry a figure that varies that much from account to account.
Notifying by measured impact is not a way of ducking the problem, it is how the strictest regimes already work. Vehicle recalls go by first class mail to each registered owner of the affected vehicles, not to everyone who bought the brand, and a second notice is required once the remedy exists. Under the GDPR a breach reaches the individual only where the risk to them is high. Both put the duty on the people it happened to, and both make the follow-up a second contact rather than a promise.
How it works
Trigger conditions first
River restates the defect as a set of tests every affected account has to pass.
The population narrows
Each test is applied to the release population in turn, and the drop at every step is reported.
Escape routes joined
Exports, scheduled sends and integration reads are matched against the affected records to find what left.
Dates become rows
Each commitment the notice makes is written to a tracker with an owner and the accounts told.
What you get
- The release population narrowed to the accounts that met every trigger condition, with the arithmetic shown
- Each affected account split by whether the wrong output stayed on screen or left the product
- Exports, scheduled sends and integration reads counted as distinct accounts, so overlaps are not double counted
- A per-account deviation figure, so the notice can say how wrong that customer's number actually was
- Three drafted notices, one per band, from a silent correction to a named person with a record list
- Every date in the notice written as a tracked row carrying an owner and the accounts told
Common questions
We have no export logs. Does this still work?
You still get the population narrowing, which is the larger saving. Without egress data the escape split becomes a question the notice asks rather than a fact it states, so affected accounts get one tier of notice instead of two. You also get the specific log fields to start keeping, which overlaps with an instrumentation audit.
Is this not just under-notifying to avoid embarrassment?
The opposite. A blanket note to Ravensmere's 4,182 accounts would have told 3,712 of them about something that never touched their data, and buried the 271 who had already forwarded a wrong number. Narrowing takes more work, not less, because you have to prove who was hit before you can leave anybody out.
What if the affected set really is everyone?
Then the arithmetic says so and the blanket note goes out with something behind it, which is worth having on its own. Most defects are conditional. Ravensmere's needed three things true at once, and 11.2% of the release population met all three, so the blanket version would have been fifteen times too big.
How is a tracked follow-up different from promising a review?
A promise lives in the sent email and nowhere else. Here each date becomes a row carrying an owner and the accounts that were told it, so when 12 March slips you can name the 470 accounts owed a second message. The vehicle recall rules take the same view and require a second notice once the fix exists.
Who signs the notice, support or product?
Both, and the split follows the bands. The 199 contained accounts get an in-product note and a corrected figure, which needs no reply. The 271 whose output left need a named person, because the customer has work to do outside your product. River drafts each version and marks which accounts get which.
The bug is already public. Does that change the method?
It changes the order, not the method. A public thread means the broad note goes first to stop the speculation, then the segmented notices follow carrying the per-account detail. The tracker still holds the dates, and the public note quotes the same ones rather than inventing softer versions.
Is this the same as a release note?
No. A release note is a broadcast about what changed and reaches everyone equally. This addresses a defect to the accounts it damaged, and asks some of them to go and correct something downstream that has already left your product.
Product Bug Notice for Affected Customers
Fill in the form and your workspace opens with the work already underway.