# Attendance for field teams: what to do when there is no fixed entry point

- Canonical: https://qrgate.az/en/attendance-for-field-teams
- Markdown: https://qrgate.az/en/attendance-for-field-teams.md
- Language: en

**Attendance for field teams** differs from the office model in one fundamental way: there is no fixed entry point. The site changes, the crew splits, and the working day sometimes starts at a customer's address.

In those conditions the terminal model never really closes. Below is how the alternative setup works and which points have to be agreed in advance.

## What makes field work different

In an office the recording point is a door, and it stays where it is. In construction, installation, service and sales teams the site can change several times a week.

The result is one of two typical scenarios. Either no record is kept at all and a "worked / did not work" list is written at month end, or the foreman fills in a list from memory at the end of the day.

Both produce the same outcome: those rows become the most disputed part of the timesheet. The employee says "I was there" and there is no document; the foreman says "as I remember it" and no document is asked of them either.

## A site-linked record

The central idea of the alternative setup is this: the record attaches not to a device but to a *site*.

In practice it works like this. Every site is set up as a separate unit in the structure - a branch, an area or a point. The working day starts at the site itself and the record is written against it. Later the report answers "who worked where" directly.

A second layer sits on top: the record is matched against the location of the expected point, and a mismatch reaches the responsible person as a notification. That moves the matter from month end to the same day - a particularly large difference in field work, because recalling a site change twenty-six days later is practically impossible.

## Crew and site reporting

Field work needs two cuts more than any others: **daily staffing per site** and **how the load is distributed between crews**.

Both depend on the system's structural support. With branch, department and section levels in place, the same records can be read by site, by crew and by individual employee. Without that structure the report is either too general or too granular.

The practical test question to ask during a demo is this: "This month, at site four, how many people from which crew worked how many hours?" If the answer does not come in a few clicks, the reporting is not ready for field work.

## Checking the conditions

Field conditions differ sharply from office conditions, and the trial has to run there.

- **Network coverage** - tested at the farthest and deepest point of the site.
- **Physical conditions** - dust, gloves, sunlight, temperature.
- **Device availability** - what share of the crew has a suitable smartphone.
- **Time pressure** - how many seconds a record takes at the morning shift start.

A trial run in the office tests none of these four and makes the result look artificially good.

## Handling exceptions

In field work the exception is the rule, so it has to be planned for in advance.

**An employee without a phone.** Two routes exist, both inside the same system: a record at an NFC point, or a record entered manually by the foreman. The latter leaves a trace with its author and timestamp, so it can be checked later.

**A weak-coverage point.** The rule is agreed in advance: who makes a correction, in which cases, and within what time. A written rule turns the exception into something manageable; an unwritten one becomes a monthly argument.

**Site changes and business trips.** These need their own record type - otherwise they appear as mismatches and multiply notifications for nothing.

The most important principle: the exception must live in the main timesheet, not on a separate paper list. An exception kept outside the system becomes a second source at month end.

## Setup sequence

1. Build the sites into the structure - each as a separate unit.
2. Represent the crews at section level.
3. Write the exception rules: weak coverage, site changes, business trips.
4. Trial it for a week at the hardest site.
5. Run a parallel month.
6. Switch on notifications - at first only for a shift that has not opened.

## A worked example: a construction company

A construction company's team of sixty worked four sites at once. Two of the sites were inside the city, two outside it.

The record worked like this: at each site the foreman wrote a daily list, and the lists were brought to the office once a week. At month end HR transferred four notebooks into one spreadsheet.

There were two problems. First, the lists arrived late - a gap at a site became visible a week later. Second, when an employee worked at two sites in one day, which site got the entry depended on the foremen agreeing between themselves.

In the new setup every site was created as a separate unit in the structure. The record was made at the site itself and written against it; when an employee moved to a second site during the day, they opened a new record there.

Three results followed. Staffing per site became visible daily. Hours worked at a second site were read separately. And most importantly, the month-end work of reconciling four notebooks disappeared entirely.

