Mechanical contractor · Houston, TX
Cutting a mechanical contractor’s T&M billing cycle from 26 days to 4
A Houston mechanical contractor was writing off nearly a fifth of its change order value. Most of it traced back to tags written from memory at shift end.
Representative engagement. This describes work of a type we build, with figures modeled rather than measured at a named client. We would rather tell you that than invent a customer you cannot phone.
Outcome Measured after go-live
- 26 → 4 days
- Internal processing time
- From work performed to a change order request leaving the building.
- 18% → 6.5%
- Change order value written off
- Measured across 90 days post go-live against the prior four quarters.
- $780k
- Annualized recovery
- Recovered billing plus released working capital, net of the retainer.
The situation
A mechanical contractor working plant maintenance and capital projects across the Houston Ship Channel. Roughly 340 T&M tags a month, averaging just under $3,900, spread across eleven general contractors and four direct plant owners.
The finance team knew there was a problem because the write-off line had grown three years running. What nobody could explain was why. The work was real, the crews were good, and the customers were repeat business.
What the audit week found
Two days on site with a field supervisor, the billing clerk and the controller, and the pattern was visible by Tuesday afternoon.
Tags were being written at the end of a shift, in a truck, from memory. Not because anyone was careless, but because the foreman had spent the day doing the work and the paperwork happened afterwards. By then the description was thin, the photographs did not exist, and the superintendent who had verbally authorized the work had gone home.
Three specific findings drove everything else:
Descriptions were unarguable in the wrong direction. A tag reading “repair line, 6 hrs, 2 men” is not defensible against a GC who wants to know which line, why, and who told you to. Most disputes were not about whether work happened. They were about whether the tag proved it.
Rates were being applied from memory. Three GCs had different rate schedules and two had been amended mid-year. Nobody was checking a tag against the governing document before it went out.
Nobody could produce an ageing report for outstanding tags. Tags went out and were chased informally when somebody remembered. Roughly $400k of submitted but unapproved change order value was sitting somewhere in the system at any moment, and the company had no way to see it.
The prototype we built that week read 40 of their real tags and priced them against the correct rate schedule. Eleven had a rate discrepancy. Two of those were live and unbilled.
What we built
A field app the foreman actually opens. Tag written on a phone at the point of work, with the equipment and labor picked from lists rather than typed, photographs attached, and a signature captured on glass while the superintendent is still standing there. Works with no signal inside a plant and syncs when the truck reaches the gate.
Contract-aware pricing. Labor, equipment and material priced from the rate schedule governing that specific customer, with markup applied by the rule in the agreement. Anything outside tolerance is held before it leaves.
A submission packet, formatted per GC. Each general contractor wanted something slightly different. The system assembles what each one expects rather than making the billing clerk reformat by hand.
An ageing log. Every outstanding tag, who has it, and how many days they have had it. That screen turned out to be the most-used part of the build, which is not what anyone predicted.
What happened
Internal processing went from 26 days to 4 inside the first month, which was expected. The write-off improvement took a full quarter to show, which was not: the tags already in the system had to work their way through before the cleaner ones started landing.
The unexpected result was on the GC side. Approval time fell from 31 days to 22 without the general contractors changing anything at all. Better documentation generated fewer questions, and fewer questions meant fewer revision cycles.
What went wrong
The rate schedules were the actual project. They lived in 40-odd PDFs across two shared drives in inconsistent formats, and three had been superseded without the old versions being removed. Two weeks of the engagement went into getting them into one machine-readable place. That unglamorous work produced more value than any of the extraction did.
One superintendent refused to sign on a phone. He had been signing paper for thirty years and was not going to stop. The system now prints a tag for signature and photographs it back in. Fighting this would have been a mistake.
Sage had no usable write API for what we needed. Approved tags land through a batch import processed overnight, which put a day of latency back into a process we had just spent six weeks compressing. We found this in week one, which is why integration goes first rather than last.
What it cost
| Workflow Audit | $7,500, one week |
| Build | $68,000, six weeks, fixed price |
| Care and feeding | $5,500 a month, optional |
| Cloud and model usage | Paid directly by the client, roughly $310 a month |
Source code sits in the client’s repository. The system runs in their Azure tenant on their keys. There are no seat licenses and nothing to renegotiate.
What it was built with
- React Native field app (offline-first)
- Postgres on the client’s Azure tenant
- Claude for handwriting and photo extraction
- Sage 300 CRE integration