TMS Software: What a Transportation Management System Does and When a Dispatch Shift Is Useful
Table of Contents
Anyone searching for “TMS software” will find dozens of providers and comparison lists. What most of them don’t address is this: A transport management system plans the transport, but not the coordination, which in many freight forwarding companies still takes place via email, Excel, and over the phone. The work that the system has never taken over gets stuck right between the TMS and day-to-day operations.
This article first explains what a TMS is and what it does, and then shows where a standard TMS reaches its limits and when it makes sense to have a dedicated dispatching team. It is aimed at freight forwarders and logistics service providers who already use a TMS such as Soloplan CarLo, LIS WinSped, or CargoWise but still spend a large part of their day on administrative tasks. For those who do not yet use a TMS, implementing a TMS is the first step—not adding a dedicated dispatch team on top of it.
What a Transportation Management System (TMS) Is and What It Covers
A transport management system (TMS) is the software that a freight forwarder or logistics service provider uses to plan, manage, and bill for shipments. It is to transportation what ERP is to accounting: the core operational system. When people refer to TMS software or transportation management software, this is exactly the system they mean; a TMS in logistics fulfills this role.
A fully developed TMS typically covers:
- Order Management: Enter and Manage Shipping Orders
- Schedule: Assign orders to vehicles, routes, and carriers
- Tour and Route Planning
- Freight Cost Calculation and Billing
- Telematics and Vehicle Connectivity
- Shipment Tracking (Tracking & Tracing)
- Integration with freight exchanges such as Timocom or Trans.eu
- Analysis and Reporting
Well-known systems in the DACH region include Soloplan CarLo, LIS WinSped, and the globally used CargoWise. These are mature systems that reliably cover the standard transportation process. If your workflows fit neatly into these standard processes, a well-implemented TMS is the right and sufficient solution. This article addresses the cases where that is not the case.
TMS, ERP, and Freight Forwarding Software: Where the Limits Lie
Three terms are often confused. To briefly clarify: The ERP system handles the business side—that is, accounting, purchasing, and master data. The TMS software manages transportation—that is, orders, scheduling, routes, and freight billing. “Freight forwarding software” is usually a catch-all term and, in practice, often refers to a TMS with freight-forwarding-specific functions. A freight exchange like Timocom or Trans.eu, on the other hand, is not a TMS but a marketplace to which a TMS is connected.
In practice, this means that a company rarely needs another large system, but rather a seamless connection between its existing ones. It is precisely at this interface—between ERP, TMS, and the processes that run via email in between—that the overhead discussed in the next section arises. This article shows how to eliminate duplicate data entry between such systems From double data entry to zero manual entries.
Where the standard TMS ends: the email scheduling system takes over
A TMS does an excellent job of managing shipments once a properly entered order is in the system. The effort that really takes up time at many freight forwarders occurs before and alongside that: in the work involved in entering the order into the system in the first place and navigating it through the day’s exceptions.
Four passages keep coming up:
A Order Entry is received via email, PDF, and phone and is entered manually into the TMS. The Pricing The information needed for a quote exists in the minds of experienced schedulers and in old Excel files, not as retrievable pricing data in the system. The Selection of Carriers and Subcontractors is handled through verbal requests, phone calls, and the freight exchange, while the partners' performance history is not available in any structured format. And the Status Determination takes time because the sales department calls the planning department to find out where a shipment is.
This isn't a shortcoming of any particular TMS. Standard software covers the standard use case. The specific logic, customer exceptions, and experiential knowledge that an individual company applies remain outside the system—usually in emails and Excel spreadsheets. We discussed how this array of tools has proliferated alongside the core system over the years in the article on SaaS Proliferation described.
Here’s an example: A less-than-truckload (LTL) freight forwarder with 90 employees uses CarLo as its TMS. The scheduling process is clearly mapped out in the system, but every order comes in as an email or PDF and is manually entered by two clerks; prices are pulled from old quotes; and when there are bottlenecks, the dispatchers call carriers one by one. The TMS runs flawlessly. The work leading up to it happens alongside it.
The Cost of the Gap: A Calculation Framework
The cost of this coordination can be estimated using a calculation framework. Plug in your own values; the following are a model, not a benchmark.
Assuming that, in a freight forwarding company, order entry, price research, subcontractor coordination, and status tracking—tasks not covered by the TMS—take up a conservative estimate of 20 hours per week handled by the dispatch desk. At a full cost of 55 EUR and 46 work weeks, that amounts to 20 × 46 × 55 = 50,600 EUR per year.
Important: This is a theoretical gross potential, not an actual savings amount. Part of this work does not disappear; rather, it shifts from data entry to exception handling. Only the process analysis will show how much is actually recovered. The point is the scale: Coordination around the TMS often costs more than the TMS itself, and it isn’t included in any license fee calculation.
Standard TMS, add-on module, or custom shift?
Before you consider developing your own solution, you should honestly evaluate the following points in this order.
First: Is your TMS reaching its full potential? Many companies use only a fraction of what their TMS is capable of because certain modules were never implemented or processes were never properly defined. The fastest and most streamlined approach is often to configure the existing system correctly.
Second: Is there a suitable add-on module or standard integration? There are ready-made modules for common requirements such as telematics or customs. If one fits your needs, don't try to build it from scratch.
Third: Is the gap your operational knowledge? Only when coordination is based on the logic that gives you your competitive advantage—and neither configuration nor standard modules can capture it—does creating a custom layer on top of the TMS become the right solution. This approach—prioritizing the leanest, most viable option first—prevents you from building something from scratch when a ready-made solution already exists.
Three Ways to Close the Gap
There is no single "correct" architecture. When the configuration and standard module are not sufficient, we see three patterns in practice:
Push the TMS to its limits. Activate existing modules, integrate interfaces properly, and define processes in the system. This works as long as your own logic fits within the TMS framework.
Place another tool next to it. A specialized tool for a specific subprocess, such as quote calculation. This solves one problem, but increases the number of systems between which data must be transferred manually, and thus the coordination effort—which you were actually trying to reduce.
Set an availability layer on the TMS. A lean operational layer that sits on top of the TMS, automatically captures orders from emails, provides access to pricing information and carrier history, and keeps the status transparent, while the TMS remains the leading system for billing and transportation. It is precisely this model—complementing rather than replacing—that we describe on our page about Operations Platforms for Freight Forwarders.
The choice of pattern is determined by an inventory assessment, not by a supplier's catalog.
How Much an On-Call Shift Costs
There are no fixed market prices here, because the range depends heavily on your company. As a rough guide: A single feature—such as automatic order entry from emails into the TMS—starts at a reasonable price of around 50,000 EUR for custom development. An end-to-end scheduling layer for freight forwarders of this size generally ranges from 75,000 to 150,000 EUR, plus 15 to 20 percent per year for operations and further development as a guideline.
Specific factors determine where your project falls within this range: the type and number of TMS and ERP interfaces, the quality of the master data, the number of process variants and customer exceptions, as well as connections to freight exchanges and telematics systems. The complete cost breakdown, including all ancillary items, can be found in the article The Cost of Digital Transformation for Small and Medium-Sized Businesses. The article on the topic explains how to calculate the actual benefits you can achieve without making up numbers: ROI of Custom Software.
An example for illustrative purposes only, not a formal offer: a dispatch module with automatic order entry, pricing information, and carrier history integrated into an existing TMS, with a total investment of approximately 95,000 EUR, plus about 17,000 EUR per year for operations and further development. Over five years, that amounts to approximately 180,000 EUR. This is offset by the 50,600 EUR in annual coordination costs from the sample calculation, a realistic portion of which is recouped. Whether the investment pays off depends on your own assessment, not our model figures.
Such a layer must be built for production use from day one: If the planning department relies on it, an outage means a business interruption. The reason why operational software cannot be a prototype is explained in MVP vs. Production System.
Self-Assessment: Is an on-call shift your next step?
Creating your own layer on TMS is likely your next step if several of these points apply:
- Orders arrive via email and PDF and are entered manually into the TMS.
- Pricing for quotes is determined by individual experienced dispatchers.
- Carriers are selected on an ad hoc basis; there is no structured performance history.
- The sales department calls the dispatch department to find out the status of a shipment.
- If a key person is unavailable, knowledge that isn't documented anywhere comes to a standstill.
- Your TMS has been implemented and is being used to its full potential, yet the work still isn't getting done.
She's probably not Your next step if you haven't yet maximized the potential of your TMS, if a standard module fills the gap, or if your processes fit into the system without requiring significant coordination.
What to do now
First, measure what the coordination team actually spends time on besides the TMS. Have someone track for a week how much time is spent on order entry, price research, subcontractor coordination, and status clarification, and calculate the full costs. This figure will tell you more about your next step than any list of vendors.
Then check the order: make full use of the TMS, use the standard module, and only then create your own shift. If the gap persists because it reflects your operational knowledge, a scheduling shift in the TMS is the viable solution. The questions you should ask an implementation partner in advance are listed in Selecting a Software Development Partner.
If you want to know which media discontinuity is costing you the most and what realistic benefits eliminating it would bring, we’ll work with you to map out your inventory planning process and run the numbers. View the Operations Platform for Your Freight Forwarding Company or directly a Book meeting.
Arrange a free, no-obligation consultation with our team.
EN 
DE 
FR 
ES