Getting Started With AI on a Real Jobsite

TL;DR: Contractors told AGC and Sage their biggest technology problem is not cost and not resistance. It is finding the time to implement and train, cited by 43%. The academic literature agrees that this category of constraint predicts whether workers adopt a tool at all. So the only sensible plan is one that costs almost no time and proves itself in a fortnight.

Most AI implementation advice assumes you have a spare month and someone whose job this is.

You have neither, and the research says that matters more than enthusiasm does.

In the 2024 AGC and Sage Construction Hiring and Business Outlook, drawn from nearly 1,300 contractors and published 15 January 2024, the top three IT challenges were difficulty finding time to implement and train on new technology at 43%, keeping company data secure at 42%, and employee resistance to technology at 41%.

Time beat resistance. That ordering is the whole basis of what follows.

What actually predicts whether a crew adopts a tool?

Six things, and they have been measured rather than guessed.

A systematic review by Nnaji, Okpala, Awolusi and Gambatese, published in the Journal of Information Technology in Construction in February 2023, analysed 35 studies of technology acceptance in construction. It identified perceived ease of use, perceived usefulness, social norm, attitude, perceived behavioural control and facilitating conditions as the key constructs affecting a worker's intention to accept a construction technology. Of the models tested, UTAUT showed relatively higher predictive power.

Two of those deserve translation.

Facilitating conditions means whether the worker perceives that the resources needed to use the thing actually exist. That is the academic name for the 43% problem. If there is no time, no training and no support, adoption fails regardless of how good the tool is.

Social norm means whether people around them use it. This is why single-user trials work and all-hands rollouts frequently do not. One respected person using something visibly is a stronger adoption mechanism than a mandate.

The plan below is built around those two findings.

Before you start: two prerequisites

One named person who owns the outcome. Not a committee. Where AI projects fail, the causes reported are integration with existing operations, workflows never redesigned around the output, and nobody accountable once the tool is live. If you cannot name the person, you are not ready.

One workflow you can already measure. You need a task where you can state today's cost in hours per week. If you cannot measure it now, you will not be able to tell whether it helped, and you will renew out of politeness.

Note what is absent: "get your data in order first." That is a project of its own and it is not a prerequisite for step one.

Step 1: Pick the task by paperwork, not ambition

Choose the most repetitive document task in your office.

Good candidates: retyping numbers off supplier bills, assembling the same weekly report, hunting for a photo from four months ago, turning field notes into something a client can read.

Bad candidates: anything replacing a judgment your best estimator makes on instinct, anything requiring the crew to change how they work before value appears, anything predicting an outcome from data you have never recorded.

Document work first because the output is immediately checkable, which is the practical form of perceived usefulness. The user can see whether it read the invoice correctly. A tool predicting cost overruns cannot be evaluated for six months.

Failure mode: everyone wants to fix a different task. Escalation: pick the one where the person who currently does it is in the room and wants it gone. That is social norm working in your favour. If nobody present does the task, you are choosing from the wrong list.

Step 2: Write down the number before anything is installed

One number, measured this week, on paper, dated.

Hours per week on the task. Documents processed per day. Days between job completion and invoice going out.

Twenty minutes of work, most often skipped, which is why tools get renewed without anyone knowing whether they worked.

Failure mode: the number is hard to measure or nobody agrees on it. Escalation: treat that as a finding rather than a blocker. If you cannot measure the current cost, the task is not the bottleneck you assumed. Move to the next candidate instead of building a measurement system first.

Step 3: Gather a genuinely awkward document sample

Ten to twenty real documents, deliberately including your worst.

This separates a trial from a demo. Vendors test on clean inputs. Your operation runs on the invoice with handwriting in the margin, the submittal in a format nobody else uses, the crooked scan.

Do not tidy them. The awkward ones are the test.

We learned the general version of this on the data side of our own platform. Across client onboardings, the most common failure when moving data between systems is field mapping: source fields rarely align cleanly with destination fields, so names arrive in company fields, phone numbers land in email columns, and custom data disappears with no error at all. You discover it weeks later when a report looks wrong.

AI document handling fails the same quiet way. It returns a confident, well-formatted, wrong answer, and only your awkward samples reveal it.

Failure mode: it handles the clean documents and fails the messy ones. Escalation: the most likely outcome, and not disqualifying. Establish what proportion it fails on, then decide whether a human reviewing every output still beats doing the work manually. Often it does. What is disqualifying is a vendor who blames your documents instead of quoting a realistic rate on them.

Step 4: One person, two weeks, fallback available

Not a pilot committee. The person who does the task, doing the real work, with the old method still available.

Two weeks is long enough to hit awkward cases and short enough that stopping costs nothing. Keeping the fallback is deliberate rather than weak: under deadline pressure people revert to what they trust, and a tool that forbids reverting gets worked around rather than used.

Failure mode: they quietly stop after four days. Escalation: ask why once, without pressure, and take the answer literally. Usually the tool takes more steps than the habit it replaced, which is a perceived-ease-of-use verdict and not a training problem. No amount of training reverses it. Cancel and try the next candidate.

Step 5: Check the number, then decide

Three outcomes. It moved materially, so expand to a second user. It moved slightly, so you have a preference rather than a business case and should probably stop. It did not move, so cancel now while cancelling is easy.

Failure mode: ambiguous result and the team likes the tool. Escalation: extend two weeks with stricter measurement, once. Still ambiguous at four weeks is a no. Ambiguity at small scale becomes expensive at large scale.

