Lateness alert software: what changes when the information arrives the same day
06.09.2026
Most people searching for lateness alert software are not really looking for a report. They want to change one thing: to have information about lateness arrive the same day rather than at month end.
The difference looks small and in practice means two different operating modes. This page explains how notification rules are built and why most of them stop being read after a few weeks.
Two different questions
A report and an alert do not replace each other, because they answer different questions.
The report answers "what happened". It is read at month end, serves documentation and payroll preparation, and demands accuracy.
The alert serves "what can be done now". If a shift has not opened, cover is arranged within the hour; if three people at a branch are late, the decision is made before customer traffic starts.
The practical consequence: nothing can be done about lateness learned at month end - it can only be recorded. The entire value of an alert lies in the ability to act the same day.
What a notification rule consists of
A working notification rule is made of three elements:
- The event - what triggers the notification.
- The recipient - who it goes to, and for which part of the structure.
- The action - what that person does when it arrives.
The third is the most often skipped and the most important. A notification with no specific action behind it is not information but noise - and after a few weeks it stops being opened at all.
Which events are worth setting up
The four events used most in practice:
- Lateness - the day started later than the schedule.
- Early departure - the day closed earlier than the schedule.
- A day that never started - the case that demands action most.
- Overtime - the case that requires approval.
Two technical events can be added: a record that does not match the expected point, and an employee's device change. Both are events to review - not automatic conclusions.
An important rule: they should not all be switched on at once. Starting the first month with one or two produces a more durable result, because the team gets time to build the habit of responding.
Who should receive it
The most common mistake: every alert goes to everyone.
When ten notifications that do not concern someone arrive, the eleventh goes unread too. That is behaviour, not technology - and no setting fixes it.
The model that works splits by role and scope:
- Branch manager - cases from their branch only.
- Department head - their team only.
- HR - the overall picture, usually as a periodic summary.
- Company owner - a periodic report rather than daily events.
The full method for building that split is on the distributing notifications page.
The noise problem
Notifications die for three reasons, and all three are solved at the setup stage.
The recipient list is too wide. Fix: define the recipient for every notification together with the structural scope.
The threshold is unrealistic. Alerting on a five-minute delay is usually pointless because nobody acts on it. The threshold has to line up with the company's own rule.
The action is undefined. Fix: before setting it up, write one sentence - "when this notification arrives, who does what".
Practical scenarios
Retail chain. At opening time one of the two staff at a store has not arrived. The alert goes to the branch manager, who asks a neighbouring store for cover - the matter closes before customer traffic starts.
Shift-based production. As the night shift starts, one of three people has made no record. The alert goes to the shift supervisor; the problem surfaces at the beginning of the shift rather than halfway through.
Field crew. The working day at a site has not started. The alert goes to the site manager - the day is not lost.
What the three scenarios share is that in each of them a specific, pre-agreed action sits behind the alert.
Setup sequence
- Write the lateness threshold - a number that matches the company rule.
- Pick one event: "the day never started" is usually the most useful.
- Define the recipient together with the structural scope.
- Write the action in one sentence.
- Run it for a month and ask: how many times did these alerts lead to a real action?
- Based on the answer, add a second event or refine the first.
Building alerts and reports together
Building a notification system on its own is the most common mistake. In practice the two layers only work together, and dividing them rests on one simple question: does this event require action today?
If the answer is yes - an alert. If no - a line in a periodic report.
One company's split looked like this:
- Alert: a shift has not opened, an employee has not arrived at the site, overtime is awaiting approval.
- Daily report: the lateness list per branch - the manager reads it in the morning.
- Weekly report: comparison across departments - discussed at the meeting.
- Monthly report: the timesheet and payroll cut.
After that split was built, the number of alerts fell from thirty a day to four - and those four started being read.
A worked example: bringing alerts back to life
A retail chain had set up a notification system a year earlier and nobody looked at it any more. To find the cause, one simple check was run: over the last month, which alerts had been followed by a real action?
The result was clear. Of 640 alerts, 610 were about lateness, with the threshold set at one minute. Thirty were about shifts that had not opened - and every one of those had been followed by an action.
The fix had three steps. The lateness threshold was aligned with the company's own rule - ten minutes. Lateness alerts were routed to the branch manager, while shifts that had not opened went to both the branch manager and the operations director. HR stopped receiving daily alerts and instead started receiving a daily summary report at nine in the morning.
A month later the open rate on alerts rose from 12% to 87%. The system had not changed - only the rules had.
The next step
A notification system does not replace reporting - it completes it. The best result comes from building both together: urgent events by alert, the overall picture by periodic report.
See how those two layers work in what QRGate does, or calculate the price.
