TMS Multi-Stop Route Optimization: Practical Mileage & Toll Cost Parity Solvers

The Multi-Stop Dispatch Friction Problem

Truckload and dedicated fleets routinely accept multi-stop linehaul loads where the shipper's rate is based on practical highway miles published by industry mileage guides. Yet the driver's actual operating cost is determined by the specific sequence of stops, the chosen routing algorithm, fuel consumption on that route, and any tolls incurred on northeastern turnpikes, bridge crossings, or congested bypass corridors.

This creates persistent margin leakage. A route that appears profitable on practical miles can lose $180-$450 per load once tolls and incremental diesel are applied. Dispatchers lack the time to manually compare routing options across every combination of stops while simultaneously honoring delivery windows, hours-of-service compliance, and equipment constraints.

PC*MILER Routing Algorithms in Enterprise TMS

Modern TMS platforms integrate the ALK PC*MILER engine with three primary routing profiles that must be solved simultaneously for every multi-stop order:

• Practical - follows the National Network and primary highways a professional driver would normally select.
• Shortest - minimizes total distance regardless of functional class or operational constraints.
• Toll-Discouraged - applies a cost penalty to every toll facility, producing a toll-avoidance route that is still legally and physically viable.

The TMS must call the routing service multiple times per order, once for each profile, while preserving the exact stop sequence requested by the shipper or receiver. The resulting mileage values are stored in separate fields (practical_miles, shortest_miles, toll_discouraged_miles) so that rating, carrier settlement, and driver pay can be calculated independently of the route the driver is actually dispatched on.

Dynamic Toll Cost Calculation and Transponder Interoperability

Northeastern toll authorities have achieved substantial interoperability through the E-ZPass system, which now spans 19 states and multiple tolling agencies. Most Class 8 tractors carry an E-ZPass transponder mounted on the windshield and, in many cases, a PrePass transponder for weigh-station bypass. Additional regional transponders (iPass, SunPass, TxTag, etc.) are maintained when a fleet's lanes justify the administrative overhead.

Within the TMS, toll cost is calculated by passing the exact route geometry, axle count, and vehicle class to a toll lookup service. The service returns a precise dollar amount for each segment. These costs are then attributed to the specific stop sequence so that incremental toll expense can be isolated to each additional delivery or pickup.

State-by-state business rules are stored in a configuration table that maps authority, toll facility ID, time-of-day pricing (where applicable), and axle class. This table is updated quarterly to reflect new toll plazas, rate changes, and modifications to interoperability agreements.

Building the Cost Parity Solver

The parity solver is a software engineering component that runs inside the TMS dispatch workflow. For every multi-stop load tender, the solver performs the following steps in near real time:

1. Receive the ordered list of stops, equipment type, and shipper mileage basis (usually practical miles).
2. Call the PC*MILER web service or local library for each routing profile (practical, shortest, toll-discouraged), preserving stop sequence.
3. Retrieve toll costs for each profile using the current transponder configuration and state-by-state toll matrix.
4. Calculate incremental diesel consumption using route-specific fuel economy factors derived from historical telematics (typically 5.8-6.8 mpg on practical routes versus 5.2-6.1 mpg on toll-discouraged routes that include more stop-and-go segments).
5. Combine tolls and fuel delta into a total variable cost for each profile.
6. Divide total variable cost by the shipper-paid practical miles to produce a true cost-per-mile for each routing option.
7. Present the dispatcher with a ranked list of viable corridors showing net margin per mile after tolls and fuel.

This calculation must complete in under 2.5 seconds to remain invisible inside the dispatch user experience. Caching of frequently used origin-destination pairs and pre-computed toll matrices are essential performance techniques.

Database Schema Considerations for Route Cost Parity

A robust implementation stores the following normalized data:

CREATE TABLE route_profiles (
    profile_id INT PRIMARY KEY,
    order_stop_sequence_id INT REFERENCES order_stops(id),
    routing_type VARCHAR(20) CHECK (routing_type IN ('practical','shortest','toll_discouraged')),
    total_miles NUMERIC(8,2),
    toll_cost NUMERIC(8,2),
    estimated_fuel_gallons NUMERIC(6,3),
    calculated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE toll_matrix (
    authority_code VARCHAR(10),
    facility_id VARCHAR(25),
    axle_class SMALLINT,
    rate_effective_date DATE,
    rate_amount NUMERIC(6,2),
    time_band_start TIME,
    time_band_end TIME,
    transponder_type VARCHAR(15)
);

These tables feed both real-time dispatch decisions and post-trip reconciliation. Carrier settlement and driver pay modules reference the chosen profile so that any toll reimbursement or fuel surcharge is applied correctly.

Integration with Broader TMS Practices

The parity solver does not operate in isolation. It must be tightly coupled with several other enterprise capabilities:

• TMS Implementation - ensuring the routing and toll engines are correctly configured during initial rollout.
• Transportation Accounting Integration - flowing the chosen route cost components into the general ledger and freight settlement modules.
• ELD and EDI Integration - validating that the dispatched route matches the driver's actual GPS trace for compliance and audit purposes.
• Carrier Rate Matrix Optimization - adjusting buy rates dynamically when toll-heavy lanes are consistently selected.
• Business Process Optimization - redesigning dispatch workflows to incorporate the parity recommendation without adding clicks.
• Advanced Reporting - producing lane-level margin reports that isolate the financial impact of toll versus practical routing decisions.

These integrations are especially valuable for brokerage and 3PL operations, intermodal drayage, and truckload fleets that routinely manage multi-stop freight across toll-intensive corridors.

Implementation Best Practices

Strong Tower Consulting recommends the following technical approach when deploying a parity solver:

• Abstract the routing and toll services behind a single RouteCostEngine interface so that PC*MILER, Google Routes, or other providers can be swapped without changing dispatch logic.
• Store transponder assignments at the tractor level with effective dates to support accurate historical toll reconstruction.
• Implement a nightly batch job that re-costs all open orders using the latest toll rates and fuel prices, surfacing any material margin erosion to planners.
• Expose the parity recommendation through both the TMS user interface and via API for carriers or brokers who consume load tenders programmatically.
• Maintain an audit trail of every routing profile considered and the final selection reason chosen by the dispatcher or automated rule.

Conclusion

Multi-stop route optimization that ignores toll and fuel cost parity leaves meaningful margin on the table. By engineering a TMS component that simultaneously solves practical, shortest, and toll-discouraged routes, calculates exact transponder charges, and surfaces net per-mile contribution, dispatchers can make informed corridor selections that protect both shipper relationships and fleet profitability.

Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership (separate EINs; liability firewall). Scott Elliott is founder and transportation systems architect of both.