Route Optimization Software for Fleet Dispatch

Shyftbase route optimization builds each day's delivery routes against live fleet capacity, then returns a stop sequence and an ETA for every stop. The routing engine routes by zone, can plan a portion of the day's volume, sequences combined delivery-and-install jobs, and adjusts routes as conditions change. Load planning and per-client routing rules are included.

Route optimization in Shyftbase is the planning half of the transport management system. It takes the day's orders, the vehicles and crews actually available, and the rules a client or a zone imposes, and returns a stop sequence per vehicle with an ETA for each stop. What separates it from a router bolted onto a map is where the plan lands: the modules share one data model, so the sequence dispatch releases is the same shipment record the warehouse picks against and the billing module prices. For the plain definition of the term rather than the product, see the glossary entry for route optimization.

What the plan is built from

Capacity is a live input here, not a vehicle profile somebody filled in last year. Routes are built against real-time fleet capacity, across fleet types with different capacities and requirements. A truck with a tail lift, a two-person crew vehicle and a contracted carrier's van each take a different subset of the day's stops, and a plan that does not know which is which produces work nobody can run. Load planning sits in the same step: automated volume calculations fill each vehicle against the cube it can actually carry, not a pallet count typed into a field last quarter.

The second half of the setup is the shape of the day rather than the size of the truck. The routing engine routes by zone, so a network planned by service days, postal codes and geographic areas produces runs that respect those boundaries instead of cutting across them. It can also be limited to a portion of the volume, which is how most rollouts should start: plan one region, or one shift, or the appointment work only, and leave the rest of the book on the dispatcher's existing process until the plan has earned trust. Client rules ride on top of both — routes can be optimized per client, so an account with a fixed receiving window or a nominated crew keeps them without being pulled out of the run by hand every morning.

Routing inside the TMS, not beside it

A plan is worth what the systems around it do with it. Because routing is a module rather than a separate application, the sequence it produces stays attached to the shipment record: dispatch releases it to drivers and carriers through the communication tools in the same module, the ETA goes out from that record, and what was actually delivered is what the automated billing module prices. There is no export step between the plan and the invoice.

The alternative is what most operations run today. A standalone router learns about the shipment twice — once from the order system in the morning, and once from whoever fixes the day after it changes — and the second telling is where the two records begin to disagree. The router holds the sequence re-planned at 10:40, the ERP holds the one released at 05:30, and the invoice gets built from whichever the billing clerk trusts. That disagreement does not surface as a routing problem. It surfaces as a credit note three weeks later, argued over a proof of delivery that matches neither plan.

Where the orders arrive from is the other half of the same question. Shyftbase connects to the ERP, accounting and warehouse systems an operation already runs — the connectors are listed on the integrations hub — and routing plans from the orders the platform already holds, not from a spreadsheet exported at six in the morning.

Delivery and install on one appointment

Two crews and one appointment is the case a generic route planner handles worst, and the case this module was built around. Delivery and installation are scheduled as one job rather than two: time-locked scheduling holds the pair together, and the routing engine sequences both crews so the delivery vehicle arrives with buffer time while the installation crew is still en route. Get that order wrong and someone waits: an install crew in a hallway with no appliance, or a delivery crew leaving a boxed unit for the second visit the pairing was meant to avoid.

Installation work is modelled per job, not as a flat allowance. The system holds the specific tools, skills and time each installation needs, and installation requirements can differ by product, by service level and by location. Both legs are tracked while they run, with estimated completion times and status updates, and a record of the service activity is kept afterwards, which lets an operator answer the "who did what, and when" question on a job that went wrong.

This is the shape of big-and-bulky delivery: large, heavy items that need an installer at the other end, where a failed appointment costs two crews and a second vehicle trip rather than a courier's re-attempt. How large that buffer should be is an operational decision to settle in a demo against your own install durations, not a figure to take from a vendor page.

