Grab · Execution · Mid · 45 to 60 minutes
How to scale Grab chat support
Grab is a Southeast Asian superapp for transport, delivery, payments, and other everyday services. Answer this product management case and get it graded line by line against a weighted rubric.
- Prioritization
- Metrics design
- Experimentation
- Operational thinking
- User empathy
The situation
You are the PM for support experience at Grab. Leadership wants to expand real time chat as an alternative to phone support because users want help inside the app and agents need a support flow that fits digital issues better than voice calls. An early in app chat experience has shown promise, but the operation is under strain as demand grows. During peak periods, users wait too long before an agent joins, some are no longer responsive by the time support arrives, and agents spend too much time typing and managing several conversations at once. Support leaders also lack enough live visibility to make quick operational changes when queues spike. Engineering can improve both the user chat flow and the agent tool, but capacity is limited and any plan must work across multiple countries, issue types, and support teams. The Head of Support and an engineering lead ask you for a plan for the next two quarters. What should Grab prioritize in the chat journey, how would you measure success, and how would you roll changes out without harming service quality or forcing users into a worse channel?
What to produce
Write a 1 to 2 page product execution memo.
Your answer must
- Define the core problem in the chat support journey and break it into the most important sub problems for users, agents, and operations.
- Recommend a prioritized plan with 3 initiatives max for the next two quarters, with rationale, expected impact, and key trade offs.
- Specify a success framework with 1 north star metric and at least 4 supporting operational metrics, plus guardrails.
- Describe how you would instrument, test, and roll out the changes, including how you would learn quickly before full scale launch.
- Explain how your plan handles situations where chat demand exceeds support capacity and what fallback experience users should have.
Constraints
- Do not assume new agent headcount in the next quarter.
- Build on Grab's existing app and internal support tooling, not a greenfield support stack.
- The solution must work across multiple countries and issue types, so heavy manual tuning by market is not scalable.
- Phone support may remain as a backup channel for cases where chat cannot meet service levels.
Format
Use short sections such as problem, priorities, metrics, rollout, and risks. A simple table for metrics or prioritization is fine.
How Grab actually played it
Grab moved support from phone queues to chat and reports what changed. Smarter routing cut chat waiting time by about 30 percent and unresponsive users by about 7 percent, and a chat timer and prompts cut average chat time by 12 and 22 percent. The post connects each product tweak to a measured support metric.
- Move users to the channel that fits the problem, then optimize it.
- Small prompts and timers can beat large rebuilds.
- Report each change against a named operational metric.
Built from Reshaping Chat Support for Our Users by Grab Engineering.
Related case studies
- Cut post allocation ride cancellationsGrab · Metrics · Mid
- How should Grab serve grocery shopping?Grab · Product sense · Mid
- How should Grab pilot a driver growth loop?Grab · Go-to-market · Entry
- How should Grab summarize merchant reviews?Grab · AI product · Mid
- Improve rider driver communicationGrab · Product sense · Entry
- Google Docs launch cut plan for Review QueueGoogle Docs · Execution · Mid