The site diary and timesheet system your sites fill in each day

A phone on every site, a spreadsheet in the labour office, and a pay run on Thursday that depends on both.

A typical business running one of these has 40 to 150 people on the books, labour-only subcontractors included, somewhere between eight and twenty live sites, a labour manager, a payroll clerk and contracts managers who each look after a handful of sites. The diary lines run to a few hundred a day, and most days a handful of gangs still send a photographed paper sheet. Whether it is an Access file with an app bolted on or a browser system with an app of its own, the week it runs is the same.

In the labour manager's words, it allocates gangs to sites for the week, takes each site's daily diary from the app, weather, visitors, deliveries, delays, plant on site, who was there and for how long, turns the hours into timesheet lines for the contracts manager to approve, sends the approved PAYE hours to the payroll package, and pays the labour-only subcontractors weekly less CIS. Every hour is costed to a site, and the diary feeds the weekly report the client's project manager expects on a Friday.

The rules it applies are the ones a new payroll clerk takes a year to learn:

• Overtime starts after 39 hours in the week, except for the gangs on price, who get none.
• Travel is paid from the yard for sites beyond a set distance, and lodge beyond a further one, both measured from the yard rather than the operative's home.
• A day is locked once the contracts manager approves it; anything after that goes through a correction line the following week.
• A diary with no entry on a day the site was open is chased on the Monday, and that day's hours are held until it is in.
• Gangs on price are paid on measure, so their hours are recorded for costing but never paid.

Most of that is in the code and the payroll clerk's head, and the week's allocation is usually still a spreadsheet on the labour manager's second screen.

It started as an Excel timesheet in the late 1990s and moved into Microsoft Access around 2008, built by someone in the office who knew Access and was given the job. Between 2014 and 2016 a local agency added a PhoneGap app so the site managers could fill in the diary and the gang's hours on a phone, posting to a small web service on the office server that writes into the Access database. The office side is still a set of Access forms, a desktop program that wants to be a web one, with the file on the shared drive. The labour board stayed in Excel.

The agency moved on and the tooling the app was built with has gone, so the app can only be kept on the phones that already have it. The web service in the middle has no documentation and no owner. Every new user in the Access file brings the Thursday lock closer.

Some contractors replaced the lot between 2019 and 2022. A small agency or a freelancer rebuilt the office side as a web system in React, Angular or Node, with a site app in Ionic or React Native, or the office put its own together in Power Apps because everyone already had a login for it. From the labour office it looks settled: timesheets approved in a browser, photos on the diary, no Access file to lock on a Thursday.

The site app is what stopped it. Last built in 2022, it cannot be updated under the 2026 store rules without a rebuild nobody has quoted for, so a site manager with a new phone is back to photographing paper. When the travel distances changed, the app and the office screens measured them differently and paid a gang lodge they had not claimed, and the rule has been left alone since. The agency closed, and the hosting renews each year without anyone logging in. The labour board, promised for a second phase, never came, and since 2023 a few labour managers have tried to build it themselves in an AI app builder; those efforts usually stop where the board has to write into payroll. Over a decade younger than the Access file, it found its own way to be stuck.

A pay run that goes out on Thursday with every hour costed to a site, and a diary that stands up a year later.

Without the system, the hours would arrive as photographs of paper and someone would type them for two days. With it, the site manager's phone is the timesheet, the contracts manager's approval locks the day, and the payroll clerk exports rather than types. Every hour lands on a site, so the surveyors' cost to date includes labour, which is the biggest number on most jobs.

When the client's project manager disputes a delay from last March, the answer is the diary line for that day: the weather, the delivery that never arrived, the plant that stood idle. The labour board answers the other daily question, who is where tomorrow, before the phones start at six. And because the subcontractor payments come from approved hours, the CIS statements match the money that went out.

Some of it has broken. The rest has frayed.

The app cannot be rebuilt. Adobe shut PhoneGap down in 2020. Since 28 April 2026 App Store uploads have had to be built with Xcode 26, and from 31 August 2026 Google Play updates must target Android 16. A site manager with a new phone cannot install the app, so that site is back to a paper sheet photographed and sent on WhatsApp for the office to type in.

