Shipsy’s territory design engine draws delivery territories, balances driver workload across them, and reshapes them continuously as demand patterns shift — turning what is usually a once-a-year planner exercise into a living, data-driven decision. Enterprises that move from static territories to Shipsy’s balanced territories typically see 15–20% productivity lift and dramatically lower overtime variance across drivers.

Why we built this

In most networks, territories are drawn once — historically, by a dispatcher with a paper map — and then rarely revisited. Demand shifts but the territory boundaries don’t. The consequences are predictable: some drivers work 10 hours while others finish by noon, some territories consistently miss SLA while adjacent ones consistently beat it, and the dispatcher absorbs the imbalance every day through manual task-swaps.

We built the territory design engine so territory boundaries become an output of the optimization, not an input. The engine treats territories as the boundary condition for daily planning — draw them well, and the daily plan is dramatically easier.

How it works

The engine runs three passes:

Pass 1 — Demand surface estimation. For each geographic cell (typically 200m grid), the engine estimates expected daily stops, expected service time per stop, expected SLA mix (standard vs express vs slotted), and expected spatial density. The estimate uses rolling 28-day history plus seasonality decomposition — so a cell near a university that spikes in September is treated differently than a steady-state residential cell.

Pass 2 — Territory construction (constrained clustering). Cells are clustered into territories using a constrained clustering algorithm: contiguous cells only, roughly equal expected workload per territory (weighted by service-time estimates, not just stop counts), and respect for physical boundaries (rivers, highways, pincode/zip lines where they matter). The engine produces N territories sized to match the available driver count, with an explicit balance-error metric and a compactness metric per territory.

Pass 3 — Driver-to-territory allocation. Drivers are allocated to territories based on familiarity (drivers run 10–20% faster on familiar territory), skill fit (some territories require special handling — hills, tight streets, elevator-only buildings), and fairness (rotation policies so no driver is stuck on the hardest territory forever). Allocations are long-lived — typically 4–12 weeks — to preserve familiarity.

Continuous reshaping. The engine monitors territory health indicators weekly: average overtime per driver, SLA adherence, stop density drift, and driver feedback. When a territory drifts outside tolerance, the engine proposes a reshape — usually a boundary shift with an adjacent territory — and the planning team approves or overrides before it goes live.

Here’s the flow at a glance:

flowchart LR A[Historical load signals] --> B[Demand surface by cell] B --> C[Constrained clustering] C --> D[Balanced territories] D --> E[Driver allocation] E --> F[Deploy + monitor] F --> G{Drift outside tolerance?} G -->|Yes| C G -->|No| F

Early results

Enterprises deploying territory design typically report, within 90 days:

A leading Western European parcel operator with 50%+ national market share uses this engine to maintain balanced territories across 8M+ shipments, adapting quarterly as demand patterns shift.

What’s next

Three upgrades: scenario-based reshaping (the engine proposes two or three reshape options per territory with explicit trade-offs), vehicle-aware territories (territories tuned for the specific vehicle type the driver runs — small vans handle different geographies from large trucks), and cross-territory elastic capacity (the engine identifies pairs of adjacent territories that can elastically share capacity on peak days).