Transportation software has consolidated around a set of platforms that do a lot. Load boards, dispatch, settlements, IFTA, maintenance, compliance reporting. For a general freight operation they cover most of the ground.
The friction appears when an operation is not general.
Where standard platforms stop fitting
Specialized freight with specialized requirements. Temperature-controlled with monitoring obligations, hazmat with documentation chains, oversize with permit tracking per jurisdiction. The platform has fields. It does not have workflow for the thing that makes this freight different.
Dedicated or contract operations. Running dedicated lanes for a handful of customers is not the same problem as spot market freight. The economics, the planning horizon and the customer relationship all differ, and platforms built around load-by-load transactions model it awkwardly.
Mixed models. Asset-based with a brokerage arm, or carrier operations alongside warehousing. These usually mean two systems that do not talk, and someone reconciling between them.
Customer-specific requirements. A large shipper wants their data in their format on their schedule. The platform exports its format. Somebody bridges the gap manually, every week, forever.
The numbers that matter to you specifically. Revenue per mile by lane by customer, net of the costs your operation actually incurs. Deadhead patterns. Driver retention against route assignment. Standard reporting covers standard questions, and the ones that determine your profitability are usually not standard.
What the spreadsheet layer is telling you
Every logistics operation running a platform also runs spreadsheets. Lane profitability. Customer margin. Driver assignment planning. Equipment utilization. A weekly report someone assembles for a customer.
That collection is a specification for what the platform does not do. It is also a risk: undocumented, maintained by one person, and holding the analysis the business actually runs on.
The question is not whether the spreadsheets should exist. It is whether the operation can afford for them to be the only version of that information.
What building alongside looks like
The pattern that works keeps the platform for what it handles and adds what it does not.
Operational visibility in one place. Loads, drivers, equipment and customer commitments in a single view, pulled from wherever it lives. Most operations answer “where does everything stand” by checking three systems and asking two people.
Profitability at the level you decide. By lane, by customer, by driver, by equipment type, calculated continuously from data that already exists rather than assembled monthly.
Customer-facing status. Shippers want to know where their freight is without calling. A portal or automated update handles most of that traffic, and the calls it eliminates are a real cost.
The workflow specific to your freight. Permit tracking, temperature exceptions, detention documentation, whatever your niche requires that the platform treats as a note field.
Exception surfacing. Loads running behind, equipment approaching a service interval, a customer whose volume dropped, a lane whose margin eroded. Things that need attention, found by the system rather than by someone reviewing reports.
The integration reality
This work is mostly integration, and integration in logistics is uneven.
Some platforms have solid APIs. Some have limited ones. Some involve scheduled file transfers in formats that predate the web. ELD providers, load boards and customer systems each have their own arrangements.
This is the part that determines cost and timeline, and it should be assessed before anything is committed. A build that assumes clean data access and discovers otherwise runs over in exactly the way that gives custom software a bad reputation.
The practical advice: scope the integration first, as its own piece of work, before scoping the system that depends on it.
Judging whether it is worth it
Count the spreadsheets people depend on daily. Ask how many hours a week go to assembling information from multiple systems. Ask what questions about the operation cannot be answered today without a project.
Then ask what one bad decision costs, made because the information was not available in time. In freight the answer is usually a lane run unprofitably for months, or equipment utilization nobody noticed slipping.
If those numbers are meaningful against a build, the case exists. If the operation is small enough that one person holds it comfortably, keep the spreadsheets and revisit when that stops being true.
If your operation runs on a platform plus five spreadsheets, get in touch. We build visibility and workflow layers for carriers and brokers around the systems already in place.
Frequently asked questions
Should a small carrier replace its TMS?
Rarely the right first move. TMS platforms handle load management, settlements and compliance reporting that would be expensive to rebuild. The more common approach is keeping the TMS and building the visibility and workflow layer it does not provide.
What about ELD and compliance data?
That stays with the systems built for it, and those requirements are not worth reimplementing. The value of a custom layer is usually in bringing that data together with dispatch, customer and financial data that currently live apart.
At what size does this make sense?
It is less about fleet size than about how much of the operation runs on spreadsheets alongside the TMS. An operation with three or four workbooks that people depend on daily has a case regardless of truck count.