New Zealand AI Implementation Case Study: Site Timesheets and Job Costing for a Construction Company, Run from a Chat Group

How were hours recorded before?

The company builds on the South Island as both head contractor and carpentry subcontractor, with forty-odd workers on site and a dozen or more projects running at once. Management is the owner and a partner; below them a project manager and several foremen (Site Managers). Before we started, internal communication ran in WeChat groups, external in email, and hours in Excel: a foreman recalled after work who had done how many hours, typed it into a sheet, and the accountant totalled it at month end for payroll.

On 9 April the owner stated the need in the group for the first time: ‘I want a system where site workers’ hours and projects are filled in daily and tracked, for site managers who roster workers, for the workers themselves, and for office accounting and admin, so that everyone can quickly see what they need.’ On 28 April came two more items: VO (Variation Order) records and a site diary, ideally voice-entered, and the diary had to take photos.

Taken apart, that is three things: who went to which site for how long each day (hours); what happened on each site each day (diary and VOs); how much labour each project has consumed to date (cost). The first two live with the foremen, the third in the owner’s head, and no table connected them.

Where to cut first: hours, not the whole system

What the client ultimately wanted was a system showing the progress of every project. At the scoping session on 21 April we set phase one as ‘smart site’ hour tracking: the biggest data volume, happening every day, and the easiest to check for right and wrong. Project progress tracking went to phase two.

Two design principles were fixed that day. First, whatever a foreman fills in should come from dropdowns and simple checks: worker names and site names picked from a list, hours over 12 flagged automatically, no free typing on a phone. Second, voice is only used to ‘call up the form’, never to issue commands directly; entry accuracy comes from form structure, not from a model guessing.

On 22 April our business consultant drew phase one as a five-step flow and four roles: the project manager issues tasks in the morning, the foreman confirms or edits, records a VO when needed, reports actual hours before knocking off, and the system consolidates and generates the site diary. Workers need no company account; they receive notices in one external Lark group.

One unglamorous hurdle: an overseas company could not get Feishu enterprise verification at the time, and the owner spent over a week sorting out registration. Meanwhile we ran the two-way project-manager-and-foreman flow in an internal group, with the workers’ group as one-way broadcast, so nothing stalled.

What did we connect?

The principle was still connect, don’t replace: workers still talk in the group, the owner still reads tables; what was added is a layer of agents in between that write tables.

• Lark group as the entry point: One group per site. The foreman posts the day’s completed work, incidents and photos and @-mentions the agent; anyone who does not want to type uses Lark’s built-in speech-to-text and checks the words before sending.
• Runs locally: The agents run on a Mac mini in the client’s office, orchestrated by OpenClaw, with the model billed to the client’s own Codex account; the data stays in the client’s own Lark workspace.
• Split into several agents: One each for hours, site diary and VOs, so they do not interfere. Decided internally on 15 May: split agents feel better to the client and are easier to debug.
• One Base as the foundation: A worker profile table for identity, a pay-rate table versioned by effective date, a daily record table with one row per site per day, a daily hours detail table as the single source of hours and labour cost, a project cost detail table for non-labour cost such as materials, transport, expenses and subcontracts, plus VO table, site diary index and the cost cockpit dashboard. Twelve core tables by the 27 June handover.
• Hours to payroll without an LLM: A Base automation fires when a daily record is added or changed, loops through the linked workers’ pay rates, updates the matching row in the monthly payroll summary or creates one. Anything that can be calculated wrongly is not handed to something that guesses.
• People stay in three places: Foremen confirm actual hours daily; the project manager edits tasks and approves cross-site transfers; the owner and accountant check pay rates and cost. The agent does not change rates, does not compute payslips, does not approve anything.

Month one: the problem was not features, it was stability

On 7 May the first workflow ran end to end and the engineer recorded four demos: tasks pushed by site at 9 a.m., foremen prompted to confirm at 5 p.m., a foreman replying with corrected hours, and a second reminder at 7 p.m. for anything unconfirmed. On 8 May the owner joined the test group.

