Who to tell when you ship a fix: notify by error hit, not by report

A&A perspective

When a fix ships, define who to notify by the users who actually hit that error, not by the person who reported it. Reports arrive from only a fraction of the users who hit a bug, so replying to the reporter alone leaves everyone who stalled on the same defect and quietly left with nothing. Whether it resolved is checked by one record: did the notified user run the same operation again and succeed? The inputs change too. The deciding material is not your list of inbound tickets but your error records, plus what each of those users did afterwards.

A&A perspective

Running on that definition needs three things settled in advance. First, move the notification trigger off the inbound side and onto the side where the fix appears, which is the code merge. Second, write the conditions for notifying and the conditions for not notifying on the same single sheet. Third, separate shipped from resolved, and keep the resolution check as a process distinct from the notice. Add notifications without settling those three and you increase contact with people who were never blocked while still missing the ones who were.

A&A perspective

A word first about what this article produces. It is not a notification template. It is one sheet whose rows are split by what the affected user did after hitting the error, each row carrying whether to notify and which record decides it. The wording can be written once the conditions exist. Reverse that order and you spend the time polishing sentences without ever settling who receives them.

A&A perspective

When you build and operate alone, support improvements go to intake first: automatically attaching the plan, the preceding action and the error the moment a message arrives. That works. The intake design itself is covered in "Solo AI SaaS support: attach the failure context before automating replies"; this article is the stage after it. But no amount of intake polish increases the number of messages that arrive. Intake improvement makes what did arrive faster to handle. It does not touch the people who stayed silent.

A&A perspective

What humans handle, then, reads as only the part that reached a human. But that sentence is about the end-users of Decagon's customers, the page says nothing about the human side itself, and it says nothing about what share of your own users stay silent. One reading still carries over. The inbound you see is not everything that happened, only what reached a human. A report arrives only when being blocked was joined by a second condition, a willingness to pay the cost of reporting. The choice on the other side of that cost is to stop using the product without saying anything.

A&A perspective

So when you design the post-resolution process, the first question is not how to make replies faster. It is which users this fix concerns. Without a record that can answer that question, a notification mechanism still only yields the ticket list as its recipients, and the operation collapses back to replying to reporters.

A&A perspective

For a small company the value of that three-way split is not about headcount; it is about triggers. Treat all three as one lump of after-the-ticket work and the trigger collapses into whenever you happen to remember. On a busy day none of them runs. Kept separate, you can later tell which one failed to run. The reason a two-person operation splits it three ways reads as a difference in triggers rather than a function of staffing.

A&A perspective

Note that the Gumloop article never says to pick the recipient by who hit the error rather than who reported it. It says a merge triggers telling users that a fix relevant to their issues shipped. Widening the target from the reporter to everyone who hit the error is A&A's proposal, not a claim from the source.

A&A perspective

With the trigger on the inbound side, the people you can notify are limited to those who hold a ticket, and only reporters hold tickets. No amount of operational effort removes that limit, because the set of reachable recipients is already fixed by where the trigger sits.

A&A perspective

Move the trigger to the fix side and the set becomes the users who hit the error that this fix repaired. Whether a ticket exists drops out of the condition. Before any implementation talk, that substitution is the substance of the design.

A&A perspective

In practice you need one token that links a fix to its recipients. Run it by hand and a single rule suffices: when you merge a fix, always write the identifier of the error it repaired into the merge description. The identifier can be an error code, an exception type or the name of the operation that failed, any one of them. Without it, even a built notification mechanism keeps a step where a human has to recall which error this fix repaired.

A&A perspective

At one-person scale, the rule comes before the automation. That one-line commitment to write the identifier into the merge description is the connection point for automating notices later. Go the other way, automating notices while leaving the identifier unwritten, and you hand the guessing of that link to a machine, building your own route to notifying the wrong people.

A&A perspective

This is the precondition for everything above. If your error records carry nothing that identifies a user, you cannot define the notification target as the people who hit it. So there is exactly one thing to check before designing notices. Open one recent error record and see whether you can identify the user from it. If you cannot, your first task is not the notice; it is building that link.

