Building an Effective UPI In-App GRM for India’s Consumers

Authors 1: Aishwarya Narayan, Deepti George

0F

Abstract
UPI has emerged as a ubiquitous payment mode for small-ticket transactions, and a variety of new
solutions within UPI have been rolled out targeting low-income and low-digital proficiency user groups. To
ensure that these advancements result in tangible positive effects on users’ experiences with UPI, it is
important to monitor customer grievances and grievance resolution experiences. Data across public and
non-public sources indicates that the user experience of grievance redressal is not hassle-free. In this
study, we focus on whether consumers use the grievance mechanisms provided in UPI apps in
smartphones, and whether those mechanisms make for an easily navigable grievance redress journey
ending in satisfactory resolution. Through this three-phased project, we seek to improve the
comprehension and effectiveness of in-app grievance redressal experiences in UPI applications - with a
focus especially for constrained users who form a significant segment of UPI consumers. In the first phase,
we conducted an on-field study to understand how constrained and new-to-UPI user groups interact with
the in-app GRMs in UPI applications and to deduce bottlenecks in the user journey through user testing.
The following phase leveraged the insights from this fieldwork to create an improved prototype of the
grievance redress mechanism for a UPI app. These prototypes were tested on-field with users in the final
phase, to understand whether they solved various user concerns and whether any additional changes to
the prototypes were required. Besides the prototypes, the report covers user experience guidelines for
designing UPI in-app GRMs, a consolidation of the key insights from this project. The GRM Framework for
UPI, also placed in this report, can support GRM design and aid in strategic long-term decisioning for it.
We believe these, and the Toolkit accompanying this report, will be of value to policymakers, regulators,
banks, TPAPs, product tech and design enthusiasts who are trying to design digital interfaces for the billion
users.

Disclaimer: We have focused on improving the constrained users’ experience for their grievance redress journeys with payments
transactions related issues in UPI via this project. The UPI GRM has many other, more sophisticated components, such as merchant
flows, credit card and credit line flows, among others, to be further studied from a UX perspective and possibly strengthened in
the future.

1
This report documents the research and activities undertaken for this project. The project has been executed with
the ample support of Achyutha Sharma and Narayan Gopalan, who are consultants hired by Dvara Research.
Contents
Project Context & Motivation ....................................................................................................................... 5
Methodology................................................................................................................................................. 9
Phase 1: Problem-First Research................................................................................................................. 12
Stage 1: Triggers for the redressal journey ............................................................................................. 13
Stage 2: Discovering & accessing channels for redressal ........................................................................ 14
Stage 3: Grievance Submission ............................................................................................................... 16
Stage 4: Grievance Redressal Follow-Up ................................................................................................. 17
Stage 5: Grievance Redressal .................................................................................................................. 18
Stage 6: Impact of GRM on Users ........................................................................................................... 18
A Mental Model for Constrained Users’ Grievances ............................................................................... 19
GRM Framework for UPI in India ................................................................................................................ 20
Consumer Value I: Inclusive .................................................................................................................... 21
Consumer Value II: Simplified Process .................................................................................................... 21
Consumer Value III: Resolution ............................................................................................................... 22
Consumer Value IV: Protection ............................................................................................................... 22
Adopting the UPI GRM Framework......................................................................................................... 23
Phase 2: Solution Approach ........................................................................................................................ 24
Overarching Goals for the Solution Approach ........................................................................................ 24
Summarised Problems ............................................................................................................................ 26
Applying The Design Process .................................................................................................................. 26
Mapping the User Journey .................................................................................................................. 26
The HMW (How Might We’s) .............................................................................................................. 27
Wireframing ........................................................................................................................................ 27
Designing user flows with a help navigation tree ............................................................................... 28
Phase 3: Prototype Testing .......................................................................................................................... 29
Key Evaluative Insights ................................................................................................................................ 29
Entry into Help ........................................................................................................................................ 29
‘Help’ Landing Screen.............................................................................................................................. 31
Problem Identification for Transaction Related Issues............................................................................ 32
Data Gathering For Transaction Related Issues ...................................................................................... 34
Resolution for Transaction-related Issues ............................................................................................... 35
Self-Resolution Without Ticketing........................................................................................................... 35
 Pending or in-progress Transactions ................................................................................................... 35
Failed Transactions .............................................................................................................................. 36
Grievances related to UPI Autopay ..................................................................................................... 37
Grievances Related to Fraudulent Transactions.................................................................................. 38
Resolution with Ticketing ........................................................................................................................ 40
Ticket Filing.......................................................................................................................................... 41
Ticket Confirmation and Acceptance .................................................................................................. 42
Ticket Tracking ..................................................................................................................................... 43
Broader Insights ...................................................................................................................................... 44
Project’s Limitations .................................................................................................................................... 45
Takeaways for Stakeholders ........................................................................................................................ 46
Impact on the User ................................................................................................................................. 46
Impact on UPI App Providers .................................................................................................................. 46
Supporting Regulators’ Objectives for Inclusive Digital Payments.......................................................... 47
User Experience Guidelines for Designing UPI in-app GRMs .................................................................. 47
Conclusion ................................................................................................................................................... 50
Appendix I: Comparative Study of UPI Apps ............................................................................................... 51
Appendix II: Prototypes............................................................................................................................... 52
Project Context & Motivation
UPI, unlike other products in financial services, is lightning-fast, and enables payments between persons,
without the need for any trusted human intermediary (such as the merchant with a Point-Of-Sale (POS)
machine, the Business Correspondent (BC) touchpoint, the bank employee) or the bank’s mobile or
internet banking portals, or even an OTP. It relies on identifiers such as mobile number, name, QR code
and UPI ID, rather than on bank account or IFSC numbers. Buoyed by this seamless experience, meteoric
adoption has followed (see Table 1), due to UPI’s very intuitive product features and ease of use for
literacy-constrained users. In June 2024, of the 13.88 billion UPI transactions that citizens and their
businesses executed, about 63% were P2M and 37% were P2P. An overwhelming 85% of P2M transactions
and 77% of P2P transactions were below INR 500 in value2, implying that a significant portion of
transactions may be coming from individuals from lower-income backgrounds, new to banking and new
to digital financial services.

Many of the developments in the UPI ecosystem are

Table 1: Participating entities enabling UPI 3
1F

focused on making the payments experience accessible

Banks
and convenient for the average Indian customer. For
PSP & Issuer 52
instance, the Reserve Bank of India (RBI) recently
Issuer only 535 launched UPI123Pay to facilitate payments through
PSP & PPI Issuer 15 feature phones.4 Further, users can now make UPI
TPAPs 30
payments without internet access through UPILite, an
on-device wallet that can fund transactions below INR
PPI App providers 19
200.5 The RBI has also approved the linking of RuPay
credit cards to UPI for a digitally enabled credit card experience for customers.6 Customers can also
manage recurring payments through the UPI ecosystem, using UPI AutoPay.

There have also been considerable improvements in the user experience for customers filing grievances
on the UPI platform. In 2020, NPCI had introduced an online dispute resolution (ODR) system to support
the handling and resolution of grievances pertaining to UPI transactions.7 This feature, the Unified Dispute

2
NPCI. (2024). UPI P2P and P2M Transactions. Accessed via https://www.npci.org.in/what-we-do/upi/upi-
ecosystem-statistics#innerTabThreeJun24
3
Retrieved from NPCI website on 1st August 2024
4
Reserve Bank of India. (2022). Reserve Bank of India launches (a) UPI for Feature Phones (UPI123pay) and (b)
24x7 Helpline for Digital Payments (DigiSaathi). Accessed via
https://www.rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx?prid=53385
5
NPCI. (2022). Introduction of “On-Device wallet” – UPI Lite for Small Value Transaction. Accessed via UPI-OC-138-
Introduction-of-On-Device-wallet-UPI-Lite-for-Small-Value-Transactions.pdf (npci.org.in)
6
NPCI. (2022). Operating Circular for RuPay Credit Cards linked to UPI – Amended. Accessed via
https://www.npci.org.in/PDF/npci/upi/circular/2022/RuPay-OC-019-A-Operating-circular-for-RuPay-Credit-Cards-
linked-to-UPI-(Amended).pdf
7
NPCI. (2020). UDIR-Enhancing Complaint handling and resolution process for UPI transactions. Accessed via
https://www.npci.org.in/PDF/npci/upi/circular/2020/Circular-98-UDIR-Enhancing-Complaint-handling-and-
resolution.pdf
& Issue Resolution (UDIR) system, also referred to sometimes as UPI Help, has considerably improved the
transparency of transaction statuses to the customer through automated transaction and dispute status
checks and pre-approved online refunds for disputed/failed transactions.8

While these improvements have certainly improved the customer experience of UPI, it is important to
continue monitoring customers’ UPI grievances as well as their experiences of grievance resolution to
ensure that all these developments actually translate into reduction of pain-points in users’ UPI
experience.

We try to comprehend the nature of pain-points experienced by constrained users who are new to UPI,
using various available data sources. For the purpose of this project, we have defined the constrained user
as someone from a low-income household and with low-mid level digital proficiency in India. Data on the
true level of issues is spread across many public and non-public data sources. For instance,

➢ Of the nearly 200,000 complaints received by the RBI Integrated Ombudsman in FY 2022-23, data
points to a 30% jump in the proportion of mobile/electronic banking complaints from the previous
year. It is unclear how much of this is in relation to UPI.

➢ Technical declines9 in the month of June 2024 ranged from 0.02% to 15.42% bank to bank –
indicating considerable variation between these banks.

Table 2: Some Statistics on Debit Reversals and downtime incidents in UPI

Debit Reversals Jan 2022 Apr 2024
Proportion of UPI transactions of top remitter banks that went into 0.67% 0.61%
debit reversal
Bank with lowest proportion of such transactions 0.22% 0.00%
Bank with highest proportion of such transactions 4.99% 3.74%
Median value across banks for this proportion 0.86% 0.56%
Banks with debit reversal transactions >1% of their UPI transactions 19 5
Proportion of total UPI transactions that these banks process 15.15% 2.19%
Downtime Incidents and Duration Mar 2023 Mar 2024
Member Banks with at least 1 Incident Count 10
9F 25 13
Longest downtime by a bank (Incident count, downtime in hours) 28, 62:32 hrs, 17, 48:52 hrs,
State Bank of India India Post
Payments Bank

8
NPCI. (2023). Implementation of Advanced API as part of UPI Help. Accessed via
https://www.npci.org.in/PDF/npci/upi/circular/2023/NPCI-UPI-OC-165-Implementation-of-advanced-refund-API-
as-part-of-UPI-Help-(UDIR).pdf
9
As defined by NPCI, technical declines refer to transactions being declined due to technical reasons, such as
unavailability of systems and network issues experienced by the bank or NPCI.
10
As stated by NPCI, Incident/downtime criteria are transaction decline count more than 3 Lakh (300,000) and
duration more than 30 minutes. Accessed via https://www.npci.org.in/statistics/bd-td-and-uptime
 ➢ NPCI’s data on debit reversal success rates indicates the proportion of transactions wherein a
customer (payer) account may be debited and their bank is unable to confirm instantly the status
of reversal of the debit. When reversal/credit is not processed instantly, it is processed manually
by the bank 11. Data on debit reversals can provide some insights into consumers’ experience in
10

the event of a transaction failure. Debit reversals had a good variability between banks (See Table
2, Figure 1 and 2). For January 2022 and April 2024, less than 1% of UPI transactions needed a
debit reversal in the overall system. During the months between these two reference months,
while the base (volume of UPI transactions) has burgeoned and so has the number of institutions
on-boarded, the number of banks with more than 1% of their transactions going into debit
reversal, has dropped considerably from 19 in January 2022 to just 5 in June 2024 (Table 2).

➢ NPCI’s data on downtime incidents in UPI, where transaction decline counts were more than
300,000 and for a duration more than 30 minutes, reveal, that the period between March 2023
and 2024 saw a more than 50% drop in the total number of incidents, from 110 to 51 (Table 2).
Incident counts for State Bank of India, the country’s largest bank, dropped from 28 to 2 in the
same period.

➢ Figure 1 charts the proportion of debit reversals that did not succeed, among the total debit
reversals for the period of January 2022 to April 2024 for 42 banks.12 Clearly there is considerable

Figure 1: # of Top Remitter Banks, Failed Debit Reversals

/ Total Debit Reversals (Histogram)

11
Description as per NPCI webpage on UPI Ecosystem Statistics.
12
Debit reversals that did not succeed for each bank in a given month were calculated as: (100% – debit reversal
success rate for the month) x Total number of debit reversals for the month. The total number of month-wise debit
reversals that did not succeed for a bank, over the period January 2022 - April 2024 is summed up, and divided by
the total number of all debit reversals for that bank over the same period. The resulting figure is plotted for 42 banks
for whom data was available, in Figure 2.
 variation across banks, with public sector banks performing relatively better than their private
sector counterparts.

Figure 2: Proportion of debit reversal transactions that did not succeed (in the month) for 42 of
the Top 50 Remitter Banks
80%
70%
60%
50%
40%
30%
20%
10%
0%

Rajasthan Marudhara Gramin…

Andhra Pradesh Grameena…
Bandhan Bank

Karur Vysya Bank

Bank of Baroda
Karnataka Bank