The same day our business consultant wrote one line in the internal group: ‘Over these days of development and testing, OpenClaw’s stability has been the biggest problem. Until it is solved, this cannot go commercial.’ The instability had four sources: a mismatch between the Lark plugin version and new OpenClaw releases, bot permission settings in Lark, the model account running out of tokens, and gateway disconnects. In the 9 May weekly report, that was the only blocker listed.

The fix was not mysterious: pin a stable version, back up before changing anything, add configuration so reconnects hold. On 9 and 10 June another round of Codex authentication failures and model cooldowns hit; the engineer connected remotely, fixed it, and left the client a written troubleshooting note to follow next time.

On 22 May the owner read the draft VO and site-diary plans and said something that made us sit up: ‘Can you solve voice input or some easier way of entering data? Otherwise this is not much of an improvement on filling in a form by hand. The AI is improving too little.’ She was right. The person filling in the form is a foreman standing on site with dust on his hands. The answer was not in the tables but in the keyboard: install a speech-to-text keyboard on the phone, see the words, then send, rather than throwing audio at a model to guess. We wrote no code for this.

The on-site meeting on 27 May: defining the site diary

On 27 May we went to the client’s office and the project manager attended for the first time. The meeting listed what the site diary must record: weather and its impact, hours, communication with the principal’s site manager, inspections and QA, progress against the construction programme, drawing updates, and VO information. Mostly text, photos allowed, handled by a separate agent that generates one Daily Site Log at a fixed time each day.

Two business details only surfaced in that room. First, diaries differ between lump-sum and non-lump-sum projects, so an attribute field went onto the project table, set when a site is created. Second, VOs are submitted by foremen in plain language and extracted by the agent into the VO table, but principals have two signing habits (one sheet per day, or one sheet for several days), so two Excel formats had to be exportable.

The meeting also narrowed phase one to a single goal: cost visibility. Comparing progress against the principal’s programme was deferred to phase two. The engineer left with a list: bind daily records to sites, build the hours and cost tables, generate and consolidate VOs, add reminders to the site-diary agent.

June: go-live, upgrade, rule changes

From 1 to 3 June, all phase-one functions were deployed to the Mac mini in the owner’s office and the test group moved into the production work group. The cost cockpit screenshot of 6 June: 15 projects, 6,013 hours logged, 210 daily records. On 15 June the owner wrote in the group, ‘we are officially open for business today’, and the whole company was on the system.

Four things changed in the first two weeks. On 12 June, the Base had used 41% of the basic plan’s 2,000 rows per table since 5 May and would certainly exceed it within a quarter, so it was upgraded to the professional plan (20,000 rows per table), starting with the daily hours detail table that gets one row per worker per day. On 16 June, date misalignments were traced to the Base time zone having been set to Beijing time; it was changed to New Zealand time. The same day the owner pointed out that everyone in the hours group could see the payroll table; it was hidden from group members that day, and a separate technical group was created so foremen did not have to watch engineers fixing things. On 18 June, VO hours stopped going into a separate table and instead carry a ‘VO’ tag on the daily hours detail, defaulting to ‘regular’, so the two can be split when querying.

A manual audit on 17 June is worth writing down. The engineer went through the tables line by line and listed four kinds of error: two blank daily records on the same day, with no project, no worker, zero hours and zero cost, probably created by mistake; a worker appearing in a project’s worker list with no hours description; the same project on the same day split into two records, needing a human to confirm whether it was a duplicate; and a morning scheduled job that had announced ‘no site tasks today’ while actual hours appeared in the group later that day. The system caught none of these. People found them by comparing.

A rule changed the same day, in plain language. The owner’s instruction: ‘If a message is not about hours, record it in the site diary or the event description.’ The agent confirmed: from now on, anything @-mentioned to it without explicit hours goes first to the daily record’s event description or the site diary instead of stalling for lack of hours; only messages clearly about billable hours are written to the daily hours detail. After the change, the two stalled records were completed on the spot and no existing hours were touched.

The first-quarter handover on 27 June: numbers and dashboards

