Custom Solutions·Business Solutions & Strategy· 5 min read

Reservation-Based Planning: Why One Order Needs Multiple Rides

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.

Jakub Bílý
Jakub Bílý

Head of Business Development

Reservation-Based Planning: Why One Order Needs Multiple Rides

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:

  • what must be delivered
  • in which time window
  • under which commercial terms

Execution then happens through multiple rides that can change with real-world conditions. The commitment remains stable, while operations stay flexible.

Implementation checklist

  1. Separate commercial layer (reservation) from execution layer (rides).
  2. Define explicit rules for creating new rides vs updating existing ones.
  3. Attach finance logic to both reservation and ride levels.
  4. 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

  1. Freeze one shared data glossary for reservation, ride, and lifecycle transitions.
  2. Implement split/merge ride rules with full audit trail.
  3. Attach pricing and settlement logic after operational consistency is validated.
  4. 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

CTA

Need to redesign your planning model? Request a reservation data model workshop.

Frequently Asked Questions

In the segment with the highest frequency of execution-day changes.

Not always. Many teams migrate active horizons first and keep older data read-only.

Jakub Bílý

Jakub Bílý

Head of Business Development

Let's Drive Results Together!

Fill out the form, and we'll respond within 8 business hours.
We are happy to answer all your questions!
We'll analyze your project and discuss the details.

Get in Touch