ICICI Bank

Federal Bank
South Indian Bank

UCO Bank
Jammu and Kashmir Bank

Yes Bank Ltd

IDBI Bank Limited

Union Bank of India

State Bank Of India

Airtel Payments Bank

Fino Payments Bank

Bank of Maharashtra

Maharashtra Gramin Bank

Saraswat Bank
IndusInd Bank
City Union Bank

HDFC Bank Ltd

Punjab and Sind Bank

India Post Payment Bank

IDFC First Bank
Ujjivan Small Finance Bank

AU small Finance Bank

Axis Bank Ltd

Kotak Mahindra Bank

Central Bank Of India

Punjab National Bank

Standard Chartered

Indian Bank
Bank of India
Canara Bank

Indian Overseas Bank

DBS Bank India Limited
Tamilnad Mercantile Bank

ESAF Small Finance Bank Ltd.

Pragathi Krishna Gramin Bank

Kerala Gramin Bank
Private Public Sector RRB / Cooperative

➢ A recent report by Bureau and Praxis noted that in May 2022, 55% of all digital payment frauds
were related to UPI and half of these frauds were of a small-ticket size (less than Rs. 10,000).13 A
study by the Future Crime Research Foundation at IIT Kanpur revealed that online financial fraud
constituted 77% of all cybercrime incidents in India between 2020 and 2023. Among these, frauds
within UPI were the most prevalent, accounting for 47.25% of all online financial frauds.14

➢ An inhouse AI/ML social media market monitoring suptech tool created by Dvara Research, called
Dvara PARSE, for tracking UPI-related issues on Twitter/X and Google PlayStore indicated that since
Q1 of 2020 till Q1 2024, negative social media posts formed 67% of posts linked to prominent UPI
app handles. Of these:

• About 33% of the time, these posts were about 'transaction failures'.
• Another 33 % of the time, they were about 'inadequate redress’.
• About 13% of the time, ‘transaction failures’ and ‘inadequate redress’ co-occurred.

The remaining categories that the tool ‘clustered’ pertained to technical issues, access issues,
fraud, and third-party issues. Social media had more datapoints than the RBI ombudsman - 42
posts were available for analysis for every complaint in the Ombudsman forum.

Considering these data points together, we conclude that while UPI has focused sharply on improving
user-ease for executing transactions, the user experience of its grievance redressal mechanisms is not

13
Bureau & Praxis. (2023). Anatomy of Fraud 2023. Retrieved from https://www.praxisga.com/reports-and-
publications/technology/anatomy-of-fraud-report-2023
14
Future Crime Research Foundation. (2023). A Deep Dive into Cybercrime Trends Impacting India. Future Crime
Research Foundation, IIT-Kanpur.
hassle-free. Third Party Application Providers (TPAP) and banks do have in-app grievance resolution
mechanisms that are managed by very sophisticated teams of specialists. More importantly, NPCI’s UDIR
has pushed the entire ecosystem of participants to obtain much faster settlements for the end-user for
pending and failed transactions. The question we ask is, do consumers use UPI’s In-app grievance redressal
mechanisms (GRM) and do they obtain resolution through it? What are the barriers to effective use, and
what can be done to improve the customer experience of the In-app GRM, so that they can engage with
it meaningfully, to make wholesome, their experience of their UPI app?

Through this project, we seek to improve the comprehension and effectiveness of in-app grievance
redressal experiences in UPI apps - with a focus on especially constrained users who form a significant
segment of the Indian consumer. This work complements the UDIR’s efforts to engender trust in UPI by
accelerating the process of settlements for pending transactions, in that, it seeks to engender trust through
enhanced comprehension of the GRM process and clarity for the constrained user.

Methodology
Our project objectives have evolved through the course of this project, as we have learned more about
constrained users and their usage of grievance redressal within their UPI app. This work began when we
observed how users learn about UPI - through their social networks such as friends and family.15 They avail
help to memorise essential actions on the UPI app, like sending money to a friend, or checking their
transaction history. Users are not familiar with navigating and exploring an app’s information architecture
on their own. We hypothesised that users may not be able to use grievance functions with ease.

To first understand the grievance redressal offerings in the UPI ecosystem, we embarked on a self-review16
of some of the top UPI apps in 2022-23 (both TPAP apps as well as bank apps). Through this app analysis,
we identified aspects of the user’s grievance redress journey which were potentially difficult to access and
use. At the time of writing the earlier report in March 2023, we found that some apps did not have any
grievance functionalities; while those that did had hard-to-understand tracking features and inconsistent
support for vernacular languages across apps. This exercise provided a basic understanding of potential
problem areas from the researchers’ lens.

Moving forward, we pivoted our methodology to reflect a more human-centred approach. We conducted
user testing to validate and expand on the problem areas identified through the researcher’s lens and
arrive at broad principles for designing accessible in-app grievance redress for UPI. This work unfolded in
three phases and is further detailed in the coming sections of this report:

15
Dvara Research. (2022). Understanding new-to-UPI users’ experiences with UPI-based digital payment apps.
Accessed via https://dvararesearch.com/wp-content/uploads/2023/12/Dvara-Research-Centre-for-Social-and-
Behavioural-Change-UPI-Quantitative-Report.pdf
16
Dvara Research. (2023). Do UPI Grievance Redress Mechanisms Work for Constrained Users? Accessed via
https://dvararesearch.com/do-upi-in-app-grievance-redress-mechanisms-work-for-constrained-users/
 • Phase 1: Problem Discovery

The problem discovery phase consisted of 2 parts. First, we conducted an expert 17 analysis of top UPI apps
6

to look for consistency across apps along a set of themes/features (See Appendix I). Throughout the rest
of the project too, this analysis was repeated and/or the themes/features list updated.

Then, we conducted an on-field study during October 2023. The scope of the field study was both
generative (to capture users’ motivation, intent and behaviours) and evaluative (to capture usability of UPI
apps for grievance redress). We sought to understand how constrained and new-to-UPI user groups
interact with the in-app GRMs in UPI apps, and to identify bottlenecks in the customer redress journey.

Field testing was done through 18 qualitative and exploratory interviews across Gujarat, Uttar Pradesh and
Telangana.18 All participants had experienced UPI-related grievances in the past but may or may not have
formally interacted with the complaint submission mechanism on the UPI app. All participants were
frequent users of UPI from informal occupation categories such as street vendors, small traders, tea shop
owners, gig workers, and migrant workers and had annual incomes less than INR 500,000. They ranged
from low digital proficiency (only use smartphones for basic digital tasks such as messaging and making
payments) to high digital proficiency users (who use their devices for more complex tasks such as online
shopping).

In these interviews, users were asked to describe their grievance redress journey corresponding to the
interface of their UPI apps. In cases where users had no experience with the grievance redress journey,
they were asked to attempt one for the first time. In both cases, we observed how users identify,
understand, and cope with issues that arise along the grievance redress journey. Given that the interviews
involved observing and recording user’s phone screens, these interviews followed protocols of privacy and
data security, laid out by an Institutional Review Board (IRB).19

• Phase 2: Solution Approach

Armed with insights from Phase 1, we identified potential areas for redesign and a design solution was
conceptualised as a prototype. The design process involved mapping the existing resolution process for
leading UPI apps for some issues prioritised from Phase 1. Through an iterative process involving the
creation of both low -and high-fidelity mockups, we systematically refined our design approach, and this
ultimately culminated in a comprehensive prototype.

• Phase 3: Prototype Testing

The designed prototype was tested for its performance on standards of accessibility, useability,
comprehension, etc. through user-testing with constrained cohorts. Formative testing of prototypes was
conducted among 19 users across rural and semi-urban regions in Madhya Pradesh, Karnataka and

17
Narayan Gopalan has expertise in Interaction Design and in creating engaging user experiences that cater to the
objectives laid out by each of his clients.
18
Participants were recruited from the following districts in each of the states: Anand (Gujarat); Sitapur (Uttar
Pradesh); Nalgonda and Rangareddy (Telangana).
19
An IRB reviews research methodologies pertaining to human subjects to ensure that projects are ethical and do
not cause harm to study subjects.
Odisha.20 All 19 users had experienced UPI-related grievances in the past. 12 users had prior experience
in interacting with the in-app GRM and had raised a ticket in the past. All participants had annual
household incomes below INR 500,000, had educational backgrounds ranging from primary education to
undergraduate level, and were engaged in occupations in the informal sector. Women whose family
members worked in the informal sector were also included in the testing.

User-testing was conducted in the form of task-based interviews, where participants were provided with
a testing mobile device through which they could access the GRM prototype. In each interview, the
moderator narrated a hypothetical scenario to the participant and provided the context for the grievance
they had experienced. For instance, a participant would be asked to imagine that they transferred money
to their friend 2 days ago, but their friend is claiming that they did not receive money yet. Based on this
scenario, the participant is then required to interact with the prototype and demonstrate how they might
submit a complaint regarding this issue. Since multiple scenarios were tested, prototypes were created
for the corresponding user grievance flows. Each of these workflows is accessible in Appendix II.

Users were asked to perform specific tasks and their reactions to the prototype were probed after
completion of each task. The insights presented below are based on the moderators’ observations of user
behaviour and their reactions to the prototypes. Users were given the option to complete tasks in the
language of their choice (English or Hindi). The moderator evaluated some questions with users to assess
their readiness to respond in the chosen language. Similar to Phase I interviews, protocols of privacy, data
security, laid out by the IRB were followed.

Insights from Phase 3 were parsed to identify specific changes to be made to the prototypes that were
tested. The prototypes were then updated to reflect these changes and are presented both in this report
as well as in the Toolkit available on the Dvara In-App UPI GRM microsite.

Alongside these phases, the research team also undertook fresh expert analyses of the grievance
mechanisms of UPI apps – these app reviews intended to explore the user’s ability to use grievance
functionalities as well as to understand the structures and components of their current design.

In the next few sections, we discuss our findings, synthesized learnings and the created prototypes, as
implicated in specific phases.

20
Participants were recruited from the following districts in each of the states: Kalaburgi (North Karnataka),
Kendrapada (Odisha), and Khargone and Dhar (Madhya Pradesh).
Phase 1: Problem-First Research
The objective of Phase 1 was to understand users’ lived experiences of grievance redressal in UPI (through
field testing) and to contextualise these experiences within the landscape of grievance redress offerings in
UPI apps (through an expert app-review). Hence, any data gathering from TPAPs and banks were not
undertaken in this phase as this would bias the process.

An important anchoring in this phase was its ‘problem-first’ nature – spending a great deal of time and
effort in defining and understanding the problem statement before proceeding to solution building. A
problem-first approach is effective because it ensures that solutions built are appropriate for the user
base.21

Accordingly, we have identified usage patterns, thought processes, preferences, and expectations of users
through their grievance redress journey on UPI apps.

Issue Triggers & Impact

User identifies the grievance/complaint

Discovering and Accessing Channels of Redressal

User explores available grievance channels and User accesses the preferred channel and understands
identifies an appropriate one how to initiate a grievance

Grievance Submission
User defines the complaint, provides necessary documentation and submits the complaint

Grievance Follow-up
User tracks the status of their grievance ticket and responds to any additional requests for information

Grievance Resolution
User receives and understands the resolution provided, and determines whether further action is required

Impact of GRM on Users

User reflects on the outcome of resolution and its impact on their original issue

Overall, we find that users with a lower digital proficiency struggle through each stage of the user journey
compared to those with higher digital familiarity. Low-proficiency users, whose digital familiarity is limited

21
Rosala, M. (2020). The Discovery Phase in UX Projects. Retrieved from
https://www.nngroup.com/articles/discovery-phase/. Also see “The problem first” design process. Kaushik Panchal,
2018. Retrieved from https://uxdesign.cc/the-problem-first-design-process-616977b6808c
to instant messaging and payments, experience frustration and confusion as they navigate the redressal
journey.

Stage 1: Triggers for the redressal journey

The most commonly occurring issues that trigger UPI users to pursue grievance resolution are described
below. Users (or their friends and family) report having experienced the following issues. Select
respondent quotes have also been provided:

• Transaction Failures due to technical issues: Users may experience delays in the processing of
transactions or outright failure of processing due to network issues, server downtime, insufficient
funds in the account, or failed execution of payments due to incorrect PIN, UPI ID or phone number
being entered. Repeated failed transactions detract from the overall UPI user experience and cause
great inconvenience for users. Users may change their payment behaviours to adapt to the risks that
arise from transaction failures. For instance, a user developed a preference for carrying cash as a
backup. Another now splits each transaction into two - to reduce the perceived risk of losing the entire
sum to a transaction failure. Overall, users question the reliability and trustworthiness of UPI apps.

“I have faced several transaction failures, which has led me to question the reliability of the UPI app.
Now, whenever I go to the market to purchase anything, I carry some cash with me as a backup in case
the transactions fail.” - Male, Anand District (Gujarat)

“I tried to send money to my brother, but the amount was deducted from my account, but it was not
credited to my brother’s account. I arranged Rs. 12,000 from others and sent it to my brother again, as
there was an urgent need. I did this because if my brother had not received the money, everyone would
have thought I deliberately did not send him the money. I would have lost trust.” -Male, Nalgonda District
(Telangana)