Coverage was weak at one of the out-of-town sites. The rule was written in advance: at that site the foreman makes the correction during the day and the correction stays as a trace. That turned the exception into something manageable.

## How the foreman's role changes

In field work a rollout often meets resistance from the foreman - and the reason is understandable: the record used to be their authority.

The explanation that works in practice: *nothing is being taken from the foreman; they are being given a document.*

Previously the month-end question "did this person work on the 14th" landed on the foreman's memory, and nothing stood behind the answer. With the record in the system the same question is answered at a glance, and the foreman is protected from the dispute too.

The second change concerns authority: the ability to make a manual correction stays with the foreman, but now it leaves a trace. That does not reduce responsibility - it makes it visible, and in practice most foremen read that as an advantage.

## The next step

In field work the value of the system shows less in the report itself than in the drop in disputes: when where and when a record was made is stored, the month-end discussion gets shorter.

[Calculate the QRGate price](https://qrgate.az/en) for your site structure, or first [look at what it does](https://qrgate.az/en/advantages).

### Related pages

- [GPS attendance system](https://qrgate.az/en/gps-attendance-system)
- [Attendance system for multiple branches](https://qrgate.az/en/multi-branch-attendance-system)
- [Mobile attendance system](https://qrgate.az/en/mobile-attendance-system)
- [Attendance tracking for shift workers](https://qrgate.az/en/attendance-tracking-for-shift-workers)

## FAQ

### Why is attendance harder in field work?

Because there is no fixed entry point. The terminal model is tied to one door, while the site changes - sometimes several times a week. As a result the record is either not kept at all or becomes an end-of-day list built from the foreman's memory. That list is usually the most disputed part of the monthly timesheet.

### When the site changes daily, what does the record attach to?

To the site itself. The recording point is set up as a separate site in the structure and the record is written against it, so "who worked where" is later answered from the report. Location matching then works as an extra layer: the record is checked against the expected point, and a mismatch reaches the responsible person as a notification.

### What should be done at sites with weak coverage?

Run the trial exactly there - a trial in the office makes the result look artificially good. For weak-coverage points a rule should be agreed in advance: who makes a correction, in which cases, and within what time. Written down, the exception becomes manageable; left unwritten, it becomes a monthly argument.

### Can reports be produced per crew?

Yes, if the structure supports branch, department and section levels. The report can then be read by site, by crew and by individual employee. That is the cut most often needed in field work: daily staffing per site and how the load is distributed between crews.

### What is done for a field worker without a phone?

Two routes inside the same system: a record made at an NFC point, or a record entered by the foreman. A manual entry leaves a trace with its author and timestamp, so it can be checked later. What matters is that the exception is held in the main timesheet rather than on a separate paper list - otherwise two sources are being reconciled again at month end.

## Related pages

- GPS employee oversight - [Markdown](https://qrgate.az/en/gps-employee-oversight.md) | [HTML](https://qrgate.az/en/gps-employee-oversight)
- Alternatives to a fingerprint system - [Markdown](https://qrgate.az/en/alternatives-to-fingerprint-attendance.md) | [HTML](https://qrgate.az/en/alternatives-to-fingerprint-attendance)
- Different working hours - [Markdown](https://qrgate.az/en/attendance-for-different-working-hours.md) | [HTML](https://qrgate.az/en/attendance-for-different-working-hours)
- GPS attendance system - [Markdown](https://qrgate.az/en/gps-attendance-system.md) | [HTML](https://qrgate.az/en/gps-attendance-system)
- Who QR attendance suits - [Markdown](https://qrgate.az/en/who-is-qr-attendance-suitable-for.md) | [HTML](https://qrgate.az/en/who-is-qr-attendance-suitable-for)
- Choosing attendance software - [Markdown](https://qrgate.az/en/choosing-employee-attendance-software.md) | [HTML](https://qrgate.az/en/choosing-employee-attendance-software)