With two sites, spreadsheets work. With four they become awkward. By seven the company is no longer managing attendance - it is managing files. The case for a multi-branch attendance system usually begins on one specific day: somebody notices that one of the three files sent to head office is an old version, and the month-end report slips by a day. The problem is not Excel itself. It is having several people fill in the same thing in parallel.
What changes as sites are added
Excel is an excellent tool for one person. The difficulty starts when several people maintain the same structure at once. As sites are added, three things grow faster than linearly:
- Reconciliation time. Merging three files takes half an hour; merging ten takes half a day, because each file has developed its own small differences.
- The number of queries. "What does this cell mean?" has to be asked per site.
- Error probability. Every additional copy step is another place to get it wrong.
What is worth noticing is that this growth depends on the number of files, not the number of employees. A single 200-person office can live with Excel. Six sites of 60 people cannot.
Versions and the consolidation trap
Consolidation - merging separate files - is where most of the loss happens. Four classic problems appear there:
| Problem | How it shows up |
|---|---|
| Version sprawl | "final", "final_2", "corrected_final" |
| Template drift | A site added a column or renamed one |
| Different meanings | The same mark means time off at one site and a work day at another |
| A late file | One site has not sent theirs and the report waits |
The last one repeats most often. A single delayed file stops the entire report, because the report can only be assembled once everybody's file has arrived.
What central visibility really means
The defining difference of one system is not a nicer interface - it is that a site stops being a file and becomes a filter.
In practice it looks like this: a manager sees the whole network's day on one screen, narrows to one site, then to one role. At no point is a file opened, merged or waited for.
The more important consequence is that reporting no longer depends on waiting for everyone's file. Data accumulates during the day, so month-end becomes a review step. We explain the general logic of such a system on the what is an employee attendance system page.
Site-level and network-level reporting
A multi-site company always needs reporting at two levels, and the two must not be mixed.
- Site level. Own team, own timesheet, own lateness list. A site manager should not see another site's data.
- Network level. Comparison: where attendance is weaker, where a shift is chronically understaffed.
With spreadsheets the second level barely exists, because comparison requires every file to keep an identical format - and that never survives for long. We describe how such a report is structured on the attendance report page.
What a growth-ready setup looks like
When you open a new site, four questions reveal how ready your setup is:
- How many steps does adding a site take - one record, or a new file and a new process?
- Is a site manager's field of view actually restricted?
- Does the network report wait for individual files?
- Does the new location require hardware to be installed?
The last question matters most, because the hidden cost of opening a site usually hides there. We covered why a QR-based approach is lighter in that respect on the advantages of a QR attendance system page.
A practical example
A pharmacy chain with seven branches kept attendance in seven separate spreadsheets. At month-end one person at head office merged them - around two working days.
Opening the eighth branch changed the arithmetic: two days became three, and the report missed the date finance expected. That, rather than any growth in complexity, was what triggered the change - the process simply was not built to grow.
After moving to one system the merge step disappeared entirely. The result the company valued more, though, was different: for the first time it could compare branches against the same criteria, because the data was now collected in the same shape.
How to test where you stand
One question is enough: how many people does your month-end report depend on?
If the answer is one, you have no problem. If it is three or more, the timing of your reporting is no longer under your control - and that only gets worse as sites are added.
Dividing responsibility between centre and site
The second half of moving to one system is organisational rather than technical: who is responsible for what?
The split that works: the site manager is responsible for the accuracy of daily data - whether time off was recorded, whether a shift change was written down. That concerns their own team and nobody else can do it.
Head office is responsible for the rules and the reporting: schedule types, the lateness threshold, report formats and deadlines.
The common mistake is handing the first responsibility to the centre as well. HR then tries to police site-level detail remotely - ineffective and a source of friction.
Starting with one site
The transition does not have to happen everywhere at once. Starting with one site usually produces faster results.
Pick the simplest structure rather than the most troublesome one. The aim is to get the process running and settle the rules.
The second site then joins with the rules already written, which usually takes a few days.
Next step
Think back to last month's report: how many days did you wait for the final file?
QRGate keeps attendance in a site-aware context, so a branch becomes a selection rather than another file. See what QRGate can do or calculate the price.