• Unclear transaction status: Some users report a lack of adequate notifications on the status, progress
or failure of their transactions. This leads to confusion and anxiety about the status of the transaction.
For those receiving UPI payments, unclear transaction status can cause anxiety regarding whether the
initiated payment will successfully reach the person or not. Merchants, for instance, may benefit from
clarifying the transaction status, so they do not need to insist on the payer repeating the transaction
or waiting to deliver the goods/services. For constrained users who are payers in such transactions,
locking up money in repeated transactions is a cause for worry and inconvenience given the high
degree of funds-cycling they do with their money.

“I had asked for a payment from a boy. He made the payment, but it did not come to my account. He
said it will come into my account but until then I was stuck waiting there. It was 3 AM and it was a
problem. They should give some option to solve this problem.” – Male, Sitapur District (Uttar Pradesh

• Low awareness and comprehension about UPI AutoPay: User cohorts and their networks do not fully
understand the functionalities of UPI Autopay. They don’t understand the features, value proposition,
constraints and potential issues with the UPI Autopay mandate. A user described how an acquaintance
unknowingly authorised an Autopay mandate and was later surprised when their account balance
 decreased due to debits. Low-proficiency users have difficulty finding and managing their UPI AutoPay
mandates. They may have uninstalled the app that requested the mandate, changed their mobile
phones, or lost access to their mobile number.

“My friend uses several fantasy cricket game apps and has added his UPI account to these apps. He did
not realise that he activated UPI AutoPay in one of these apps. The following month, an automatic debit
occurred due to the UPI AutoPay mandate, which he was unaware of. He visited the bank multiple times
to complain about this unknown debit but received no information about the transaction. He asked me
for help with this unknown transaction. I assisted him by checking all the UPI apps on his mobile phone. I
went into their settings and looked for any active UPI Auto-debit mandates. I found an Auto-debit
mandate in one of the UPI apps and deactivated it. Without my help, he might not have found this Auto-
pay mandate. This is a common problem among people who are not well-versed with UPI transactions.” -
Male, Sitapur District (Uttar Pradesh)

• Susceptibility to fraud: Users are susceptible to fraud and report having mistakenly shared their OTP
with scammers, and such acts led to fraudulent transactions. Many users generally comprehend fraud
only after the execution of the transaction(s) and are unable to articulate where exactly in their
transaction journey they could recognise the fraudulent actor’s modus operandi or even what the
nature of the modus operandi was.

“I once experienced a fraud incident. During a festival fair, a person approached me at my flower shop
and asked several questions related to COVID-19, such as whether I had been vaccinated and what my
address was. He then informed me that I should have received a number for address verification. When I
shared this ‘number’ with him, ₹1000 was deducted from my account. At the time, I didn’t understand
what had happened. I thought the ‘number’ was just a number, but it turned out to be an OTP (One-Time
Password).” - Male, Sitapur District, (Uttar Pradesh)

• Onboarding Issues: While onboarding a new UPI service, users must link their bank account and
authenticate their identity. Some users experienced issues while adding their bank account to the UPI
app. For instance, an individual who sought to register and use UPI on PhonePe via Aadhaar-based
verification was unable to do so. Another user was unable to add her account to the UPI app because
her mobile was not linked with her bank account. Issues at the onboarding stage are barriers for the
transition of prospective customers into active UPI users. Onboarding issues require users to
undertake some investigation and corrective action on their own.

“I was not able to add my bank account to the UPI apps. I could not find out the reason. A few days later,
my brother visited the bank to enquire about the problem. It was then that we discovered that my mobile
number had not been correctly registered with my account, which was the reason I was unable to add my
bank account to the UPI apps.” - Female, Nalgonda District (Telangana)

Stage 2: Discovering & accessing channels for redressal

Once the user has encountered an issue, they gather information on how to resolve it and select a
redressal channel to engage with. Overall, it appears that many low-digital proficiency users will first seek
information on how to resolve an issue outside of the UPI app and its inbuilt grievance support. That is,
they approach friends and family, customer support helplines, or online sources to learn more about the
issue and how to resolve it. They must then access the in-app GRM of the UPI app to initiate the redressal
process. Regarding accessing the in-app GRM itself, we find that only a few users are able to access the in-
app GRMs with ease via the profile icon, even if they expressed a preference to access the GRM quickly.
Depending on the app, the help landing page is nested within the menu list on profile, and it is reached
after either one or two click-throughs from the profile page.22 However, most users are able to access the
help landing page through the transaction detail page.

Users first seek to learn more about the issue they have encountered and what they must do to pursue
redressal through:

• Personal networks: Most users seek help from their specific family members and friends whom
they believe are better equipped to resolve UPI-related grievances. These users were not
confident in their own ability to use the app features or navigate the ‘Help’ section. They first
approach trusted individuals to support them in obtaining redressal.
• Customer support helplines or in-app GRM: Users perceive customer support helplines as reliable
channels to pursue grievance discovery. Helplines are a familiar and preferred way of seeking
redressal for this cohort. Speaking directly to app representatives provides users with confidence
in describing their issue and obtaining quick resolution. They may access helplines through online
searches or by exploring the app. Some users also perceived helplines as being secure, since they
were asked to verify account ownership before further information is provided. Users may attempt
to use the in-app GRM support via chat or the complaint submission process. However, users are
often unclear about chatbot functionalities.
• Bank Branch: A few users associate phone calls or app-based support with the potential risk of
fraud. For instance, a user was hesitant to type their problem into the app due to fear of
accidentally closing their UPI account, indicating a fear of potential loss. Such users prefer to
directly visit the bank branch to seek support and perceive the bank branch to be a highly reliable
way of seeking support.
• Self-learning: Only a small fraction of users did not require assistance to discover redressal
options. These users who have high familiarity with YouTube, tended to search YouTube for local-
language content pertaining to their grievance. They opined that availing help from others could
worsen their issues rather than resolve them. These users will try to resolve the issue by
themselves without the in-app GRM or customer support. They are also confident in assisting
others in their network with similar queries and have learned how to handle some types of
recurring grievances.

Most users avail themselves of support from friends and family, bank staff, or customer support helplines
for redressal of their issues. They prefer these channels as their first port of call for resolution before using
the actual in-app GRM provided. They may perceive these channels to be quicker than waiting for a
resolution from the in-app GRM. Users may also experience anxiety over how to quickly resolve the

22
Since the time of our field study, many UPI apps have now put GRM on the main menu of profile page.
grievance in order to avoid potential financial and reputational loss and may not trust the UPI provider to
effectively resolve their issue.

Next, users must access the chosen channel of redressal to initiate the complaint resolution process. Only
a small subset of users who are already confident with Help sections of digital apps were able to access
the GRMs in the UPI apps they use with ease.

Since users with low digital proficiency prefer to approach their personal networks to discover redressal
options, it appears that awareness about in-app GRMs and how to access them is low - users do not by
default resort to using the in-app grievance mechanisms inside the UPI app. These users also may not
easily comprehend the visual cues and/or written text that directs them to the entry point of GRMs.

“I saw the "Contact Page" (chatbot interface), but I didn't understand how to move forward from this
screen. Then I thought I would visit the bank branch for complaint.” – Female, Anand District (Gujarat)

Further, low-digital proficiency users tend to display a fear of making mistakes or digital errors that may
lead to further/potential loss for them. These users have a limited exposure to digital products and may
have also developed a perception that they are likely to lose money on the basis of anecdotes shared from
their personal networks.

Some apps had multiple entry points to access the GRM, each of which led to a different sub-screen of the
GRM.23 For instance, a leading UPI app allowed the user to access the GRM from different locations (such
as the profile page, home screen, Notifications). However, each entry point is through a ‘question mark’
button and led the user to a different subset of the GRM. Each of these pages was titled ‘Help’ and provided
the user with different information and options. It becomes challenging for the user to distinguish between
these. We observe a lack of consistent and dedicated real estate for the GRM in the design of UPI apps,
the presence of which can build familiarity for users to access GRMs easily.

Stage 3: Grievance Submission

Once users have successfully accessed the grievance redress section of the app, they will attempt to submit
their complaints. This requires them to select the relevant category of grievance, accurately convey their
issue to the app, and provide necessary details or documents/ screenshots. From probing users’
experiences with grievance submission, we conclude that the grievance submission process may be
confusing to users.

Some aspects of the existing in-app GRMs do not match user expectations, and this leads to confusion and
a lack of clarity on how to submit grievances. For instance, a few users anticipated a ‘complaint’ option on
the app home screen, which was not present. Some apps also prompt individuals to ‘contact’ the support
teams. This sets high expectations, as users now tend to anticipate direct contact with the customer
support teams - either through chat or a phone call. However, they may be disappointed to encounter a
chatbot with limited options. Users appear to be unclear about the functionality of the chatbot, and lacked
an understanding that the chatbot is a channel for submitting complaints. Many apps have predefined
categories for users to select from before they can lodge a grievance. These categories may not accurately

23
This may have changed since then.
capture the user’s specific issue and users may find it difficult to comprehend problem categories or feel
that their grievance does not fit into the provided categories. For instance, users had some difficulty in
understanding some category labels such as ‘Referral issues’, ‘Other Issues’.

“I think that in ‘Others’ category in [Third-party app], I can find information about the complaints raised
by me.” – Male, Sitapur District (Uttar Pradesh)

Users were also uncertain whether selecting a subcategory would lead them to relevant help articles or
advance them in the complaint process. Users expressed disappointment upon discovering that only
certain subcategories provided the option to lodge a complaint, while others did not.

“I thought if I click on ‘issues with pending payments’ my pending payment will be shown to proceed with
complaint submission.” – Male, Nalgonda District (Telangana)

Since users must select from predefined grievance categories, their ability to articulate their problem to
the app by themselves is limited. In a few apps, a text field for typing out one's complaint only becomes
visible after the complaint has been submitted. The placement of this text field limits its discoverability,
The text field is also only available for certain grievance categories (e.g. ‘I was asked to pay in advance by
a seller’) but not for others (e.g. ‘Payment Issues’).

“If I am not able to find the correct option, I will talk to customer care” – Female, Nalgonda District
(Telangana)

Stage 4: Grievance Redressal Follow-Up

Once the user has submitted a grievance (and before it is resolved), UPI apps allow users to track resolution
progress and respond to any requests for additional information that may be required. In the user’s
grievance redress journey, this stage is paramount to ensuring that users are informed of and satisfied
with the resolution process and outcome. However, we observe a lack of transparency in the manner in
which users are provided updates on their resolution progress.

Users find it difficult to discover and access sections of the user interface which contain follow-up
information on the grievance. This stands out as the biggest and most fundamental challenge for
constrained users. Most users were unable to check the status of their complaints in the app. Some stated
that they did not receive notifications regarding updates on their complaint status and expressed a
preference for the same. However, our expert app review reveals that multiple UPI apps do notify users
about complaint status, especially when there is an automated response or a reply from a live chat agent.
Users’ impressions could be due to a lack of clear communication or visibility of these updates within the
apps.

“I don’t know how to check the status of the complaint.” - Male, Anand District (Gujarat)

As users are not able to discover the status of tickets, and apps usually do not have a landing screen with
the status of tickets raised, users interpret this as a lack of transparency from the service provider. Users
also don’t know the approximate Turn Around Time (TAT) for resolution of tickets, which increases their
level of anxiety around the urgency required to avoid potential loss and the lack of knowledge and control
over the raised ticket.
Most users couldn’t understand complaint tracking features available in the GRMs in the apps. The phrase
‘ticket’ is not well understood. The term ‘ticket’ is not commonly used by most users to refer to a complaint
in everyday conversation. When prompted to explain what the phrase ‘View Ticket’ means in the help
section, many users were unsure.

“I don't know what a ticket is and what this page is about”. – Female, Nalgonda District (Telangana)

Stage 5: Grievance Redressal

At this stage, users try to understand the resolution or final decision regarding their grievance. Users face
several challenges in this stage, such as a lack of clear communication from the app or customer care, and
difficulty in comprehending the resolution or decision, especially if it involves technical terms or jargon.

Overall, there is a significant gap between the communication provided by the apps and the users’
perception of it. Despite the apps sending notifications about the resolution of submitted grievances,
most users reported not receiving any other form of communication from the GRM. This discrepancy may
be attributed to limited digital proficiency and reading skills. It is also possible that when many
notifications come on their phones, users may ignore them, or they may not be able to comprehend or
recollect correctly. Moreover, when a user changes phone settings for notifications, they may end up
switching off the UPI app related ones and claim that they did not receive them. Only a few users recollect
encountering communication regarding the resolution or decision provided by GRM. These users received
customer-care calls or notifications on the UPI app.

Users are unsure about how to verify whether their issue was marked as ‘resolved’ within the GRMs of
their UPI apps. They typically rely on tangible outcomes, such as seeing a refund reflected in their
transaction history or being able to add their bank account to the UPI app, as indicators of issue
resolution. Users will often check their bank balance rather than the app to determine status of resolution.

Stage 6: Impact of GRM on Users

The final stage of the user journey is the outcome and impact from the in-app GRM for users of UPI. Users
reflect on the resolution provided compared to their original problem. Their perception of the GRM’s
effectiveness impacts their present satisfaction with the service, as well as future interactions with the UPI
app, even in situations where the responsible party for an issue may be a bank (the remitter bank, the
beneficiary bank or the PSP bank), the mobile network operator, the phone being used, or the user
himself/herself. This stage considers a longer-term horizon since it pertains to understanding the impact
and effectiveness of the grievance redressal process.

Users who have low-mid level digital proficiency tend to find the GRMs less effective, based on the
following parameters:

• Issue resolution: Some users find the GRM effective as their issues were resolved and they
received their money back in case of failed transactions. Those who had not had their issue
resolved felt the GRM was ineffective.
• Ease of use: Some users face difficulties in understanding and using the help pages, language
options, and complaint status in the apps.
 • Checking complaint status: For the majority of users, assessing the resolution status of their
concerns within the GRM proved challenging. Many users resort to checking their bank account
details through balance checks as an alternative method to determine issue resolution.

Table 3 below captures a short summary of findings across the six stages of the user grievance redress
journey.

Table 3: Summarised Findings across User Grievance Redress Journey

User Grievance Redress Findings from Phase 1
Journey
Stage 1: Triggers of the The commonly occurring grievances are:
User Journey • Transaction failures
• Onboarding issues
• Unclear transaction status
• Lack of understanding about UPI AutoPay
• Susceptibility to fraud
Stage 2: Discovering & • Most users prefer to seek resolution outside of the in-app GRM which allows
accessing channels of them to find redressal more quickly than waiting for a resolution from GRM
redressal • Users lack awareness about how and where to access in-app GRMs
• Users have a fear of making mistakes or digital errors that may lead to
further/potential loss
Stage 3: Grievance • Users experience confusion and lack clarity on how to submit grievances
Submission • Users find it difficult to comprehend problem categories provided at the
grievance submission stage
Stage 4: Grievance • Lack of transparency in updating users about transaction progress such as
Redressal Follow-Up turnaround times (TAT) and status
• Lack of access and discoverability of redressal status or follow-up
Stage 5: Grievance • Lack of clear communication from the app or customer care regarding
Redressal grievance resolution
• Difficulty in comprehending the resolution or decision
Stage 6: Impact of GRM • Users perceive the GRM as effective if their issue has been resolved/money
on Users returned. Those whose issues remain unresolved felt the GRM was ineffective

We further summarise the insights on the user grievance redress journey from field interactions into
a mental model that is characteristic of this cohort.

A Mental Model for Constrained Users’ Grievances

Understanding the mental model of users helps in creating intuitive and engaging interfaces that match
the user’s expectations and needs. The users’ mental model for redressal can be described as follows:

• Users seek clarity: Users rely on clear and easily understandable information or instructions to
use in the in-app GRMs. It appears that users are not understanding the information/instructions
being provided by the GRMs of various apps. For instance, many users reported not receiving
additional communication from the GRM about their issue resolution - though these apps do send
such notifications.
 • Users prefer upfront access to GRMs: Users comprehend accessibility based on how easy it is to
notice and/or discover various components of the GRM screen. A greater number of steps or a
deeper level of access to the GRM leads to poorer accessibility experience.
• Users prefer contacting customer care: Users opt to contact customer care (of the bank or the
TPAP) or visit their bank directly when faced with transaction-related issues while using UPI, rather
than approaching the in-app GRM. For those who preferred banks, they perceive that the bank is
the reliable party and that it is the most effective way for issue resolution.
• Users fear loss or digital errors: Users had a fear of negative consequences such as mistakes that
may impact their bank accounts, which limits their confidence in undertaking self-exploration and
attempting to resolve issues on their own.
• Users assess a perceived speed for the resolution: Users assess the perceived speed of resolution
when choosing the grievance channels. This impacts their decision on whether to use the GRM
for resolution of issues in the future. Users are more likely to stay engaged if they perceive a quick
resolution process, while delays result in disengagement or frustration.

Some aspects of this model will require concerted efforts on the part of UPI providers and banks to suit
their offerings more aptly for this user group. Other aspects (such as the user’s bias for in-person support)
are likely to be shifted away from in due course as these cohorts become more familiar with digital finance.

While the user’s mental model indicates a preference for resolution of grievances outside of the in-app
GRM, it does not imply that users have no intent to engage with the in-app GRM. Users want to submit
grievances through the in-app GRM for issues they perceive as severe - loss of funds to a transaction failure
or being unable to add their UPI account in their apps. They are less likely to submit complaints for issues
that have a lesser impact - for instance, a small transaction repeatedly failed and so the transaction was
settled in cash, or processing of a transaction is delayed.

Users who have a high intent to submit complaints may believe it is a way to flag an issue to the provider
On the other hand, some users may engage with the GRM only when there is a need to redress loss that
they have incurred. GRMs can be tailored to the requirements of both types of users.

GRM Framework for UPI in India

The Grievance Redressal Mechanism (GRM) has been recognised as a standard protocol for addressing
consumer-facing complaints faced by customers in the financial and other sectors. International
organisations have prescribed various standards for GRMs such as the United Nations Development
Programme’s (UNDP) approach to GRMs for stakeholder engagement24 and the World Bank’s rights-based

24
UNDP. Supplemental Guidance: Grievance Redress Mechanisms (GRM). Retrieved from
https://info.undp.org/sites/bpps/SES_Toolkit/SES%20Document%20Library/Social%20and%20Environmental%20St
andards/Supplemental%20Guidance_Grievance%20Redress%20Mechanisms.pdf
approach.25 However, these lack relevance in their applicability for the Indian context specifically. The
Payment System Vision-2021 of the RBI highlighted the need for technology-driven, rule-based, customer-
friendly and transparent dispute redressal systems. The RBI laid out the minimum requirements of an ODR
System for digital payments in 2020 26, and this led to the NPCI’s introduction of UDIR.27
5

Here, we present an original GRM Framework tailored for the UPI environment, intended to develop or
improve GRMs in UPI products offered by third-party app providers and banks in India. The framework has
been developed using a problem–first lens – prioritizing user problems over actionability or solution-
building. The framework considers challenges at both ends of a GRM, i.e., at the back end in UPI product
development for TPAPs/ banks, and those faced at the front-end by users. The framework was constructed
on the basis of insights from the study detailed in this report, on user cohorts from rural and semi-urban
parts of India and is therefore relevant for the largest user groups that UPI supports.

The UPI GRM Framework consists of four consumer values which are the core pillars for GRMs in UPI.
From our field research, it has become clear that customers of UPI expect these values to be embodied in
the design of these apps. Each of these pillars are mapped to a corresponding product principle that
outlines how UPI providers may operationalise each of the consumer values.

Consumer Value I: Inclusive

An inclusive approach ensures every user, irrespective of their background (in terms of income group,
digital proficiency, occupation group, etc.) can access GRM product features on UPI apps with ease and
seek resolution for the grievances they may encounter in their UPI transactions.
Product principle: Accessible
Inclusivity mandates that the grievance functionalities of UPI apps be made accessible for users across
backgrounds and digital proficiencies. The app interface should support ease of discoverability and access
of the GRM within the digital product. For instance, the user journey on the app should not require the
user to navigate multiple screens or steps to access the GRM. After initial access too, users should be able
to navigate to further screens to carry out any necessary actions to seek resolution. Accessibility is the
first important step for the success of GRM support for consumers facing issues.

Consumer Value II: Simplified Process

A simplified process for the GRM requires that it be easily comprehensible and visible for users at the
backend (UPI/customer support teams) and frontend (customers) alike. At the backend, GRM processes
are often ambiguous, complex, or opaque, which contribute to frontend interfaces being difficult for the
end-user to understand.

25
World Bank. (2022). Assessing Project-Level Grievance Redress Mechanisms Using a Human-Rights-Based
Approach. Retrieved from https://openknowledge.worldbank.org/server/api/core/bitstreams/bd391cff-3eaa-5fbb-
8708-4e24ad7d32c5/content
26
RBI (2020). Online Dispute Resolution (ODR) System for Digital Payments.
https://www.rbi.org.in/commonperson/English/Scripts/Notification.aspx?Id=3194
27
NPCI (2020). UDIR – Enhancing Complaint handling & resolution process for UPI transactions. Retrieved from
https://www.npci.org.in/PDF/npci/upi/circular/2020/Circular-98-UDIR-Enhancing-Complaint-handling-and-
resolution.pdf
Some of the UPI apps studied do not allow their users to undertake grievance redress journeys 28 inside 7

the app for all the significant grievance scenarios29 experienced, and some of the current processes do
not present clarity for users on how to seek resolution or to explore the status of their submitted
grievances. Simplifying the GRM can help to build capabilities amongst consumers to proactively seek
resolutions to their issues through the app itself.
Product principle: Transparency
Simplifying the grievance process requires GRMs to facilitate clarity and transparency for all stakeholders
(UPI teams and the end-customers). Customers often have limited information as they use the in-app
GRM – for instance, they are unclear of the upcoming steps in the GRM flow and may not be privy to
information regarding the status of a complaint or the expected turnaround time. This builds anxiety for
users. Transparency at the front end allows the customer to understand their grievance in terms of
potential risk and urgency, building trust with the product.

Consumer Value III: Resolution

Users often do not get a clear resolution despite engaging with the GRM process on UPI apps, leading to
low engagement and a deficit of trust. An important pillar of the GRM framework is to provide continuous
engagement until a clear resolution is found. Successful resolutions over time will build more trust
amongst users and result in higher engagement with the GRM. It can also help UPI stakeholders leverage
an effective channel for feedback by identifying potential areas of improvement.
Product principle: Objectivity
Consumers view GRM as a medium to obtain justice when they have faced unfair challenges or losses.
Viewed in this manner, resolutions should be fair and objective to the user. Objectivity provides an
effective lens for UPI stakeholders and users alike. Objectivity in providing resolution should be embedded
at the back end, where grievances are objectively resolved without biases, assumptions or unfair
practices. It requires a clear classification of diverse problems and impartial solutions for a grievance. This
leads to unbiased resolution delivery for consumers on the front end.

Consumer Value IV: Protection

The primary intent for users engaging with GRM is to seek protection from perceived threats such as
potential loss of funds or fraud. Users across regions, levels of digital proficiency and socio-cultural
backgrounds build trust with any platform based on their experience of protection offered by it. Effective
protection leads to better adoption and engagement of consumers with the GRM and improves the overall
trust with which users regard UPI.
Product principle: Guardrails
To provide users with a sense of protection, the product interaction through the interface needs to be
designed with certain guardrails in place. While there may also be other areas where a sense of protection
is required (such as platform interface, cyberattacks, and authentication), the focus here is on the GRM
interface. Guardrails in this context have both a preventive and protective approach.
The preventive approach requires users to be warned and reminded about the critical steps they are about
to take and potential risks (if any) but without being alarmist about it which can deter users from engaging
with UPI altogether. Though some such steps have already been implemented by TPAPs, these need to be

28
Since UDIR has been made mandatory, all UPI apps will need to ensure that the scenarios that are implied are
accounted for in their apps.
29
For instance, money not received even if the payer has sent it.
continuously updated and improved. The protection approach gives assurance and aids users in protecting
themselves from potential loss, digital errors, or fraud.
Guardrails in GRMs may provide temporary assurances to reduce user anxiety before obtaining final
resolution, help users comprehend critical features that protect them, and support them in detecting and
taking action when faced with fraud.

Adopting the UPI GRM Framework

This framework has been developed to create a positive impact on consumers’ trust and confidence.
Applying this framework in the design of in-app GRMs in UPI can improve the adoption of GRM and the
UPI ecosystem as it grows further in reach.
The framework is helpful for stakeholders in the following ways:
• It prescribes user-centric values which are holistic and functional, and corresponding product
principles which provide a practical approach to how these values may be applied by a bank or
TPAP.
• It builds a consistent reference and vocabulary of values and principles to aim for, in an ideal
GRM.
• It helps align stakeholders across policymaking, business and other stakeholders to execute the
GRM consistently across platforms that serve UPI consumers.
• It provides a way to measure impact such that the need for a GRM is no longer a one-time design-
and-execute business decision but one that becomes a necessary precondition for enabling a
seamless app experience. The GRM can thus receive continuous upgrades based on technological
changes and the scale of consumer reach. The UPI GRM Framework enables stakeholders to draw
up and refer to a common benchmark of metrics to measure the effectiveness of their GRMs.
Phase 2: Solution Approach
In Phase 2, the project team sought to design and build solutions for the problems identified in Phase 1.
Our solution approach is calibrated to the UPI GRM Framework detailed in the previous section and is
elaborated in the below sections.

Overarching Goals for the Solution Approach

The following overarching goals help us to align or combine a user-centric experience across diverse
solutions recommended across problem areas.

➢ Users should be able to comprehend and adopt GRM more easily than before
➢ GRM experience should lower the user’s anxiety about potential loss and increase trust in the UPI
platform
➢ UPI service providers should be able to resolve user’s grievances effectively
➢ Banks & other UPI service providers want to save costs on customer support. A lower number of tickets
raised leads to lower customer support cost

For each stage of the user grievance redress journey, the following solutions emerge (Table 4):

Table 4: Emerging Solutions

Findings Solution Recommendations

Stage 1: Triggers of the User Journey

• The commonly occurring grievances • Solve for accessibility to transaction-related

are: issues in GRM and for an effective resolution
- Transaction failures process for it.
- Onboarding issues • Solve for better comprehension of the UPI
- Unclear transaction status Autopay mandate in the GRM as part of the user
- Lack of understanding about UPI experience.
AutoPay • Although user cannot cannot resolve fraud
- Susceptibility to fraud within the GRM process, we can help users
detect fraudulent activity or patterns based on
their transaction activities. We need to help
users detect and report fraud more easily within
the GRM journey.

Stage 2: Discovering & accessing channels of redressal

• Most users prefer to seek resolution • Explore a new approach to embed a self-
outside of the in-app GRM which allows resolution journey within the GRM process. The
them to find redressal more quickly majority of users are likely to find such an
than waiting for a resolution from GRM. approach effective as they already demonstrate
such behaviours.
• Users lack awareness about how and • Improve the access to the GRM icon and make it
where to access in-app GRMs. more visible within the UPI home page for
• Users have a fear of making mistakes or better noticeability.
digital errors that may lead to • Create a simpler, more seamless user
further/potential loss. experience to build familiarity amongst users for
frequent usage, which will lead to more
confidence and lower anxiety about digital
errors/mistakes.

Stage 3: Grievance Submission

• Users experience confusion and lack • Create a solution that helps navigate users easily
clarity on how to submit grievances. and seamlessly to submit their issues. We may
• Users find it difficult to comprehend consider re-structuring the help navigation tree
problem categories provided at the on both the users’ side and at the backend to
grievance submission stage. allow redressal which is objective, effective and
consistent.
• Embed the grievance submission process that
takes users through a logical flow of narrowing
down the problem.

Stage 4: Grievance Redressal Follow-Up

• Lack of transparency in updating users • Providing social validation for use-cases/issues

about transaction progress such as where users are required to wait it out, can be
turnaround times (TAT) and status. helpful to lower their anxieties towards
• Lack of access and discoverability of potential loss.
redressal status or follow-up. • To build better visibility, introduce a potential
“ticket view” screen which is a dashboard for
the status of tickets and providing effective
notifications to users that help discoverability
and comprehension of status.

Stage 5: Grievance Redressal

• Lack of clear communication from the • Improving UX writing for clarity of resolutions,
app or customer care regarding and on simple and clear status information.
grievance resolution.
• Difficulty in comprehending the
resolution or decision.

Stage 6: Impact of GRM on Users

• Users perceive the GRM as effective if • Aiding users to comprehend the difference
their issue has been resolved/money between the roles played by their TPAPs and
returned. Those whose issues remain their banks, in simple language.
unresolved felt the GRM was
ineffective.
All the problems and solution recommendations listed out have been combined, restructured, and
prioritised / deprioritised in subsequent phases based on the scope of this project.

Summarised Problems
From the diverse problems in user grievance flows, a subset was selected for solutioning. We prioritised
solving for those issues where a high number of users are likely to face similar problems, where the impact
of the solution on users would be large, and implementation would be feasible for UPI providers. These
problems are:

• Solution Navigation: All UPI apps - through lists or a chat-based interface - presented users with
a range of problems to choose from. This approach may require the user to browse through
various forms of content such as FAQs, videos and articles, to find the relevant solution to the
problem they are facing.
• The Ticketing Process: The ticketing process is unclear and inconsistent across apps. Some apps
create a ticket for every query (and automatically close it) while some allow the user to explore
self-resolution before raising a ticket. This led to confusion over the resolution time of a ticket -
while some were resolved immediately with a chatbot, others required a 3-day wait. The concept
of a ‘ticket’ too was unclear to users.
• Inconsistent Entry points: While most apps had entry points into the GRM from the transaction
detail page, entry into the GRM for issues that did not involve a transaction or where a transaction
was missing, was hard to find. Often nestled inside the profile menu, this item was difficult to
locate for the average constrained user.

Keeping these in mind, we continued into the Solution Approach of Phase 2.

Applying The Design Process

The design process of building a solution involved the following steps of (1) Mapping the user journey, (2)
Studying the How Might We’s, and (3) Wireframing.

Mapping the User Journey

By mapping the steps involved in the existing process of resolution across the leading apps and service
providers, the lack of consistency in user journeys across apps became apparent. When switching from
one app to another, users are required to relearn how to navigate the GRM, while also being presented
with various forms of content (FAQs, videos, articles, etc.) in various tones of voice and styles of
communication. This leads to constrained users taking more time and effort in building comprehension
and proficiency of apps or dropping out.

The existing resolution journeys for the following types of issues were mapped:

• Transaction in a ‘failed’ state

• Transaction in a ‘pending’ or ‘in process’ state
• Transaction originating from a UPI AutoPay mandate
• Suspicious Transaction
In most cases, users are presented at first with a wide range of problem categories in the help navigation
tree, with a ticket being filed at the next stage or further downstream of problem sub-category selection,
and we found that there is a long wait time before the user is presented with a solution.

At this point, we decided to exclude onboarding issues from the purview of this project. This is because
these issues will vary based on whether the UPI services are being accessed on a standalone UPI app or
whether it is nested within an app with a broader set of functionalities, such as a banking app or an e-
commerce app. Therefore, from this point on, our focus narrowed to user-issues related to transactions
undertaken within UPI. Issues unrelated to transactions, such as those which arise during addition or
removal of payment instruments, Aadhaar e-KYC related issues or sim-card related issues, are to be dealt
with based on the unique characteristics of each app environment and are outside the scope of this
project.

The HMW (How Might We’s)

‘How Might We’ (HMW) is a design thinking approach that enables designers to reframe and expand their
problem statements, facilitating effective, focused, and innovative ideation sessions to address design
challenges. HMW serves as the connection between the Define and Ideate phases in the design thinking
process.

The starting point for solutioning was to study each step in the resolution process and identify parts that
worked well as well as parts that were not effective. For example, entry into the GRM through the
transaction detail page was consistent across all apps and easily discovered by users due to already
existing familiarity. On the other hand, with challenges, ticketing journeys proved to be ambiguous. Users
were hesitant to file tickets due to lack of clarity between steps, a perceived fear of digital errors or that
it was too complex for them to follow each step. These users preferred to contact the app provider
through chat and other touchpoints.

In arriving at potential solutions, we balanced users' need for a better customer experience on the one
hand, with the service provider’s business interests, on the other. This is especially so for self-resolution,
because it saves a call to (and cost associated) the call centre while providing the user with a faster
resolution time. We focused on self-resolution and ways to improve the grievance redress experience
without dependencies on service providers’ customer support teams.

We hypothesised that a tree-based approach with fewer options to choose from initially, and with some
additional steps to arrive at the solution, could give users more clarity of thought and help pinpoint the
nature of issue for a more precise solution.

In many use-cases, such as frauds, the resolution is not within the app and outside of the UPI provider’s
ambit. For such cases, we added transparency towards the issue by providing additional information and
details about channels of support in the upcoming steps of the resolution process.

Wireframing
Wireframing is the first part of designing interfaces, where screens are created with a rough layout and
placement of all key features and real estate (dedicated space within a screen view) on each screen is
decided. These wireframes do not have detailing that includes text or visual components.
Through an iterative process involving the creation of both low and high-fidelity 30 mockups, we 9

systematically refined our design approach, and this culminated in a comprehensive prototype. These
prototypes represent user journeys on UPI apps (see Appendix II) and the objective is to effectively tackle
the identified "How Might We" (HMW) challenges. Detailed descriptions of the prototype are located in
Phase 3 of this report. By intricately weaving together the insights gleaned from these mockups, we
crafted a user journey that not only pinpointed and addressed existing problems but also seamlessly
incorporated solutions for a spectrum of use-cases, fostering an optimised and user-friendly experience
within the design of our solution.

Designing user flows with a help navigation tree

The design of the user flows was structured based on a ‘help navigation tree’ – which represents the
problem categories of the user journey from the time of encountering an issue to achieving resolution and
closure of the grievance. It outlines the sequential steps that users should follow to navigate through the
support process effectively and efficiently. The structure of the tree determines the end-user’s experience
because it decides how the user engages with screens through their grievance redress journey. A
streamlined help navigation tree that presents the user with an ideal number of relevant options to select
from can simplify the user’s decision-making burden and accelerate the resolution process.

For instance, a wider tree provides the user with more options upfront and enables them to reach the
endpoint of resolution more quickly. In contrast, a narrow tree provides fewer options to the user and may
involve more steps until the final resolution may be reached. We recommend a narrower tree which can
break down problems for the customer, building objectivity for both users and customer support teams.

The help navigation tree developed and deployed in these prototypes takes the following form:

• Level 1 Problem Identification: To identify the user’s problem by capturing the primary context of
the issue. The user is presented with a carefully crafted set of limited options regarding the nature
of their grievance.
• Level 2 Data Gathering: To gather additional data regarding the user’s problem. The user is asked
to identify the transaction relevant to their concern or proceed without a transaction for such
grievances (in cases where a transaction is not visible to the user). It also allows users to provide
any other additional information or data that could help categorise the problem effectively and
take the user through the relevant resolution journey.
• Level 3 Resolution: The user is provided with adequate information which is broken down using
an objective approach. It allows clarity for users to comprehend the resolution and take further
relevant actions in the redressal journey.

The prototypes were tested as per the methodology provided and the insights documented in Phase 3 of
this report. Minor changes were made to the prototypes based on the Phase 3 insights and these
prototypes can be accessible in Appendix II.

30
Fidelity in UX (User Experience) refers to the level of detail and accuracy of a design or prototype that represents
the final product.
Phase 3: Prototype Testing
The prototypes developed in Phase 2 were designed to create mock screens representing the user
grievance redress journey, from accessing the GRM, to raising a ticket, and obtaining resolution. These
prototype screens were partially clickable, so users could interact with them in the user testing exercises
of Phase 3. User testing was undertaken as part of an evaluative research approach to evaluate design
decisions and inform relevant changes that could be made to the prototypes.31 Both English and Hindi
versions of the prototypes were tested with users, but in this section, only the English prototypes are
discussed.

Key Evaluative Insights

This section summarises evaluative and testing insights across the GRM journey. The insights are
structured as per the key stages of the user grievance redress journey:

Entry into Help

Within the UPI environment, there are 2 key points of entry into the “Help” i.e. the GRM section of the
UPI app.

• Entry from the Transactions Details Screen, which is already present in all UPI apps
• Entry from the home screen/menu, especially for queries unrelated to a specific transaction or
for transactions that are not visible to the user.

We found that across UPI apps, users are offered varying and inconsistent entry points into the
grievance/help sections. Since the mental model of this cohort prioritises upfront access to GRMs, the
standard practice of nesting the GRM within the ‘profile’ menu from the home screen is not easily
accessed by the cohort of constrained users. We find that only high digital proficiency users can access
the in-app GRMs with ease, and hence providing multiple entry points to the GRM can enhance its
accessibility.

31
Kanji, F. (2021). UX Research and Testing Techniques: Find the right technique for the job. Accessed from Akendi-
UX-Research-Testing-Techniques.pdf
 Accordingly, our prototype offered two entry points to access the
GRM from the UPI home screen – one through the ‘profile icon’
menu and another via the ‘question mark’ icon located at the top
right of the prototype for the home screen (see Figure 1). The
former was not tested in Phase 3 since Phase 1 insights already
indicated that users did not find this route easy to use. The latter
provides users with a direct, single-step access to the GRM
functionalities of the UPI app. It provides a dedicated real estate
for GRMs on the home page. Its placement on the top bar
facilitates ease of discoverability for the user.

This approach can be especially useful where users may not have
a transaction reference for their grievance, (such as with
onboarding issues or incoming but pending transactions, where
entry into GRM through the transaction detail page will not be
feasible).

In our field testing of the prototype, we found that users were

able to discover these entry points due to their existing familiarity
with UPI apps, or by trial and error. The ‘question mark’ and
‘profile’ icons however did not sufficiently convey to users that
they represent an entry to the GRM. We conclude that explicitly
labelling the icon as ‘Help’ can reinstate the option and provide
more clarity to users.32
Figure 3: The prototype offered
multiple entry-points to the GRM Nearly all users, when presented with a hypothetical scenario,
tend to navigate to the transaction history screen to discover
the specific transaction that requires redress.

32
The updated prototype screen is presented in Figure 3. The version of the screen used in field testing did not
contain the phrase ‘Help’ in the top right corner, below the question mark.
‘Help’ Landing Screen
Once users have entered into the GRM, the prototype presents
a screen where all help-related information is housed (see Figure
3). Currently, the various grievance functionalities available to
users (FAQs, tutorial videos, grievance submission forms) are
interspersed throughout the UPI app rather than being
presented on a single screen for users to explore. The prototype
instead provides a landing screen through which the user can
further navigate to the relevant subsection.

The landing screen allows the user to select an entry point

relevant to the grievance they are experiencing. The first section
in the Help landing screen, titled ‘What do you need help with?’
contains subsections of the grievance mechanism which are
relevant to the various product offerings of the app. For
instance, customers with grievances related to UPI transactions
are directed to the UPI icon, while those with grievances
regarding rewards, other products, etc. can use the other
available options. The user’s choice directs them into a menu
relevant only to their concern – unrelated grievance categories
are filtered out upfront and the user is less overwhelmed by
having to choose from irrelevant concerns.

The app may also host information about active tickets. For more
details, refer to the section on Ticket Tracking. The landing
Figure 4: All grievance-related screen of the help section may also include sections such as
information is housed on a Frequently Asked Questions which help the user to learn and
single landing screen. understand more about the product features.

Field testing with users reveals that most users were able to discover the UPI icon as they were familiar
with the term “UPI”. In the Hindi version, a few users were unable to associate the label ‘कोई सहायता
विषय चुने’ with the help options. The earlier title that was used in the testing (for English), of ‘Select help
topic’ was rephrased to ‘What do you need help with?’ for improving user’s clarity.33 Many users were
unable to comprehend the ‘View Tickets’ label. Users are not familiar with the term ‘ticket’ in the context
of grievance redress mechanisms. We nevertheless recommend continue using the word ‘ticket’ because
we believe it may be in the users’ interest to gain familiarity with this term given its pervasive usage across
customer care interactions in digital platforms. Most users were able to read and understand the FAQs
and found them useful.

33
The updated prototype is presented in Figure 4.
Problem Identification for Transaction Related Issues
The help navigation tree approach in designing the prototypes is
detailed in the Phase 2 section of this report. As described earlier, a
narrow help navigation tree has been devised to support users in
breaking down issues they are experiencing. Once the user has
entered into the grievance redressal section of the app, the help
navigation tree supports them to identify their problem by selecting
from among four options – ‘Problems Sending Money’, ‘Problems
Receiving Money’, ‘Unknown Payments’, ‘Other Issues’ (See Figure
5). These short, easily understandable phrases can help the user
categorise their grievance without much cognitive burden. From our
Phase 3 testing, we conclude that most users were able to
comprehend that this list represents UPI-related problem categories
and were able to choose the appropriate subcategories related to the
hypothetical scenario described to them.

Additionally, the category ‘Problems receiving money’ expands the

scope of the grievance mechanism to allow aggrieved receivers of
money raise grievances as well. Typically, UPI in-app GRMs only allow
grievances to be raised from the payer’s perspective – however,
allowing receivers to raise grievances may further enhance users’
trust and comfort while using the payments service. Our phase 1
insights indicated that there were specific examples of issues where
the grievance redress journeys for receivers of money was implicated.

The category ‘Unknown Payments’ is intended to capture user Figure 5: The problem
grievances in situations where it is unclear to the user what the identification screen asks the
transaction is. For instance, money has been deducted from the user’s user to select from broad
account, but the user is unclear or is unable to identify or recall the categories related to their type
payment. Users could have grievances related to fraudulent of grievance.
deductions or Autopay mandates which do not currently come under
the scope of transaction-related grievance mechanisms. This category was earlier titled ‘Money got
debited’, but this was not easily understood by users (who found it to overlap with ‘Problem Sending
Money’) and hence it was rephrased to ‘Unknown Payments’.
To cater to users who prefer listening to, rather than reading text,
the problem identification screen also provides an audio playback
facility to comprehend the screen. Users noticed and discovered the
availability of talk and chat buttons that were allowing for
alternative ways to address issues. The playback feature was earlier
represented as a microphone icon, which some users understood as
being for audio input rather than for audio playback. The icon has
accordingly been replaced with a ‘play’ button.

Overall, most users displayed a high intent to locate the transaction

in the transaction history screen first, possibly because that is the
user flow they are familiar with as it is present on most UPI apps.
Further, participants usually looked for the specific terms on the UPI
categories main page. Since specific phrases indicating their concern
such as ‘fraud’ could not be located on this screen, a few users
speculated that issues related to fraud might fall under the ‘Other
Issues’ category.

Once users select an option, they were taken to the next screen (see
Figure 6) to provide further information on their grievance. For
‘problems sending money’, users may experience money being
deducted but not received, transactions stuck in a processing state,
or failed transactions. However, a few users found that the title
‘money was deducted but not received’ could apply to the other two
subcategories as well, namely ‘My transaction is stuck in processing Figure 6: This screen was
state’ and 'My Transaction has a failed state’. It was difficult to causing some confusion among
clearly differentiate between the subcategories based on their titles. users and has been omitted from
While we tested this screen in February 2024, NPCI’s UDIR now the prototype.
allows for this information (on whether the transaction is in-
progress, pending, failed or successful) to be pulled from it automatically and this information can be
played back to the user. Given this development, this screen has been omitted from the prototype
altogether. Hence, for Level 1 Problem Identification, we do not go further than the prototype in Figure
5 and do not introduce any further screens in the help navigation tree.
 Data Gathering For Transaction Related Issues
Once the nature of the problem has been identified, the user is
presented with a list of transactions categorised as incoming or
outgoing to select the relevant transaction corresponding to their
issue. If the user chose Problem Sending Money in Level 1 Problem
Identification, only the outgoing transactions (including pending /
in-progress) will be presented. Alternatively, if the user chose
Problem Receiving Money, only incoming transactions will be
presented. Here, if the transaction has not been successful yet, it
will not show up in the list of incoming transactions. From our field
work, most users identified the relevant transactions from the
transaction list, in the scenarios where the transaction under
scrutiny was already visible to them. For issues within UPI, not
related to transactions, ‘Other Issues’ is provided as a 4th option –
this option has not been considered further in the Phases 2 and 3
of our project.

Additionally, users are also provided with the option to proceed

without selecting a transaction. If the user chose Problem
Receiving Money in Level 1 Problem Identification, then the
incoming transaction may not show up in the transactions list
presented to the user in cases where the transaction has not been
fully processed yet. For these, an additional ‘My Transaction is Not
Visible’ button is also presented to the user, which the users were
able to select in the tested scenario where money had not yet been
Figure 7: User may select the received by the user (Figure 7).
relevant transaction or proceed
without selecting a transaction. When the user selects a relevant transaction in Level 1 Problem
Identification, this allows for the GRM to gather data on the
transaction (Level 2 Data Gathering). Where a transaction is not visible, , the user is guided through a
process (See Ticket Filing section in report) where all necessary information is gathered, for instance, on
an incoming (and not visible) transaction, and a ticket initiated to address their concern effectively (which
is Level 3 Resolution).

Once the user has furnished sufficient information regarding their concern, this information, such as
transaction ID, status, amount, etc., is displayed on the screen. This helps to reconfirm that the user has
selected the correct transaction and provided the correct details, thus improving accuracy of the Level 2
Data Gathering process.

Users therefore have the opportunity to provide detailed context about their issue, and allowing for this
helps in gathering comprehensive details on the grievance. The resolution process is streamlined and
provides more targeted assistance to users.
Resolution for Transaction-related Issues
The user is then directed to the next level, Level 3 Resolution. Here, the information regarding resolution
for the transaction-related issue is presented to the user in a clear and effective manner.

The resolution detail screens have been designed to have four critical components to them, in the
following order – a reason statement, an actionable step for the user, a feedback loop on whether the
issue was resolved, and an option to speak/chat with agent. The resolution detail screen presents a reason
statement containing the potential reason for the issue encountered, in clear and straightforward
language. The solution is laid out to the user such that the next actionable step(s) from their end are
apparent. The solution may entail specific actions within the app or outside of it, such as waiting for a
specified number of days, reattempting the transaction, contacting customer support, reporting fraud, or
following predefined in-app troubleshooting procedures. The question ‘Did we solve your issue?’ on the
resolution detail screen was easy to understand. It provided users with a direct way to express satisfaction
or dissatisfaction, offering a sense of assurance that their concerns would be addressed. Lastly, the option
to speak/chat with agent (agent here can be a live agent, a chatbot or any other) is also available for users
who may still wish to exercise this option.

We elaborate on these resolution detail screens below, along two distinct buckets, self-resolution without
ticketing, and self-resolution with ticketing. This demarcation is made for the sole purpose of providing
explanatory clarity in this report and is not a separation made in the design of the prototypes.

Self-Resolution Without Ticketing

Our work indicates that there are possibly four themes in relation to transaction-related issues that will
overwhelmingly cover the universe of issues34 for the four categories presented in Level 1 Problem
Identification - the transaction is pending or in-progress, it is a failed or declined transaction, it is a
fraudulent transaction, or it is an Autopay mandate (the last two transactions will also pertain to
transactions that were successful). This aligns well with NPCI’s UDIR which classifies transactions as failed
transactions (where no money is debited from payer’s account), transactions in progress (where money
has been debited from payer’s account but is stuck either with remitter bank or with beneficiary bank),
and successful transactions (where money has reached receiver’s account). Since the UDIR allows for
auto-updates on pending transactions into the payer’s UPI app multiple times in a day, the outputs from
the UDIR will form part of the resolution screens for issues where ticketing can be largely obviated.

Most users were able to read and understand the details in the resolution detail screens. The provided
reason and solution tested were comprehensible to the users and offered clarity and temporary
satisfaction regarding their issues.

Pending or in-progress Transactions

For a transaction that is pending or in-progress, it is likely that money has been debited from the payer’s
account and is stuck either at the remitter bank or at the beneficiary bank. If it fails later (this is different
from a transaction that is declined upfront and payer account does not get debited), the money gets

34
We do not consider issues in relation to ancillary services in UPI such as RuPay card transactions, availing and
repaying credit lines, voice-enabled UPI transactions, UPI for feature phones, and so on
refunded back to the payer’s account immediately or after a delay (automatically or with manual
intervention).

Figure 8: The resolution page re- Figure 9: The resolution page re-
confirms the transaction details for confirms the transaction details for
the consumer, provides a reason for the consumer, provides a reason for
the grievance, and actionable next the grievance, and actionable next
steps. steps.

There may be instances where the debit reversal does not succeed on the same day and takes longer.
Figure 835 provides the resolution detail screen for users (payer) in this situation who want to find a
resolution. It provides a reason statement and the next actionable step.

Failed Transactions
Figure 9 provides the resolution detail screen for a transaction that has failed. In field testing, most users
were able to notice and comprehend the tag “Transaction Failed” on the resolution detail screen.

35
This screen was not part of the scenarios tested in Phase 3.
In user testing, various phrases in the Hindi versions of prototypes were found to be difficult for the users
to comprehend. This was the case for many of the screens tested. It is suggested that vernacular language
be made simple (as close to spoken language as possible) and easy for the constrained user to
comprehend (also see Broader Insights).

Grievances related to UPI Autopay

Sometimes, customers may flag successful outgoing transactions as pertaining to a grievance. These
transactions may pertain to Autopay mandates that had earlier been approved by a user, possibly by
mistake. Given the novelty of the feature and potential for user confusion, the resolution screen should
be clear and transparent to the user. From our field testing, it is apparent that most users are not familiar
with the term Autopay or UPI mandate and hence are unable to comprehend this feature and
consequently, any relevant steps pertaining to Autopay in the GRM as well.

A few users who had preliminary or basic comprehension of UPI AutoPay mandates, demonstrated a
familiar approach of discovering the issue first through a transaction listed on the transaction detail page.
This led them to first seek information on the specific transaction linked to UPI mandate, which helped
them recollect if they carried out any previous transaction of the same debited amount or not. If they
discovered the transaction amount in a particular month, they would also attempt to trace it back to
previous debits of similar amounts in past months. This helped them establish a correlation of repeated
debits, but they still had an intent to verify with the bank first before raising a complaint on GRM.

This insight is also helpful for the ecosystem to consider building features in the future that create better
accessibility via the transaction history pages. This is because most users have built this familiar UX path
to discover or establish issues that require resolution.

Educating the user by providing more information about UPI mandates is required to build familiarity and
comprehension of the payment mandate feature. The prototype (Figure 10) addresses this through a
reason statement offering users a clear and concise explanation for the deduction, emphasising that it
resulted from a UPI AutoPay mandate set up by the user. This
straightforward explanation helps users understand the
nature of the transaction and the automated deduction
mechanism associated with UPI AutoPay. It aims to alleviate
confusion and clarifies the legitimacy of the deduction.

The user is then presented with precise and actionable steps

to effectively address the issue at hand. In instances where a
refund cannot be facilitated, users are empathetically
informed of alternative measures to prevent future debits,
notably by considering a cancellation of the UPI AutoPay.
From here, users are seamlessly directed to the AutoPay
detail screen, where they can promptly initiate the necessary
actions to manage their AutoPay and prevent future debits
from happening if they so wish (‘Cancel Autopay’).

Most users did not comprehend the options ‘Cancel this

Mandate’ or 'Manage all your Mandates' and showed
apprehension in taking the next step as they were unfamiliar
with the term 'Mandate'. Incorporating this user feedback,
the buttons have been titled ‘Manage AutoPay’ for
increased clarity.

As the transaction details of AutoPay cannot be accessed

within the steps of the help navigation tree, it becomes
imperative to provide users with clarity regarding the
recurring nature of UPI AutoPay mandate transactions.
Therefore, within the section titled ‘Can this happen
again?’, users are briefed on the recurring feature of
Figure 10: User is provided clarity
AutoPay enabled transactions, and this sits alongside an
on UPI AutoPay mandates.
explanation about the likelihood of similar occurrences in
the future.

Furthermore, users are empowered with the option to review all active AutoPay, allowing them greater
insight over their financial transactions that have AutoPay enabled on them, and control over their
bank account savings.

Grievances Related to Fraudulent Transactions

When users encounter or notice a transaction that raises suspicions in their minds regarding its
authenticity, they are provided with the option to report it as fraud. Before proceeding with the reporting
process, the transaction details are broken down for the user. For instance, users are presented with
comprehensive transaction details, including recipient information. They are reminded that this
transaction has been authenticated by their PIN, reinforcing the importance of authentication. Finally,
they are presented with resolution options.

While acknowledging that a refund may not be possible, users are empowered with the option to contact
the payee directly. By directing them to the UPI transaction screen, users can initiate communication with
the payee, either through messaging or calling the associated mobile number. This option is currently
possible only in a few UPI apps and will require significant legal protections to be put in place before it
can become a feasible option for all UPI providers.

In user testing, most users were able to understand the information provided about the unknown
recipient of the money. They also appreciated the feature to check the details of the UPI account (the
UPI ID or phone number) that received the deducted amount from their UPI account.
In case users are not able to
recognise the transaction,
they may report the
transaction as fraudulent by
using the ‘Report as Fraud’
button (Figure 11). In user
testing, most users were able
to comprehend that a report
wasn’t submitted just by
navigating to the ‘Report
Fraud’ screen.

Users are therefore

presented with two
additional follow-up options
for resolution:

A. Report the transaction

as fraudulent: The UPI
app provider can provide
guidance to the user on
the next steps, such as
Figure 12: Users may report a
contacting the user’s fraudulent transaction or change their
bank, or contacting the Figure 11: User is reminded that they UPI Pin.
cyber crime branch or authorised the transaction, can
helpline. This enables communicate with payee, or report the
transaction as fraudulent.
users to continue with their fraud resolution journey
outside of the UPI app. However, most users expressed a preference to contact their bank and the
UPI app customer care before using the 'Call Cyber Crime Helpline 1930' button. Some users were
reluctant to use the cybercrime helpline and stated they wanted to know what information or
documents might be required to register a complaint on the helpline. We recommend that in addition
 to providing a direct way to call the 1930 Helpline, information on the broad documentation
requirements for reporting to the Helpline should also be mentioned on the same screen, either in
the form of a video link or a checklist 36 (Figure 12).
5

B. Change their UPI PIN for added security: Users are encouraged to enhance their security measures
by changing their UPI PIN. This mitigates the risk of further fraudulent transactions if their current
PIN had been compromised.
Well-structured resolution detail screens empower users with adequate guidance to address their
grievances efficiently. It ensures that users are informed about the issue, understand the proposed
solution, and can take actionable steps to resolve the issue with confidence.

Resolution with Ticketing

Ticketing is a process of raising a ticket that is automated by the backend system or by a human agent.
The grievance flows presented in the prototypes so far emphasise the self-resolution of user grievances,
which can also decrease the volume of tickets raised in the UPI app provider’s grievance management
system. That is, before creation of an actual grievance ticket, the system first emphasises providing
information, in an automated manner, on the nature of their grievance, reasons for its occurrence, and
clarity on actionable steps required, in a manner that is comprehensible to the constrained user .

In some cases, this approach may still not be sufficient in providing satisfactory resolution to the user. In
these instances, given below, a ticket may be created in the following ways:

1. Unknown transaction (My transaction is not visible): When users are unable to find a specific
transaction in the transactions list, they click on ‘My transaction is not visible’. This is a Call to
Action for the user and leads to the creation of a ticket. During this process if the user identifies
the said transaction as a fraudulent transaction, they are then directed to the next page to
report a fraud. If the user does not consider this as fraudulent, then they are led through the
resolution process via the new ticket that is created when the user files a ticket.
2. Call/ Chat with agent: The user has the option to call/ chat with an agent during the GRM
process. When the user exercises this option, a ticket is triggered and created from the backend,
from the agent’s side.
3. Problems with transactions: If the user is not satisfied with the given self-resolution for issues,
they may click the answer ‘No’ in response to the question ‘Did we solve your issue?’. The ‘No’
answer will lead to the ticket filing screen where the user can file a ticket and obtain further
assistance.

36
This is not part of our prototype.
Ticket Filing
When a ticket is being created, it is important to document the
steps taken thus far as it provides visibility for the service agent who
is investigating and responding to the ticket, without the need to
repeat significant parts of the data gathering exercise in Level
2. Doing so also enables the GRM to identify potential patterns in
recurring grievances so that they can be addressed proactively.

For the creation of a ticket, we recommend a structured flow for

the collection of data from the user, such that it collects the
following details from the user:

• Date of issue / transaction

• Amount in dispute
• Additional context or explanation regarding the issue /
transaction through a textbox, voice input, and or
photos/screenshots (in some cases)
From user testing, it was found that most users were able to
understand and use the date, amount and comment options
correctly. The straightforward design of prototypes contributed to
their ease of use and appeared to allow users to perform these tasks
without confusion (Figure 13).

In terms of the modes of information collection, most users Figure 13: A user-friendly
appreciated the flexibility to describe their issues either by typing or interface that facilitates efficient
recording their voices. and comprehensive submission
of information.
Most of the users found the information presented in the automated
response difficult to understand as these were technical in nature. Users suggested that vernacular
language options or audio playback based on previous steps of testing could be helpful for them to
comprehend effectively.
Ticket Confirmation and Acceptance
Once the data is submitted, a ticket detail screen is created for the issue. This screen immediately confirms
to the user, the successful submission of data, and serves as an
acknowledgement that their grievance has been registered
(Figure 14). It also provides an automated resolution (in the form
of a chatbot response) to the user, which includes resolution
steps and follow-up actions. The chatbot responses may be
provided in cases where the user has provided sufficient
information to warrant an automated response. While most users
were able to comprehend the automated responses, some found
the language complex and difficult to understand.

The screen also leverages analytics available throughout the

grievance ecosystem (and possibly from NPCI’s UDIR) to offer
some social validation to the user in the form of statistics, feedback
demonstrating expected turn-around-time for resolution of
issues, and so on. This reassures users of the platform’s
acknowledgement of the nature of the issue, its understanding
of the issue’s prevalence, and its commitment to resolving their
concerns effectively and in a transparent manner. While some
users found the content on social validation difficult to read and
understand, others appreciated the information provided and
construed it to be a reassurance.
Finally, users are presented with an option to escalate their issue
Figure 14: Once ticket is filed, by speaking with or requesting assistance from a service agent.
user receives a confirmation of This allows users to seek further clarification or assistance by
ticket-creation, an automated providing a more familiar, human-assisted alternative to the digital
response, and some social grievance redress solution. In our conceptualisation of these
validation information to provide
prototypes, we have placed this option throughout almost the
assurance.
entire resolution and ticketing process. We acknowledge that
making this option available adds to the support team resource
costs. Our intuition is that as the UDIR mechanisms mature further, and as users gain more comfort and
familiarity with in-app resolution mechanisms, the need for offering this option will reduce and can be
retracted in a systematic manner. The option may be placed only for those small proportions of issues
that may still need a human-assisted redressal mechanism.
Ticket Tracking
After users have filed a ticket, it is necessary for them to be able to quickly and easily refer to the ticket,
especially while it is still active. Users are alerted about updates on active tickets with a red-dot indicator
at the entry point to the ‘Help’ section which effectively notifies users of ongoing issues that may require
attention (See Figure 15). In our field testing, most users understood that the red dot on the ‘question
mark’ icon signified updates related to their complaints.

Figure 16: Easy access to a Figure 17: A dedicated

Figure 15: A 'red-dot'
dedicated dashboard for recent dashboard for recent tickets,
indicator notifies users of
tickets. both active and closed
updates on active tickets.

Upon entering the Help landing screen, the user can view a dedicated dashboard which previews all active
tickets requiring their attention. This section of the prototype includes a callout highlighting the presence
of active tickets and provides easy access for users to view and manage these tickets (See Figures 16,
17). This proactive approach enhances user engagement and facilitates timely resolution of outstanding
concerns.
Most users were able to discover the ticket status update from the app’s home screen (Figure 15) and
were able to comprehend the information provided in the ticket banner (Figure 16) in the Help landing
page.

The ‘View Tickets’ screen is a landing page presents a record of all active and closed tickets. This was
perceived as helpful by a few users in conveying that a ticket is associated with a submitted complaint.

Most users were able to comprehend the follow-up question on the ticket, ‘Have you received the
money?’ and had clarity for the next step in the task of engaging with ‘Yes/No’ and responded accurately.

Broader Insights
The following two insights are not limited to any specific screen tested and are relevant for considering
throughout the entire user journey. Both these pertain to the Consumer Value of Inclusivity and the
Product Principle of Accessibility.

A. The use of vernacular language: From the Hindi prototypes tested, we conclude that users
appreciated the use of vernacular language in the prototypes. However, there were various phrases
in the Hindi versions of prototypes that were found to be difficult for the users to comprehend. This
was the case for many of the screens tested. For instance,

• In the Hindi version, all users were unable to understand and read the term ‘प्रबन्धित’ in the CTA
‘अपने सभी मैंडेट प्रबंवित करें ’. “Cancel”, displayed as the English term or even transliterated in Hindi
language is more comprehensible for constrained users.
• Few users had difficulty understanding the statement ‘तीसरी पाटी के ऐप्स से सेट वकए गए यूपीआई
मैंडेट का स्वचावित रूप से पता िगाया जा सकता है ’ due to low comprehension of the concept of
mandates. This statement is related to UPI mandates set in third-party apps.

We suggest that vernacular language be made simple (as close to spoken language as possible) and
easy for the constrained user to comprehend. While we have only tested vernacular prototypes for
Hindi translations, a variety of permutations and combinations are possible, such as transliterations,
combinations of Hindi and English text, English words in Hindi script, and so on, which need to be
further tested in each app environment. Translation or transliteration can be made in spoken
language to match with spoken language proficiency.

B. Retaining certain technical words in their English form: ‘Ticket’ is a word that users are not familiar
with, in the context of GRMs. We nevertheless recommend continue using the word ‘ticket’ because
we believe it may be in the users’ interest to gain familiarity with this term given its pervasive usage
across customer care interactions in digital platforms.
C. The use of audio listening elements: We tested the audio playback button in the Level 1 Problem
Identification screen (but did not do so for remaining screens). This was a ‘play’ button indicating
audio playback of the problem category and its description. Users suggested that just like with
vernacular language options, the audio playback option (which they encountered in Level 1 Problem
Identification) could be helpful for them to comprehend the text effectively. We therefore suggest
the use of audio listening element for screens that are text heavy and where readers don’t have intent
 to read), and to do so subject to additional testing. This is particularly so for screens where technical
