Optimise the network
around the promise.
Ordinal is a logistics decision intelligence company. Every promise changes the network, so we evaluate the consequence before the commitment is made.
Today that means delivery-window decisioning and network optimisation: customer preferences evaluated against capacity, commitments and constraints. Works alongside your existing logistics stack.
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.
Customer preference and operational efficiency.
Every promise changes the network.
Ordinal evaluates new delivery decisions against existing commitments, fleet availability and operational constraints, so each recommendation reflects the network as it stands now, not an isolated shipment.
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 been made.
Becomes part of the network state.
Evaluated against commitment 01.
Evaluated against everything promised so far.
Reflects the network as it stands now.
Optimise the commitment
before optimising the route.
Five stages, one decision.
From operational data to a delivery commitment the network can actually serve, with every commitment shaping what can be promised next.
- Understand the network
Ordinal receives operational demand, fleet and delivery-preference data: orders, delivery coordinates and dates, preferred windows, flexibility levels, parcel volume, service time, drivers, vehicles, capacity, shifts and depots.
- Orders
- Delivery coordinates
- Delivery dates
- Preferred windows
- Flexibility levels
- Parcel volume
- Service time
- Drivers and vehicles
- Vehicle capacity
- Shifts
- Depot locations
- Existing commitments
- Model the constraints
The engine models capacity, shifts, service time, geography, existing commitments and customer preferences together, rather than treating a requested delivery time as an isolated preference.
- Capacity
- Shifts
- Service time
- Geography
- Existing commitments
- Customer preferences
- Evaluate the alternatives
For each eligible date and time window, Ordinal evaluates how the delivery could fit into the current network and whether it is operationally feasible.
- Incremental distance
- 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 viable options according to their operational consequences. The customer or operator still chooses. Ordinal changes which choices are operationally attractive, not whether there is a choice.
Delivery options- ★ THU 13:00–15:00
- THU 15:00–17:00
- FRI 09:00–11:00
- Commit
Once a delivery window is selected, the commitment becomes part of the network state considered by subsequent decisions. The committed network is then solved as a full routing problem with time windows.
- Date + window
- Hard operational commitment
Committed orders
↓
VRPTW optimisation
↓
Routes and dispatch
The delivery can move when doing so materially improves the network.
The requested window is prioritised, but alternatives may be considered when operationally beneficial.
The specified delivery constraint must be respected.
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
Model the opportunity. Then decide in operation.
One workflow studies a network from supplied data. The other evaluates individual delivery-window decisions against the live network state.
Ordinal analyses historical or supplied network data and compares your current delivery network against an Ordinal-optimised scenario. Analyses run independently in the background and the results remain available once complete.
What could change if customer delivery preferences were part of network planning?
- Distance
- Driver hours
- Route utilisation
- Vehicle-days
- Orders served
- Unassigned orders
- Delivery-window performance
- Fleet utilisation
When a shipment needs a delivery-window decision, the engine evaluates feasible alternatives against the network as it currently stands and returns ranked delivery-window options.
Which delivery windows can this network honour without adding avoidable cost?
- Available fleet
- Vehicle capacity
- Driver shifts
- Existing commitments
- Delivery date
- Window constraints
- Parcel volume
- Service time
- Incremental distance
- Incremental driver time
- Routing implications
- Operational feasibility
- Shipment
- Operational context
- Feasibility evaluation
- Candidate windows
- Ranked recommendation
- Selection
- Delivery commitment
Not another route planner.
Decision intelligence.
Routing answers how to serve the orders you already accepted. Ordinal helps decide which delivery promises should enter the network at all.
Logistics decisions should account for when customers actually want their orders, not only how to move them efficiently.
A delivery promise is evaluated against the wider network before it is offered.
Recommendations account for real constraints: capacity, shifts, service time and existing commitments.
Ordinal evaluates what adding or changing a commitment does to the network.
A decision intelligence layer, not a forced replacement for your logistics stack.
Built around the realities of Saudi delivery operations: growing volumes, dense urban networks and rising customer expectations.
Production infrastructure.
Pilot-stage deployment.
Ordinal is built for controlled pilot deployments. We are now working with operators on network analysis and pilot opportunities.
Delivery commitments and network state persist across analyses and operational decisions.
Network analyses run independently in the background and remain available when complete.
Customer operational environments are logically isolated from one another.
A secured production API with monitoring, backup and recovery mechanisms in place.
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.
Analyse Your Network →- 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
Start with what you have.
The exact dataset can be discussed with Ordinal before an analysis begins. We work with the operational data you already hold, anonymised where you prefer.
- Shipment or order identifier
- Delivery location
- Delivery date
- Preferred delivery window, where available
- Parcel size or volume
- Estimated service time
- Driver or vehicle identifier
- Vehicle capacity
- Shift availability
- Depot location
- Historical routes
- Actual delivery times
- Failed delivery events
No integration.
No disruption.
Before integration,
there is analysis.
Supplied operational data
is enough to start.
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.
Analyse Your Network →- 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.
Orders with delivery locations, dates, preferred windows where they exist, parcel volume and service time, plus fleet details: vehicles, capacity, shifts and depots. Anonymised is fine, and the exact dataset is agreed before we begin.
Not to start. The initial analysis runs on supplied operational data with no connection to your production systems. A later live deployment is scoped with you.
No. Ordinal sits ahead of them, deciding which delivery windows are worth offering. It does not dispatch vehicles. Existing planning and execution systems stay in place.
Ordinal estimates the marginal operational impact of each eligible date and window against the current network: incremental distance, driver time, vehicle requirements, capacity and feasibility. The full routing problem is solved after commitment, not for every option shown.
Delivery preferences are modelled at three levels. Flexible deliveries can move when it materially improves the network, preferred windows are prioritised, and hard constraints must be respected.
Ordinal runs on production infrastructure with persistent network state, background analysis and a secured API. Commercially it remains in controlled pilot and early deployment.
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.
Days, not quarters, once the 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.