AI Construction Site Diary: How It Actually Works

A construction site diary is one of the most valuable records on a project, and one of the easiest to let slide, because filling it out properly competes with everything a supervisor is already managing on site. This guide is for PMs and supervisors who want the diary kept without the daily grind. It comes from my full walkthrough of building a self-maintaining site diary with Claude, Airtable and WhatsApp, in the video below.

Key takeaways

• A site diary works when record-keeping is faster than the memory of the day. AI closes that gap by turning a voice note into a structured entry in a minute or two, instead of the half hour to an hour a form usually takes.
• The database structure matters more than the tool. Cost codes, labour hours, quantities, subcontractors, weather, deliveries and delays are the core fields. Everything else is an optional extension.
• AI structures what a supervisor already knows. It does not decide what happened on site, and it never sets percent complete.
• A project WhatsApp group can feed the diary too, through a scheduled task that reviews the day’s messages and pulls out anything that matters.
• The confirmation step, where AI asks what’s missing and the supervisor approves the entry before it writes, is what makes the record trustworthy enough to use in a claim.

What is an AI construction site diary?

An AI construction site diary is a daily record system where a supervisor gives a plain-language update, by voice note or text, and AI structures it into a database: labour hours against cost codes, quantities completed, deliveries, subcontractors on site, weather, delays and safety notes. It checks for gaps and asks before writing anything, so the record stays complete without anyone filling out a form.

The point of a site diary isn’t the diary itself. It’s what you can do with it later: substantiate a claim, run earned value management, or prove what the weather was doing on the day a delay notice depends on it. None of that works if the diary is inconsistent or half filled, which is normally exactly what happens when the person who knows what happened on site is also the one who has to type it into a spreadsheet at the end of a long day. It’s built to answer, months later, exactly what happened on a given day and why, which is the moment a site diary actually earns its place on a project. This workflow sits alongside the rest of the AI for construction workflows series, drawings, RFIs, contract admin and procurement, all running on the same read, process, write pattern.

How does a voice note become a structured site diary entry?

A supervisor sends a short voice note or text summarising the day, and AI turns it into a structured entry in a minute or two rather than the half hour to an hour a form usually takes, running through four steps: capture, clarify, confirm and write. Here’s how each one plays out:

1. Capture. The supervisor talks or types a plain summary: what got done, who was on site, what came in on delivery, whether there were delays.
2. Clarify. AI checks the update against the diary’s required fields and asks about anything missing, for example who was on site and for how long, or which cost code a subcontractor’s work should sit against.
3. Confirm. AI sends back a summary of what it’s about to log, hours by employee, quantities, deliveries, subs, delays, safety, so the supervisor can check it before anything is written.
4. Write. Once approved, the entry writes to the database. Tim uses Airtable through an MCP connection in the video, though Excel, Notion or SharePoint work the same way.

In Tim’s own worked example, a supervisor described a productive day: one delivery of 100 m³ of concrete, a slab pour on level two, and a steel fixing subcontractor who put in 17 tons of steel with four people on site. AI asked two clarifying questions, who was on site and for how long, and which cost code the steel should be logged against, then wrote the full entry, employee hours, quantities, deliveries, subcontractors and a task to upload the concrete docket, back to the supervisor for approval.

The skills behind that loop, construction-site-diary-setup to build the Airtable base, plus daily-diary-update and the WhatsApp chat-sweep to run it day to day, are all in the ContractorOS community, for anyone who wants to set the same thing up on their own project.

“All we’re really using AI to do is to take unstructured data and move it into structured data,” is how Tim frames the whole architecture, and it’s the reason this particular use case works so cleanly. Nothing about the site changes. Only how fast the record of it gets made.

What should a construction site diary actually record?

A useful site diary records what happened against the same structure your budget and schedule already use: labour hours by cost code, quantities of work completed, and the events around them, weather, deliveries, subcontractors, plant and safety, each tied to the cost codes you set at the start of the project. Cost codes get set up once at the start of the project, from the estimate, and every day’s entry ties back to one of them, which is what lets the same data drive your cost tracking and your program later.

On a site excavation cost code, Tim’s own example budgets 500 cubic metres of quantity against 200 hours of labour, the two running totals every day’s diary entry adds to.

