Bid automation
Bidding and quoting automated rather than assembled by hand, so brokers spend their attention on the loads where judgement actually changes the outcome.
Freight brokerage · Custom TMS
A brokerage on a platform it could not change
The brokerage ran on Truckstop's ITS platform and decided to leave it. Nothing was being switched off — the platform simply could not be shaped around the way this brokerage actually works, and that had become the limit on the business.
- Sector
- Freight brokerage
- Replaced
- Truckstop ITS (off-the-shelf)
- Core
- Bids · Carrier docs · Invoicing · Tracking · Reporting
- Integrations
- QuickBooks two-way · Load boards · Carrier tracking · AI assistance
The situation
The platform still worked. That was the problem.
- Workflow shaped by someone else's product
- Workarounds standing in for features
- A ceiling on what the operation could become
A brokerage's software is not a convenience layer over the business — for a broker it very nearly is the business. This one had years of operating history, habits and carrier relationships built on Truckstop's ITS platform, and that platform kept working perfectly well.
Staying would have been the easy decision. The business chose to leave anyway, because a bought product quietly sets the limit on how you are allowed to work. Every change to the operation has to be expressed inside someone else's software, and often the answer is that it cannot be.
A move by choice is still a full move. The replacement has to be at least as complete as the thing it replaces on the day it goes live — which is why this was worth deciding deliberately, rather than eventually and under pressure.
Why leave something that works
Software you cannot change eventually decides what the business is allowed to do.
Starting point
The software had started deciding how the business worked.
An off-the-shelf TMS is a set of decisions someone else made about how brokerage should be done. Where those decisions matched, it was fine. Where they did not, the business absorbed the difference — a workaround, a spreadsheet beside the system, a step that took longer than it should. None of that is dramatic on any given day. It compounds, and it caps what the operation is able to become.
- A bought platform that could not be adapted to this brokerage's workflow
- Workarounds and side spreadsheets filling the gaps the product left
- Years of operating history and habit built around the outgoing platform
- Brokerage-specific workflows that generic tools do not cover
- No appetite for a migration that lost carrier relationships or documents
- Quoting, covering and invoicing had to continue throughout
How it started
Same method, and a decision that had to earn itself.
The approach was the one we always use — analyse the real workflow, interview the people inside it, prototype early — but leaving a platform that still works has to be justified. The replacement must match what the old system genuinely did and then go past it. So the questions were "what does this actually do today", "what must exist on day one", and "what can a system of our own do that a bought one never will".
- 01
Workflow analysis
We traced a load from first quote through carrier selection, document collection, tracking, invoicing and settlement — and separated what the old system genuinely did from what people had learned to work around.
- 02
Interviews
Brokers, carrier sales and accounting. Broker workflow is full of judgement that never appears in documentation, and most of it lives in the heads of the people doing it daily.
- 03
Prototyping
Real screens in front of brokers early, because covering a load is a fast, high-frequency task where small friction compounds across a day.
- 04
Day-one scope
An explicit line between what had to be live at cutover and what could safely arrive afterwards — agreed before the build, because a brokerage cannot run half on one system and half on another.
Architecture
A core worth extending, not a like-for-like copy.
Rebuilding an outgoing system feature-for-feature would have inherited its limits along with its behaviour. We built the backbone around what a brokerage actually is — a load, a customer, a carrier, a margin — and then delivered the workflow on top of it. That is why capabilities the old platform never had, like AI-assisted day-to-day operations and a genuinely rich reporting layer, could be added without another rebuild.
- One record for the load, carrying customer, carrier, documents and margin
- Every financial figure derived from the operational record, not maintained beside it
- Day-one parity first; capability the old system never had, second
- Architecture chosen so later additions did not require re-founding
What moved in
What the platform does
A brokerage lives or dies on speed and paperwork. Most of the build went into removing the friction from tasks that happen dozens of times a day, and automating the ones that are pure administration.
Carrier documents
Collecting documents from carriers — authority, insurance, agreements — chased and captured by the system instead of by a person with a follow-up list.
Invoicing & billing
Customer invoices and carrier bills produced from the load record, so what gets billed matches what was actually moved.
Carrier tracking
Live tracking pulled from carrier tracking systems, so status comes from the truck rather than from a phone call.
Load boards
Posting and sourcing coverage through load board integrations, inside the same workflow as everything else.
AI-assisted operations
Helpers for the repetitive parts of a broker's day — the reading, sorting and drafting that consume time without needing judgement.
Reporting
A rich reporting layer over the operational record: margin, carrier performance, customer activity and the questions management actually asks.
Connected systems
Integrations
The brokerage's money and its freight both live partly outside the platform. Making those boundaries invisible was a large share of the work.
- QuickBooks — two-way
- Invoices and bills go out to QuickBooks; collected payments and paid bills sync back into the TMS. The operational record therefore shows real cash position, not just what was billed.
- Load boards
- Posting available freight and sourcing carrier coverage without leaving the workflow.
- Carrier tracking systems
- Position and status against the load, so customer updates do not depend on someone making a call.
- AI services
- Applied to day-to-day operational work rather than bolted on as a feature — document handling, drafting and triage.
Operational complexity
Two problems at once. The obvious one is scope: a brokerage TMS has to cover quoting, coverage, compliance documents, tracking, invoicing and settlement, and be fast at all of them. The harder one is the cutover. A brokerage cannot run half on the old platform and half on the new one, so the replacement has to be complete enough to run the business from the day it goes live — which forces genuinely hard decisions about what belongs in day one and what can follow.
Systems approach
Analyse the real workflow, interview the people inside it, prototype early, then build a core worth extending rather than a copy of the outgoing system. Day-one parity first, then the capability the old platform never had: two-way accounting, AI assistance in daily operations, and reporting worth reading.
Scope
What it involved
- Custom freight brokerage platform
- Bid and quote automation
- Carrier onboarding and document collection
- Customer invoicing and carrier billing
- Two-way QuickBooks synchronisation
- Load board and carrier tracking integrations
- AI-assisted day-to-day operations
- Reporting across margin, carriers and customers
- Migration off Truckstop ITS onto a platform the business controls
Working principle
When the software cannot be changed, it quietly starts deciding how the business works.
Questions we get asked
Before you start a project like this
The questions below come up in almost every first conversation. If yours is not here, it is a good thing to open with.
- Why leave Truckstop ITS if it still worked?
- Because it could not be changed. A bought platform encodes someone else's view of how a brokerage runs, and where that view differs from yours, you absorb the difference as workarounds and spreadsheets beside the system. That is tolerable for a while, and then it becomes the ceiling on what the operation can do. Nothing was being switched off — the business decided to own a modern system built to its own requirements rather than keep working around one it could not change.
- Is a custom platform sensible for a brokerage, or should we buy one?
- Buy, if a product fits your workflow without forcing you to work around it — we say so when that is the answer. Custom made sense here because brokerage workflow is specific, this business had already found the limits of a bought platform, and another general product would have replaced one set of workarounds with another.
- What does two-way QuickBooks sync actually mean?
- Invoices and bills are pushed out to QuickBooks, and the money coming back — collected payments and paid bills — syncs into the TMS. The operational system therefore shows real cash position rather than just what was invoiced, so nobody has to open two systems to answer a question about one load.
- Where does AI fit into brokerage operations?
- In the repetitive parts of the day: reading and sorting documents, drafting routine messages, triaging what needs a human. It is applied to work that consumes time without requiring judgement — not to the decisions that brokers are actually paid for.
- How do you migrate without losing carrier relationships or documents?
- By treating the document and carrier history as first-class data during discovery rather than as an afterthought at cutover. What is genuinely a record gets modelled and migrated; what is a working note does not need to survive the move.
Next case study
Replacing a legacy ERPStart with the operation
Talk about your operation.
Every engagement starts the same way, whatever the industry: understanding how the work actually happens.
Start a conversation →