It is one of the most frequent sentences in a demo: "our system works in real time." That phrase says almost nothing, because every vendor means something different by it. The practical value of real-time attendance is measured by one question: after a record is created, when does it become visible and to whom? This article moves the phrase out of marketing and onto criteria you can actually test.
What real time does not mean
Three misunderstandings are common, and none of them surfaces during a demo.
First, device speed. A record appearing within a second is not real time - that is reading speed. The question is where the record appears.
Second, daily synchronisation. In some solutions records accumulate on the device and are pushed to the centre once a day. That can be a perfectly workable model, but it is not real time.
Third, a refreshing screen. A page updating automatically says nothing about whether the data arrived promptly - it may already be stale.
What companies actually need
In truth a company does not need "real time". It needs timely visibility, and the two are different things.
How timely depends on the type of work:
| Scenario | When the data is needed |
|---|---|
| Shift coverage | Within the first 15-30 minutes of the shift |
| Reacting to lateness | The same day |
| Weekly trends | At the end of the week |
| Timesheet and payroll | At month-end |
Only the first row genuinely demands speed. For the other three, a daily update is sufficient.
How to ask the right question
Asking "do you work in real time?" during a demo is useless - the answer is always yes. Ask three specific questions instead:
- How many seconds or minutes after a record is created does it appear on the central screen?
- Is that true for every recording method, or only some of them?
- What happens to a record when connectivity drops, and how does the system behave once it returns?
The third question is the most informative. If the answer is "the record is lost", the model may not suit you - particularly at sites with weak connectivity.
Offline behaviour: the detail that matters
In practice the difference between systems shows not while the internet works but at the moment it fails.
Three behaviours are possible: no record is created at all; the record is stored on the device and transmitted later; or a record is created and its time is reconciled afterwards.
Each has its own consequence, and the right one depends on your conditions. What matters is knowing in advance which one applies - learning it during the first outage is too late. We cover the cloud and on-premise distinction on the cloud or on-premise attendance system page.
Realistic expectations about notifications
Notifications are often promised broadly during a demo. A careful approach is warranted.
The right question is not "do you have notifications?" but "for which event, to whom, and under what conditions?". Some capabilities may be enabled separately rather than being available to every customer.
So confirm in writing before signing which notification types are included in your plan. A verbal promise is not enough on this subject.
Reporting from current data
The second benefit of timely visibility sits in reporting, and it is rarely discussed.
When data accumulates during the day, the month-end report is not "assembled" - it already exists and only needs checking. That is the main factor shortening timesheet preparation.
Conversely, when data is transferred once a day or once a week, month-end always turns up gaps, and investigating them takes time.
When speed genuinely matters
Not every company needs the same speed. Four situations make it critical:
- Shift work - coverage problems need an immediate response.
- Service operations - one missing person means a customer queue.
- Security requirements - who is on site has to be known.
- Multiple sites - without a central view every decision arrives late.
In a single office on fixed hours, a daily update is usually entirely sufficient and not worth paying extra for.
Fast is not the same as complete
This is the point most often missed. A record can appear within a second and still be incomplete.
The reason is that an attendance record carries no meaning on its own - it needs schedule, leave and time-off context. If the context is absent, speed solves nothing.
In practice a fast but context-free system is less useful than one that lags an hour but is complete. We describe what such a system should cover on the what is an employee attendance system page.
A practical test during the demo
Instead of debating in the abstract, run an experiment: create a record during the demo and watch the central screen at the same moment.
Note three things: how many seconds until it appeared; did it appear with schedule context; did the site filter work?
That three-minute test tells you more than a long discussion.
What to get in writing
Four things belong in the proposal or contract: the visibility delay, offline behaviour, the list of available notification capabilities, and which sources the report can combine.
Verbal promises are not remembered six months later. A written record helps both sides.
A practical example
A 60-person shift-based company chose a system on the promise of "real time". After installation it emerged that records accumulated on the device and were transmitted to the centre once a day, overnight.
Technically the vendor had not lied: the record was created on the device immediately. But the company's need was different - knowing within the hour who was missing from the morning shift.
The problem only surfaced three months later, after a serious coverage incident. In the next selection round the company asked one question up front: "when does a record appear on the central screen?"
We cover the wider picture on the monitoring employee attendance page.
How to judge your own need
Three questions define it: within how many minutes must you know that shift coverage has broken; how many sites do you monitor at once; do you have locations with weak connectivity?
If the answer to the first is "a few hours", speed is not your main criterion and is not worth paying extra for.
Next step
Run one measurement on your current system: what time was today's first record created, and what time did it appear on the central screen? If there is a gap, write it down in minutes.
QRGate shows records as they are created, together with site and schedule context. See what QRGate can do or calculate the price.
