Skip to main content
A retail last-mile network blends an in-house fleet with subcontracted vans, delivers to stores before opening hours as well as to end customers, and routes some access-restricted deliveries (lockers, secure sites) only through drivers who hold the right key.

What makes this vertical distinctive

  • Key-holder-only access windows — a locker or secure site opens early only to drivers who hold the key, with a narrower standard window for everyone else.
  • Blended subcontractor/in-house costs — subcontractors are paid a flat fee covering their first few drops plus a rate per extra stop delivered, in-house drivers a straight per-kilometre rate — one cost model, two structures.
  • Pre-opening store drops — store deliveries land in an early window before the shop opens, for chains that need it.
  • Trusted-keychain deliveries — a set of key-gated stops is kept to a single driver for the day.

Combined example

Early access for key holders

order-locker-site carries two authorizedTimeWindows: an early one (06:00-20:00) tagged resourceTags: ["key-holder"], and a narrower standard one (09:00-17:00) with no tag. Only driver-key-holder can use the early window; every other resource is restricted to the untagged one. See Restricting a window to specific resources.

Blended subcontractor/in-house costs

driver-key-holder.cost.km.costCoeff: 1.2 charges a straight per-kilometre rate. van-subcontractor-a.cost is instead priced per stop delivered, through costsByCapacity on a stopsDelivered capacity that every stop increments by 1: a flat constantCost: 80 that covers the first 3 stops (costFloor: 3), then costCoeff: 15 for each stop delivered beyond that. The two resources are priced on different structures, but both roll up into the same minimizeCosts objective for a single, comparable plan. See The cost object and Piecewise-linear cost functions.

Pre-opening store drops

order-store-1.authorizedTimeWindows is a single hard window (05:00-07:00), ahead of the store’s opening hours — an ordinary authorizedTimeWindows use, no different in kind from Multiple time windows per stop, just with one window instead of several.

Trusted-keychain deliveries

order-keychain-0 carries the tag keychain:trusted-set-1; a globalConstraints entry of type maxCumulatedCost caps the number of distinct driver-tagged resources allowed on that tag at 1 across the whole fleet, so whichever driver takes the first keychain stop is the only one who can take the rest of the set. See Constraints catalog.

Full payload

The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (workingTimeWindow, departure, arrival), the complete objectives list, and enough orders to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own.

See also

Ready to model an operation like this one? Send your first API call with your own data, or contact customer.success@kardinal.ai to walk through your specific constraints.