details or instructions are being provided to the user.

Project’s Limitations
This project and its outputs have the following limitations that stakeholders are to keep in mind when
using the insights presented.

1. Issues that users have in relation to onboarding onto the UPI app, such as with their bank accounts
and wallets (pre-paid instruments), Aadhaar e-KYC, mobile phone hardware or operating system-
related issues, non-linking of mobile numbers, and so on have not been considered in drawing up the
navigation architectures for the prototypes. Only issues in relation to UPI transactions on UPI apps on
smartphones have been considered. The screen for Level 1 Problem Identification of the help
navigation tree, however has the fourth option (‘Other Issues’) that has been earmarked for this
purpose and the downstream screens are best left to the UPI app providers to work out depending on
the functionalities offered by their respective apps.
2. Relatively newer features that have been introduced into UPI (including RuPay card transactions,
availing credit lines, voice-enabled transactions, by the NPCI have not been worked out in the flows.
This is because, a) these features were not discovered as being used by the respondents in phase 1,
and b) the project itself had limitations on how much the scope could be broadened.
3. The project did not study merchant-related issues, where merchants were the receivers of payments
(in either P2M or P2PM UPI transactions).
4. The prototypes tested have incorporated screens that pertained to issues faced by receivers of UPI
transactions – Under Level 1 Problem Identification, ‘Problems Receiving Money’ is one of four salient
options for the aggrieved user to choose from. In contract, NPCI’s UDIR has been designed for the
payer in mind. Other than insights from Phase 1 of our study, we do not have access to any aggregate
data to establish whether or not receivers form a non-trivial set of aggrieved customers. However, we
believe that incorporating in the design of the in-app GRM, flows that allow for the receiver to engage
with the support that UDIR can provide is an important feature that can be incorporated. This will
ensure that the representation of user grievances that the in-app GRM can allow for, can become
complete.
5. The prototypes do not consider the grievance redressal flows for transactions into wrong UPI accounts
that need to be refunded. This is because the initiating such refunds involves processes that are
specific to each provider and at the time of creating the prototypes, it was not clear whether the NPCI
was considering a mechanism for this via the UDIR, and whether the ecosystem was matured enough
to solve for this issue in an ex-post manner (current measures are directed towards ensuring that
checks and balances prevent such transactions from being executed in the first place). It is also unclear
what the proportion of such issues were within the universe of issues for which users contact the
customer care agents. Our Phase 1 field study did not include any discovery of this issue.
6. While we have only tested vernacular prototypes for Hindi translations, a variety of permutations and
combinations are possible but could not be tested due to resource constraints, such as transliterations,
combinations of Hindi and English text, English words in Hindi script, and so on.
7. The audio playback button was tested only at Level 1 Problem Identification screens and were not
tested for subsequent levels.
Takeaways for Stakeholders
We have covered only a small part of the overall GRM experience for UPI through this project. We have
focused on improving the constrained users’ experience for their grievance redress journeys with
payments transactions related issues. The UPI GRM has many other more sophisticated components, such
as merchant flows, credit card and credit line flows, among others, to be further studied from a UX
perspective and possibly strengthened in the future. We hope that this project will pique the interest of
important stakeholders in the UPI ecosystem, namely regulators such as the RBI and the NPCI, and UPI
providers such as banks and TPAPs. We envisage this work to have impact in the following ways.
Impact on the User
This project has sought to reimagine how GRMs inside the UPI apps are presented to its low- to medium
digital proficiency users such that a) the underlying logic, steps, and flow can potentially become more
consistent across apps that users engage with for executing UPI transactions, and b) users no longer
experience anxiety and confusion while finding resolutions for any transaction-related issues.