The sequence

Three weeks to a defensible decision, at roughly a day of total effort. That is what a 43% time constraint permits.

What is the real learning curve?

The tool is the easy part. Everything around it is not.

Agreeing what counts as a correct output, deciding who checks it, and working out what happens when it is wrong takes longer than learning any interface. That is the facilitating-conditions problem again, and it is why buying a tool with no owner produces nothing.

Worth knowing that the skills constraint is broad rather than particular to you. Autodesk's 2025 State of Design & Make report, published 16 April 2025 from 5,594 industry leaders across architecture, engineering, construction and operations plus manufacturing and media, found 61% saying new employees with the right technical skills are difficult to find, up 16 points from 2024, and 46% saying AI skills will be a top hiring priority over the next three years.

You are not going to hire your way out of this quickly. Which is another argument for tools that work without integration.

Where this approach fails

Three cases, plainly.

Genuinely cross-departmental tasks. A two-week single-user trial will not surface coordination problems and will give you a false positive. Those need a slower method.

Documents that exist only on paper or in people's heads. Nothing to read, and no trial changes that. Digitising is a separate project with its own justification.

A decision already made. If leadership has chosen the vendor, this is theatre. A trial whose outcome cannot be "no" is not a trial, and running one costs you credibility for the next decision.

Frequently Asked Questions

Why start so small when the industry productivity problem is so large?

Because the problem's size is not an argument for a large first step. The review cited above notes construction gained roughly 1% in productivity over three decades, around three times lower than all industries combined. That gap accumulated through many small failures to adopt, and it closes the same way. A three-week trial that produces a real answer beats a twelve-month programme that produces a report.

Should I announce it to the whole company?

No. Tell the person using it. Social norm is a genuine adoption factor, which means visible successful use spreads better than an announcement, and a public rollout you later reverse makes the next one harder.

What if my documents contain subcontractor pricing?

Settle the data questions before the trial, not after. Ask whether your documents train the vendor's models, what happens to copies in their test environments, and who can read them. Get it in writing. A trial is still a real disclosure.

Does any of this apply to field tools rather than office tools?

The method does; the risk profile does not. Anything a crew uses on site carries a safety dimension that office document work does not. Construction employs roughly 6% of the US workforce while accounting for over 20% of work-related fatalities, so a field tool that distracts or misinforms has consequences a report generator does not. Trial field tools with more caution and a competent person involved.

How do I know if the vendor's accuracy claim is realistic?

You do not, which is why step 3 exists. Published accuracy figures are measured on curated datasets. The only number that matters is performance on your documents, and any vendor confident in their product will accept that test.

If you can name the one task and the one person, you can start this week and have an answer by month end.

See ClickWerxs AI services or get in touch. Before choosing a vendor, the questions worth asking first and what AI actually does for a construction business.

Sources

1. AGC and Sage, 2024 Construction Hiring and Business Outlook, technology findings published 15 January 2024 — nearly 1,300 contractors; top three IT challenges reported as difficulty finding time to implement and train on new technology (43%), keeping company data secure from hackers (42%), and employee resistance to technology (41%); 47% use cloud-hosted technology for field operations. sage.com
2. Nnaji, C., Okpala, I., Awolusi, I. and Gambatese, J. (2023), "A systematic review of technology acceptance models and theories in construction research," Journal of Information Technology in Construction (ITcon), Vol. 28, pp. 39–69, published February 2023 — three-phase systematic review of 35 articles; identifies perceived ease of use, perceived usefulness, social norm, attitude, perceived behavioural control and facilitating conditions as key constructs affecting workers' intention to accept a construction technology; UTAUT showed relatively higher predictive power. The paper also reports, citing Barbosa et al. (2017), that construction gained approximately 1% in productivity over three decades, around three times lower than all industries combined, and cites BLS data indicating construction employs about 6% of the US workforce while accounting for over 20% of work-related fatalities. Open access under CC BY 4.0. itcon.org
3. Autodesk, 2025 State of Design & Make report, published 16 April 2025 — 5,594 industry leaders across AECO, design and manufacturing, and media and entertainment across APAC, EMEA and the Americas; 61% say new employees with the right technical skills are difficult to find, up 16 points from 2024; 46% say AI skills will be a top hiring priority over the next three years. adsknews.autodesk.com
4. MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025," July 2025 — enterprise AI failure attributed substantially to integration with existing operations, workflows not redesigned around model output, and absence of ownership once live. Methodology comprised review of 300+ publicly disclosed initiatives, 52 organisational interviews and 153 survey responses, and has been publicly criticised. aigl.blog
5. ClickWerxs client onboarding pattern — field mapping is the most common data migration failure; source fields rarely align cleanly to destination schema, producing names in company fields, phone numbers in email columns, and silently dropped custom data. First-party operator data.
6. ClickWerxs field operations platform — 421 commits and 85 written threat models as of 22 June 2026. First-party operator data.

Third-party survey figures are attributed with sample sizes and publication dates; one source is noted as methodologically contested, and figures reported at second hand within the peer-reviewed review are attributed to their original authors. This post describes an evaluation method and does not guarantee any result. Nothing here is safety advice; field technology carries risks that office software does not. ClickWerxs sells AI implementation services and earns revenue from those engagements, including work a reader might scope using the steps above. This is operator opinion and not legal, financial, or professional advice.

Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut