Which notifications deserve your team's attention?

A project changes several times during an afternoon. Your system sends a message for each update. By the time someone asks you to approve the revised brief, that request sits among messages you only needed to know about. Reviewing the notification rules starts with understanding what each message does for its recipient.

Our suggested review separates action requests, useful confirmations and updates that can wait for a digest or a visit to the record. These are three purposes to examine with the team, rather than a rule that every tool must use the same channels.

Give each message a purpose

An action request asks someone to do something. It should identify the relevant work, the action required and any real deadline. The person receiving it should have enough context and the right access to continue.

A confirmation tells someone that an action reached the expected point. A request received message, for example, can answer a question that would otherwise remain open. Its value comes from explaining what has happened and what that result means.

An informational update helps someone stay aware of work. Its timing depends on when they need that information. Some updates can be grouped into a summary. Others can remain in the activity record until a person chooses to review them.

The GOV.UK guidance on emails and text messages recommends sending messages that meet a user need. It recognises transactional confirmations as useful and advises making requested actions and deadlines clear. We use those principles here as a starting point for reviewing messages in a working tool.

Read the same event from different roles

Consider a fictional studio reviewing a client brief. A coordinator uploads a revised document and asks the project lead to approve its scope by Thursday. Another colleague follows the project to prepare a monthly account summary.

The project lead needs an action request: "Review the revised brief by Thursday." The message should identify the project and open the relevant version. A short explanation of what changed can help the lead understand why another review is required.

The coordinator needs confirmation that the review request was recorded. That confirmation must describe the actual state. A recorded request does not mean the lead has read it or approved the document.

The colleague preparing the monthly summary may need the final decision in a digest. Every intermediate edit may be unnecessary for that task. Ask the colleague which changes affect their work before deciding what to group.

The event is shared. The useful message depends on the recipient and the job they have to do.

Review a real sample before changing the rules

Take the last ten messages received by one role in your team. Keep the review inside your authorised workspace and use example content when discussing it more widely. For each message, ask what question it answered or what action it made possible.

Write down whether it arrived at a useful moment, whether the recipient could act and whether another channel sent the same information. A duplicated message may still be justified for an agreed urgent case. The point is to identify its purpose and choose the rule deliberately.

Include confirmations in this review. If a person cannot tell whether a submission succeeded, removing its receipt would leave an important question unanswered. Conversely, a confirmation should describe only what the system can establish at that moment.

Make one notification rule explicit

Use the following note for one message type:

Event: Which change creates the message?

Recipient: Who needs to know, and for which task?

Purpose: Request action, confirm a result or provide an update?

Timing and channel: When is it useful, and where should it appear?

Content: Which record, action, deadline or confirmed state must be clear?

After the next change: What should happen if the request is completed, cancelled or assigned to someone else?

That last question matters when messages describe work that keeps moving. Before sending a reminder, the rule should check whether the original request is still relevant.

Test the revised rule with the recipient

Choose one proposed change and walk through it using sample work. Check that the intended person receives the message, can recognise its purpose and can open the relevant record. Also check what happens after the task is completed.

Ask the recipient whether an essential signal disappeared. Use their answer to adjust the rule before applying the same pattern more broadly.

Review ten recent notifications and name the purpose, recipient and useful timing of each.

Prepared for WGMI with AI assistance.