When a notification system is set up, everything looks fine in the first week. A month later the typical picture is this: the notifications arrive and nobody looks at them. Splitting attendance notifications is the fix for exactly that problem.
This piece covers why a notification "dies" and how the distribution is built.
The sequence in which a notification dies
The process runs almost identically every time.
Week one: the notification is new and everyone opens it. Week two: the recipient notices most of them do not concern them. Week three: they close it without reading. Week four: notifications are muted.
Notably, this has nothing to do with the quality of the notification. The information is correct and arrives on time - it simply is not for that person.
When ten notifications that do not concern someone arrive, the eleventh goes unread too. That is behaviour, not technology - and no setting fixes it.
Three questions before the split
Three answers should be written for every event:
- When this event happens, who has to act?
- What is that action?
- Which part of the structure is that person responsible for?
The third is skipped most often and makes the biggest difference. Sending a branch manager every lateness in the company makes the notification useless from the first week - whereas the same notification scoped to their own branch gets read every day.
The second question - the action - is the next most commonly skipped. A notification with no specific action behind it is not information but noise.
The distribution model that works
- Branch manager - events from their branch: a shift that has not opened, lateness, early departure.
- Department head - their team only.
- HR - the overall picture, usually as a periodic summary rather than daily events.
- Company owner - a weekly or monthly summary.
- Accounting - not events at all, only the approved periodic report.
The governing principle: the higher you go, the lower the frequency and the wider the scope. Frequent and narrow at the bottom, infrequent and broad at the top.
Notification or report?
The most useful distinction for building the split is made with one question: does this event require action today?
If yes - a notification. If no - a line in a periodic report.
A practical example: a shift that has not opened requires action today - cover has to be arranged. Monthly lateness statistics per branch do not - looking at them once a week is enough.
Once that distinction is made, the number of notifications usually drops sharply - and the ones that remain start being read. More on this: distributing notifications.
Choosing the channel
The channel follows the recipient's working pattern; they are not all switched on at once.
For a manager out on site, a notification visible on the phone is most effective. For an HR manager at a desk, email is enough. SMS and messaging are used only for urgent events and in limited numbers.
The rule is simple: the channel follows the urgency of the event. Using three channels for a non-urgent event drains attention from notifications very quickly.
Tying the split to roles
The most overlooked detail in practice is staff turnover. When a branch manager changes, notifications often keep going to the old address - sometimes for months.
The way to prevent this is to tie the distribution to the role rather than the person. Then, when a new manager is appointed, the notifications transfer automatically and no extra setup is required.
A second practical detail: in their first week a new manager does not know what the notifications mean. Adding the distribution table to the onboarding document closes that gap.
The quarterly check
Distribution is not something you set once and forget. Once a quarter - and whenever the structure changes - one question is asked:
Over the last month, which notifications were actually followed by an action?
The answer is usually short and the conclusion direct: any notification type that led to no action should either be switched off or turned into a line in a periodic report.
The check takes ten minutes, but it is what keeps a notification system working into its second year.
A worked example: from thirty alerts to four
A restaurant chain had five sites and ninety employees. When the notification system was set up, every event was switched on and all of them went to three people - the chain director, HR and the operations manager.
In the first month each received about thirty alerts a day. By the end of the second month all three had muted them.
The review asked one question: over the last month, which alerts had been followed by a real action? The answer pointed to only one of four event types - a shift that had not opened.
A new split was built: unopened shifts to the site manager and the operations manager; lateness only to the site manager and only for their own site; HR receiving a daily summary at nine in the morning instead of individual alerts; the chain director a weekly summary.
The result: the site manager received four alerts a day and read all of them. On top of that, response time to unopened shifts fell from forty minutes to eight - because the alert was now actually visible.
How to build the distribution table
In practice a one-page table is enough. Columns: event, recipient, scope, channel, action.
The rows are filled in one by one, and for each row the last column - action - must be written. A row left blank means no notification is needed for that event; it belongs as a line in a periodic report.
Once the table is complete, run one check: how many rows does each recipient have? More than five, and the distribution is probably too wide - some events should move into a report.
The table also becomes the reference document when the structure changes: when a new branch opens, who gets what is not re-debated - the table is consulted.
The next step
The simplest way to build the distribution is to start with one event - usually "the day never started", because the action behind it is obvious.
See how notification rules are set up, look at what QRGate does, or calculate the price.
