The Greater Vancouver Board of Trade's 2025 AI report is the most comprehensive look at B.C. business adoption we've got. The headline numbers are everywhere: 68% of B.C. businesses haven't considered AI, and 69% of the holdouts can't identify a clear use case.
For trades and construction businesses, both numbers are misleading.
The GVBOT report treats every sector the same
When a marketing agency says it can't find an AI use case, it usually means the team hasn't sat down to think about it. The use cases are obvious once someone looks: drafting client emails, summarizing meeting notes, producing a first pass at ad copy. That gap tends to close within a quarter, usually because someone on staff gets curious on a slow Friday and starts poking around.
When a trades business says the same thing, it means something different. The owner isn't being lazy about it. The owner is thinking about the field, where the value sits in physical execution, and the software can't pour concrete or run conduit or read a rough-in the way a twenty-year superintendent can. That part is correct. Nobody's disputing it.
The mistake is treating both answers as the same data point. A marketing agency saying "no use case" is describing a knowledge gap. A construction company saying the same thing is describing an accurate read of AI's limits, applied to the wrong part of the business. The survey question can't tell those two answers apart, so it counts them the same way, and the resulting percentage gets reported as if it means one thing.
Where AI actually fits in a trades or construction business
The use cases in a trades business don't live in the field. They live in the friction around the field.
The proposal that takes three days because the estimator has to chase pricing from four suppliers before anything gets typed up. The one senior person who's the only one who knows how to price a particular type of job, which means every quote with any complexity waits on their calendar. The closeout package cobbled together at midnight before the invoice goes out, because nobody wrote down what happened on site until the deadline forced it. The RFI sitting in someone's inbox for a week because answering it means stopping to dig through drawings. The change order that never got formalized, so six months later nobody can prove what was agreed to.
That's where time and money leak out of a construction business. Say a residential framing contractor runs four crews and closes thirty jobs a year. None of those thirty jobs need AI anywhere near the site. But all thirty generate a proposal, a schedule, a stream of change orders, and a closeout package, and right now every one of those documents gets built from scratch or copied out of whatever similar job someone can dig up in an old folder. It's an office problem that happens to wear a hard hat.
Subcontractor coordination is its own version of the same drag. A general contractor juggling framers, electricians, plumbers, and finishers is really juggling a dozen separate email threads, each one a slightly different version of "when are you on site" and "did you get the updated drawings." None of that requires judgment. It requires someone to track it, chase it, and keep it consistent, which is exactly the kind of work that eats a project manager's week without ever showing up as a line item anyone bills for.
Walk one mid-sized job through its own paperwork and the pattern is obvious:
- A proposal built partly from memory and partly from a spreadsheet nobody's updated since spring
- A schedule that exists in someone's head until a sub asks for it in writing
- Three change orders discussed verbally on site and never formalized until the client disputes an invoice
- A closeout package assembled the night before it's due, from photos scattered across two phones
None of that is unique to one company. It's close to the default state of the industry, and it's exactly the kind of repetitive, document-heavy work that AI is good at once someone sets it up properly.
The GVBOT report doesn't capture any of this, because it's a survey of self-reported barriers, not an operational audit. It asked business owners whether they'd identified a use case, and construction owners answered honestly based on what they know AI to be good at: chatbots, image generators, customer service bots. None of that maps onto their business, so they said no. When a B.C. contractor reads the report and sees the 69% figure, what they hear is confirmation that there might not be a use case for them.
There is one. It's just not where they're looking.
Why self-reported surveys miss this every time
This isn't a flaw specific to the GVBOT survey. Ask any business owner whether they've found a use case for a technology they haven't explored, and you'll get a version of the same answer, because you can't picture a use case for a tool you don't understand well enough to imagine inside your own operation. The question assumes the respondent already knows what the technology can do. Most don't, and there's no reason they should. Nobody in the trades signed up to become an AI evaluator on top of running a business.
That's a fair place to be. It's also exactly the gap an outside assessment is built to close, because the person running it has seen enough operations to know where the friction usually hides, even when the business owner can't name it yet.
I spent eighteen years on the trades side before I started doing this work, and the honest version of that history is that I would have answered the GVBOT survey the same way most of these owners did. AI wasn't on my radar because nothing about it looked like it applied to a job site. What changed my mind wasn't a sales pitch. It was watching how much of a week disappeared into quoting, chasing paperwork, and re-explaining the same job details to three different people, and realizing that part of the business had nothing to do with the tools in the truck.
"We already tried something and it didn't help"
This is the second most common reaction, right behind "there's no use case for us." Usually it means someone tried a general chatbot for something specific, like generating a quote from a set of drawings, and the output looked close enough to be tempting and was wrong enough to be dangerous. The tool got shelved, and the story that stuck was "AI doesn't work for construction."
That conclusion says more about the tool than the technology. A general-purpose chatbot has never seen your pricing, your suppliers, your crew rates, or the way you structure a proposal. Asking it to price a job cold is like handing a new hire zero training and expecting a correct number on day one. The tool wasn't wrong to fail. It was set up to fail.
The businesses getting real use out of AI in this space aren't running it out of the box. They're feeding it their own historical job data, their own templates, their own pricing logic, and narrowing the task down to something specific and repeatable. A tool that drafts a first-pass proposal from your last ten similar jobs behaves very differently than one asked to invent a number from nothing.
"Isn't this just for the bigger outfits?"
It's a reasonable assumption. Most of the AI coverage a trades owner runs into is written for tech companies or enterprise buyers with an IT department to lean on. That framing makes it easy to conclude the tools are out of reach for a fifteen-person mechanical contractor or a two-truck electrical shop.
In practice it's closer to the opposite. A large general contractor with a dedicated estimating department already has systems and staff absorbing some of that friction. A small shop where the owner writes every quote personally, after hours, on top of running jobs during the day, is the business with the most to gain from taking that task off one person's plate. Size isn't the deciding factor. What matters is whether the same repetitive document work is currently sitting on too few shoulders, which describes most trades businesses in the Okanagan regardless of headcount.
What an AI readiness assessment actually surfaces
After running assessments with trades and manufacturing firms across B.C., the pattern holds up job after job. The use cases that surface tend to cluster in three areas.
Pre-construction work: estimating, proposals, bid analysis. This is usually the biggest single time sink, and it's the one owners are most surprised by, mostly because they've stopped noticing how much of it happens after hours. It's also the one with the clearest payoff, since a faster, more consistent quote wins more of the jobs a business is already chasing.
Project administration: documentation, RFIs, change orders, closeouts. Nobody got into this business because they wanted to write reports. Most of this paperwork exists because insurance and contracts require it, not because it adds value on its own, which is exactly why it's such a good candidate for a tool to draft the first pass.
Knowledge management: the senior person whose head holds the playbook the rest of the team relies on. Every trades business has one. When that person takes a vacation or retires, a chunk of institutional pricing and sequencing knowledge goes with them, unless someone's written it down. Almost nobody has, mostly because there's never a slow enough week to sit down and do it.
None of that involves replacing anyone on the tools. It's about stopping the drain of two days a week going to paperwork that doesn't bill.
Where the GVBOT report is genuinely useful
The governance findings are the part worth taking seriously. The report flags how few B.C. businesses have any framework for AI accountability: who owns the output, what data is in bounds, where the boundaries sit.
Construction businesses already carry a lot of liability: contractual, regulatory, safety. Bolting AI onto that without governance is how a productivity shortcut turns into a problem the lawyers solve instead of the operations team. Say a project manager pastes a subcontractor's confidential pricing into a free public AI tool to help format a comparison spreadsheet. That data is now sitting on a server outside your control, and depending on what the contract with that sub actually says, a breach may have just happened without anyone intending one.
What governance actually looks like on a jobsite
Nobody needs a thirty-page policy that ends up filed and forgotten. A handful of plain rules covers most of it: which tools are approved for company data, what never gets typed into a public chatbot, who reviews AI-drafted client communication before it goes out, and who's accountable when the output is wrong. Most businesses could write this in an afternoon once someone sits down and works through it. Almost none have, because nobody's forced the conversation yet.
That's the gap the GVBOT report is actually measuring, whether it set out to or not. Businesses aren't short on use cases. They're short on the guardrails to adopt AI responsibly once they find one.
There's also an insurance angle worth thinking about before it becomes a problem instead of after. Errors-and-omissions and liability underwriters already ask detailed questions about data security practices, and it isn't a stretch to expect AI use in client-facing work to join that list before long. A construction company that can point to a written policy, even a short one, is in a materially different position than one that can only say "we don't really have rules around that." That gap won't show up in a survey question about use cases. It shows up the first time a claim gets filed.
How to read the GVBOT report if you run a trades business
Read it for the governance findings. Skip the conclusion that there's no use case. Then run the analysis on your own operation instead of B.C. business in aggregate, because the survey wasn't built to tell a marketing agency apart from a mechanical contractor, and averaging the two together produces a number that describes neither one well.
The free AI Readiness Assessment is built specifically for trades, construction, and manufacturing firms. It surfaces the use cases actually present in your operation, and it tells you what needs to be in place, governance included, before any tool gets implemented.
The use case is there. The survey just wasn't measuring for it.