Splitting a worker's hours between several job sites

A tradesman spends his morning on one site and his afternoon on another, twenty minutes away. By the end of the week, his eight hours for the day are logged against only one of the two. The short answer: log the change the moment it happens, do not reconstruct it from memory on Friday. The rest explains why this small detail matters more than it looks, and how to fix it.

Why a worker changes job site within the same day#

A company running several projects at once regularly moves its crews: a tradesman finishes a task on one site in the morning, then joins a crew running late on another in the afternoon. A site manager visits two or three sites in a single day to supervise. This is not an exception, it is the normal way a company running several sites works.

The problem is not the change itself. It is that nobody logs the exact time it happened.

What gets distorted when hours are not split properly#

When eight hours split across two sites in one day get logged against only one, two things go wrong at the same time.

• Each site's margin. The site that received no logged hours looks more profitable than it really is, and the other absorbs a labour cost that does not fully belong to it.
• Some site-linked pay items. A travel allowance, a meal allowance, or a premium specific to certain sites gets calculated wrong if the system does not know the day was split between two locations.

Take a company with fifteen tradesmen, where on average one day a week involves a mid-day change of site. Suppose two hours out of eight get misallocated each time, at a loaded cost of €32 an hour: that is €64 of cost wrongly attributed per incident. Over forty weeks, that is more than €2,500 a year, spread across the wrong sites rather than truly lost, which is almost worse: the displayed profitability of each job becomes wrong without anyone noticing.

The method: log the change, do not reconstruct it#

Reconstructing the split on Friday, from memory, does not work: after four days, nobody remembers the exact time of the change, or sometimes even the morning's site.

The rule that changes everything is simple: a site change is logged like a clock-in, the moment it happens. The rest, the addition and the split, happens on its own.

What changes with an application built for the company#

An application built around the way the company actually works removes the reconstruction from memory, not just the re-keying.

• Changing site happens with one tap, from the phone, with the time logged automatically.
• Each site gets exactly the hours it is owed, with no rough split at the end of the week.
• Site-linked pay items are calculated with the correct split, with no line forgotten.
• The site manager sees, site by site, who worked how long, the same day.

This accurate split of hours is what later makes it possible to track a site's margin without waiting for the final invoice: a margin calculated on misallocated hours stays wrong, even if the rest of the method is correct. It relies on the same action as logging hours from the field without a spreadsheet, simply repeated at every change of location during the day.

What not to do#

Do not ask the worker to calculate the split themselves as a percentage of their day: that is an estimate, presented as an exact figure. Do not ignore changes of under an hour either: added up over a year, those are often the ones that weigh most on a small site's profitability.

Splitting hours between job sites: the key takeaways#

A worker changing job site during the day is not a rare case, it is the normal way a company running several projects works. What costs money is reconstructing the split from memory at the end of the week instead of logging the change the moment it happens.

The rule is simple: a site change is logged like a clock-in, with its time. That is what makes both the pay and each site's margin accurate, without asking the worker for more than a tap on their phone.