# How to split notifications between HR, managers and other owners

- Canonical: https://qrgate.az/en/blog/splitting-notifications-between-hr-and-managers
- Markdown: https://qrgate.az/en/blog/splitting-notifications-between-hr-and-managers.md
- Language: en
- Date: 2026-08-14

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:

1. **When this event happens, who has to act?**
2. **What is that action?**
3. **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](https://qrgate.az/en/distributing-attendance-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](https://qrgate.az/en/lateness-alert-software), [look at what QRGate does](https://qrgate.az/en/advantages), or [calculate the price](https://qrgate.az/en).

## FAQ

### Why do people stop reading notifications after a while?

Because the recipient list was built too wide. When ten notifications that do not concern someone arrive, the eleventh goes unread too - that is behaviour, not technology, and no setting fixes it.

### What should be written before building the distribution?

Three answers per event: when this event happens, who has to act; what that action is; and which part of the structure that person is responsible for. The third is skipped most often and makes the biggest difference.

### Which distribution works in practice?

By role and scope: the branch manager gets their branch's events, the department head their team, HR the overall picture - usually as a periodic summary rather than daily events. For the owner, a weekly or monthly summary is more useful.

### When should the distribution be revisited?

Once a quarter and whenever the structure changes. The check is simple: over the last month, which notifications were followed by a real action? Any type that led to none should be switched off or turned into a line in a periodic report.

## Related pages

- Hardware requirements - [Markdown](https://qrgate.az/en/does-qr-attendance-need-extra-hardware.md) | [HTML](https://qrgate.az/en/does-qr-attendance-need-extra-hardware)
- Distributing notifications - [Markdown](https://qrgate.az/en/distributing-attendance-notifications.md) | [HTML](https://qrgate.az/en/distributing-attendance-notifications)
- Lateness alert software - [Markdown](https://qrgate.az/en/lateness-alert-software.md) | [HTML](https://qrgate.az/en/lateness-alert-software)
- Multi-branch attendance system - [Markdown](https://qrgate.az/en/multi-branch-attendance-system.md) | [HTML](https://qrgate.az/en/multi-branch-attendance-system)
- Shift worker attendance - [Markdown](https://qrgate.az/en/attendance-tracking-for-shift-workers.md) | [HTML](https://qrgate.az/en/attendance-tracking-for-shift-workers)
- Attendance without fingerprints - [Markdown](https://qrgate.az/en/attendance-without-fingerprint-scanners.md) | [HTML](https://qrgate.az/en/attendance-without-fingerprint-scanners)