You shipped it. It works. Tickets are resolving. So why are customers leaving?

Gladly's 2026 Customer Expectations Report uncovered a gap that most CIOs don't see until it's too late: 88% of customers get their issues resolved through AI — but only 22% prefer that company afterward. Resolution without loyalty is just churn on a delay.

The difference isn't the model. It's the architecture. How AI is integrated into the customer journey, what it hands off and when, and whether the system is designed to build relationships or just close tickets.

Download the report to see what consumers actually expect from AI-powered service — and what the data says about the platforms getting it right.

If you're responsible for the infrastructure, you're responsible for the outcome.

Get the data

Most personalisation systems are lying to you. Not maliciously. They just operate on yesterday's information.

When a user books a Grab ride to a mall, the app has a window — maybe fifteen minutes — to offer them something relevant. A dining discount. A GrabPay reward for shopping. A nudge based on where they're going and what they usually do there.

But Grab's personalisation system wasn't built for that window. It was built for a different world.

For years, Grab's user data system — the central place that stores everything the company knows about its passengers, drivers, and merchants — updated once a day. Every morning, a scheduled job would run, process the previous day's activity, and write fresh user profiles. Campaign targeting, personalisation, ad retargeting — all of it depended on this daily refresh.

That system tracked over 1,000 data points per user across Grab's three-sided marketplace (passengers, drivers, merchants). It was powerful and well-managed. It powered marketing, experiments, machine learning features, and connections to ad platforms like Facebook Ads and TikTok.

But it was built to look backwards, not react in the moment.

The gap was real. Think about what happens at an airport. A user lands, opens the Grab app, and is immediately in a moment of genuine need — they want a ride, maybe they're hungry, maybe they need a hotel recommendation. The best time to reach them is right now, in this specific context. Not based on what they did last Thursday.

With once-a-day updates, Grab couldn't act in that window. By the time the daily refresh ran, the traveller was already in their hotel.

The engineering team also spotted a deeper problem. Whenever someone at Grab wanted a new real-time personalisation feature, an engineer had to build a custom system from scratch. The growth team wants to re-engage users who abandoned checkout? An engineer builds a one-off pipeline. Every new idea meant new code, new infrastructure, and a long wait. Marketers and product teams couldn't move without engineering help, and engineering was always stretched.

Grab's answer was a feature called Scenarios, built on top of the existing user data system.

The core idea is simple: instead of asking "what did this user do yesterday?", Scenarios ask "what is this user doing right now, and what do we already know about them that makes this moment matter?"

A Scenario is a rule — set up by marketers, not engineers — that combines three ingredients.

When those ingredients come together and a Scenario fires, Grab can send a personalised action — a push notification, an in-app banner, or an ad — within 15 seconds of the triggering event.

The system runs on three main technologies: Scribe, Flink, and Kafka.

Scribe is Grab's internal event tracker. Every meaningful action in the Grab app — a tap, a booking, a screen view — creates a Scribe event. These events are the raw material for real-time personalisation.

Flink is the processing engine. It receives those events and applies the Scenario rules. Think of it like a factory assembly line versus a warehouse. A warehouse collects everything and processes it all at the end of the day. An assembly line handles each item the moment it arrives. Flink is the assembly line. It processes each event immediately, applies the rules, pulls in historical data if needed, runs the prediction model if one is configured, and produces an output — all within the 15-second target.

Historical context comes from StarRocks, a database built for fast lookups. When a Scenario needs background information — say, pulling a user's food preferences to make sense of their current mall visit — Flink queries StarRocks in the middle of processing and folds that data in. This is what makes the system genuinely powerful: it doesn't just react to what just happened. It combines that with everything the platform already knows.

Kafka handles the output side. Think of it as a reliable delivery system that carries data between different services at high speed. Scenario results flow through Kafka to whatever needs them: notification systems, ad platforms, in-app personalisation. For services that prefer to look up results on demand rather than receive a constant stream, Grab routes outputs to Amphawa — the company's internal data store, built on Amazon's DynamoDB.

The system solves a real tension: how do you make personalisation fast without making it fragile?

The self-serve interface was a deliberate choice. The old approach — engineers building custom systems for every new use case — had hit a wall. It worked, but it couldn't keep up. By putting Scenario creation in a visual interface that non-engineers could use, Grab separated two problems: the infrastructure (built once by engineers) and the experimentation (done anytime by marketers). A new Scenario goes live within an hour of being set up.

(Image below)

This design also meant Scenarios could be tested before going live. Marketers can run a new Scenario against fake data — the system processes test events and shows what would happen. That matters when a badly configured trigger could send the wrong notification to millions of users.

Supporting both Kafka and Amphawa as outputs was a practical decision. Some systems want a continuous stream of data. Others want to look things up on demand. Supporting both meant Scenarios worked across Grab's existing setup without forcing other teams to change anything.

The location-based targeting is worth highlighting. Scenarios can be set to fire only when a user is in a specific place — an airport terminal, a particular mall, a hotel zone. A user booking a ride to a mall isn't just showing intent to visit. They're creating a window where a relevant offer could actually change what they do. The system can factor in their destination, the time of day, their spending history, and their food preferences to decide whether they're likely heading to shop, get groceries, or eat — and serve the right offer.

The team had over 12 live Scenarios running in production at the time of writing.

The main example Grab shared was the Grab Unlimited sign-up flow. Grab Unlimited is the company's subscription product — recurring discounts on rides and food delivery.

The problem was abandonment. Users would start signing up, get partway through, and leave. The old approach to winning them back was delayed and generic — not triggered by the actual moment of abandonment, not timed to when the user was still interested.

The Scenario rebuilt this as a real-time trigger. When a user started the sign-up but didn't finish, the system captured the abandonment. It processed the event, checked the user's history, and fired a re-engagement notification within 15 minutes. The notification was personalised, well-timed, and sent only to users who had actually abandoned.

The result: a 3% increase in subscriber conversions compared to campaigns that didn't use real-time triggers.

Three percent sounds small. But in subscription economics at Grab's scale — 800 cities across eight Southeast Asian countries — it adds up fast. And it came from a Scenario that a marketer set up without a single engineering sprint.

The engineering team outlined three directions.

The first is smarter scaling. As more Scenarios run at once, managing the processing infrastructure gets complex. The goal is to make this more automated so new Scenarios don't need manual setup to handle the load.

The second is multi-destination outputs. Right now, each Scenario sends results to one place. Some use cases need the same signal to go to multiple places at once — one trigger fires, and both the notification system and the ad platform get the message.

The third is delayed delivery. Real-time processing doesn't always mean real-time delivery. Grab wants to calculate a signal the moment it's available but deliver it at the perfect future moment. If a user gets dropped off somewhere with a typical 15-minute Grab wait time, the system could send a "book your return ride" notification timed to exactly when they'll need it — calculated instantly, delivered on a schedule.

Together, these point toward something bigger: a personalisation layer that doesn't just react to what users are doing, but anticipates what they'll need before they ask.

The gap between "we can send a push notification" and "we can react to any user event, enriched with historical context and live predictions, within 15 seconds, for 12 simultaneous use cases, without requiring an engineer for each one" — that gap is enormous. It's exactly the gap Grab's Scenarios system was built to close.

That’s all for today.
Don’t forget to tell me how you liked this case study
—Sid

This article is based on publicly shared details from Grab's engineering team. If you notice any inaccuracies, please let me know.