How Many Terminals, and Where
One device serving three hundred people in a ten-minute window is a sizing error with a formula, and the formula is never applied because nobody owns the number.
Sizing one site
Arrivals in the peak window
300
Service time per punch
4 sec
Capacity of one terminal in 10 min
150
Terminals actually needed
2–3
The site has one. It was sized for a headcount half the current one, and the queue has grown quietly with the business.
A terminal has a service rate. Four seconds per punch for a card or fob, six to ten for a fingerprint, longer if the reader is marginal or the person is wearing gloves.
The practical lesson in “How Many Terminals, and Where” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring how to handle multiple clients, this workforce software resource can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.
A shift change has an arrival rate: a few hundred people in ten minutes. Divide one by the other and you have the number of terminals required. The calculation takes thirty seconds and is almost never done, which is why most sites have the number they started with.
For a separate benchmark relevant to “How Many Terminals, and Where”, consult the Atlassian project-management guide. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.
The sizing calculation
Arrivals in the peak window, divided by the window in seconds, times the service time, gives the number of devices needed to keep up.
Three hundred people in six hundred seconds at four seconds each needs two devices to break even and three to have any slack. One device will clear three hundred punches in twenty minutes, and the last person in the queue waits most of that.
Add slack. A single-device site has no redundancy: when the unit fails, there is no clocking at all, which is the subject of its own note.
What changes the service time
The method. Card and fob are fastest. Fingerprint is slower and has a failure rate that adds retries. Facial recognition is fast when it works and slow when the light is wrong. PIN entry is the slowest and should not be the primary method on a busy site.
The environment. Cold hands, gloves, wet fingers, dust and bright sunlight all degrade biometric reads, and the degradation is worst at exactly the sites where shift changes are large.
The interaction. A terminal that asks a question after the punch — a job code, an attestation, a confirmation screen — adds several seconds per person and triples the queue. Every additional prompt should be justified against that arithmetic.
Where to put the second one
Not next to the first, which only helps if the queue is at the device rather than at the door.
At the other entrance, which splits the arrival stream and attacks the cause.
Or at the point people reach first, so the punch happens on arrival and the remaining queue is inside the paid day.
The prompts to remove
Most busy sites have accumulated screens: confirm your shift, select a cost centre, acknowledge a message, answer a wellbeing question.
Each was added by somebody with a legitimate reason and none of them was costed against the queue. A three-second prompt on three hundred punches twice a day is fifty minutes of queue per day.
Move the prompts to a device people use at their own pace, or to the end of the shift, or remove them. The attestation questions in particular are better asked once a week on a screen somebody can read than twice a day in front of twenty people waiting.
Measuring the queue rather than assuming it
Stand at the terminal for three shift changes. Count arrivals per minute, time ten punches, note the longest queue.
Those three numbers size the problem exactly and cost half an hour. Every alternative — asking the vendor, reading the specification, inferring from punch timestamps — is less accurate and takes longer.
The punch-timestamp method
Where observation is impractical, the punch data itself shows the queue: a tight cluster of punches at four-second intervals is a saturated device, and the duration of the cluster is the clearance time.
A site whose punches arrive in a continuous four-second sequence for eleven minutes has a queue of eleven minutes, and that is derivable from data already held.
Who should own the number
Somebody who sees both the hardware and the hours. In practice this means putting terminal sizing into whoever owns the boundary document, and reviewing it when the headcount changes.
The failure mode is a site that has doubled in ten years with the same single device, where every individual year's growth was too small to prompt a review.
The device that is slower than its specification
Published read times assume a clean credential presented squarely at the reader. In practice there are worn cards, gloves, cold fingers on a biometric, a screen that has to wake, and a person who presents the badge twice because the first beep was ambiguous.
Measure the service rate on the device you have, at shift change, rather than taking it from the datasheet. The measured figure is routinely half the specified one, and sizing from the specification is how a site ends up with the right number of terminals on paper and a queue every morning.