The Access file goes read-only on a Thursday. With several site managers, the contracts managers and payroll all in one file on the shared drive, it locks or corrupts, and somebody runs compact and repair while everyone waits.

The labour board never made it in. Neither the Access version nor the later rebuild took it on. Allocation is still done in the labour manager's spreadsheet and re-keyed into the system on a Monday. The sites find out who they are getting by phone, and the spreadsheet and the system disagree by Wednesday.

The diary has words but no pictures. The app took photos, but the Access file could not hold them and the upload was the first thing to break. So the delay claim has a diary line and a folder of photos on a phone that has since been replaced.

The same diary and the same rules, on a phone that installs, feeding a database that does not lock.

Each of these is something the system already tries to do.

A site app that installs on any phone. One the sites can install this year and next, writing into the same database, working in a hole in the ground with no signal and syncing when it finds one. The site manager fills in the same diary.

Photos in the diary. The day's photos attached to the day's entry, stored with the record rather than on the phone. The delay claim stands on the diary again.

The labour board inside the system. Gangs dragged onto sites for the week on one screen, with tomorrow's allocation on the site manager's phone by the evening before. The spreadsheet and the system stop disagreeing because there is only one of them.

Approvals from wherever the contracts manager is. Hours approved on the phone from the site, the day locked at that moment, the correction line still there for the week after.

Payroll and subcontractor statements straight out of approved hours. The export in the payroll package's own format, the weekly subcontractor statement with CIS deducted, both produced rather than assembled.

Off the Access file. The data on a supported database, the office screens in a browser, the Thursday lock gone and compact and repair a memory.

The Access forms and the old app are not switched off for any of this. The new pieces go in beside them, and the sites move one at a time.

Read what the sites send in, whatever shape it arrives in, and turn weeks and months of diary lines into something a person can check.

A diary system collects more words than anyone in the office has time to read, and that is where AI earns its place.

Paper timesheets read into timesheet lines. Some gangs will always send a photographed sheet, app or no app. AI reads the photo, matches the names to the operatives on that site and drafts the lines, marking anything it could not read, so the payroll clerk checks instead of typing names, days and hours. At a handful of sheets a day, each a few minutes of typing, that is typically half an hour to an hour back each day in the run-up to Thursday.

The client's weekly report drafted from the diary. Every Friday each site manager turns five days of entries into the progress report the client's project manager expects. AI drafts it from the entries and the photos, and the site manager corrects and sends it. Across 8 to 20 sites, that is as many Friday afternoons cut to the half hour it takes to read a draft.

A delay chronology pulled together when the claim comes. When an extension of time is argued, somebody reads months of diary lines to rebuild the story of the weather and the late deliveries. At a few hundred lines a day, six months of one site's diary runs to thousands of entries. AI drafts the chronology with each line and photo cited against its date, and the surveyor checks it: a week of reading typically becomes a day or two of checking.

Not worth doing: AI predicting labour demand per site. The labour manager's knowledge of the programme and the gangs beats any model at this size.

Thursday's pay run reads the same data, so none of this is switched on until changes can be tried on a copy first. The assessment finds where on this diary system AI would pay back soonest.

Data first, then the app, then the office, with the old forms as the fallback until the end.

1. Stabilise. The data off the Access file and onto a supported database, with the office forms left pointing at it, the app's source and the web service it talks to found and written down, a backup restored, and a test copy. This goes first because an app cannot be rebuilt against a file that locks, and because the Thursday pay run depends on the data underneath.
2. The site app. A new one on the same database, with photos and offline working, run beside the old app on the phones that still have it.
3. The labour board and approvals in a browser. Allocation and approval on one screen, with tomorrow's allocation on the phone.
4. Payroll export, subcontractor statements, the weekly diary report. Each a stage, each priced on its own, each live in weeks.
5. Retire the Access forms and the labour spreadsheet when nothing still depends on them. The last thing to go is usually the payroll clerk's export, once it has matched the old one for a few weeks.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a site diary and timesheet system that means a few days with the labour manager, the payroll clerk, a site manager or two and the code, finding the pay rules, the web service and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: Excel to a system, Microsoft Access, PhoneGap and Cordova and desktop to web, and for the newer generation React, Angular and Node, Ionic and React Native. If the agency's silence is the first problem, legacy software support covers that.