Multi-Drop Delivery
Designing for Trust in a High-Stakes System
Role
Led design strategy and execution end-to-end for multi-drop delivery, partnering with the GoSend squad
Business Context
GoSend built its reputation on fast, reliable single-package delivery — but as small businesses adopted the platform, their needs outgrew it. A seller with multiple orders to send in a day had no way to book them together; each package meant a separate order, a separate driver, and a separate wait. Competitor apps made multi-package sending easy, and GoSend's internal product narrative put it plainly: "customers perceive GoSend as lacking in innovation and being expensive despite the various promotions we continue to offer." The business wanted to grow its user base, grow revenue, and improve brand perception — but research into existing users surfaced a more complicated picture. Two distinct groups relied on GoSend: heavy sellers running small businesses, and non-sellers such as housewives sending occasional packages. Their pain points clustered around driver management, coordinating multiple pickups, timing and scheduling, and the limits of existing promotions — not a single missing feature.
Strategic Decision
**Details-First vs. Price-First**
Context: multi-drop delivery could be introduced two valid ways. A Details-first approach asked users to enter their full route and delivery details before showing any price — safer and more familiar, closer to how GoSend already worked, but slower to reveal value. A Price-first approach showed an estimated price as soon as a second stop was added — faster to compare, more persuasive for someone deciding whether to switch from a competitor, but riskier if the estimate didn't hold up once real details were entered.
Options: concept testing mapped each approach to a different user. Details-first mapped to existing GoSend users and competitor sellers already comparing services, was preferred when a user had already decided to use GoSend, and optimized for the perceived benefit of avoiding mix-ups when sending multiple items. Price-first mapped to competitor users and non-sellers, was preferred when someone was still comparing brands, and optimized for the perceived benefit of checking cost upfront.
Trade-off: choosing Details-first meant knowingly deprioritizing price-sensitive acquisition, accepting slower experimentation, and parking some research learnings for future iterations. Choosing Price-first would have meant asking for trust — an accurate price before the actual route was verified — from users who had the least reason to extend it.
Decision: Details-first.
Why: Details-first protected trust, reduced operational risk, and built on habits GoSend's existing users already had — even though it was the less flashy, less immediately persuasive option. At this stage, breaking trust would have been more expensive than missing short-term growth.
Design Principles
1. **Trust > Speed** — every decision defaulted to the option that protected user trust, even when a faster path was available.
2. **Failure Transparency > Silent Retries** — failures were shown, not hidden or silently retried behind the scenes.
3. **Power User > Casual User** — the design optimized for sellers who would use multi-drop repeatedly, not the lightest, most occasional use case.
4. **High Cost of User Error** — because a mistake in a multi-drop order affects multiple recipients at once, the interface treated the cost of user error as high by default.
Key Product Decisions
**1. Designing for correctness before speed**
Problem: multi-drop orders meant more fields, more addresses, more chances for a mistake — and a mistake here affects a real, physical delivery to the wrong place.
Options explored: optimize the flow for speed (minimize taps, streamline entry), vs. optimize for correctness (slow entry down to reduce the chance of an error).
Decision: correctness first.
Solution: address entry always came first in the flow; actions like saving a favorite address were visually de-emphasized relative to the address itself; related fields were grouped visually to reduce mis-entry.
Business impact: reduced the likeliest source of failed or misdirected deliveries at the point where it was cheapest to catch — before the order was placed.
**2. Opting into complexity, not being forced into it**
Problem: adding stops changes the price, the route, and the vehicle eligibility — surfacing that complexity too early or too late either overwhelms users or surprises them at checkout.
Options explored: show full pricing and routing complexity as soon as the flow starts, vs. keep the default flow simple and reveal complexity only as users actively opt into it by adding a second or third stop.
Decision: reveal complexity progressively, tied to user action.
Solution: a single-destination order starts simple; adding a stop immediately signals the cost impact (for example, "Pay Rp1000 cheaper by optimizing your route") rather than waiting until checkout to surprise the user with a price change.
Business impact: no surprise jumps in price — cost impact was signaled at the moment of the decision that caused it, not after.
**3. Designing continuity across system states**
Problem: multi-drop deliveries fail more often than single-drop ones simply because there are more legs that can go wrong — no driver found, a stop skipped, a delivery only partially completed. Treating these as rare edge cases would leave the product unprepared for something that happens routinely.
Options explored: treat failure states as exceptional, low-investment screens, vs. design failure as a first-class part of the experience with the same visual continuity as the happy path.
Decision: treat failure as a first-class experience.
Solution: failure states, like "all drivers are busy," preserved the same visual language as the rest of the flow, made clear that failure did not mean crash, and gave users a clear path to recovery instead of a dead end.
Business impact: reduced the chance that a failure state would read as the app being broken, versus a normal, recoverable part of a multi-stop delivery.
**4. Handling mixed outcomes with clarity**
Problem: in a multi-drop order, some packages can be delivered successfully while others are on hold, returned, or delayed — a single success-or-failure status can't represent that.
Options explored: report order status as a single aggregate state, vs. report each stop's status individually within a clearly grouped view.
Decision: report per-stop status, grouped clearly.
Solution: each recipient in a multi-drop order got its own status — delivered, on hold, returning — inside one grouped view, in a neutral tone, with nothing about the outcome hidden from the sender.
Business impact: directly reduced downstream disputes and support tickets by making mixed outcomes legible without a support conversation.
**5. Reducing downstream operational load**
Problem: errors like an unserviceable location, an invalid phone number, or a route exceeding the delivery radius were previously discovered late or led to disputes and support contact.
Options explored: let these errors surface downstream during driver assignment or delivery, vs. validate and surface them immediately, in context, during order creation.
Decision: validate and surface immediately.
Solution: specific, in-context error states — unserviceable location, incorrect phone number, distance over the 45km limit — each with an illustration, a clear explanation, and both a Cancel and a Change path.
Business impact: fewer disputes, clearer accountability for what went wrong and why, and errors deflected before they became support tickets.
Outcomes
**Business:** piloted in 3 cities, validating the core assumptions — adoption was healthy and the feature proved cost-effective for users (roughly 30% savings) while giving driver partners more earnings through longer trips.
**Customer:** 800+ completed multi-drop orders, averaging 2.5 shipments per order, with a 73% average booking completion rate.
**Operations:** cross-functional alignment with PMs and researchers on acceptable risk, and with Engineering on system feasibility, kept the rollout scoped without compromising safety.
**Engineering:** average delivery SLA held under 2 hours (P90) even with the added complexity of multi-stop routing.
**Support:** UI clarity was designed explicitly with Ops & Support to reduce dispute tickets, though no specific ticket-volume figure was shared for this feature.
Reflection
The clearest lesson from choosing Details-first was that it was the right call for the users we had, and the wrong call to treat as permanent. It protected trust when trust was the scarcest resource, but the price-sensitive, brand-comparing users we deprioritized didn't go away — they just weren't who we designed for first.
If I were continuing this work, I'd build a progressive path toward price-first discovery for the audiences the initial version explicitly excluded, and follow the same trust-first lens into a phased expansion to Jakarta, GoSend's main market — rather than assuming a decision made for pilot cities should stay fixed as the product scales.
The principle I still carry from this project: sequencing a trade-off is not the same as avoiding it. Choosing Details-first didn't solve the price-first need — it deferred it deliberately, with a plan to come back to it. That's different from a decision made by default.