Role & Summary
Led design of GoSend's multi-drop delivery end-to-end, choosing a details-first flow over price-first to protect trust. Piloted in 3 cities, it drove 800+ orders at 73% completion and ~30% cost savings.
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. It was 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. It was 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. Correctness before speed: address entry came first and was deliberately unhurried to reduce entry errors, catching the likeliest source of misdirected deliveries before the order was even placed.
2. Progressive complexity: the flow stayed simple for a single destination and only surfaced pricing/routing complexity (e.g. "Pay Rp1000 cheaper by optimizing your route") the moment a user added a stop, avoiding checkout-time surprises.
3. Failure as a first-class state: failure screens like "all drivers are busy" kept the same visual language as the happy path with a clear recovery path, instead of reading as a broken app.
4. Per-stop status, grouped clearly: each recipient in a multi-drop order got its own delivered/on-hold/returning status inside one grouped view, cutting disputes and support tickets from ambiguous outcomes.
5. Validate errors immediately, in context: unserviceable locations, bad phone numbers, and over-radius routes surfaced instantly with a clear explanation and Cancel/Change paths, deflecting disputes 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.
