Match each mission to the right fulfilment provider.
FromProprietary fulfilment→ToOpen fulfilment
Not every transaction is a parcel. Installing an AC or fixing a washing machine is a sequence of appointments, people, parts and proof. An open network can compose that sequence from independent participants. It works only if responsibility is explicit, because the customer experiences one journey.
Products and services fulfil differently
Discovery is one problem and transaction is another. Fulfilment is where the promise becomes real, and where the architecture must stop treating every transaction as a parcel.
| Mission | Fulfilment sequence |
|---|---|
| A specialty product, today | Merchant → pickup or hyperlocal delivery → consumer |
| Deliver and install an AC | Delivery → appointment → technician → installation → testing → completion |
| Fix an appliance I own | Diagnosis → part identification → sourcing → repair → testing → warranty |
| Customise a kitchen | Measurement → design → sourcing → manufacture → installation → inspection |
The agent’s question is not which delivery partner should carry this. It is what operational sequence completes this mission. Fulfilment is a capability too: one node may have the product but not installation capability, another may install but hold no inventory, and a third may repair and have access to spare parts. The network can compose them.
- Consumer intent
- Product node(product)
- Installation node(technician · equipment · appointment)
- Completion
- Proof · warranty · review
Openness creates responsibility problems
Suppose merchant A sells the product, logistics provider B delivers it and technician C installs it. The consumer experiences one journey and, when something breaks, asks one question: who is responsible?
The CSEP 2026 e-commerce report notes that when sellers, buyer-side apps, logistics providers and ONDC-integration apps are all involved, the grievance-redress mechanism gets complicated and building a reliable reputation takes time[2]. So fulfilment has to be an explicit object with explicit fields.
| Field | What it answers |
|---|---|
| Service area | Where will this node go? |
| Time window | When will it happen? |
| Capacity | Can the node take this job now? |
| Handoff point | Where does one party’s responsibility end and the next begin? |
| Equipment requirement | What must the node bring? |
| Scope and warranty owner | What is covered, and by whom? |
| Cancellation terms | What happens if either side cancels? |
| Proof of completion | How do we know the job is done? |
| Escalation owner | Whom does the consumer contact when it fails? |
Two rules follow for the pilot. First, every transaction gets one named escalation owner, shown before booking. Second, the pilot starts with single-node missions and adds multi-node orchestration once handoff failure rates are known.
Verification, recommendation and guarantee
The moment the network says a provider is trustworthy, it takes on responsibility for that judgement. Three commitments need to stay distinct: verification (this credential exists), recommendation (this provider fits your mission) and guarantee (we stand behind the outcome).
ONDC’s 2022 trust consultation paper is candid about the limits here. Rather than act as a controller, ONDC says it has no direct role in, or visibility of, any transaction. Its network policy requires seller apps to report accurate and complete information, transaction-level contracts are executed through the protocol, and participants and their grievance officers run issue resolution, with disciplinary action for repeated violations. At the time of writing, the paper listed its grievance chapter and online dispute resolution service as still under development[3]. So recourse has to be designed rather than assumed. People buying services want recourse, and a managed platform such as Urban Company, which describes its approach as a full-stack model[4], keeps the service standard and the customer relationship inside its own platform. The named escalation owner is the minimum. Beyond that, the team has to decide explicitly whether to offer a limited, priced guarantee in the pilot category. Leaving it open weakens the proposition against managed platforms.
Go deeper
Open logistics as a building block
ONDC’s Open Delivery Protocol is designed as a single integration that gives sellers access to many last-mile providers. Self-reported: ONDC cites more than 70 logistics service providers, coverage in more than 150 cities, more than 45 small fleet operators and more than 50,000 merchants supported, with partners including Ola, Uber, Shiprocket and Delhivery[1]. The page gives no date for these figures, and the evidence review treats them as ecosystem figures. They are enough to support the principle that the network can orchestrate fulfilment instead of owning a fleet: depending on the mission, it can use local fleets, third-party logistics, merchant delivery or specialised service operators.
Service levels should follow the mission too, whether that means minutes, hours, same day, scheduled, by appointment or pickup. The goal is not universal ten-minute delivery[CN]. The neighbourhood also holds fulfilment capacity of its own: delivery riders, auto drivers, technicians, installers, workshops, storage, small fleets and pickup points. The distributed route won’t always be cheaper. The point is that the network can choose the fulfilment architecture that suits the mission.
The optimisation changes
Centralised commerce optimises inventory movement. Open distributed commerce could optimise capability coordination. The question moves from how do we deliver this SKU fastest? to how do we complete this person’s mission with the capabilities available? Every completed mission also produces evidence that feeds back into trust, which closes the loop described in Shift 9.
What could go wrong
- Coordination failure.Multi-party jobs fail at handoffs, with no clear owner.
- No recourse.Without a clear escalation owner or guarantee, service buyers stay with managed platforms.
- Service flows on ONDC.It is untested whether ONDC’s current domain specifications and buyer apps handle quotes, appointments and custom work well enough.
- Cost.The distributed route won’t always be cheaper, and coordination overhead may exceed what it saves.
How we’d test it
Multi-party completion falls below the agreed threshold, or no clear owner can be named for failed jobs.
| The test | What we would measure | What would end the idea |
|---|---|---|
| Mission completion (Experiment 6) | Completion rate by number of handoffs; escalation resolution time; disputes; refund and cancellation outcomes | Multi-party completion below the agreed threshold |
| Service levels by mission | Pickup, scheduled delivery, same-day delivery and appointment-based service tested separately; on-time rate and satisfaction by mode | Any mode whose on-time rate stays below the agreed floor is dropped from the pilot |
How strong is the evidence?
- Established
- Open logistics infrastructure exists at scale (self-reported); ONDC’s own consultation limits what a decentralised network can guarantee.
- Evidence-supported
- Service levels should match the mission.
- Hypothesis
- The orchestration advantage exceeds the coordination cost.
- Unknown
- Completion reliability across handoffs, how well ONDC flows carry service fulfilment, and the recourse model.
Sources
- [1]ONDC, Hyperlocal LogisticsChecked; the figures carry no date
- [2]CSEP, India E-Commerce Report 2026Checked (p. 28)
- [3]ONDC, Building Trust in the ONDC Network: Consultation Paper (2022)Checked
- [4]Urban Company, Annual Report FY26Checked (excerpt)
- [CN]Voice-session working notes (internal)Provided
Spotted a source we missed or a rule we misread? Tell us what we got wrong.
Everything so far can be built on rails that already exist. So what, exactly, is left to build, and what keeps it open?