Premier Roofing Company

Thomas Burgett is an experienced technology leader specializing in AI-driven automation, data analytics and enterprise systems integration. He develops solutions that streamline workflows, improve efficiency and deliver measurable business value.

Measure the baseline before you buy

In my experience, most construction technology is purchased based on a demo and judged on a feeling. A vendor presents a dashboard, someone in operations sees the potential to save time, and a year later, no one can say whether it delivered the promised results.

I run IT and AI at Premier Roofing, a multi-branch roofer with 140 full-time staff plus seasonal contractors. My team buys software, integrates it and builds our own automations when nothing on the market fits. Return on these projects can be measured, but those measures have to be determined before someone signs on the dotted line. Otherwise, the baseline is gone, and we are left judging the result on a feeling.

Before we automate anything, we write down how the work gets done today and what it costs. For our accounts payable sync between CRM and ERP, we asked the AP team how many bills they keyed by hand each week, how long each one took and how often one went in wrong or twice. Those numbers became the test that the integration has to pass in accounting's hands.

Pick one or two measures per project. A claims bot should be judged on how long a job sits waiting for its next step. Give a project ten metrics, and a vendor will always find one that went up.

Count the hours people actually get back

Vendor ROI calculators multiply minutes saved by headcount by hourly wage. The result is usually large and mostly fictional. Saving a coordinator 20 minutes a day puts no money in the bank unless that time goes to work that pays. After asking how much time a tool saves, ask what the person will do with it. For our AI claims bot, the useful answer is that coordinators can carry more files, and that shows up in job counts per coordinator.

In-house builds look free until you count the developer weeks. A SaaS tool looks cheap until you count the integration nobody quoted and the cost of changing processes. Integration work, my team's maintenance hours, and the time staff spend learning a new solution all come out of the return.

Returns that don't show up as hours

Some of the best returns are errors that stop happening. A duplicate vendor payment or a bill coded to the wrong job costs money and hours to unwind. If you counted those errors in the baseline, you can count how many go away.

"Do not fall into a sunk cost fallacy, especially when the only cost has been time."

Cash timing is another. Faster invoicing and faster supplement approvals from carriers bring money in sooner. On an insurance job, shortening the gap between inspection and an approved supplement can be worth more than the labor it saves.

The hardest return to measure is better decisions. We built a chatbot that answers questions from our data warehouse, and an AI analyst called Skye that pulls working knowledge out of company communication in Google Workspace. The value is that a branch manager gets an answer without filing a report request with my team. I measure these by usage and accuracy. For the warehouse chatbot, we are building a test set from real questions people asked, each paired with the SQL that answers it correctly, and every change to the bot gets scored against it. A tool people stop using, or one that gives wrong answers confidently, loses money no matter what it costs.

Stop projects that aren't paying

Do not fall into the sunk cost fallacy. If the measure hasn't moved by the agreed-upon time, stop the work or have it rescoped. A vendor we hired couldn't deliver a stable AI solution, so we stopped that engagement, and my team built it in-house. The vendor might have eventually delivered, but at what cost? Walking away from a half-built project feels like a waste, but the time and money already spent are gone either way. The only question is whether the next dollar earns more there or somewhere else.

Before signing a contract, I want to understand the current cost of the process in hours and errors, and who has measured it. I also need to know which one or two metrics should improve, by how much, and within what timeframe. If the technology frees up employees' time, we should have a clear plan for how to use it. Integration and ongoing maintenance costs must also be accounted for, including the hours my own team will spend supporting the solution. Finally, we need an agreed-upon result and deadline that determines whether the work continues. If a vendor or internal sponsor cannot tell us what the process costs today and what should improve, we are not ready to buy.