Send a notification

Send a clear, trustworthy message that informs the user about something that has happened, or prompts them to take a next step, without requiring them to stay in the service.

This step supports one-way communication. If the service expects a response or information to be returned, use a separate Request information functional pattern.

Use this step to:

• confirm an action or outcome for example booking confirmed, application submitted

• remind users about a time-bound event such as appointments, deadlines, expiry)

• notify users of a status change or decision

• prompt users to return to the service to continue a task

• send authentication or security messages for example OTPs

When not to use

• the message itself must be a legal or official document

• the service requires the user to reply with information (instead ask users for information)

• sensitive personal data would need to be included in the message itself

---

Considerations

Channel choice

Use the right channel to support the urgency, trust, and inclusion of the message.

• SMS: for urgent or time-bound messages such as appointments, reminders, OTPs. Keep content short.

• Email: for confirmations and updates that do not need immediate action.

• App inbox / notification centre: for messages linked to an ongoing service or case.

• Letter delivered via post: when written proof is needed, digital delivery fails, or users have limited internet access

• Phone / assisted contact: for complex issues, high-risk cases, or when users need extra help or accessibility support.

Respect user contact preferences and provide opt-in and opt-out choices.

Content

Every notification should include:

• Who it’s from A recognisable and trusted service name.

• Why the user is receiving it Clear context (for example “about your appointment” or “about your application”).

• What happened or what’s needed Confirmation, update, reminder, or action required.

• When (if relevant) Dates, times, or deadlines.

• How to continue safely A clear call to action, usually linking to a secure environment.

• Fallback support What to do if the user can’t use the channel or link (for example a phone number or in-person option).

• Reference (when useful) A booking, case, or application reference the user can quote.

The message should be understandable on its own, without requiring prior context.

Content to include

Include only what people need to understand the message and know what to do next

Who it’s from: use a clear and trusted service name so people know the message is genuine.

Why they are receiving it: explain what the message is about, for example “about your application” or “about your appointment”.

What happened or what they need to do: say clearly if this is a confirmation, update, reminder, or if an action is needed.

When: Include dates, times, or deadlines if they are relevant.

How to continue safely: tell users exactly what to do next, with a clear and safe link or instruction.

Where to get help: Explain what to do if they cannot use the link or channel, such as a phone number or in-person option.

Reference number (if useful): Include a case, booking, or application reference people can quote if they need support.

The message should be clear on its own, without needing any other context to understand it.

Accessibility and inclusion considerations

• Do not rely on a single channel or assume smartphone access.

• Keep messages short and readable.

• Avoid images as the only way to convey meaning.

• Avoid exposing sensitive information on shared or insecure devices.

• Make sure the user can complete the task through an assisted channel if needed.