Skip to content

Multimodal Delivery Switching

Mode-switching process — instantiates Endpoint Fan-Out Fulfillment

Maintains a portfolio of delivery modes and moves an endpoint from one to another — home, pickup, mobile, partner, assisted, remote — when its conditions, cost, or repeated failures change which mode fits.

Multimodal Delivery Switching is the decision layer that sits above the individual delivery modes and reassigns each endpoint to the one that currently fits. It is not any single mode — not the locker, the mobile unit, or the partner — but the portfolio of them plus the logic and rhythm for moving an endpoint between them as its conditions change. Its defining move is cross-mode reassignment on a trigger: a delivery that keeps failing, an endpoint whose access changes, a cost that shifts, or a periodic review flips the endpoint from its current mode to a better-fitting one. Where a router optimises the path within a chosen mode, this process changes the mode itself.

Example

An online grocer offers four ways to receive an order — home delivery, locker pickup, curbside, and collection at a partner store — and Multimodal Delivery Switching decides who is on which, and when to change it. A household defaults to home delivery. After two failed doorstep attempts with perishables at risk, the process switches the order to the nearest locker with chilled compartments. A customer who moves into a new area with no delivery slots is switched to partner-store collection. During a heatwave, frozen orders are switched to the fastest available mode regardless of the usual default. Each endpoint sits in one mode at a time, and a running set of signals — failures, cost, access, conditions — decides when it should move.

The process's output is the right mode for each endpoint at each moment, kept current as the world around the endpoint changes.

How it works

  • Maintain the mode portfolio — the menu of available delivery modes and the eligibility rules for each — as the space the process chooses from.
  • Watch per-endpoint signals — repeated failures, cost, access changes, conditions — that indicate the current mode no longer fits.
  • Reassign on trigger or cadence — move the endpoint to the best-fitting available mode when a signal fires or a scheduled re-evaluation comes due.

The distinguishing logic is that the process operates across modes, reassigning the channel itself, rather than improving performance within a fixed one.

Tuning parameters

  • Switch triggers — which conditions flip a mode (a failure count, a cost threshold, an access change). Sensitive triggers adapt fast but fire often.
  • Hysteresis — how much a signal must persist before a switch, and how much before switching back. More damping prevents thrash; less makes the process more responsive.[1]
  • Re-evaluation cadence — how often endpoints are reviewed for a better mode even absent a trigger, trading freshness against churn.
  • Portfolio breadth — how many modes are offered. Wider fits more endpoint situations but multiplies operational complexity.
  • Default mode — where a new endpoint starts before any signal is known.

When it helps, and when it misleads

Its strength is heterogeneous, changing endpoints: it matches each to the mode that fits now and rescues failing deliveries by changing the channel instead of retrying a broken one.

Its failure modes start with dependency — it can only pick from modes that actually exist, so its value is capped by whether the hubs, units, and partners have been built. Switching itself has friction and cost, and un-damped triggers cause thrash: an endpoint flip-flopping between modes, confusing the recipient and churning the operation. The classic misuse is switching toward whatever is cheapest for the operator rather than what fits the endpoint, dressing a cost cut as a service decision. The discipline that keeps it honest is to trigger on endpoint fit, not operator cost alone, and to damp switches with hysteresis so the process adapts without oscillating.

How it implements the components

  • service_mode_portfolio — it owns the menu of available modes and their eligibility rules; the portfolio is the space it selects from.
  • adaptation_cadence — it sets the rhythm and triggers by which endpoints are re-evaluated and moved between modes as conditions change.

It does not build the modes it selects among — the fixed node (Micro-Hub or Pickup-Point Network), the mobile reach (Mobile Service Unit), the delegated completion (Local Partner or Agent Network) — nor does it optimise the route within a chosen mode, which is Dynamic Route Optimization.

References

[1] Hysteresis — building in a lag so a system does not flip state the instant a signal crosses a line, as a thermostat waits for a temperature band rather than switching at a single point. Applied to mode switching, it is what stops an endpoint from oscillating between two modes on noisy signals. ↩