UK vs US construction automation: same problem, different paperwork
The admin burden is identical; the artefacts are not. A site manager in Leeds and a superintendent in Ohio lose their evenings to the same four jobs: recording what happened, chasing information, filing documents and proving compliance. What differs is the paperwork each system expects: RFIs versus TQs, submittals versus technical approvals, AIA payment forms versus JCT and NEC mechanisms, OSHA versus CDM 2015.
That difference sounds cosmetic. It is actually the single most useful thing a UK buyer can understand about construction software, because most of the big platforms were built in the US, around US artefacts, and that is precisely why so many UK firms buy them, bounce off them, and conclude that "construction tech doesn't work for us". The tech works fine. It was just shaped around someone else's paperwork.
Is the admin problem really the same on both sides?
Yes, almost embarrassingly so. Strip the vocabulary away and both industries run on the same underlying loop: something happens on site, someone needs to know, a record must exist, and money moves against evidence. Both suffer the same failure at the same point: the loop runs through busy people typing things into forms after the fact, so the record is late, thin or missing. Automation, on either side of the Atlantic, is valuable exactly where it removes the typing-after-the-fact step. The problem travels perfectly. The forms do not.
What are the actual artefact differences?
| Job to be done | US artefact | UK equivalent |
|---|---|---|
| Ask the designer a question | RFI (Request for Information) | TQ (Technical Query), or an RFI under some forms |
| Get materials and methods approved | Submittal packages | Technical submittals and approvals against the spec |
| Apply for payment | AIA G702/G703 style applications | Applications and notices under the Construction Act regime, administered through JCT or NEC machinery |
| Change the work | Change orders | Variations (JCT) or compensation events (NEC) |
| Run site safety | OSHA compliance programme | CDM 2015 duty holders, construction phase plan, principal contractor duties |
| Prove building safety | Jurisdiction-specific codes | Building Safety Act golden thread for higher-risk buildings |
Each row is the same job wearing different clothes. But software does not model jobs; it models clothes. A US platform's payment module generates a G702-shaped application because that is what a US general contractor's client expects to receive. It has no native concept of a due date, a payment notice deadline or a pay less notice window under the Construction Act payment regime, because no US customer ever asked for one.
Safety is the sharpest example. OSHA compliance is largely inspection-and-training shaped. CDM 2015 is duty-holder shaped: it cares who the principal designer and principal contractor are, what the construction phase plan says, and whether the file exists. A "safety module" built for OSHA toolbox talks does not know those objects exist.
Why do UK firms bounce off US-built software?
Because form-first software makes its assumptions load-bearing.
A form-first system works like this: here is our RFI form, our submittal workflow, our change order screen; put your project inside them. If your project speaks TQ, technical approval and compensation event, you have two options: rename everything and live with fields that do not quite fit, or configure heavily, which usually means a consultant, a long implementation and a system your subcontractors never adopt. Either way the site team is now translating between the words on their contract and the words on their screen, and site teams do not translate. They go back to WhatsApp.
This is not a criticism of the US platforms, which serve their home market well. It is a buying lesson: when you evaluate software, ask what artefacts it assumes, not what features it lists. If the demo shows you a change order screen and your world is NEC compensation events with their notice clocks, the gap you are looking at is not cosmetic.
What kind of system travels better?
Capture-first systems, because reality is the same in both countries even though the forms are not.
A capture-first system starts from the traffic that already exists: the photos, messages and voice notes a site generates every day, the WhatsApp group that is already the de facto project record. It structures that raw material into a record first, then produces whatever artefact the contract requires: a TQ here, an RFI there, a diary entry, an application. The artefact becomes an output format rather than the skeleton of the system, so swapping JCT vocabulary for AIA vocabulary changes a template, not the architecture.
That ordering also matches how automation actually succeeds in small firms. The hard part was never the form; it was getting the information off the site without adding a data entry job. Which is why the useful question is automation, not software: a workflow built around your own artefacts beats a platform built around someone else's. The same logic applies a layer down, too. The large language models underneath these tools are country-agnostic; choosing a model for a construction team matters far less than choosing what the system captures and what paperwork it emits.
What should a UK buyer take from all this?
One test question: "show me where your system knows what a pay less notice is."
If the answer is a blank look or a custom field, you are looking at software that will make your team speak American on a JCT job, and adoption will die quietly within a quarter. If the answer is that the system captures what happened and can produce whatever your contract calls it, the geography of the vendor stops mattering. The admin problem crossed the Atlantic centuries ago. Buy the system that automates the problem, not one that ships someone else's paperwork.