A plan to launch "Captains" — local commerce partners who bring in new customers and handle last-mile delivery on Troopzy's behalf, without ever touching Troopzy's own inventory or pricing. This document covers the complete vision — onboarding, ordering, delivery, batching, commission, loyalty, zone automation, and eventually AI-assisted matching and routing — organized into three phases so it can be built, trusted and paid for incrementally rather than all at once.
The business case for the Captain role, in plain terms.
Troopzy currently reaches customers directly — through its own delivery team and apps. A Captain extends that reach into a neighborhood or community through a trusted local person, who signs up customers, takes their orders (including items not yet in the catalog, via a photo request), and delivers the finished order back to them. Troopzy keeps full control of stock, pricing and fulfillment; the Captain earns a commission for the customers and orders they bring in.
New customers in areas Troopzy's own delivery team doesn't cover yet, without opening a new store.
Captains never touch stock or set prices — every order still flows through Troopzy's existing warehouse and pricing.
Captains are paid a visible, order-linked commission, so their earnings grow directly with the business they bring.
The path a single order takes, from the customer's request to delivery — and back, if returned.
flowchart LR Cu["Customer"] -->|"1 · Places order\nwith Captain"| Ca["Captain"] Ca -->|"2 · Submits order\n(+ photo for special items)"| OMS(["Troopzy OMS"]) OMS -->|"3 · Sent for picking"| Bi["Biller / Picker"] Bi -->|"4 · Order packed"| DT["Delivery Team"] DT -->|"5 · Packed order\nhanded to Captain"| Ca Ca -->|"6 · Delivered, payment\ncollected"| Cu Cu -.->|"7 · Return or\npartial return"| Ca Ca -.->|"8 · Return logged"| OMS
Every box already exists in Troopzy today except the Captain — the order still goes through the same picking, packing and warehouse process as any other order.
The same flow, laid out in time — showing exactly what each party does at each step of one order's life.
sequenceDiagram
autonumber
participant Cu as Customer
participant Ca as Captain
participant OMS as Troopzy OMS
participant Bi as Biller / Picker
participant DT as Delivery Team
Cu->>Ca: Requests products (catalog items + special requests)
Ca->>OMS: Creates order (photo attached for special requests)
OMS->>Bi: Order queued for picking
Bi->>Bi: Verifies special-request items, maps to a real product
Bi->>OMS: Order picked and packed
OMS->>DT: Order marked ready for handover
DT->>Ca: Hands over packed order
Ca->>Cu: Delivers order, collects payment (cash / UPI / credit)
opt Return
Cu->>Ca: Returns item, in full or in part
Ca->>OMS: Logs the return
end
OMS->>OMS: Updates the Captain's commission ledger
This is the exact sequence Phase 1 is built to support — nothing here depends on features planned for later phases.
Every capability the client asked for is scoped below. Nothing is dropped — the phasing is purely about build order: get a real Captain taking real orders first, then add scale and automation once that foundation is proven.
Built in four stages, each tested locally and confirmed working before it goes live.
Adds the pieces that matter once there's more than one Captain: ownership rules, consolidated deliveries, and the full commission/loyalty engine.
Formal ownership: which Captain acquired which customer, and what happens if a customer's number is already claimed.
Many orders for one Captain consolidated into a single handover from the delivery team, instead of one-by-one.
Orders from business customers automatically use a different, separately-configured commission rate.
A separate, auditable ledger for the long-term benefit — accrued, vested, and settled as its own lifecycle.
Each Captain is mapped to pincodes and fixed delivery days; the app only ever shows them what applies to their zone.
Admin view of sales, returns, commission and loyalty accrued per Captain, for day-to-day management.
Automation and prediction on top of a proven Phase 1 + 2 — valuable once there's enough real order history to learn from.
A customer's requested-item photo is automatically suggested against the real catalog, instead of manual review every time.
Predicts likely order volume per zone/Captain ahead of time, to help with stocking and staffing.
Captain + pincode + delivery day + order volume is used to build handover batches without manual grouping.
Delivery/handover sequencing is optimized automatically rather than planned by hand.
Early signals on which Captains/zones are likely to under- or over-perform, ahead of the monthly numbers.
Flags a Captain's customers who are ordering less than usual, before they're lost entirely.
Early concept screens spanning both the Captain App (screens 1–5, Phase 1) and the batch/admin views that arrive in Phase 2 (screens 6–7) — enough to show the shape of the experience. Visual design (colors, branding, exact layout) is refined during build, not fixed here.
Every Captain is assigned a plan with its own rates — nothing is hard-coded, and two Captains can be paid completely differently without an app update.
Captains handle money and customer orders, so what each role can and cannot do is fixed by the system, not by trust.
Standing reports the system produces on its own — no manual spreadsheet work to know how the Captain network is performing.
| Step | What happens |
|---|---|
| Build | The feature is built on a local copy of Troopzy — production is untouched. |
| Automated tests | Existing tests must keep passing; new tests are added for the new feature. |
| Manual walkthrough | Someone clicks through the real flow — create customer, place order, pick, pack, deliver — before sign-off. |
| Backup | A verified backup of live data is taken before anything is deployed. |
| Go live | Only after the above pass; each stage is deployed and monitored on its own, not bundled with the next. |
Approving this document authorizes work to begin on Phase 1, Stage 1A. Every later stage — through Phase 2 and Phase 3 — will be shown working before it is deployed; this approval is for the full scope and phased roadmap above, not a commitment to build everything at once.
All comments