Many logistics teams still run with a one order = one ride model. It looks simple, but it breaks quickly when you face overnight operations, split loading windows, or 2-3 driver/equipment swaps during execution.
Article series: Dispatch → Cash Flow
Definitions
Definition: Reservation lifecycle
A set of states and transitions that define what “done” means over time and when an item becomes an exception. A practical minimal set:
Draft → Confirmed → Planned → In-Execution → Completed → Invoice-ready → Settled
Each transition has entry conditions (mandatory data / document / approval). If conditions are not met by the deadline, the item moves to Overdue/Exception .
Why the old model fails
An order is often a commercial commitment, not one physical ride. If the system cannot represent "reservation -> multiple rides," dispatchers start patching reality outside the core workflow and historical data becomes unreliable.
Typical impact:
inaccurate capacity planning, often with 10-20% variance
difficult performance split across drivers
weak change traceability
poor inputs for invoicing and reporting
A practical target model
Use reservation as the primary business entity. It should define:
Execution then happens through multiple rides that can change with real-world conditions. The commitment remains stable, while operations stay flexible.
Implementation checklist
Separate commercial layer (reservation) from execution layer (rides).
Define explicit rules for creating new rides vs updating existing ones.
Attach finance logic to both reservation and ride levels.
Track change versions to keep historical data auditable.
Where custom development helps
This is where many standard TMS setups hit their limits. Custom development is often needed for:
reservation/ride domain model design
migration from legacy structure without history loss
consistent integration with finance and settlement flows
Operational takeaway
If your commercial commitment is tied to one mutable ride record, dispatch teams will keep improvising. A reservation-based model reduces that pressure and improves planning confidence.
Implementation pitfalls
rushing legacy order mapping without strict versioning rules
unclear boundary between creating a new ride and editing an existing one
missing link between dispatch changes and finance impact
underestimating enablement of dispatch leads who own exception decisions
In environments running 200-500 rides per day, these gaps usually surface in the first 2-3 weeks. A pre-defined stabilization mode with daily controls is useful.
Recommended rollout sequence
Freeze one shared data glossary for reservation, ride, and lifecycle transitions.
Implement split/merge ride rules with full audit trail.
Attach pricing and settlement logic after operational consistency is validated.
Migrate historical data in waves, for example by week or region.
Practical scenarios
Scenario A, overnight transfer between hubs
One reservation keeps the commercial commitment, while the system creates two linked rides. Each ride has a separate driver, timing, and load responsibility. Performance split stays clean without manual reconstruction.
Scenario B, loading window change on execution day
The original ride is not overwritten without trace. A new version or new ride is created based on rules. Reporting and finance can see why the change happened.
Decision criteria
share of reservations requiring two or more rides by service segment
planned-vs-actual capacity accuracy after rollout
number of changes without audit trace (target zero)
invoicing preparation time for multi-ride reservations
Recommended next reads
Need to redesign your planning model? Request a reservation data model workshop.