Automated customer notifications: checking messages against system state

An automated customer notification is part of the outcome a system delivers. Before building email or text-message delivery, define which business state permits each message, who should receive it and what happens if data changes before sending. Technical success at a messaging provider does not prove that the content is correct. Acceptance checks should connect the system record, selected wording and message actually received, including situations in which nothing should be sent.

What happened with Grail's notifications?

In June 2023, MedTech Dive reported incorrect letters sent to about four hundred people. According to Grail's statement quoted in the article, letters containing inaccurate information were triggered by a software configuration problem at telemedicine provider PWNHealth, rather than an incorrect laboratory result. This is the company's account of a historical incident. It does not establish that the test never produces errors or constitute our assessment of its medical quality.

Our proposed product lesson is to examine the path from information to notification as carefully as information creation itself. An external supplier may perform delivery, but someone in the business must still approve the meaning and the conditions under which it can be communicated. We have no basis for claiming this is always the cheapest system component. We can reasonably require explicit ownership of message meaning instead of leaving it between teams.

Start with business state, not an email template

List the notifications users may receive and connect each to a defined state. In a hypothetical order workflow, receipt of a request, payment approval and shipment departure are different events. Reusing one template for all three can imply that a later step has already happened. For each template, define required fields, their authoritative source and the condition that prevents sending when information is insufficient.

Include changes such as cancellation, a corrected address, an updated amount or a different contact. A queued notification may be sent after its underlying state changes. Decide whether to recheck data at sending time, cancel a pending message or issue a correction. Record that choice in the technology product specification according to its business meaning, rather than leaving it as an accidental consequence of the delivery tool.

Distinguish persistence, sending and delivery

A saved business action is not necessarily a sent notification, and a provider-accepted message is not necessarily one that reached its recipient. Name these states separately. When sending fails, the team needs to know whether the underlying business action completed and whether another attempt is needed. A generic error can prompt someone to repeat an already successful action, creating duplication that must later be resolved.

An internal Julius integration decision for enquiry notifications specified persistence before notification, together with a recorded notification outcome for failure handling. This is a documented design decision, not a claim that the solution was verified in every production environment or that every email arrived. The example illustrates why the record system and its notification need separate definitions even when users experience them as one event.

Check recipient, language and destination links

Prepare examples involving different users, roles and languages. Verify the correct recipient, wording appropriate to the state and a link to a record the recipient may access. Testing only with an administrator account can conceal links that fail for an ordinary customer. For sensitive information, consider what must appear in the notification and what is better displayed after signing into the system.

Use test recipients and prepared data so that checks do not accidentally send real notifications. Exercise long text, missing fields, Hebrew mixed with numbers and permission-controlled links. Inspect the delivered result rather than only a template preview. If the sending provider allows templates to change outside the codebase, define who may change them and how changes are checked before use.

Prevent duplication and prepare a stop mechanism

Define how to recognise another attempt at the same message and distinguish it from a new notification about a genuine change. Retrying after a timeout should not automatically produce two contradictory messages. Ask the team to demonstrate the case in a test environment and show the evidence retained for investigation. Do not promise exactly-once delivery without understanding the chosen integration and provider's limitations.

Provide a way to stop a particular notification type without necessarily stopping all business activity. During an incident, identify affected recipients, pending messages and the person authorised to approve corrections. A correction is itself an action requiring review: it must explain what changed without introducing unsupported claims. Retain enough evidence for investigation while limiting personal information that is unnecessary for operations.

What changes when AI drafts the message?

Separate selecting facts from expressing them. A model may help with wording but should not invent payment, approval or shipment status. Define which fields must come from an authoritative source, permitted formulations and when human approval is needed. Our guide to choosing AI developers discusses quality checks and action boundaries. Match the level of control to the consequences of an incorrect message, not merely the ability to produce persuasive text.

For a conversation with Julius about software development, bring two existing messages and a scenario in which one must not be sent. Request an event table, sending conditions, named owners and an end-to-end test plan. This makes notification behaviour part of the product estimate and provides a way to verify that the message tells customers what actually happened in the system.