Context
Customers needed a broad choice of nearby restaurants
In 2018, the nascent Indian food-delivery industry was extremely competitive, with local competitors anchoring their moat through deep platform-funded promotions and free delivery while benefiting from domestic brand preference. The Uber Eats app experience was primarily US-centric and required localisation to adapt to South Asian user behaviours and needs.
Some of my work focused on making Uber Eats a market-adapted global product, localising customer journeys and operations for each market. One part was improving our restaurant partner experiences: the tablet, onboarding, and local experiments. Uber Eats tablets were our primary tool for communicating with restaurants in India, as most had no point-of-sale integration and our guidance had to make sense between orders.
Problem
Around 2018, restaurants received little direct help when sales began to fall after their two-week onboarding period
An initial analysis showed that restaurant sales came from a small top tier of partners, primarily established franchises with clear-cut playbooks for managing inventory, product range, and customer service. That left the majority of onboarded restaurants in a long tail that was difficult for our account management teams or starter playbooks to support one by one, so more education was needed.
I narrowed this to long-tail restaurants with declining sales. Performance could drift for weeks before an account manager stepped in. I kept coming back to one question: could we show restaurants a problem while they could still act on it?
Insights
Hands-on support was concentrated in the first two weeks
A new restaurant first spoke with sales, signed a contract, and entered a two-week launch period. We helped with menu photos and copy, pricing, promotions, and an initial visibility boost. Account managers stayed close through one-to-one support.
After that, account contact shifted to roughly every two weeks or monthly. The person managing orders was not always the owner or the person who had gone through onboarding. That was the gap I wanted to understand.
The Pareto pattern told me which restaurants to study. I spoke with long-tail partners, worked through recurring issues with account managers, and reviewed the internal dashboards they used in partner meetings.
Online-hour expectations were not always clear to the staff managing the shift.
Restaurants could go offline early without connecting it to fewer order opportunities and weaker visibility.
Reliability problems were hard to diagnose.
Teams saw late orders, but not whether the issue came from acceptance, preparation, or handoff.
Partners lacked a product-level view of demand.
They could not easily see which dishes were gaining views or orders, or might benefit from an offer.
Returns and poor item performance were easy to miss.
Problems could repeat before the right person saw the pattern.
Education was the common thread. Restaurants needed help understanding what had changed before the next account-management check-in.
Exploration
I looked at four ways to close the education gap
I worked with UX to turn those findings into quick concepts. We compared four routes by who they reached, how close they sat to the order workflow, their reliance on account teams, and delivery effort.
I chose the tablet, then cut the first version down to one question: would showing expected-hour coverage help restaurants cover more of those hours, and would sales improve?
Decisions
I changed the scope so the pilot could ship
The first technical estimate nearly stalled the pilot. The data team already had other commitments. I used the revenue exposure and competitor timing to make the case, then reduced the work in three steps.
Start with declining-sales restaurants in Hyderabad
I limited the pilot to one audience in one market.
Leave point-of-sale integrations out of the MVP
The first version used restaurants and data already managed through Uber Eats.
Do the metric discovery before validation
An analyst defined the measures and found candidate tables. This gave data engineering a smaller, better-defined plan to validate and removed several weeks from the estimate.
Solution
The MVP began with Engagement
Churn was the lagging business problem. For the MVP, I chose expected-hour coverage as the earliest behaviour restaurants could control, with weekly sales as the commercial check. More time online meant more chances to appear to customers and receive orders, so the Hyderabad pilot included only the Engagement view.
Engagement
Compare hours online with expected hours and estimate the sales missed while the restaurant was offline.
Reliability
See the current ready time, handoff performance by time of day, Missed Orders, and estimated lost sales.
Quality
Review returns, ratings, comments, and item-level problems before they affect more orders.
Trending Products
Follow seven-day demand for popular nearby dishes and find gaps between local demand and the menu.
Growth
Find dishes that could support an offer, check margin limits, and review sales after discounts.
Once we saw better expected-hour coverage and sales in the Engagement pilot, we added the other views in stages and used partner feedback to refine each one. The pattern stayed the same: show the number, explain why it matters, and suggest one next step.
Use the dashboard reconstructionResult
One view gave us enough evidence to keep building
The Hyderabad pilot included only Engagement. Restaurants covered more of their expected online hours, and the same cohort showed higher weekly sales. That gave us enough confidence to continue.
We added Reliability, Quality, Trending Products, and Growth in stages, gathering feedback as each view went live.
Conclusion
From Hyderabad to wider APAC markets
We expanded the dashboard across South Asia, and other product teams adapted the approach for additional APAC markets. The work also helped us prioritise better tools and data pipelines for measuring restaurant performance at scale.