Driving Sustainability
Gojek's Carbon Offset Initiative
Role
Business Context
Gojek already ran two sustainability initiatives — a carbon footprint calculator and a tree-planting program — but both lived outside the booking flow, in a separate GoGreener web experience that converted below 1% between July and August 2021. The business wanted a carbon offset option that could scale across Gojek's three biggest service lines — Transport, Food, and Logistics — without adding a step that would cost bookings in a super-app where speed is the primary reason people open it. Customers had no reason to distrust the existing green initiatives, but they also had no reason to notice them — a separate web flow is invisible mid-booking. Operationally, any fix had to work identically across three services with different booking UIs, price points, and user expectations, or it would create three maintenance burdens instead of one.
Strategic Decision
**Depth vs. Reach**
Context: A richer, more explanatory offset experience — walking users through their impact before asking for it — would build more trust per user. But every additional screen in a booking flow costs conversion, and the business case depended on reaching as many riders as possible, not converting a smaller, better-informed subset.
Options: (1) a guided, multi-step opt-in that explains impact before asking for payment, or (2) a single toggle, on by default in the flow, with trust-building deferred to after the trip.
Trade-off: choosing reach meant accepting that some users would opt in without fully understanding what they were paying for at that moment.
Decision: the single-toggle approach, with impact reporting moved to a screen users would see after committing, not before.
Why: the offset amount was small enough that the cost of a wrong decision was low; the bigger risk was a flow so heavy that people opted out before ever engaging with it. Trust could be built retroactively through visible impact — it didn't have to be earned upfront.
Design Principles
1. **Zero Friction** — every added step in the booking flow costs conversion, so the feature could not slow down the primary task.
2. **Flexible Access** — one toggle pattern had to work across Transport, Food, and Logistics without turning into three different features.
3. **Simplified Pricing** — a flat, small fee people could hold in their head, not a variable, emissions-based calculation nobody would stop to compute mid-booking.
4. **Impact Visualization, After the Fact** — the payoff had to be visible, but only once users had already committed, not as a precondition for opting in.
Key Product Decisions
**1. Pricing model**
Problem: how much should the offset cost, and how should that cost be communicated?
Options explored: variable, emissions-based pricing calculated per trip vs. a flat, small fee per trip regardless of distance or vehicle.
Decision: flat fee per trip.
Solution: a fixed small charge added to every trip when the toggle is on, with no calculation shown at checkout.
Business impact: removed a source of checkout friction that would have required real-time carbon calculation on every booking, keeping the ask simple enough to need no explanation on the primary booking screen.
**2. Impact reporting placement**
Problem: how to build trust in an outcome users can't verify — trees planted, emissions absorbed?
Options explored: show projected impact before payment as part of the pitch, vs. show cumulative impact after the trip, once the user has already opted in.
Decision: after the trip.
Solution: a post-trip confirmation screen ("You've made Earth a lil bit greener") showing a running participant count, expanding into a step-by-step explainer of how the money is used.
Business impact: kept the opt-in moment to a single toggle while still giving users a reason to keep the feature on for future trips.
**3. One shared pattern vs. three bespoke flows**
Problem: Transport, Food, and Logistics have different booking UIs, price points, and teams — building a custom offset flow for each would triple the design and engineering surface area.
Options explored: a bespoke offset flow per service line, tailored to each one's UI patterns, vs. one shared toggle component reused across all three.
Decision: one shared component.
Solution: the same toggle, pricing logic, and post-trip reporting screen shipped across all three service lines, with only the price point adjusted per service.
Business impact: traded a slower initial build — the shared component had to accommodate three different underlying pricing and booking systems — for a permanently lower maintenance cost, since future changes update one component instead of three.
Outcomes
**Business:** adoption reached well beyond the standalone GoGreener web flow's sub-1% baseline — 1M+ users subscribed and roughly 4.79 million tons of emissions offset to date.
**Customer:** users got a concrete, cumulative measure of their contribution instead of an abstract environmental claim buried in a separate web page.
**Operations:** a single toggle pattern across Transport, Food, and Logistics meant one design system to maintain instead of three separate flows.
**Engineering:** reusing one component across service lines reduced the custom integration work needed per vertical.
**Support:** no support-specific data was available for this feature.
Reflection
The biggest surprise was how much the pricing model mattered more than the price itself. Users didn't push back on paying — they pushed back on not understanding what they were paying for. A flat number they could hold in their head did more for trust than any amount of impact visualization after the fact.
If I were doing this again, I'd invest earlier in the post-trip reporting screen. It ended up carrying most of the trust-building work the toggle itself couldn't, but it was treated as a secondary screen for most of the process.
The principle that still shapes how I design opt-in features: separate the decision from the explanation. Ask for the commitment where the user already is, and save the convincing for after they've said yes.