The problem it solves
Every depot has a veteran courier who knows the block. She knows that 14 Rue Saint-Paul’s loading dock only fits a van before 09:30, that the pharmacy on the corner of Avenue Charles accepts neighbour drops, that the residential street behind the school goes one-way after 15:00, and that three of the nineteen addresses on today’s manifest are actually the same building with different intercom codes. None of this is in the address database. None of it is in the TMS. When she takes a week off, her route collapses — stop sequence flips, parking eats 40 minutes, and the last eleven parcels miss their window.
Classical VRP solvers optimise distance. They do not optimise for the building she can walk to in 90 seconds, the parking spot that fits a 3.5-tonne, or the seven parcels that can be handed over in a single elevator ride. The tribal knowledge walks out of the depot every shift — and the route cost walks out with it. Multiply that leak across a network of 60 depots, 3,000 drivers, and 12 million parcels a year, and the missed-window rate is not a quality problem — it is an eight-figure cost line hiding in plain sight.
What it is
Micro-Cluster Route Optimization is Shipsy’s routing mechanism that treats a delivery route not as a sequence of GPS points but as a sequence of micro-clusters — walkable groups of stops tied to a single parking action, a single building, or a single operational context. It sits underneath the dispatch stack as a dedicated solver, not as a module inside a generic TMS.
What makes it different: the solver does not generate clusters from coordinates alone. It learns them from driver GPS breadcrumbs, parking behaviour, dwell time, and corrections fed back through the driver app. The output is a route that any new driver can execute the way a 20-year veteran would — because the 20 years are baked into the clusters themselves. A new-hire driver with two weeks of tenure runs the same route at 92% of veteran productivity on day one, not day three-hundred.
Under the hood it runs a column-generation optimiser over a driver-validated cluster graph, scored against SLA windows, vehicle constraints, and depot-level service promises. It plugs directly into Astra, Shipsy’s planning agent, and feeds live sequence updates to the driver app. The mechanism is vertical-agnostic — it runs today across parcel, postal, B2B express, quick-commerce, and returnable-asset operations — but it is depot-specific by design. Every depot has its own cluster graph. The knowledge is local because operations are local.
Core capabilities
| Capability | What it does |
|---|---|
| Driver-validated clustering | Mines six to eighteen months of GPS breadcrumbs and ePOD timestamps to infer which stops are “one parking action.” Drivers confirm or split clusters in the app; confirmations rewrite the clustering model weekly. |
| Parking-spot intelligence | Every cluster carries a preferred parking polygon — not a pin — with vehicle-class compatibility (van, 3.5T, cargo bike). Drivers see the exact entry vector and reverse-approach angle on the map. |
| Walking-pattern recognition | Detects which stops within a cluster are walked in what order, including elevator-aware multi-floor sequencing in vertical buildings. Walking time is a first-class cost in the solver, not a Haversine approximation. |
| Column-generation solver | A decomposition-based optimiser that generates candidate routes as columns and prices them against SLA, cost, and driver-shift constraints. Handles thousands of stops per depot in single-digit minutes. |
| Depot-aware service promises | Each micro-cluster inherits the depot’s service commitments — 09:00-12:00 window, signature required, reefer at 4°C — so the route never violates the promise it was built from. |
| Dynamic re-clustering | A cancelled stop, a failed delivery, or a new priority pickup triggers re-clustering on the in-flight route within 30 seconds. The driver sees only the delta, not a rebuilt manifest. |
| Tribal-knowledge ingestion | A one-time import from dispatcher spreadsheets, rider notes, and historical notes captures informal rules (“never park on Rue Mercier before 11”). The solver treats these as soft constraints. |
| Cluster-level performance scoring | Every cluster is scored on adherence — if a cluster consistently misses its promised window, it is flagged for re-learning. Underperforming clusters get escalated to the depot manager weekly. |
| Multi-modal awareness | Clusters can span a van drop + cargo-bike handoff in dense centres. The solver models the handoff as a known transfer point, not a two-independent-route problem. |
| Returns and reverse-logistics co-optimisation | Pickups (returns, empties, RPM crates) are clustered alongside deliveries — not bolted on as a second route. A single cluster can carry a drop and a pickup from the same building. |
| Simulator for what-if planning | Depot managers model “if we add two more riders on Tuesdays” or “if we close the downtown parking zone to vans” before the change touches production. |
| Closed-loop learning | Every completed route, every driver correction, every parking violation ticket feeds back into the cluster graph. The system gets more local every week it runs. |
How it works
The architecture separates the cluster graph (a long-lived, slowly-evolving asset) from the solver (which runs on every plan) from the executor (the driver app that acts on the plan). The cluster graph is the memory — it is where tribal knowledge lives. The solver is the intelligence — it composes routes from clusters under the day’s constraints. The executor is the loop-closer — it validates what actually happened and feeds corrections back.
The workflow runs overnight for next-day routes and near-real-time for in-shift replanning. A typical evening plan for a depot of 120 drivers and 14,000 parcels completes in under four minutes. Mid-shift re-clustering — triggered by a cancellation, a traffic event, or a priority pickup — returns in under 30 seconds and pushes only the affected clusters to the affected driver’s app. The solver is stateful across the day: it remembers what has been committed, what has been executed, and what was rejected, and it never invalidates work already done.
The cluster graph is the critical asset. It is built once per depot from historical breadcrumbs — typically six to eighteen months of data — and then evolves continuously. Every execution event is a training signal. A driver who splits a cluster in the app because “the elevator is broken this week” creates a short-lived soft constraint. A driver who merges two clusters because “we always walk from here to there” creates a durable preference. Over 90 days, a new depot’s cluster graph converges to match the veteran dispatcher’s mental map — and then keeps improving.
Proven outcomes
| Customer type & scale | Outcome |
|---|---|
| Leading Western European parcel operator, 50%+ national market share, 8M+ shipments/year | Delivery-window adherence from 30% to 90%+; $5M+/year in avoided failed deliveries and overtime; 22% reduction in per-parcel cost-to-serve |
| National postal operator powering 90% of mail to 200+ countries | First-attempt delivery rate 90%+ on hard-to-address consignments; cluster graph absorbed the knowledge of 400+ veteran couriers |
| Southeast Asian air-logistics network, 164 hubs across APAC | 20% driver productivity gain on ground legs; 75%+ reduction in planning time across middle-mile hubs |
| Premium Indian B2B express network, 49 cities, 3,500+ pincodes | First-attempt delivery from ~75% to 90%+; 16-18% freight-cost savings on the linked trunk-plus-last-mile operation |
Integrations
- TMS and order sources: Shipsy TMS, SAP TM, Oracle OTM, Salesforce Field Service, Shopify, Magento
- Address and geocoding: Shipsy AI Address Intelligence (native), Google Maps, HERE, OpenStreetMap polygons
- Telematics: Wialon, Wheelseye, Samsara, Geotab, MiX Telematics — raw CAN + GPS streams ingested for breadcrumb mining
- Driver apps: Shipsy native driver app (iOS + Android), or embedded SDK into 3PL-branded apps
- Dispatch and exceptions: Native handoff to Astra for allocation, Clara for delivery-window comms, Atlas for supervisor override
- Data platforms: Snowflake, Databricks, BigQuery for breadcrumb archive + model training; Kafka / Pub/Sub for live telemetry
Deployment
Phase 1 — Discovery (weeks 1-2). Depot selection, breadcrumb availability audit, tribal-knowledge interviews with two to three veteran dispatchers per depot, baseline KPIs captured (current FADR, window adherence, planning time, overtime hours).
Phase 2 — Configuration (weeks 3-5). Initial cluster graph built from six months of historical breadcrumbs. Parking polygons imported or drawn. SLA and vehicle constraints loaded. Shadow-mode runs against the existing planner produce side-by-side comparisons.
Phase 3 — Pilot (weeks 5-8). One depot, one rider cohort. Daily plans generated by Micro-Cluster, executed by drivers, corrections captured through the app. Weekly retro with dispatchers to tune soft constraints. Target exit criteria: 10%+ window-adherence lift and dispatcher NPS > 7.
Phase 4 — Scale (weeks 8-16). Expansion to all depots, region by region. Cluster graph per depot, shared learning for cross-depot patterns. Governance: a monthly cluster-health review owned by the regional operations lead; a quarterly solver tuning review owned by the Shipsy customer team. Most enterprises reach full-scale by week 14, with measurable financial impact by week 10.
Security & compliance
- SOC 2 Type II, ISO 27001, GDPR-compliant data handling
- Driver breadcrumb data processed on regional infrastructure (EU data stays in the EU)
- Full audit trail on every plan produced: solver version, constraints applied, cluster-graph snapshot
- Three-tier confidence scoring on inferred clusters (high / medium / low) — low-confidence clusters surfaced for driver confirmation before they become production routes
- Human-in-the-loop for any solver decision that violates a soft constraint or removes a driver-confirmed cluster
- No PII persists in the cluster graph — only anonymised stop IDs and geometric features
Case study callouts
Leading Western European parcel operator · 50%+ market share
Window adherence moved from 30% to 90%+ after rolling Micro-Cluster across the national network. Over $5M/year in avoided failed-delivery and overtime cost, with driver-rated route quality up 2.4 points on a 10-point scale. The cluster graph now encodes the walking patterns of the operator’s top 400 veteran couriers.
National postal operator · 90% of mail to 200+ countries
Paired Micro-Cluster with Address Intelligence to handle a route network where 40% of addresses were informal or ambiguous. First-attempt delivery hit 90%+ on hard-to-address consignments, and the planning team shifted from manual sequencing to exception-only review.
Premium Indian B2B express network · 49 cities
Greenfield deployment where the cluster graph was built from scratch in 90 days. First-attempt delivery moved from ~75% to 90%+; trunk-plus-last-mile freight cost dropped 16-18% by co-optimising middle-mile consolidation with last-mile clustering.