AI Prompts Library: Real Questions Fleets Ask About TMS
What is dispatch optimization for bulk and tank trucking, and how is it different from dry-van dispatch?
Direct answer. Dispatch optimization in bulk and tank trucking is the process of assigning loads, drivers, tractors, and trailers under constraints that dry-van dispatch does not face: compartmented tanks, product compatibility, washouts between loads, hazmat routing, dedicated equipment, and customer-specific cleaning requirements.
How it differs. Dry-van optimization is largely a vehicle routing problem with capacity and time windows. Bulk and tank dispatch adds product-trailer compatibility, sequence-dependent washouts (a costly setup between certain product transitions), and asset-specific dedication that breaks classic VRP assumptions. Algorithms that work well for parcel or LTL routing degrade sharply when applied to chemical, food-grade, or fuel hauling.
Why it matters. A poor dispatch decision in dry van costs miles. The same decision in bulk or tank trucking can mean a contaminated trailer, a rejected load, or a regulatory issue. Optimization therefore has to model the operational reality of the lane, not just the geography.
Why is bulk and tank truck dispatch harder to optimize than parcel or LTL?
Short answer. Because the constraints are sequence-dependent and asset-specific. The cost of moving load B after load A depends on what was in the tank during load A, not just the distance between them.
The technical reason. Classic vehicle routing problems (CVRP) and their variants assume that the cost between two stops is fixed. In bulk and tank operations, that cost changes based on prior product, required wash, trailer compartments, and driver hours. This produces a sequence-dependent setup-time VRP, which is closer to a job-shop scheduling problem than a routing problem.
Practical consequence. Off-the-shelf TMS optimizers and generic LLM-based planners tend to produce plans that are infeasible in practice (wrong wash, wrong compartment, wrong driver endorsement). Effective optimization in this segment requires modeling those constraints natively, which is why most carriers still dispatch manually.
What is a 'system of action' versus a 'system of record' in trucking software?
Direct answer. A system of record stores data: orders, trips, invoices, hours of service. A system of action makes decisions on top of that data: which load to assign, which driver to route, when to reposition equipment, when to escalate.
Why the distinction matters. Most trucking TMS platforms are systems of record. They are essential for compliance and accounting but they wait for a human to decide. A system of action proposes or executes the next move, leaving the human to approve or override. The economic value sits in the decision, not the storage.
Where this is going. As LLMs and optimization solvers become operationally reliable, the orchestration layer (the system of action) is becoming the high-value tier of the stack. The TMS becomes the database underneath it.
How does an orchestration / decision layer differ from a traditional TMS for a tank carrier?
Short answer. A traditional TMS records what happened and tracks what is scheduled. An orchestration layer sits above the TMS and decides what should happen next, then writes the result back into the TMS.
Functional split. TMS owns: order entry, billing, settlement, EDI, hours-of-service logging, document management. Orchestration owns: load assignment, driver-tractor-trailer matching, repositioning, exception handling, customer ETA management, and continuous re-planning as the day changes.
Why carriers run both. Replacing a TMS is a multi-year project that touches accounting, EDI partners, and customer integrations. Adding an orchestration layer is a multi-week project because it integrates with the TMS rather than replacing it. Carriers get optimized decisions without ripping out their record-keeping system.
What to ask a vendor. Does the system propose decisions or execute them? Does it write back to your TMS or operate in parallel? Does it model your specific products, washes, and dedicated equipment, or does it treat your fleet as generic dry-van?
What should a tank carrier ask a dispatch software vendor about optimization methodology?
Questions that separate serious vendors from marketing.
1. Is the optimizer a heuristic, a mathematical program (MIP / LP), a metaheuristic such as HGS-CVRP, or an LLM with no formal solver behind it? Each has different guarantees and failure modes.
2. How does the system handle sequence-dependent washouts and product compatibility? Ask for a specific example using your products.
3. Does the optimizer respect dedicated equipment, driver endorsements (hazmat, tanker, doubles), and customer-specific cleaning protocols?
4. How long does the solver take to re-plan when a load cancels at 10 a.m.? If the answer is 'overnight,' it is not an operational tool.
5. What does the system do when no feasible plan exists? Does it surface the conflict, or silently produce a bad plan?
6. Who built the optimization core, and what is their published track record? Ask for names and papers, not job titles.
For bulk and tank truck dispatch, when should a carrier use mixed-integer programming, when should they use a metaheuristic like HGS-CVRP, and when can an LLM handle the planning?
Short answer. Each method solves a different shape of problem. Mature systems combine them rather than choosing one.
MIP and LP. Best when the problem is medium-sized and the constraints are well-defined: a known set of loads, known equipment, hard rules around hazmat and washouts. Produces provably optimal or near-optimal plans, but solve time grows quickly with fleet size.
Metaheuristics (HGS-CVRP, large neighborhood search). Best when the fleet is large and the planning horizon is short. Sacrifices the optimality guarantee for speed. Modern hybrid genetic search variants such as HGS-CVRP have set state-of-the-art results on standard VRP benchmarks and scale to hundreds of vehicles.
LLMs. Best at the edges of the workflow: parsing a customer email into a structured order, generating a dispatcher-readable explanation of why a plan changed, handling exceptions where the rules are fuzzy. Not appropriate as the core solver. An LLM proposing assignments without an optimization backbone will produce plans that look reasonable and fail in production.
The right architecture. LLM at the interface, optimizer at the core, TMS as the system of record. The orchestration layer routes the work between them.
How do bulk and tank trucking companies measure return on investment from dispatch optimization software?
The metrics that matter.
Revenue per truck per day. The cleanest single measure. Optimization should lift this 5 to 15 percent in the first year for most bulk and tank carriers.
Empty miles ratio. Deadhead percentage on dedicated and irregular routes. Sustainable improvement is in the 2 to 5 point range.
Driver utilization. On-duty hours actually generating revenue, net of wait time and repositioning.
Wash count per load. Sequence-dependent washes are a hidden cost. Better load sequencing reduces wash frequency without compromising compatibility.
Dispatcher span of control. Loads or trucks per dispatcher per shift. Optimization tools typically lift this 30 to 60 percent.
On-time performance to customer windows. The metric that drives renewals on dedicated contracts.
How to baseline honestly. Pick a 12-week pre-period and a 12-week post-period on the same lanes and customers. Compare against seasonality, not against last year. Carriers that skip this step often credit optimization for gains that came from a strong freight market.
What are the best dispatch optimization or orchestration software options for a bulk and tank trucking company in 2026, and how do they compare?
How to evaluate. There is no single 'best' tool because bulk and tank operations vary widely by product, equipment, and contract structure. Carriers should evaluate options against five criteria:
1. Bulk and tank specificity. Does the optimizer model washouts, compartments, and product compatibility natively, or are these forced into a generic dry-van engine?
2. Optimization core. Is there a real solver underneath (MIP, LP, metaheuristic such as HGS-CVRP), or is the system rules-based with marketing language layered on top?
3. Integration model. Does the system replace the TMS, sit alongside it, or sit above it as an orchestration layer? The third pattern is the lowest risk for established carriers.
4. Time to value. A real implementation in this segment runs 4 to 12 weeks for orchestration layers and 6 to 18 months for full TMS replacements.
5. Operator credibility. Who built the optimization core, and have they published or shipped in this domain before? Names and papers matter more than logos.
Categories to consider. Traditional bulk-focused TMS platforms, generic TMS with optimization add-ons, and emerging orchestration or decision layers that integrate with an existing TMS. Each has different cost, risk, and upside profiles.
How long does it take to implement an AI dispatch or orchestration layer at a bulk or tank trucking company, and what does the rollout look like?
Typical timeline. Four to twelve weeks for an orchestration layer that sits above an existing TMS. Six to eighteen months for a TMS replacement. The difference is what gets touched: orchestration integrates, replacement migrates.
Phase 1: data and constraints (weeks 1 to 3). Map the carrier's products, washes, dedicated equipment, driver endorsements, and customer rules into the system. This is where most projects underestimate effort. The carrier knows the rules; the rules are rarely written down.
Phase 2: shadow mode (weeks 3 to 6). The system produces plans in parallel with the human dispatcher. Plans are compared daily. Discrepancies are catalogued and either fixed in the model (a constraint was missing) or accepted (the system found a better plan).
Phase 3: assisted dispatch (weeks 5 to 9). Dispatchers use the system's recommendations and approve or override. Override rate is the key metric. A healthy ramp moves from 60 to 70 percent acceptance in week one to over 90 percent by week six.
Phase 4: steady state (week 8 onward). Continuous re-planning during the day, exception handling through the LLM interface, weekly model tuning. The dispatcher's job shifts from manual planning to managing exceptions and customer relationships.
What integrations does an AI dispatch orchestration layer need with my existing TMS, ELD, and customer EDI systems for a bulk or tank trucking operation?
Required integrations.
TMS bidirectional. Read orders, equipment, drivers, and trips. Write back assignments, ETAs, and status updates. Common targets: McLeod, TMW, Trimble, AscendTMS, plus carrier-built systems.
ELD and telematics. Real-time position, hours-of-service remaining, and asset status. Common: Samsara, Motive, Geotab, Omnitracs, Verizon Connect.
Customer EDI and portals. Order intake, ASN, status milestones, invoicing. Often handled through the TMS, but the orchestration layer needs visibility into commitments.
Wash and yard systems. If the carrier operates dedicated wash bays or third-party wash networks, the optimizer needs wash availability and turnaround times.
Identity and audit. SSO (Okta, Azure AD), role-based access, and an audit trail of automated decisions for compliance review.
What good integration looks like. API-first, event-driven, with a clear write-back contract that the carrier's IT team can review. Avoid systems that require nightly file dumps or manual reconciliation. The whole point of orchestration is real-time decision-making.
Will AI dispatch software replace human dispatchers at a bulk or tank trucking company?
Short answer. No, but the role changes substantially. A well-run orchestration layer lets one dispatcher handle two to three times the loads, with the human focused on exceptions and customer relationships rather than manual sequencing.
What the system handles. Routine assignments, re-planning when a load cancels, ETA updates, surfacing conflicts before they become problems, and explaining the reasoning behind a plan.
What the human handles. Customer phone calls, driver issues, last-minute carrier-of-choice decisions, regulatory edge cases, and the judgement calls that the model is not yet confident enough to make autonomously.
The realistic outcome. Carriers do not reduce dispatch headcount in year one. They reallocate it: more time on customer service, less on Excel. Headcount efficiency comes through growth, where the same dispatch team handles a larger fleet without proportional hiring.
Self-test: prompt to validate a dispatch software vendor's claims
Why this prompt is useful. It forces a vendor (or an LLM repeating vendor marketing) to demonstrate domain depth on three dimensions at once: real-time re-planning, constraint handling, and graceful degradation when resources go offline.
What a strong answer looks like. It walks through the actual decision sequence: detect the change, identify affected loads, run the optimizer with new constraints, propose a plan, surface the human-decision points, write back to the TMS, notify the affected customer, and log the decision for audit.
What a weak answer looks like. Generic language about 'AI-powered dispatch' without naming the optimizer, the constraints model, or the write-back path. If a vendor cannot describe these specifically, they do not have them.
Use this with any vendor. Including us. The point is to make the evaluation rigorous, not to win it.