The number nobody had read

A marine contractor in Florida runs dredging and shoreline work across several active jobs at a time, with crews who log their shifts on a phone app at the start and end of every day. The owner had lost roughly a quarter of a million dollars on a single underbid job, and the number that would have caught it, the actual labour cost of a job while the job was still running, had never been produced. The hours existed. The pay rates existed. Nobody had put them on the same page.

The company's systems were the usual four: a CRM for the pipeline, the time-tracking app for the crews, an accounting system for the invoices, and the owner's head for the connection between them.

CWT is embedded with the company as the person responsible for its operating systems. The first job was making the CRM the one place a job exists, with every quote, contract and invoice attached to it. The second was connecting the accounting system to the CRM so an invoice created in one appears on the job in the other. The third was reading the time-tracking data the crews had already been producing.

For one job, a shoreline project that mobilised at the end of August, the shift records were pulled and reconciled by person and by day: 589.48 crew hours across 67 shifts by seven people over three weeks. At the company's floor rate that is $14,737.08 in labour. The number was on the owner's desk before the job closed.

A labour cost per job, produced from data the crews were already collecting, available while the job is live. A quote that can be checked against the last comparable job before it goes out. An operations coordinator, hired in September, whose morning starts with the job packet that number lives in.

Most operating companies already collect the data that would change their pricing. The gap is that no one is responsible for reading it. Once someone is, the first number arrives in weeks, from systems the company already pays for.