01 — AI EARNINGS COPILOT
PRODUCT SHIFT
Ride execution
↓
Earnings optimisation
Role — Lead Product Designer
Product — Rapido Captain
Scope — Product strategy, UX, prototyping, validation
Launch — Bangalore + Delhi
Rapido Captain was primarily designed as a ride execution app. The core job was straightforward: accept an order, navigate to the customer, complete the ride and move on to the next one. But a captain’s work doesn’t stop between rides. They are constantly making small decisions that affect their earnings — whether to wait or move, where to go next, whether an incentive is worth chasing, or whether it is time to go offline. I explored how AI could help with those decisions and move the Captain app from being a tool for executing rides to a product that actively helps captains optimise their earnings.
THE CONTEXT
The Captain app knew a lot. It wasn’t always helping captains act on it.
We had access to operational signals around online time, idle time, order frequency and earnings. Yet having information and knowing what to do with that information were two different things. A captain could be online for a long period, receive fewer orders than expected and feel that earnings were not adding up. The natural response was often to go offline or move to another platform such as Uber, Ola or Porter. The opportunity was therefore larger than simply improving order discovery. It was about helping a captain make a better decision at the exact moment that decision mattered.
Complete ride
→ Wait
→ Decide
→ Move / stay
→ Next ride
THE PROBLEM
Captains were online. But they weren’t earning enough.
The problem became visible through a combination of behavioural patterns and operational data. Captains were spending time online without getting orders frequently enough, which increased idle time and created a perception that the platform was not helping them earn consistently. That frustration had a direct business implication. When captains couldn’t see a path to better earnings, they could choose to go offline or distribute their time across competing platforms. The question I wanted to solve was simple: How might we help a captain make better earning decisions while they are on the road?
ONLINE
→ WAITING
→ FEWER ORDERS
→ LOW EARNINGS
→ OFFLINE
THE FIRST SOLUTIONS DIDN’T WORK
Our first instinct was to show captains more information.
We initially tried solving the problem through demand visibility. Heat maps showed areas where demand was higher, giving captains a way to understand the market around them. We later introduced a map pill called Demand Areas, which surfaced relevant demand zones and encouraged captains to move. It was directionally useful, but usage and discoverability were not strong enough. The learning was important. The problem wasn’t simply that captains couldn’t see demand. It was that the product was still asking them to interpret the information and decide what to do next.
“The problem wasn’t simply where demand is. It was what should I do right now?”
THE SHIFT IN THINKING
I went back to user behaviour.
One behavioural pattern stood out during research: captains often acted when someone they trusted simply told them what to do. Advice from another person could be more useful than a screen full of information because it reduced the mental effort required to interpret the situation. That changed the framing for me. Instead of asking, “How do we show demand better?”, I started asking, “How do we turn demand signals into useful advice?” I also discovered that some captains were already experimenting with generative AI tools such as ChatGPT and Gemini. This was unexpected, but it suggested that AI was becoming a familiar interaction model rather than something completely foreign to the audience.
THE HYPOTHESIS
What if the Captain app had a Copilot?
I proposed a focused AI Copilot for earnings and orders. The intention wasn’t to add a generic chatbot to the Captain app. It was to give captains a layer of intelligence that could interpret the signals already available to the platform and turn them into a useful next step. The hypothesis was straightforward: if we turn operational data into simple, actionable recommendations, captains will make better decisions and improve their earning potential. Instead of only helping captains complete rides, the product could start helping them understand their working environment, make decisions and ultimately optimise how they earn.
From a ride execution app to an earnings optimisation app.
AI WAS AN EXPENSIVE BET
The challenge wasn’t only designing the product. It was convincing the organisation to invest in it.
A full AI Copilot required meaningful engineering investment, and stakeholders naturally questioned whether captains would actually use it. I didn’t want to answer that question with a design opinion or a polished prototype. So I looked for a way to validate the direction before asking the organisation to commit to the entire build. We used existing Storyly capabilities to run a lightweight product-marketing experiment, supported by a landing page that could capture interest. The goal was deliberately narrow: not to prove the final product, but to establish whether there was enough curiosity and demand around a Rapido-specific AI experience to justify deeper exploration.
Storyly
→ Landing page
→ Captain interest
→ Evidence
→ Prototype
The experiment gave us enough evidence to keep going — but not a reason to build everything. I proposed a phased approach so that we could test a focused use case first and expand only if the product demonstrated value.
SCOPING THE COPILOT
I deliberately narrowed the first version.
The Copilot could eventually help with many parts of a captain’s day, but putting all of that into version one would have made the product expensive, difficult to validate and unclear in purpose. I therefore separated the opportunity into three priorities. P0 was Demand Planner — helping captains understand where they should go next. P1 was Help — helping them understand how to use the app. P2 was Order Problems — helping them resolve issues when something went wrong. This gave the first release a clear job to do while preserving a much larger vision for the future.
P0 — Demand Planner
P1 — Help
P2 — Order Problems
THE PRODUCT VISION
What will it do today? What will it become tomorrow?
For the first version, the Copilot would focus on demand planning. It would help a captain understand where they could move next based on demand signals and the context around their current ride. Over time, the same intelligence could become an assistance layer — explaining incentives, answering questions and helping resolve operational problems. Eventually, it could become an agent capable of taking actions on behalf of the captain.
Recommendation → Assistance → Agency
The AI didn’t need to start as an agent. It needed to first earn the captain’s trust.
THE COPILOT LOOP
Understand → Recommend → Act → Learn
The experience was designed around a simple loop rather than a chat interface. The system first uses available context — current location, recent ride, demand patterns, time and other relevant signals — to understand the situation. It then gives the captain one clear recommendation rather than asking them to interpret a dashboard. The recommendation should lead directly to an action, such as navigating towards an area with stronger demand. Finally, the system can observe what happened and use those outcomes to improve future recommendations. Importantly, the Copilot should not pretend it has perfect visibility into everything a captain does, especially when they may also work across multiple platforms.
Context
→ Recommendation
→ Action
DESIGNING FOR REAL CAPTAIN BEHAVIOUR
The AI had to fit the user’s context, not the other way around.
Research from other Captain experiences had already highlighted important behavioural constraints. Captains could distrust incentive communication when the calculation or conditions were unclear, which meant an AI recommendation involving money needed to be explainable. We also knew that captains often move quickly and may skip detailed information. That pushed the experience towards short, contextual recommendations instead of analytical dashboards. For users with lower reading fluency or accessibility needs, audio had to be treated as a core interaction rather than a secondary feature. The principle became simple: don’t make the captain understand the AI; make the AI easy to understand.
Trust
Explainability
Speed
Concise recommendation
Accessibility
Audio-first
THE EXPERIENCE
One moment. One recommendation. One action.
The experience intentionally avoided making the captain open a separate AI destination and start a conversation. Instead, the intelligence appeared in the context of the captain’s work. After completing a ride, the Copilot could surface a recommendation such as: “Demand is higher near Koramangala. Moving there could improve your chances of getting your next order.” The primary action could then be to navigate there. For a captain who may not want to read while working, the same recommendation could be delivered through audio. The goal was not to make AI visible everywhere. It was to make the next decision easier.
COPILOT RECOMMENDATION
Demand is higher near Koramangala. Moving there could improve your chances of getting your next order.
Navigate →
AI-ASSISTED DESIGN PROCESS
I didn’t just design an AI product. I used AI to design it.
AI became part of my design workflow as well. I used Claude and Figma workflows to accelerate concept exploration, UI variations, interaction ideas, prototyping, content exploration and edge-case thinking. The important distinction was that AI accelerated the execution of design work; it didn’t replace the product decisions. I still defined the problem, prioritised the opportunity, decided what not to build and shaped how the hypothesis would be validated. This allowed me to move quickly between strategic thinking and tangible prototypes without losing ownership of the design direction.
Problem framing → AI exploration → Interaction concepts → Prototype → Human judgement → Final design
AI accelerated the making. It didn’t decide the product.
LAUNCH
The first version launched in Bangalore and Delhi.
We deliberately launched with one job: demand planning. That kept the first release focused enough to observe a clear behavioural question — do captains actually follow AI recommendations? The launch was treated as a learning step rather than the completion of the Copilot vision. The broader roadmap remained Recommendation → Assistance → Agency, but the first release had to prove that the recommendation layer could create value.
EARLY SIGNALS
Early usage suggested that captains were more willing to move towards suggested demand areas. We also saw directional improvements around idle time and earnings among users of the experience. One segment stood out particularly clearly: newer captains were among the most active users. Experienced captains had already developed their own mental maps of where demand tends to appear, while newer captains had less of that intuition. This suggested an important role for the Copilot beyond recommendation. It could help newer captains build the mental model that experienced captains had developed through repetition and experience.
Experienced Captain
Existing mental model of the city
New Captain
Uses the Copilot to build a mental model of demand
REFLECTION
The biggest insight wasn’t about AI. The project reinforced that the problem wasn’t a lack of data. Captains already had information around them; what was missing was interpretation and a clear next action. It also showed how easily useful functionality can fail when discoverability is weak. The earlier Demand Areas work was a reminder that a feature can technically solve a problem and still fail to become part of a user’s behaviour. Most importantly, trust mattered more than intelligence. When AI is making recommendations that affect someone’s earnings, being understandable and explainable is more valuable than sounding sophisticated.