> For the complete documentation index, see [llms.txt](https://specs.govstack.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://specs.govstack.global/service-patterns/3.-step-patterns/send-a-notification.md). # 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: Do not use this pattern when: * the message itself must be a legal or official document * the service requires the user to reply with information, instead use the ask [users for information](/service-patterns/3.-step-patterns/ask-a-question.md) pattern. * the message would need to include sensitive personal data *** ## 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 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://specs.govstack.global/service-patterns/3.-step-patterns/send-a-notification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.