No Signal, No Battery, No Phone
The three ordinary failures that stop a punch, and the designs that keep them from stopping pay.
Technical · Procedure
Every attendance deployment meets these in the first month. Designing for them in advance is the difference between a nuisance and a grievance.
No mobile signal
A punch cannot transmit, though a position may still be obtainable.
Good apps queue locally and sync when coverage returns, preserving the original timestamp.
Bad apps refuse, or record the time of transmission.
Ask which yours does and test it: airplane mode at the door, punch, restore signal, and check the recorded time.
A product that records the sync time rather than the punch time will generate disputes at every site with a weak signal.
No position fix
Covered elsewhere, and the fallback is the same: accept with a flag.
Queueing does not help here, because the problem is the fix rather than the transmission.
Which is the argument for a second method — wifi visibility or a beacon — that does not depend on satellites.
Flat battery
The commonest of the three and the one with no technical answer.
A person with a dead phone cannot punch, and they are still at work.
Which requires a non-phone route: a terminal, a supervisor entry, a paper fallback, or a code they can submit later.
Charging points at work help more than any configuration, and cost almost nothing.
No phone at all
Broken, lost, forgotten, or never owned.
This must have an answer or the deployment has made a personal device a condition of being paid.
A shared terminal at the entrance is the usual solution and works for everyone.
Say what the answer is when the system is introduced, rather than discovering it on the day.
The rule across all four
Work performed is paid.
The fallback takes seconds and does not require finding a manager.
The failure is recorded as a failure, so the pattern is visible and the site can be fixed.
Nobody is worse off for a fault in the employer's system.
What to measure
Queued punches, as a proportion — high means a coverage problem at that site.
Fallback usage, by site and by cause.
Time from fallback to resolution.
A site with high fallback usage needs a different primary method, not a reminder to charge phones.
Test the queue behaviour
A five-minute check with a large consequence.
Airplane mode at the door, punch, restore signal.
Check the recorded time.
If it records the sync time rather than the punch time, every weak-signal site will generate disputes.
Ask the vendor first and verify anyway, because the answer and the behaviour differ more often than they should.
Connect policy to configuration
The practical choices behind this note can be compared with the field-mapping example. Keep the written purpose in control and enable only the data needed for it.
Independent reference
For an external point of reference, see Ofcom. Its published guidance provides useful context for testing the assumptions in this note.
More in this section