For using a payments solution that takes about a second to execute a transaction and is so seamless,
making available all answers, or at least answers for an overwhelming majority of user issues, is an
important and noble goal to aspire for. In the foreseeable future, when the UPI app can present an answer
or an explanation as a response to a user’s issue, the user will no longer have to rush to a bank branch or
to their nearest digitally savvy person in their social networks. For users for whom a visit to a bank branch,
or even finding solutions on YouTube is not an option (such as the elderly or illiterate women), the app
itself can be imagined as a one-stop shop for providing the necessary clarity about the issue, what to do
about it, and when not to do anything at all and to wait it out.

If in-app GRMs can be made more effective for the constrained user, the use of digital payments for daily
needs can become truly seamless for India’s substantial demographic segments. The pathway through
which this is achieved is through improved trust in the app’s ability to keep the user’s money safe,
irrespective of whether the user is a payer or a receiver. The app can then become truly inclusive because
it can work for customer personas who are digitally not as savvy, and doing so demonstrates immense
respect for the user’s time and their use of UPI for their livelihoods.

Impact on UPI App Providers

Many of the public goods we have created through this project can also be generated by each UPI app
provider if there is organization-wide intent to solve for the constrained user. While the overall experience
for proficient users is a significant consideration for strategic design decisions within the app, the
experiences of users lower in the digital proficiency spectrum may not find as much place. Moreover, it is
commonly acknowledged that the grievance support within apps do not fall among the most critical focus
areas for most entities given it is a cost center, not a revenue generator.

