Order integrity
Make it obvious the food order is safe and will not be delayed. This one outranked everything else, including conversion.
2023 · Careem · Quik
Project Flywheel: Cross-selling across a SuperApp
Careem runs a dozen services behind one icon, and only 6.7% of food customers had ever ordered groceries. I proposed the mechanic that changed that, then spent the rest of the project arguing about how far it should go.
Outcome
15–20%
of all new Quik users each day, making this the biggest acquisition driver we had
6.7% → 42%
Share of food customers who go on to order Quik
12%
higher Quik repeat-order rate after launch
550+
new orders a day coming through Flywheel
Context
A super-app only pays off when people use more than one service
Careem is a super-app. Rides, food, groceries, bill payments, car rental, laundry, a dozen more, all sitting behind one icon. The economics only work if the customer who books a ride also orders dinner, and the person who orders dinner also buys groceries. Careem had the services. What it did not have was much movement between them.
Careem Quik is the 15-minute grocery arm. When this project started, only 6.7% of food customers had ever placed a Quik order, and we had four months to take daily orders from 25,000 to 50,000 while roughly doubling Careem Plus membership in Dubai to 200,000.
Quick commerce runs on three multipliers: customer acquisition, operating levers, capital efficiency. Two of those sat with operations and finance. Acquisition was the one design could move, so that is where we went.
There was a catch. Customers already thought Quik was expensive. Delivery fees, minimum order value, the prices themselves. That perception was the biggest thing keeping people from trying it, well ahead of anything to do with stock or availability.
The problem
The cross-sell we already had was invisible
A banner promoting Quik was sitting inside the Food experience. It barely worked, for two reasons that fed each other. The home screen was noisy enough that people had stopped seeing banners at all. And a customer who has just ordered dinner cares about one thing, which is when the food arrives. Put a grocery promotion next to "where is my dinner" and the promotion loses every time.
Underneath that sits the problem specific to super-apps. Moving someone from food to groceries means asking them to switch mental models in the middle of an unfinished job. Nobody browses a supermarket while they are waiting for a pizza. The two mindsets do not overlap, and no amount of banner design fixes that.
So the question changed for me. Instead of asking how to make the banner better, I started asking when a food customer is actually open to hearing about groceries at all.
The answer showed up in the map. Once an order is confirmed people feel relief, and then they close the app. Nobody was using that gap between confirmation and delivery.
Worth saying plainly: that first journey map ran on assumptions carried over from older research. We had no fresh data for this problem. I knew it was a risk at the time, so we used the map to generate hypotheses and pushed the real proof downstream into concept testing. It mostly worked. It also cost us, which I come back to at the end.
The option we did not take
The most powerful idea was the one we left on the shelf
Discovery ran as a series of workshops I convened across Product, Business, Research and Marketing, working from problem space to goals to challenges to ideas. We came out with far more than we could build in two months, and two serious candidates for where a cross-sell should actually live.
The first used something only a super-app has. Careem knows when you take a car home from the office, which means it knows the moment you walk through your front door with nothing in the fridge. Technically it was not difficult. Commercially it looked excellent.
We deferred it. Our own discovery had already flagged the risk: customers may not trust recommendations that feel too contextual, and hyper-targeting reads as creepy. Getting that right needed research we could not fit inside the window we had. So we took the option we could stand behind immediately and left the harder one properly scoped instead of half-built.
The second candidate was the moment right after a food order is confirmed. That is where we went.
The solution
Add groceries to a food order that is already on its way
Flywheel lets someone add Quik groceries onto the food order they just placed. No second delivery fee, no minimum order value, and the same Captain brings both. It appears right after the food order is confirmed, in the window where the user would otherwise close the app. What gets recommended shifts through the day: drinks, desserts and fruit around lunch and dinner, coffee and lunch boxes in the morning.
User flow and prototype (food order → Quik basket)
On the ten-minute timer
The countdown was my idea. I had two reasons:
- The first is logistics. A Captain has to be dispatched, and the groceries have to reach that rider before they leave for the restaurant. No window, no feature.
- The second is FOMO. A visible countdown makes people decide. I knew that when I proposed it, and it's why I proposed it. Cross-sells that sit there indefinitely get ignored; this one has a deadline, and the deadline is real.
Five minutes was on the table. I argued for ten.
Five minutes is enough to feel rushed and not enough to actually look at what's in the sheet. Fifteen goes the other way: long enough that nobody treats it as a deadline, so it stops working. Ten was where both problems went away, and it happens to be about how long dispatch takes anyway, so ops didn't have to argue with it either.
The guardrails I wanted agreed first
A cross-sell is an interruption. It arrives uninvited, inside a task the person has not finished, at a moment when they are already slightly anxious about money they have just spent. I wanted the limits on the record before we designed anything, so they were not up for renegotiation later when the numbers started coming in. These came out of empathy maps we built across several food-user scenarios.
Ease the vertical switch
Being handed between two services mid-task was new to our users. The transition had to feel like the same app, not a second shop.
Graceful exit
Let people dismiss the sheet without feeling penalised or like they have lost an offer.
Clear logistics
Who brings what, and when. Especially for office addresses, where two separate orders get confusing fast.
Low cognitive load
Someone mid-order has very little attention to spare. Condensed choices, no deep browsing.
Concrete value
Free delivery, no service fee, time saved. Say the actual benefit instead of promoting it.
Validation
What ten people told us
We tested with ten participants, five single-service food users and five multi-service. The concept held up. Three findings forced changes before we shipped.
Nobody could tell if this was one order or two
The screen never said. The countdown implied a single combined order, which was wrong, and people were making that assumption at the exact point where they were about to pay.
Worry about the food order drowned out everything else
Most participants thought adding groceries would delay food they had already paid for. Until we answered that, nothing else on the screen got through to them at all.
The timer was invisible and unexplained
Hard to see, and nothing said why free delivery expired. The window I had fought to make more generous was doing none of the work it was supposed to do, because people could not tell it was there.
And then the one that mattered
Participants said the app felt like it was trying to push them into spending more.
That was the thing I had been uneasy about since proposing the countdown, handed back to me in a user's own words. It did not kill the project, but it set a hard ceiling on how far we could take the pattern, and it settled several arguments that were still open.
The same sessions gave us the way through. Participants kept saying restaurant drinks are overpriced, which told us snacks and beverages were the one cross-sell customers actively wanted rather than tolerated. We narrowed the recommendations down to those and dropped the ideas on the board that would have pushed harder into full grocery browsing.
What changed
Four changes between test and ship
- Put the food order status at the top of the sheet, permanently. Highest-value change of the four. It answered the worry before anyone had to go looking for reassurance.
- Shrank the product cards. More options visible at once, and less weight resting on any single choice.
- Made the timer bigger and attached the reason to it. Once people knew why the window existed, it stopped reading as a trick and started reading as logistics.
- Added a sticky timer chip. Time remaining stays visible while you browse, so nobody gets caught out halfway through choosing.
Reach
Four moments, and a framework that outlived the project
Flywheel ended up as four cross-sell milestones spread across the Careem journey: the rides home screen, checkout, order tracking and the payment summary. Each one tuned to whatever the user was doing at that point.
That is the super-app version of this problem. One sheet solves one handoff between two services. Four of them, placed where the seams already are, start making a collection of separate services behave like a single product.
Other teams picked it up. The home screen banner shipped on the back of it, and in 2024 Careem built the commute trigger we had deferred, for the journey home from the office, once there was research to support it. The idea had not been wrong. It had been early, and we said so at the time.
Impact
15–20%
of all new Quik users each day, making this the biggest acquisition driver we had
6.7% → 42%
Share of food customers who go on to order Quik
550+
new orders a day coming through Flywheel
12%
higher Quik repeat-order rate after launch
Reflection
What I would do differently
I would push for fresh research before the journey map. We built on inherited assumptions and got lucky that concept testing caught what we'd missed: the worry about order integrity surfaced weeks later than it should have, and it turned out to be the finding that changed the design most.
I would also measure the cost side. We tracked acquisition and repeat rate, and both looked excellent. We never tracked dismissals, or whether seeing the sheet every week wore people down. A cross-sell that works in Q1 and irritates everyone by Q3 would have looked identical on our dashboard.
If fatigue had shown up, the fix wouldn't have been a softer offer. The ten-minute window is what makes free delivery and one Captain possible; loosen it and you're offering something smaller, not gentler. The lever was exposure: someone who has dismissed the sheet three times has answered, and a fourth showing is noise. I'd have capped frequency for that group and left the mechanic alone for everyone else. We never measured it, so this is a plan for how I'd have responded, not proof I needed to.
