Designing how automated decisions speak
OVERVIEW
Grab PayLater provides users bill flexibility. Users can split a payment into 4 interest-free chunks or pay it all next month in a postpaid plan!
Whether a user could activate PayLater was decided automatically by Grab's risk and eligibility checks. My job was to design how those automated decisions were explained to users, including the ones we legally couldn't explain, in a highly contextual and empathetic manner. These errors caused a 30% drop in activation and adoption conversions within just 14 days of its launch.
GOAL
-
Investigate why the Help Centre receives a high volume of calls and identify which reasons can be shared with our users.
-
Turn every automated rejection into a clear outcome: what happened, what it means, and what to do next.
-
Define a safe fallback for every decision we couldn't disclose, so no user hit a dead end.
PROJECT STAKEHOLDERS
Product Marketing Manager, Product Manager, Product Designer, Legal and Compliance (Regulatory), Risk, and the Help Centre team.
MY ROLE
-
Teamed with data and support to estimate the cost of unclear activation errors, building a business case around 14–18 extra calls a month.
-
Mapped every eligibility reason to a disclosure tier with Legal and Compliance, defining what users could be told, what they couldn't, and the fallback for each.
-
Wrote the error messages, titles, and button copy for each tier.
-
Linked each message to the matching Help Centre FAQ, turning errors into a self-help tool, and rewrote the FAQs with the Help Centre team so the two matched.
THE PROBLEM
Several factors prevented users from activating PayLater on the Grab app across Southeast Asia (SEA). For users to understand why they cannot avail PayLater and how to fix it, we needed to provide simple and contextual messages.
Eight different automated checks could stop a user activating PayLater across Southeast Asia, but every one of them reached the user as the same vague error.
Existing error message
-
Low credit score
-
Fraudulent activity
-
App inactivity
-
Transaction declined
-
Rewards tier status
-
Age restrictions
-
KYC rejection
-
Overseas access
Unclear reason and a vague solution can leave users unsure and frustrated.
Does not state where to find the relevant information.
Let’s be honest, a lot of these reasons couldn't be disclosed to users due to privacy and legal concerns.
AN OPPORTUNITY
So, how might we clearly explain to users why they can't get PayLater without revealing sensitive information and remaining legally compliant at the same time?
PAYLATER ONBOARDING
DESIGNING THE FALLBACK DECISIONING
PayLater activation dynamically adapts to the user: identity verification, setting a PIN and enabling auto-deduction can be completed in any order. Mapping each automated check to two groups:
Usage checks:
Users with a declined transaction, no reward tier, trying to use PayLater when overseas, or being inactive on the Grab app exceeding 6 months, won't be able to complete this step.
Identity or risk checks:
Users with age restriction, KYC rejection, fradulent activity or low credit score won't be able to complete this step.
Now, let's understand how the decision reached the user?
Risk engine returns a reason code → content maps the code to a disclosure tier, agreed with Legal and Compliance → user sees a message and a next step, and the FAQ link →If the user still can't resolve it, Help Centre is the exit.
Once we identified where these errors occur, I aligned on 3 design tenets that error messages must satisfy, and when apologies are necessary.
EMPATHY
Feel user frustration — be it product issues, service mishaps, delays, policy changes, or data breaches —empathetic acknowledgment and sincere apologies are vital.
ACCOUNTABILITY
Owning up to mistakes.
Beyond legal compliance, a user's loyalty hinges on transparent and timely communication.
Taking responsibility for the issue help restore a positive user experience.
COMMITMENT
Help users move forward.
Providing clear solutions or workarounds, while safeguarding sensitive information can effectively guide users past the problem.
Disclosure Tiers:
2 rules behind the tiers:
• Never reveal a sensitive reason by elimination. The tier 3 message is identical for credit, fraud and KYC, so no combination of messages narrows it down.
• Every message has an exit. If users can't fix it themselves, they're one tap from the right FAQ or the Help Centre.
HOW CAN WE CONTEXTUALISE THESE ERROR MESSAGES TO USERS' THOUGHTS, FEELINGS, AND EXPECTATIONS?
Looking at the number of users and the category of ineligibility they fall under, I came up with a win-win idea that would meet user needs and the company's priorities.
I used SEO to ensure the CTA links within the error messages direct users to relevant FAQ articles. This became a self-help resource, allowing users to troubleshoot issues on their own and find information without direct assistance.
FINAL DESIGN
Our research indicated that most users only skim through the error message, so we aligned the title and button copy of the error message for clarity. This way, even if users don't read the body copy, they'll know what to do next.
1. Incomplete Activation (TIER 1): The user's PayLater activation got paused. The user needs to complete the pending steps through the link to become eligible again!
Before
After
The reason
The workaround
The solution
2. Not eligible yet (TIER 3 Fallback): The user has lost his eligibility due to a number of factors. The user needs to follow the next steps (link) to become eligible again.
Before
After
3. Overseas access (TIER 1): A user's Grab points and vouchers won't work in other Southeast Asian countries due to security checks. To use them there, the user needs to get whitelisted in the new country.
Before
After
Previously, age discrepancies couldn't be identified among PayLater applicants. Implementing age validation error messages resolved this issue.
4. Under-age
(TIER 1)
5. Over-age
(TIER 1)
RESULTS
The positive impact on Activation conversions increased the overall PayLater revenue.
Activation conversions went up by
60% (3.5 pp).
SINGAPORE & MALAYSIA
Based on age validation checks alone, we identified the following number of users.
Under-age users: 1,210
Over-age users: 182
SINGAPORE & MALAYSIA
Our Help Centre team received
30%
fewer tickets
and made
15%
fewer calls than last year.
SINGAPORE & MALAYSIA
Concept: if an AI agent handled this today
A design exploration, not shipped work. The disclosure tiers become the guardrails for a voice or chat agent answering the same question.
Tier 3 conversation (reason can't be disclosed):
-
Customer: Why can't I get PayLater?
-
Agent: I've checked, and PayLater isn't available on your account right now. I can't share the exact reason, as it's based on checks we keep private to protect you. What usually helps is using Grab regularly and keeping your payments up to date. Want me to send you the steps, or connect you to our team?
-
Customer: Is it my credit score?
-
Agent: I'm not able to say which check it was, sorry. Our team can explain your options in more detail if you'd like. Shall I connect you?
Tier 1 conversation (reason can be disclosed):
-
Customer: Why can't I turn on PayLater?
-
Agent: You're nearly there. You just need to set up your PIN to finish activating. Want me to take you there now?
KEY TAKEAWAYS
-
Automated decisions need a communication layer designed as carefully as the decision logic itself. Defining what we could disclose, what we couldn't, and what to say instead turned an opaque rejection into a next step, and lifted activation by 60%.
-
Sensitive reasons can be handled honestly: say what you can, never hint at what you can't, and always offer a way forward.
-
Content shapes the experience even under engineering constraints. Clearer messages changed outcomes without changing the eligibility rules.
-
Error messages and Help Centre content are one system. Our FAQs were out of sync with the app, so we rewrote them together with the Help Centre team and pointed each message's link at the right article.
REFLECTION
Looking back, I'd add a logged default for any unmapped reason code, so a new risk rule could never reach users as a generic error. I'd also measure repeat contacts by tier, to see which messages still left users stuck.