This project has sought to bridge this gap by documenting some of the mental models and experiences of
constrained users, designing and testing prototypes that try to solve some of the challenges unearthed.
These have been converted into easily consumable insights made available freely in the public domain, in
the form of a Toolkit for product managers and UX research enthusiasts and professionals to enhance user
satisfaction for aggrieved users, streamline issue resolution processes, and elevate the overall user
experience of UPI apps. It has been created to support anyone navigating the complexities of designing a
GRM system within an app offering UPI services. It helps make informed decisions regarding the
integration of the GRM into the application, with the objective of offering a seamless user experience. This
Toolkit will be socialized with UPI app providers through workshops and other events.

However, the effectiveness of any GRM can be known only by tracking and measuring its impact on users
and the business. Measuring impact can help stakeholders understand the effectiveness of the GRM, and
also signal areas where improvement and upgrades of the GRM may be required.

The UPI GRM Framework can be used as a foundation to build out a plethora of metrics along the 4 pillars
of the framework, and these can then be tracked and updated over time to establish impact. The GRM
system design should be able to establish baseline metrics against which success metrics may be captured,
which allows for continuous monitoring of progress. Such a practice would raise the bar for UPI products
and the ecosystem. One direct impact metric for the UPI app provider would be the drop in tickets or
complaints raised and the reduced costs for customer support. From the user side, impact may be
captured through ratings/reviews and feedback on the resolution experience itself.