Field	What it captures	Why it matters
Labour hours by cost code	Who worked, how long, against which activity	Feeds cost tracking, though Tim recommends pulling labour from accounting software like QuickBooks rather than tracking it natively
Quantity completed	Metres trenched, cubic metres poured, units installed	Feeds percent complete and earned value management
Weather	Rain, temperature, site conditions	Substantiates inclement weather delay claims
Deliveries	What arrived, quantity, docket reference	Ties to supplier invoices and material claims
Subcontractors on site	Who, how many people, what work	Builds the record for subcontract cost value reconciliation
Delays and disruptions	What happened, who caused it, any client instruction	The raw material for a notice or an EOT claim
Safety	Incidents, observations, toolbox talks	Reused by HSE workflows, not duplicated in a separate register

One point Tim makes explicitly: labour is the messiest field to track natively, because of normal time, overtime and different pay categories. His recommendation is to pull labour hours from accounting software with an MCP connection instead of building payroll logic into the diary itself.

Where does WhatsApp fit into a construction site diary?

A project WhatsApp group already contains a lot of what should be in the diary, instructions, delay chat, subcontractor coordination, so a simple Zapier automation copies every new message into Airtable as it arrives, and a scheduled task reviews the day’s messages and pulls out anything worth keeping. This runs separately from the daily voice-note update. It’s a safety net for the information that gets discussed in a group chat and never makes it into anyone’s end-of-day summary.

The automation itself is close to trivial to set up: a trigger on new message, a Zapier step that writes it to a WhatsApp messages table in the same base as the diary. Tim describes a project chat with ten or fifteen people in it where issues get raised and buried within minutes. Once a day, a scheduled task reads through the day’s messages, and where something is a genuine record item, a notice to chase, an instruction from the client, a subcontractor update, it gets added to the diary or to a task and site chat register, tagged with who it’s allocated to and where it came from.

That register is a different layer from the diary itself. The diary is the raw daily record. Registers, tracked lists of RFIs, obligations, notices and open items built from events across the project, sit on top of it, covered in AI for construction registers. A chat message about chasing an RFI status might show up in both places: once as a line in the diary, and again on the RFI register once someone decides it needs a formal notice.

Where does AI stop in a site diary, and why does it matter for claims?

AI structures what the supervisor already knows. It never decides what percent of an activity is complete, and it never judges whether a delay is worth a formal claim. Those calls stay with someone who has eyes on the actual work and understands the contract. A diary that quietly lets AI infer either one stops being a record anyone can trust.

This is the same trust boundary that runs through the rest of project controls. Structuring raw site data, reading a voice note or a WhatsApp thread and coding it against cost codes, is a genuinely good fit for AI. Recording accurate raw data on site is the hard part, and that stays a human job well before anything reaches a database. The moment the loop moves to measuring true percent complete, the S-curve problem, where 95% of the quantity installed is rarely 95% of the activity complete, that call sits with a person, always. The labour hours and quantities the diary captures each day are exactly what feeds the next step, covered in AI for construction cost control, where AI does the CPI and SPI arithmetic once percent complete has been set.

For claims specifically, the diary’s value is less about any single entry and more about consistency. A claim stands on evidence that the same thing was recorded the same way every day, the weather, the delay, the instruction, the subcontractor on site. A diary that only gets filled out when something goes wrong looks exactly like what it is, evidence assembled after the fact, and that’s a weaker position than a diary that’s been complete since day one.

Common mistakes to watch for

• Skipping the confirmation step to save time. The whole point of AI here is speed without losing accuracy. If entries write straight to the database with no human check, you’ve traded a slow accurate record for a fast unreliable one.
• Tracking overtime and pay categories natively in the diary. Labour gets messy fast. Pull hours from accounting software instead of building payroll logic into a site-diary base.
• Treating the daily update and the WhatsApp chat sweep as the same feed. They serve different purposes. The daily update is the supervisor’s deliberate summary. The chat sweep is a safety net for what got missed in the group conversation.
• Setting the database structure up after the diary is already in use. Cost codes need to exist before day one, since every quantity and labour entry ties back to one. Retrofitting cost codes onto months of loose entries is a much bigger job than setting them up first.
• Letting AI infer percent complete from what’s logged. Quantity and hours logged are inputs to that number, not the number itself.

The full walkthrough, including the live Airtable base and the WhatsApp automation running end to end, is in the video above.