Last-Mile Delivery

1. Overview — the last mile is the whole problem

For e-commerce in urban India the last mile is a solved, commoditised line item. In rural India it is the entire unsolved problem: homes have no postal-grade address, density is too low to justify a dedicated courier round, roads peter out into cart tracks, and the cost of a single failed door attempt wipes out the margin on the parcel. RideChain's thesis is that the rural last mile is not a delivery problem but a network problem — and that the network was already invented in Europe. We take three proven European primitives and adapt each to Indian village reality.

None of these three is novel on its own. The product is the combination: the Point removes addressing and failed attempts, the piggyback partner removes the cost of dedicated capacity, and the Block-Hub milk-run removes the cost-per-parcel through bundling. Stitched together by software, they turn an uneconomic geography into a routine one.

flowchart LR
  subgraph EU["European primitives (proven)"]
    MR["Mondial Relay / Packstation
(PUDO points + lockers)"]
    SH["Shopopop
(crowd courier)"]
    LP["La Poste
(scheduled milk-run)"]
  end
  subgraph IN["RideChain India adaptation"]
    PT["RideChain Point
kirana / CSC / panchayat / chai stall"]
    PB["Piggyback partner
milkman / school van / mandi-bound farmer"]
    BH["Block Hub feeder
consolidate + scheduled village runs"]
  end
  MR --> PT
  SH --> PB
  LP --> BH
  classDef eu fill:#e8f0fb,stroke:#1f5fae,color:#143d6e;
  classDef ind fill:#fff3e0,stroke:#f4920b,color:#8a5200;
  class MR,SH,LP eu; class PT,PB,BH ind;
        

2. The RideChain Point (PUDO)

A RideChain Point is a Pickup/Drop-Off (PUDO) location hosted by an already-trusted village business — most often a kirana shop, but equally a CSC, a panchayat office or a chai stall. The host signs up as a Point operator (see Onboarding & KYC), earns a per-parcel fee, and gains footfall. The Point plays four roles in the network.

The Point is what makes the rural last mile economic, for two reasons. First, it drives first-attempt success toward ~100%: a parcel is never "missed" because the human comes to the parcel, not the other way around. Second, it removes rural addressing entirely — the destination is a Point, not a house that GPS cannot find. The hardest part of rural delivery (finding an unaddressed home) simply does not occur on a POINT drop. (For the DOOR/POINT mode matrix and why POINT → POINT is cheapest, see Booking & Delivery Flow.)

flowchart TB
  S["Sender"] --> D{"Pickup mode?"}
  D -- "DOOR" --> PU["Partner collects at door"]
  D -- "POINT" --> OP1["Origin Point: operator accepts
scan QR + stage parcel"]
  PU --> OP1
  OP1 --> INV["Point inventory: on-hand,
storage clock starts"]
  INV --> SWEEP["Swept onto next leg
(milk-run or partner)"]
  SWEEP --> DP["Destination Point:
accept + store"]
  DP --> COLL{"Receiver collects
within window?"}
  COLL -- "yes" --> OK["Drop OTP + POD → delivered"]
  COLL -- "no (storage limit)" --> RTS["Return-to-sender clock
→ reverse leg"]
  classDef pt fill:#fff3e0,stroke:#f4920b,color:#8a5200;
  class OP1,DP,INV pt;
        

Inventory & storage handling. Every parcel resting at a Point is on-hand inventory in the operator app: a list of parcel-IDs with their state, age, storage deadline and the leg they are waiting for. The operator can only ever see and act on parcels that the system has assigned to that Point (this is the assignment lock, below). When a parcel exceeds its storage window uncollected, the system auto-starts the return-to-sender clock and offers the receiver a final reminder before triggering a reverse leg.

3. Delivery topologies — and when the engine picks each

A booking decomposes into ordered legs, and the matching/routing engine assembles those legs into one of three topologies. The choice is driven by the speed tier, the pickup/drop modes, distance, and whether a scheduled milk-run already serves the corridor.

flowchart TB
  subgraph A["Mode A · Direct door-to-door (one partner, one leg)"]
    SA["Sender door"] -->|"single leg"| PA["Partner"]
    PA --> RA["Receiver door"]
  end
  subgraph PP["Point-to-Point (single partner, no hub)"]
    SP["Origin Point"] -->|"one shared leg"| PPp["Partner"]
    PPp --> DPp["Destination Point"]
  end
  subgraph B["Mode B · Relay / milk-run (multi-partner, multi-leg via hub)"]
    VX["Village X Point"] -->|"leg 1: Partner A"| HUB["🏬 Block Hub
consolidate"]
    HUB -->|"leg 2: Partner B (milk-run)"| VY["Village Y Point"]
  end
  classDef hub fill:#fff3e0,stroke:#f4920b,color:#8a5200;
  class HUB hub;
        

4. The milk-run & bundling — where the cost disappears

A milk-run is a scheduled feeder route out of a Block Hub that visits a sequence of village Points in one loop, dropping and picking up at each. It is the single biggest cost lever in the network, because the trip cost is fixed while the number of parcels it carries is variable. Bundling many parcels onto one run is a classic Vehicle Routing Problem (VRP): given the hub, the set of village Points to serve, vehicle capacity and time windows, find the cheapest multi-stop loop.

flowchart LR
  HUB["🏬 Block Hub
(start + end)"] --> V1["Point · Village 1
drop 3 · pick 1"]
  V1 --> V2["Point · Village 2
drop 2 · pick 4"]
  V2 --> V3["Point · Village 3
drop 5"]
  V3 --> V4["Point · Village 4
drop 1 · pick 2"]
  V4 --> HUBR["🏬 Block Hub
(return, backhaul to mandi)"]
  classDef hub fill:#fff3e0,stroke:#f4920b,color:#8a5200;
  class HUB,HUBR hub;
        

The economics are simple and brutal in RideChain's favour:

1. Trip cost is fixed. Fuel, driver time and vehicle wear for the loop are roughly constant whether it carries 1 parcel or 30.
2. Cost per parcel = trip cost ÷ N. Doubling the parcels on a run nearly halves the cost each one bears — the curve bends down hard as the network densifies.
3. The Point makes N large. Because parcels consolidate and wait at Points, a single run can sweep a whole village's accumulated volume rather than chasing one parcel at a time.

5. The custody chain — the integrity mechanism

A network that hands parcels between strangers — kirana operators, milkmen, farmers, hub staff — only works if every handover is provably honest. RideChain's answer is a custody chain: each handover is gated by four interlocking checks, and the chain repeats at every leg, forming one unbroken, auditable record from origin Point to final receiver. Crucially, each leg's money release is gated by the successful handover that closes it — no honest handover, no payout.

sequenceDiagram
  autonumber
  participant OP as "Point operator (giver)"
  participant SV as "Go custody service"
  participant PA as "Partner (receiver, leg N)"
  Note over OP,PA: Leg N handover — all four checks must pass
  SV->>PA: "Assignment lock: parcel visible ONLY to assigned partner"
  PA->>SV: "Scan tamper-evident QR (unique parcel-ID)"
  SV-->>PA: "QR match? mismatch BLOCKS handover"
  OP->>SV: "Confirm: handing to named + photo-verified partner"
  PA->>SV: "Enter / scan two-sided handover OTP"
  SV-->>SV: "Verify geofence + stamp SERVER timestamp"
  SV-->>SV: "All 4 pass → close leg N custody record"
  SV->>PA: "Custody transferred; release leg N money (gated)"
  Note over OP,PA: Chain repeats: Point to partner to hub to next partner to receiver
        

flowchart LR
  OPt["Origin Point"] -->|"gate ✓ → release leg 1"| P1["Partner A (leg 1)"]
  P1 -->|"gate ✓ → release leg 1 hub-in"| HUB["🏬 Block Hub"]
  HUB -->|"gate ✓ → release leg 2"| P2["Partner B (leg 2)"]
  P2 -->|"gate ✓ → release leg 2"| RCV["Receiver / dest Point"]
  classDef hub fill:#fff3e0,stroke:#f4920b,color:#8a5200;
  class HUB hub;
        

6. Per-leg money & handoff

Because the custody chain closes leg by leg, money also releases leg by leg. The booker pays once into escrow at booking time (the platform holds no money — see Payments & Integration); the held funds are then released as a split per leg, each slice triggered by that leg's successful handover (the four-check gate above, finishing with drop OTP + POD). Using the canonical relay example — a total fare of ₹220:

The defining property is that Partner A is paid for leg 1 the moment they hand the parcel to the hub, even though Partner B will finish the journey hours later. Each participant is paid for the custody they actually held — no one waits on anyone else's leg. The currency in the ledger is paise (integer); the ₹ figures here are display. The single point-to-point baseline (total ₹120 → partner ₹80, drop Point ₹6, collect Point ₹6, platform ₹28) and the full split mechanics live in Split-Money Settlement.

7. Reverse logistics & backhaul

Half of a milk-run is the trip back to the hub, and an empty return leg is wasted, paid-for capacity. RideChain fills it two ways, and both improve the unit economics of every forward parcel on the route.

flowchart LR
  HUB["🏬 Block Hub"] -->|"forward: parcels in"| VIL["Village Points"]
  VIL -->|"backhaul: returns + agri produce"| HUBB["🏬 Block Hub → mandi"]
  HUBB -->|"produce sold"| MANDI["Block mandi / market"]
  VIL -.->|"return / exchange pickup"| HUBB
  classDef hub fill:#fff3e0,stroke:#f4920b,color:#8a5200;
  class HUB,HUBB hub;
        

8. Special handling

The rural mix is not just cartons. The booking flags (set at booking time) drive vehicle choice, routing priority, packaging and Point-storage rules.

Addressing the unaddressed. Most rural homes have no usable postal address. For DOOR ends RideChain uses a what3words-style landmark addressing scheme — a precise grid reference plus human landmarks ("near the banyan tree, behind the panchayat well") — so a partner can find a house with no street name. For most parcels the cleaner answer is simply a POINT destination, which sidesteps addressing altogether.

9. Edge cases & failure modes

The last mile is where things go wrong most, so every failure mode below has a defined mitigation. The full catalogue and cross-component patterns live in the Edge-Case Catalog.