Supporting Regulators’ Objectives for Inclusive Digital Payments

This project can serve Indian regulators‘ objectives for consumer protection in an inclusive manner for
digital payments.

For the RBI and the NPCI, our hope is that this work can bring focus to the in-app GRM as a critical
component of the UPI app experience. We hope that the NPCI can adopt the GRM Framework fully or in-
part and track the effectiveness of these GRMs across UPI app providers. This can also introduce more
clarity for regulated UPI app providers, be they banks or TPAPs, on how to go about designing in-app GRMs
for the constrained user. The GRM Framework may be useful to the RBI in their efforts to bring in user-
centricity across digital payments offerings by regulated entities in a very deliberate and specific way. The
Framework can also be a good starting point for devising and updating supervisory evaluation processes
for digital payments systems other than UPI, such as IMPS and NEFT.

The box below summarises key takeaways from this project in the form of good UX practice guidelines for
in-app GRMs of UPI.

User Experience Guidelines for Designing UPI in-app GRMs

✓ Entry point into the GRM section of UPI apps can be offered through two pathways:
o Entry from the transaction detail page:
Provide a button in the transaction detail page with the label ‘Get help with this
transaction’ as a clear action for the user. It provides help with a grievance by skipping
steps for retrieving data about the grievance.
o Entry from Home Screen:
Ensure that users can enter the GRM section of the app through the home screen of
the app. The entry should be placed above the fold, ideally in the top bar of the
screen. The icon should be clearly labelled ‘Help’.
✓ A help navigation tree consists of the sequential steps a user should follow to navigate the support
process. We recommend developing a user-flow based on a narrow tree which is more efficient in
ensuring user comprehension. The tree consists of three levels:
o Level 1: Problem identification
o Level 2: Data gathering
o Level 3: Resolution of the grievance
✓ Level 1 pertains to capturing the primary context of the issue.
o Users may be presented with a limited number of broad and easy to understand problem
categories, to help them narrow down on the correct issue they have experienced.
o Incorporate a ‘play’ button indicating audio playback of the problem category and its
description, especially in places where there is a dense volume of text to read or technical
details/instructions are being provided to the user.
o Ensure that buttons to connect with an agent through call and chat are available on this
screen and easily identifiable for the user.
✓ Level 2 facilitates gathering of specific details on the issue.
o Present the user with a list of transactions categorised by incoming or outgoing, from
which to select the relevant transaction.
o Additionally, provide an option to proceed without selecting a transaction.
✓ Level 3 pertains to an effective and efficient resolution process by breaking down information for
the user. The resolution process may be applicable in the following cases:
o Where the grievance pertains to a transaction, allow the user to verify that the correct
transaction has been selected by showing details that have been already selected or
provided by the user, such as transaction ID, status, amount, date and time, etc.
▪ Provide a ‘reason statement’ detailing the potential reasons for the encountered
issue, in clear and concise language without jargons that are not common.
▪ Lay out clear and actionable steps for the user to follow in resolving the issue
effectively. Where such action may be taken within the app environment, direct
users to the relevant screen seamlessly (without additional steps), where they can
initiate necessary action. For example, directing users to manage their UPI
Autopay mandates or change their UPI PIN.
o Where the grievance pertains to a transaction that is not available in the list of
transactions presented in Level 2, or where even after completing the instructions to
obtain resolution (in Level 3), the resolution has not yet happened, allow the user to
create a ticket pertaining to their issue. The following details should be collected in a
structured flow:
▪ Date of issue/transaction
▪ Amount in dispute
▪ Additional context or explanation regarding the issue/transaction through a text-
box or voice input
✓ Upon submission of a ticket, a ticket detail screen should be created, which confirms successful
submission
 o If the provided data warrants automatic resolution, is to be provided and clearly marked