A&A perspective

Keep the scope of that link inside what you already agreed with the customer. Deciding to collect more records for the sake of notifications is the same kind of decision as widening the data you hold on their behalf. This article proposes no such widening. It proposes only the order: first check whether the records you already hold can identify the user.

A&A perspective

A sheet that lists only notify conditions makes contact grow without bound once you operate it. It sends on the same basis to users who hit the error but were never blocked, users who already worked around it themselves, and users who received a different notice recently. Notification frequency can itself become a reason to cancel. So the stop conditions do not live in a separate document; they live in the same row of the same sheet.

A&A perspective

The axis that splits the rows is not the severity of the error. It is what the user did after hitting it. A fix notice means something entirely different to someone who kept using the same operation, someone who dropped only that operation, and someone whose logins stopped. And this axis is decidable from records rather than from opinion. Split by severity and the judgement returns to being subjective every time; split by behaviour and the same record yields the same row.

A&A perspective

The table below is A&A's design proposal. Neither source states how to cut the rows, what frequency ceiling to use, or how long to wait before checking. The last row is there to say that this is where you stop when the link does not exist.

A&A perspective

Use it right after merging the fix by checking the last three rows, the stop conditions, first, and only if none of them applies, reading down from the top to settle the matching row. Read from the top and stop at the first hit and you will send again to someone already notified twice, manufacturing the very over-contact this section exists to prevent. Once the matching row is settled, whether to notify and which record decides it are settled together. The point is to stop assembling the judgement from scratch each time, so verifying that the deciding record is actually in your hands matters more than adding rows. Rows whose record you do not hold read not as notification conditions but as a list of records you still need to build.

A&A perspective

Apply that view to a fix notice and the sentence "we have fixed the defect" belongs on the explanation side. What is stalled on the user's side is work, not understanding. To move it toward completion, the notice carries the one move that restarts the stalled work: on which screen, which operation to retry. If the retry already happened automatically, the notice carries the fact that it did.

A&A perspective

This is not about making the wording more considerate; it is about making it shorter. The cause analysis, the prevention policy and the volume of apology are surplus against the purpose of the notice. What goes in is the name of the operation they hit and the one move that restarts it, and nothing else. A notice missing those two leaves the recipient with the judgement of what to do now, which is to demand their effort a second time.

A&A perspective

The resolution check is a process separate from this notice. That you sent a notice is not evidence that the issue resolved. That Gumloop holds effect confirmation as its own daily process reads as following from the same separation: the fact of sending and the fact of being fixed are different facts. At one-person scale the signal can be a record rather than a survey. Did the notified user run the same operation again afterwards and succeed? Settle that one signal in advance and the check stops being a manual round of outreach each time.

A&A perspective

Leaving a numeric target out of the hypothetical is deliberate. What this design changes directly is the range of users a fix reaches and the count of resolutions you could confirm. How cancellation or retention rates move does not come out of this table.

A&A perspective

Four limits. First, both sources are the publishers' own accounts of themselves, not independent audits. The Gumloop article describes that company's operation and the Decagon page describes that company's product philosophy. Neither demonstrates reproducibility at small-business scale. The figures displayed on both pages are also left out of this article, because no denominator or definition is given for them.

A&A perspective

Second, neither page says to pick the recipient by who hit the error rather than who reported it. That deciding axis, and the design of writing stop conditions into the same table, are A&A's proposals. Third, the Gumloop machinery runs on a premise that errors, users and merge history are already linked. For a product without that link, the precondition section above is the first task.

A&A perspective

Fourth, this article measures no effect. A&A has not measured any relationship between this design and cancellation, retention or revenue, and offers no prediction that wider notification reduces churn. That excessive notification frequency works against you is anticipated in the design itself, which is why the stop conditions sit in the same table.

A&A perspective

There is one step available today. Open one recent error record and check whether you can identify the user from it. If you can, start by writing the identifier of the repaired error into the description of your next merge. If you cannot, the work of building that link waits ahead of any notification design. Either way, the entrance from an operation that relies on memory to one that relies on records is in the same place.