Network control.
Customer choice.
One decision.
Ordinal evaluates the operational impact of delivery dates and time windows before they become commitments.
Offer meaningful customer choice while protecting network efficiency.
Today, someone has to compromise.
Either the operator keeps control of the network and the customer loses timing control, or the customer chooses and the network inherits the consequence.
- ·Order
- ↓Route built
- ↓Customer contacted
- ↓Delivery when operationally convenient
The operator retains flexibility, but the customer has little control over when the delivery actually arrives.
- ·Order
- ↓Customer chooses a date / window
- ↓Promise becomes fixed
- ↓Network absorbs the constraint
The customer gets more choice, but the network inherits commitments before their operational impact is fully understood.
- ·Order
- ↓Network-aware choices
- ↓Customer selects
- ↓Hard commitment
- ↓Optimised fulfilment
Ordinal makes customer choice and network efficiency part of the same decision.
The promise is part of the network.
Every delivery promise changes the network. A customer choosing Tuesday at 11:00 instead of Wednesday at 15:00 can change route density, driver time, capacity utilisation and whether another vehicle is required.
Most systems only optimise after that decision has already been made. Ordinal evaluates the consequence first.
Optimise the commitment
before optimising the route.
How Ordinal works.
Five stages between an incoming order and a delivery the network can actually serve.
- Read the network
Before anything is offered, Ordinal reads the current state of the operation.
- Committed orders
- Delivery geography
- Current route state
- Fleet availability
- Vehicle capacity
- Driver shifts
- Delivery windows
- Existing network pressure
- Evaluate delivery options
For each eligible date × time window, Ordinal estimates how that order could fit into the current network. The current engine evaluates marginal operational impact using cheapest feasible insertion into existing committed routes.
- Incremental kilometres
- Incremental driver time
- Waiting
- Additional vehicle requirements
- Time-window feasibility
- Capacity feasibility
- Nearby order density
- Slot capacity pressure
- Daily network pressure
- Recommend
Ordinal ranks the feasible options. The customer still chooses. Ordinal changes which choices are operationally attractive, not whether the customer has a choice.
Delivery options- ★ THU 13:00–15:00
- THU 15:00–17:00
- FRI 09:00–11:00
- Commit
Once the customer selects an option, the date and window become a hard operational commitment. Ordinal no longer treats the order as freely movable.
- Date + window
- Hard operational commitment
- Fulfil
The committed network is then solved using a full Vehicle Routing Problem with Time Windows model.
Committed orders
↓
VRPTW optimisation
↓
Routes and dispatch
Estimate before choice.
Optimise after commitment.
Same orders. Same fleet.
Different decision logic.
Both worlds face the same demand, the same geography, the same fleet and the same fulfilment solver. Only the way delivery commitments are formed differs.
- Same orders
- Same geography
- Same fleet
- Same delivery-choice universe
- No network-aware recommendation
↓
Routing
↓
Compare
- Same orders
- Same geography
- Same fleet
- Same fulfilment solver
- Delivery options evaluated against network impact
↓
Routing
↓
Compare
- Kilometres
- Driver-hours
- Routes
- Vehicle-days
- Vehicles used
- Orders served
- Unassigned orders
- DRIVER 01
- DRIVER 02
- DRIVER 03
- DRIVER 04
Same orders. Same fleet.
Different constraints. Different routes.
What does one more delivery do to the network?
Ordinal does not recommend the emptiest delivery slot. An empty slot can be expensive if serving it creates an isolated trip, additional waiting or another vehicle.
Where can this order enter the network at the lowest marginal operational cost?
- +8.4 km
- +31 min
- +1 vehicle
- +1.2 km
- +7 min
- +0 vehicles
- +14.1 km
- +68 min
- +1 vehicle
A delivery window should be a promise.
Some delivery models provide almost no timing control to the recipient. Others ask customers to select a delivery window but struggle to consistently fulfil those preferences once the route is built. Ordinal's architecture is designed to make the promise operationally informed before it is offered.
"We'll contact you when the driver is nearby."
↓
Network tries to accommodate it later.
"Choose from delivery options that already fit the network."
↓
Selection becomes a commitment.
↓
Network is optimised around it.
Choice that the network
can actually support.
Does Ordinal actually cause the improvement?
Each simulated customer has an underlying uninfluenced delivery choice. In Control, the customer selects that choice. In Ordinal, the customer either follows the recommendation or makes the same uninfluenced choice they would have made in Control.
At 0% influence, Control and Ordinal should converge. As influence increases, a genuine mechanism should strengthen the network effect.
- 0%0%
- 20%11.1%
- 40%15.1%
- 60%23.3%
- 80%39.6%
- 100%52.0%
These results demonstrate the behaviour of the current model under controlled synthetic conditions. They are not claims of expected savings in live commercial operations.
A decision layer between commerce and fulfilment.
Ordinal is designed to complement an operator's existing logistics stack rather than replace it.
Its primary role is upstream of routing: helping determine which delivery promises should enter the network in the first place.
- Read network
- Evaluate options
- Recommend
- Capture commitment
Prove it before you deploy it.
Ordinal starts with your historical network, not a software implementation.
See what Ordinal could do to your network.
Provide anonymised historical delivery data. We reconstruct the network, replay it with network-aware delivery options and compare the result against the control world.
Request a Free Analysis →- Historical data
- Control replay
- Ordinal replay
- Comparison report
Put the model into operation.
Once the analysis shows a meaningful opportunity, run Ordinal against a defined network or operating period at a discounted pilot rate, starting in shadow mode where appropriate.
Discuss a Pilot →- Defined network
- Agreed KPIs
- Operational testing
- Performance validation
Make optimisation part of the operation.
After the pilot validates the economics and operational performance, move to an annual Ordinal contract.
- Ongoing optimisation
- Operational use
- Performance monitoring
- Network expansion
We show you the opportunity.
We prove it in operation.
We make it part of the operation.
Start with your network.
Not an integration.
Give us a sample of your historical delivery data. We reconstruct the network, replay it under control and Ordinal decision logic, and return a clear comparison.
- Kilometres
- Driver-hours
- Vehicle utilisation
- Routes
- Vehicle-days
- Unassigned orders
What do we need?
Exact requirements depend on your network. We'll work with the data you already have.
- Order coordinates
- Delivery date
- Delivery window where it exists
- Service time
- Parcel volume
- Vehicle capacity
- Driver shifts
- Depot locations
- Vehicle availability
- Historical routes
- Actual delivery times
- Failed delivery events
Before integration,
No production integration
Historical data is enough
Built for delivery networks where the promise and the network cannot be decided separately.
Operators managing time-window commitments across a shared fleet.
- Last-mile delivery networksHigh order density, tight time-window commitments.
- Retail delivery operationsStore and warehouse fulfilment with promised slots.
- E-commerce fulfilment networksDelivery promises made before the route exists.
- Fleet operatorsOwned or contracted capacity planned day by day.
Start with your network.
Ordinal does not need to be deployed into checkout on day one. The first step is to evaluate the system against historical delivery operations.
Request a Free Network Analysis →- Order coordinates
- Delivery dates / windows
- Depot locations
- Vehicle capacities
- Driver shifts
- Service times
- Historical routes where available
- Reconstruct the historical network
- Evaluate how Ordinal would have shaped delivery commitments
- Explicit customer-response assumptions
- Kilometres
- Driver-hours
- Vehicle utilisation
- Routes
- Feasibility
- Estimated operating impact
From experiment to infrastructure.
When the pilot proves the operational and economic case, Ordinal moves from an experiment into the operator's ongoing optimisation process.
- Additional depots
- Additional regions
- Additional delivery volume
- Additional optimisation use cases
Yes. The first stage is a one-off analysis and report at no cost. It does not include access to the Ordinal system; that begins with a pilot.
A historical delivery set: order locations, time preferences where they exist, depot locations, fleet composition and service times. Anonymised is fine.
No. The initial analysis runs offline on historical data. Integration is only relevant once you decide to operate the layer.
No. It sits ahead of it, deciding which delivery windows are worth offering. Existing planning and execution systems stay in place.
At the offer stage Ordinal estimates the marginal operational impact of each eligible date and window using cheapest feasible insertion into existing committed routes, supported by capacity, feasibility and network-pressure signals. The full routing problem is solved after commitment, not for every checkout option.
No. The current figures come from a development simulation on synthetic demand under a counterfactual design. They show how the mechanism behaves, not expected commercial savings.
Yes. A fixed window is modelled as a hard constraint. Flexible preferences are modelled as candidates with a cost of deviation.
Days, not quarters, once the historical data is available.
Request a free network analysis.
Give Ordinal a representative historical delivery set. See what changes when delivery demand becomes a decision variable.