At the handover meeting on 27 June our business consultant gave these figures: the project management system about 85% complete, roughly one month of formal trial, 12 core tables, 20 projects onboarded, 334 daily records accumulated, more than 10,000 hours of work logged. The dashboard that day showed 12,149 hours. The core entry point is the project overview with four modules, site records, task reporting, cost accounting and VO management; management sees the state of the business on one screen, cumulative project cost, labour and procurement cost, project cost ranking and daily labour cost trend, and every table can be opened and questioned in plain language.

Two things the owner decided in the room

We record the owner’s assessment as given: very satisfied with the team, the system delivers the core functions. More important than the assessment were two arrangements she announced on the spot: assign one person to watch system usage every day; move staff from recording hours in Excel to the Lark system, with a grace period, then make it mandatory step by step.

One more thing was said plainly: approvals are not in the system, and cost approval still happens offline by people. From the second quarter the mode of engagement changed: the client’s team operates, we coach, answering questions without jumping in lightly.

After handover: leaving the groups, a displaced binding, hours in one sentence

On 29 June we set the exit condition internally: observe until 7 July, and if it runs normally, withdraw entirely from the client’s hours group and hand it back, which also protects the client’s privacy. On 9 July our people left two groups: the hours group (which records how many hours each worker did on which project) and the site management group (which generates each site’s daily diary and photos).

On 24 July something happened. The client created a new agent themselves, and it displaced the original hours agent’s binding in Lark; from that day until it was noticed, hours were being recorded outside the original validation rules. The engineer fixed it remotely the same day, then wrote a dedicated guide, ‘how to create additional agents without breaking the existing binding’. That was not the client’s fault. When we handed over, we had not written down how not to break it.

A group exchange on 29 July shows what the system looks like day to day. A worker @-mentions the agent: ‘Work out my total hours and work locations for the whole week of 13 to 19 July.’ The agent replies: 49.5 hours for the week, work location a certain project, breakdown 6.5 hours on 13 July, 5 on 14 July, 9.5 a day from 15 to 18 July, no record on 19 July. The project manager then asks for another worker’s hours from 1 to 21 June, and it starts querying day by day. Nobody opened Excel.

On 1 September our project supervisor confirmed to the owner: ‘After these months of real operation, the agents are running stably overall, no significant problems have appeared, and this workflow has entered routine use.’ Group ownership was transferred to the client.

Four lessons from three months

Looking back, the expensive part was not development. It was these four judgements.

• Stability is the first feature: The line of 8 May, ‘until it is solved, this cannot go commercial’, was right. Pin versions, back up first, write a troubleshooting note the client can follow. These engineering habits come before any model capability.
• The entry point decides adoption: When the client said the AI improved too little, the problem was not the AI but how a foreman standing on site enters data. Dropdowns, speech-to-text, no accounts for workers: not one of those three was done by a model.
• Go-live is not the finish line; someone has to watch the data daily: None of the four error types on 17 June was caught by the system. The owner assigning one person to check every day is the real reason the system reached routine use.
• Before handing over, write down how not to break it: The displaced binding of 24 July exposed a gap in the handover documents. Role permissions, the steps for creating a new agent, where to look first when something goes wrong: these ship with the system.

Where is it now?

The system is run by the client, and our people are no longer in the hours group. In the second quarter the client’s team started a second project on the same Lark plus OpenClaw foundation by themselves: automating H1 insulation compliance calculations for their associated design practice, with us coaching.

The best acceptance test is still not a number. The next step the owner set for her own team on 27 June was to move the foremen from Excel to Lark, with a grace period. Whether a system stays depends on whether the person least willing to change is willing to use it.

Evidence boundary: every number in this article comes from the project group chat records, the notes of the first-quarter handover on 27 June and that day’s dashboard screenshots, each dated in the text. ‘12 core tables, 20 projects, 334 records, 10,000+ hours’ is a snapshot as of 27 June; the client has run the system since, and we no longer hold current figures. The client is a construction company on New Zealand’s South Island and is anonymised; company and personal names in screenshots have been cropped or masked, areas containing amounts and project names are pixelated, and payroll figures were not used.