A Charlotte-based trucking owner-operator was managing load offers, broker communications, and dispatch decisions across email, texts, and three separate spreadsheets. Nothing talked to each other. We built one internal tool that replaced all of it.
Every load decision required pulling from at least three different sources simultaneously: Gmail for incoming offers, a spreadsheet for broker history, another spreadsheet for booked loads, and a third for revenue estimates. None of them talked to each other.
The result wasn't just inefficiency — it was decisions made with incomplete information. Good loads got passed on because the rate wasn't checked against broker history. Weaker offers got accepted because the pipeline view was outdated. Time spent context-switching was time not spent running the operation.
The business was running on process that made sense when it was small. But at the volume they'd grown to, the cracks were showing up in money left on the table.
We built a purpose-built internal web app that pulls all the relevant data into a single interface, organized around the actual decision flow: what's available, who's offering it, is it worth taking, and where does it sit in the pipeline.
The tool connects directly to Gmail to parse and categorize incoming load offers. It pulls load board data and filters by lane, rate floor, and broker score. Brokers are ranked by their actual booking rate and cumulative revenue history. And the whole pipeline — from inbox to booked — lives in a Kanban view that updates in real time.
We started by mapping the existing process in detail — not the ideal process, the real one. What data sources were already being used. What decisions were made and in what order. Where the friction was costing time or money.
From there, we designed the interface around the decision flow rather than the data structure. The dashboard shows what the operator needs to act on right now. The load board is pre-filtered, not raw. The Kanban reflects how loads actually move, not a generic "to-do / in progress / done" framework.
The Gmail integration reads incoming emails, identifies load offers, parses the relevant details, and surfaces them in the inbox view automatically. No copy-pasting. No missed emails in a busy inbox. The broker ranking system is seeded with historical data and updates as new loads close.
"We built it once and built it right — the kind of tool that looks simple from the outside because all the complexity is handled on the back end where the operator never has to think about it."
Every load decision now starts from the same place. The operator has full visibility into what's available, who's offering it, and whether it's worth taking — based on that broker's actual track record, not a gut check.
The broker ranking system surfaced patterns the operator knew existed but couldn't measure precisely — which brokers consistently booked, which ones negotiated aggressively but rarely closed, and where the real revenue came from. That visibility alone changed how offers were prioritized.
The tool runs in production, accessed daily. It's not a prototype or a proof of concept. It's the actual system the operation runs on.
Any operation that runs on scattered data — email, spreadsheets, texts, multiple apps — can be consolidated the same way. The specific industry changes. The problem doesn't.
HVAC, plumbing, electrical. Job board, crew dispatch, customer status, and revenue — one screen instead of four different apps and a whiteboard.
Open ROs, pending parts, technician workload, and customer follow-up. Not a generic shop management system — built around how your specific shop runs.
If decisions require pulling from multiple places, there's a version of this tool for you. The goal is always the same: one screen, full picture, faster decisions.
Tell me what your operation looks like and I'll tell you what a consolidated version could look like. No pitch, just a conversation about what's possible.