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

- Canonical: https://qrgate.az/en/distributing-attendance-notifications
- Markdown: https://qrgate.az/en/distributing-attendance-notifications.md
- Language: en

**Distributing attendance notifications** looks like a technical setup but is really a question of behaviour. The system runs, the notifications go out - and after a few weeks nobody opens them.

The cause is almost always the same: the recipient list was built too wide. Below is how to fix it.

## How a notification dies

The process always runs in the same order.

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, and no setting fixes that.

## Three questions: who, what, which scope

Before building the distribution, 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 question 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 branch alone 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.

## Role-based distribution

The model that works in practice:

- **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 individual events.
- **Company owner** - a weekly or monthly summary; daily events are almost always excessive here.
- **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.

## Branch and department scope

The technical side of distribution depends on structural support. If the system does not support branch, department and section levels, notifications either go to everyone or to a manually picked list - and the second goes stale and gets forgotten as soon as the structure changes.

With the structure in place, the notification rule is written once and works automatically when a new branch is added: that branch's manager receives its events.

The practical test question: *when a new branch opens, do the notification rules have to be rebuilt?* If the answer is yes, the distribution is tied to people rather than the structure - and it will fall apart within six months.

## Choosing the channel

The channel follows the recipient's working pattern; they are not all switched on at once.

- **Mobile notification** - most effective for a manager out on site.
- **Email** - for an HR manager at a desk and for periodic reports.
- **SMS and messaging** - for urgent events, 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.

## A quarterly review

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.

This review takes ten minutes, but it is what keeps a notification system working over the long term.

## 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 of the three 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.

The new split was built like this. A shift that had not opened went to the site manager and the operations manager. Lateness went only to the site manager, and only for their own site. HR received no daily alerts - instead a daily summary at nine in the morning. The chain director received a weekly summary.

The result: the site manager received about four alerts a day and read all of them. The operations manager received six to eight a week. HR was freed from alerts entirely.

The company noted one detail: after the split was built, 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: arrange cover.

[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).

### Related pages

- [Lateness alert software](https://qrgate.az/en/lateness-alert-software)
- [Scheduled attendance reports](https://qrgate.az/en/scheduled-attendance-reports)
- [Attendance system for multiple branches](https://qrgate.az/en/multi-branch-attendance-system)
- [Monitoring employee attendance](https://qrgate.az/en/monitoring-employee-attendance)

## 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. A notification system that works is built from a small number of events, each aimed at a specific recipient.

### Which questions should be answered before building the distribution?

Three: 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 - sending a branch manager every lateness in the company makes the notification useless from the first week.

### Which distribution works best in practice?

By role and scope: the branch manager receives events from their branch, the department head their team, HR the overall picture. The owner is usually better served by a periodic summary than by daily events. This split is set up once and revisited quarterly.

### What is the difference between a notification and a report?

Urgency. A notification is for an event that needs action now - a shift that has not opened, an unexpected absence. A report shows the picture and is read at a set time. If an event is not urgent, it does not need a notification - it belongs as a line in a periodic report.

### When should the distribution be revisited?

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

## Related pages

- Attendance for small business - [Markdown](https://qrgate.az/en/attendance-system-for-small-business.md) | [HTML](https://qrgate.az/en/attendance-system-for-small-business)
- Shift schedules - [Markdown](https://qrgate.az/en/how-to-prepare-a-shift-schedule.md) | [HTML](https://qrgate.az/en/how-to-prepare-a-shift-schedule)
- Managing work schedules - [Markdown](https://qrgate.az/en/managing-employee-work-schedules.md) | [HTML](https://qrgate.az/en/managing-employee-work-schedules)
- Lateness alert software - [Markdown](https://qrgate.az/en/lateness-alert-software.md) | [HTML](https://qrgate.az/en/lateness-alert-software)
- Tracking clock-in times - [Markdown](https://qrgate.az/en/tracking-clock-in-clock-out-times.md) | [HTML](https://qrgate.az/en/tracking-clock-in-clock-out-times)
- Multi-branch attendance system - [Markdown](https://qrgate.az/en/multi-branch-attendance-system.md) | [HTML](https://qrgate.az/en/multi-branch-attendance-system)