The calendar, the reschedule and the day that changes

A route plan survives contact with the day for about as long as it takes the first customer to answer their phone. Schedules in Shyftbase therefore sit throughout the system rather than only in dispatch: a store can move an appointment, and so can the end customer, and rescheduling respects the lead times you set rather than accepting anything the calendar can display.

The constraint check is the part that matters. A reschedule is tested against capacity limits, service area restrictions and time-window rules before it is accepted, so the calendar cannot book work the fleet has no way to serve. A calendar that accepts everything does not remove that problem; it moves it to the morning of the delivery, where it costs a truck and a crew instead of a phone call. Adjustable service days, time windows and scheduling rules are what those checks are drawn from, which is why the calendar and the routing engine are configured as one thing.

Routes then adjust dynamically as conditions change, rather than being planned once at 05:30 and defended all day. What a re-plan should treat as immovable — the stops already delivered, the freight physically loaded on a given vehicle, the ETA a customer has already been sent — is the sharpest question to put to any routing vendor, this one included, and it is the second item in the list below.

How to evaluate a routing module

Five questions separate a router that gets used from one switched off in the third month — worth asking here and of every alternative on your list. The routing software comparison puts the same questions to the named products, using what each vendor publishes about itself.

1. Which constraints are hard, and which are only preferences? A system that treats a receiving window as a preference produces a sequence that looks right on the map and fails at the dock. Ask which constraint types are refused outright and which are traded off against distance.
2. What does a re-plan hold fixed? A re-plan that moves a stop between vehicles when the freight is already loaded emits a sequence nobody can execute. The dispatcher overrides it twice, then stops looking at it.
3. Where do orders arrive from, and where does the finished plan land? If the answer is a file in both directions, you are buying a second system of record and the reconciliation that comes with it.
4. Who is told when an ETA changes, and how? An ETA that moves and is never re-sent is worth less than none, because the customer is planning against the first one. Real-time track and trace is the visible half of it.
5. What happens to a stop that cannot be served today? Whether it rolls, splits, alerts or silently disappears is a workflow decision, and the one most demos skip.

Then ask for a plan on your own week. A demo built on the vendor's sample data proves the software runs; a plan built from one real week of your orders, compared stop by stop against what your dispatcher produced for the same week, is the only test that shows whether the sequence is better and whether your constraints were understood. Judge it on what the operation is already judged by — transportation cost, and on time in full (OTIF) — rather than on a percentage from a vendor page. Do it before the pricing conversation, not after.

What this does not do

So here is where this page stops.

Federal driving limits are not documented as a solver constraint. The rule itself is not in doubt: the limit is 11 hours of driving, sitting inside a 14-hour on-duty window^[hos]. Whether the routing engine treats those limits as hard constraints when it packs a day is not something the published product material states, so treat it as a demo question rather than an assumption.

No measured ETA accuracy. The module returns an ETA for every stop. What does not exist yet is an accuracy figure behind it — a share of deliveries landing inside the promised window, on a named data set, with a date. Until that number is published, read "accurate ETAs" as a description of the output rather than a service level.

No published ceilings. Stops per route, routes per optimization run and typical solve time are not stated here. If you plan several hundred stops a night, ask for those numbers against a book the size of your own.

Single-drop line-haul has no sequence to build. One pickup, one delivery, no ordering decision: the gain in trunking is load building and backhaul matching, which is mid-mile work rather than routing.

It cannot fix a sequence somebody else owns. When each receiving site names its own slot and those slots land at opposite ends of the day, the order of the route was decided outside your building before anyone opened the planner. A solver can price what that costs you; it cannot move it.

Service times and site constraints are inputs, not outputs. A plan built on eight minutes at a stop that really takes twenty-five is wrong before the first delivery. Shyftbase AI estimates service time from your own history, which helps; it does not remove the work of getting access restrictions, vehicle-to-site fit and crew requirements right first.