as an automated resolution.
o Utilise analytics available within the ecosystem to offer social validation to the user.
Examples include providing simple statistics or feedback demonstrating the expected time
taken for resolution of similar issues in the past.
o Provide users with an option to escalate their issue by calling or chatting with a service
agent.
✓ Consolidate all active tickets into a single and easily accessible area. Further, alert users of updates
on active tickets by prominently displaying a red-dot indicator at the entry point to the ‘Help’
section.
✓ Provide users with a chat-like interface to communicate updates and responses on the ticket.
✓ Use simple vernacular language (as close to spoken language as possible) to aid comprehension
for the user. A variety of permutations and combinations for content are possible, such as
transliterations, combinations of local language and English text, English words in local language
script, and so on, which need to be further tested in each app environment.
✓ Incorporate a feature to play back the options using voice for users who are not comfortable
reading.

The UPI market is a dynamic space characterised by technological changes, a rapidly expanding consumer
base, and changing patterns of adoption. Designing GRMs for UPI cannot be a static, one-time exercise –
constant evolution is required to keep pace with the changes in how users interact with UPI. Consumer
or user-centricity will continue to be the guiding star for how to design an effective GRM system.
Conclusion
When we set out to undertake this project, we adopted a Problem First approach where our chief
stakeholder was the constrained user of UPI – our objective has been to improve comprehension for them
so that we can imagine a future where they need to go no further than their own UPI app for finding
resolutions to their issues. However, in the course of our work that spanned over 10 months, we came to
the firm realisation that what we aimed for and what we have created can be equally applicable to the
entire universe of UPI users (non-poor, and high digital proficiency users), not just the constrained user.

There was fundamental acceptance for our work from some of the prominent TPAPs to whom we
presented this project and its outputs. However, it became clear to us that there is a need to continuously
refine and improve the approach to the in-app GRM from each provider’s side, to update the user journeys
to reflect developments from a variety of quarters, such as

➢ Updates in the NPCI’s UDIR, UDIR for UPI over feature phones (for instance, the Level 1 Problem
Identification is directly implicated here), UDIR for merchant chargebacks, GRM for credit lines, and so
on
➢ Updates to the system’s abilities to prevent and mitigate fraudulent activity over UPI (for instance, the
self-resolution screens for reporting fraud and taking certain steps to aid the enforcement authorities,
are directly implicated here)

A deliberate approach to enable and rely on feedback loops from the in-app GRM to circle back into the
product teams’ mandates, will be critical to ensure successful in-app GRMs within UPI – these are GRMs
that constrained users turn to and obtain resolution from in a clear, easy and effective manner. Such
feedback loops will answer the question of whether self-resolution is working for users, whether users are
raising tickets only for a narrow subset of issues that cannot be dealt with through the in-app GRM,
whether users are able to comprehend AutoPay mandates and manage them effectively, whether small
merchants no longer have difficulties in reconciling receipt transactions, and so on. While metrics can be
designed that can speak to each of these questions, we hope that the UPI GRM Framework provides an
essential guiding light when it comes to deciding the choice of metrics to track and incentivise for user-
centric outcomes. The NPCI plays a pivotal role in driving a data-driven approach to continually improving
the overall user experience of UPI, and we hope that this project can support the NPCI in doing the same
with the user experience for in-app GRMs.

The user experience guidelines for designing UPI in-app GRMs is a consolidation of the key insights from
this project, and we believe this will be of value to policymakers, regulators, product tech and design
enthusiasts who are trying to design digital interfaces for the billion users. The enormity of this challenge
requires a collective effort and knowledge-sharing across stakeholders, and what we have placed as public
goods via this project is a small contribution in that direction.
Appendix I: Comparative Study of UPI Apps
The table below summarises a comparative analysis that was done during October and November 2023
and updated in February 2024. Changes that may have been introduced by UPI app providers since then
will not be reflected in the table below.

Comparative Item UPI App 1 UPI App 2 UPI App 3 UPI App 4
Home Screen Icon/Link to GRM ❌ ✅ ❌ ❌
If not then, Nested within? Profile ✅ Profile Profile

Icon

Seek help: Txn Failed ✅ ✅ ✅ ✅

Seek help: Txn Success ✅ ✅ ✅ ✅
Ticket Update on Home ❌ ❌ ❌ ❌
Ticket Notification ❌ ❌ ❌ ❌
Separate UPI Section ❌ ❌ ✅ ❌
Active Tickets View ✅ ❌ ❌ ❌
Top Qs/FAQs ✅ ✅ ❌ ✅
Video Content ✅ ❌ ❌ ❌
Separate UPI Section ❌ ❌ ✅ ❌
Autopay Support ❌ ❌ ❌ ❌
Levels of Content 1 4 2 1
Appendix II: Prototypes 37 36F

Prototype 1 Problems Sending Money: UPI Help Landing UPI_GRM_Prototype_01

Page > Level 1 of Help Navigation Tree > Level 2 (Data (dvararesearch.com)
Gathering via Transactions List/Transaction Not
Visible) > Level 3 Self-Resolution (Resolution via
Reason Explanation & Call to Action
Prototype 2 Problems Receiving Money: UPI Help Landing UPI_GRM_Prototype_02
Page > Level 1 of Help Navigation Tree > Level 2 (Data (dvararesearch.com)
Gathering via Transactions List / Transaction Not
Visible) > Level 3 (Resolution via Submitting Ticket) >
Self-Resolution via Automated Response (Resolution
via Social Validation)
Prototype 3 Self-Resolution pathways > Viewing & Tracking status UPI_GRM_Prototype_03
of Tickets, Level 3 (Self-Resolution via Waiting, (dvararesearch.com)
Automated Response)
Prototype 4 Unknown Payments > Help Navigation Tree (Levels UPI_GRM_Prototype_04
1, 2, 3) (dvararesearch.com)
A. Case of UPI AutoPay – Resolution via
Managing UPI AutoPay Mandates
B. Case of Fraud – Resolution via Contacting
Counterparty & Reporting Fraud

37
These prototypes were created as part of Phase 2, and additional changes made to them based on insights from
user testing in Phase 3.