Building a unique credit payments network from scratch in 8 months.
Case study
OVERVIEW
Simpl provides a seamless way to shop online by enabling users to place multiple orders across different merchants over a period of time and pay one consolidated bill. Just like your neighborhood Kirana stores. Thereby making credit more accessible and useful.
Simpl is the first and the leading pay later service in India.
I was one of the 5 members of the founding team that built Simpl from the ground up. As the first designer, I eventually led a design team to build a unique payment network for India that processes over 100 million dollars a year, with more than 8 million active customers in 3 years.
ROLE
Product design lead.
RESULT
- Launched the product in 8 months.
- A new and unique experience of making online payments got introduced in India.
- Grew from processing 0 to 1 million daily transactions on 40+ merchants in a year.
Back story
Let’s go back to the start of this bumpy ride. It was the summer of 2015 in India. I had recently quit from one of the leading startups at that time, Housing.com. Unsure what I would do next, I spent the next few weeks sending 100s of cold emails to people in the startup ecosystem, trying to get a fresh perspective on what are the possible roads that I can take.
One Saturday morning, it was gloomy and pouring down in Mumbai. The weather called for relaxing in a cozy cafe with a delicious cup of coffee, looking at the rain droplets racing down the glass window. I asked one of my friends, who is also a brilliant product manager, to accompany me. He mentioned these 2 people (Nitya and Chaitra) who had just returned from the USA and were looking to start a fintech company in India. He had already met them a couple of times and was impressed with their enthusiasm. He insisted me to meet them, and that’s what I did.
Since you’re here to judge my work and not for the full back story. The 2 main reasons I choose to take a chance early in my career to join a company that didn’t even have a name were the people I would be working with and the potential to grow in my career.
Grab some popcorn; I’m going to briefly take you through the journey of how 7 individuals with different skillsets went about building a first-of-a-kind payment service in India.
Establishing the problem statement
Although we had a vision but to make sure we don’t go off track, to begin with, we needed to narrow down and define a goal.
Research agenda
- To gather data around all the payment instruments available in the market.
- To understand what makes a user prefer a payment instrument over others.
- To find out the difficulties faced by the users while making online payments.
- To understand a user’s behavior while making an online payment.
- To understand difficulties faced by merchants with all the available payment instruments.
What we learned
There are 800 Million bank accounts in India. Only 30% pay digitally. The rest of the 70% prefer paying via cash. From the 30% who do pay digitally face 40–45% of payment failures.
Types of payment options available
Debit Cards
To pay online using a debit card, the user has to enter the card details and then do a second layer of authentication via a unique pin or an OTP(One time password).
Credit Cards
Paying with a credit card is precisely similar to a debit card. The only difference here is that the user is using his credit balance to pay.
Net banking
To pay using net banking, the user has to login to the bank website and then do a second layer of authentication for higher amounts.
Wallets
To transact using a wallet, the user must first add money to their wallet using their debit/credit card or net banking. Once the money is added to the wallet, payment can be made instantly.
UPI — Unified Payment Interface
To transact using UPI, the user has to link their bank account to their UPI app. Once the account is linked, the user just needs to enter their unique pin to make payments.
Cash
-
Why do people prefer a payment method over another?
Having conversations with 80+ people of target demographics, we came to an understanding that people choose a particular payment method based on three main reasons
- Offer / Discount
- Utility
- Convenience / Ease / Habit
Offer / Discount
People who choose their payment instrument plainly based on the best offer available.
Utility
People who employ separate payment instruments for different use cases for convenience and/or rewards.
Convenience / Ease / Habit
People who prefer to use the same payment instrument everywhere out of habit and/or convenience.
-
By observing these people making digital payments and asking them to explain their experiences, we categorized the difficulties they spoke about below.
-
Customers payment problems
Time-consuming
Paying with Debit/Credit cards is time-consuming because of the 2-factor authentication. Net banking is the same. Wallets need recharging. UPI is the fastest of them all but still not fast enough.
Overwhelming
People who tend to prefer cash find making digital payment overwhelming with n number of options available in the market.
Security
People are afraid to give any of their bank/card details because of potential fraud. Adding to the complexities that they have to go through every time they have to make a payment.
Monotonous
Entering the same card details or the same authentication details is monotonous. Users desire a seamless and smarter experience.
Payment failures
Users are also at the receiving end of the 40–45% of payment failure rates.
Refunds and cancelations
Users have limited transparency on how refunds and cancelations are handled. It takes 7 days on average for users to get their refunds.
-
Merchants payment problems
High failure rates
Between 40–45% of online transactions fail.
Complicated refunds and cancelations
Processing refunds and cancelations take around a week. The customer hardly has any transparency.
COD is an added logistics cost
Cash on delivery costs higher than the already increasing MDR.
-
Defining Our Goals
After analyzing all the information that we had collected, we narrowed down the target audience and focused our energy on building a product that addresses the problems they face.
What do we want to build?
- A payment method that leverages credit to deliver a seamless payment experience.
- A payment method that customers can trust and feel safe using.
- A payment method that has zero failures with few exceptions.
- A unique payment method.
- A fast payment method.
A customer is not looking to make a payment. Paying is just a means to complete their primary objective.
How did we begin?
It is an illusion to think that you can get something right the first time. That is why we targeted to build an MVP as quickly as possible.
“Ship early and ship often.”
-
Our primary goal was to design an experience that is super easy to use, quick and smart. Since that is what the market was lacking. Since we knew we want to leverage credit, we took the neighborhood Kirana store analogy.
Here’s how a Khata works in the real world.
A user visits a store, gets whatever they need, then tells the store manager to add the total amount payable to their Khata. The user repeats this action every time they need something from the store and settles the total amount payable once a month.
See how seamless this is? We wanted to bring this offline experience into the digital world.
Imagine if you can do that at multiple stores? Go to any store, buy whatever you need, and the order amount gets added to your bill (Khata), which you’ve to pay once a month. Amazing right?
-
To deliver that experience, we had to first underwrite users to determine their credit eligibility. This made Simpl fundamentally a credit lending product.
In any credit product, there are 3 main aspects.
First — when the user gives his personal and/or financial details to determine their credit eligibility.
Second — when a user uses the credit for their purchases.
Third — when the user pays back the credit.
For determining the credit eligibility, we didn’t want to ask users for their information like how every other credit lending company does. Instead, we worked closely with merchants and relied on merchants’ data to identify which users we should approve and how much credit should be given to them.
We even wanted to make the process of using the credit and paying back the credit simple.
To envision how everything will work, we listed down fundamental questions to shape the product. We debated long on each of these questions to come to the solutions.
What are we going to name this product?
A: Simpl (Here is where we had the most fun. I wish I could tell you the story of how we choose that name, maybe some other day)
Where can a user discover Simpl?
A: When a user is about to make a payment on a merchant’s app, that is where a user would discover Simpl.
For example, this is the payment page of BookMyShow. This is where Simpl will come as one of the options to pay.
How are we going to onboard users?
A: When a user chooses Simpl while paying for their order, that’s where we have to onboard users. That’s when a user enters into our’ Onboarding flow.’
Since we will be Onboarding our users on the merchant’s platform, we have to ensure that the Onboarding flow is short and doesn’t add to the user’s complexity of placing an order.
To Onboard users, we designed 3 screens.
1. Intro Screen — Educate
The intro screen explains what Simpl offers.
2. Verification Screen — Authenticate
The verification screen verifies the user’s device by sending an OTP to the user’s mobile number registered with the merchant.
3. Confirmation Screen — Confirm
The confirmation screen shows the amount that they are about to transact for.
How will a repeat user flow look like?
Once a user completes their first transaction using Simpl, they’ll only see a confirmation screen next time they use Simpl.
When do we collect back from users?
A: For MVP, we decided to have 15 days billing cycle. That means Simpl bill will get generated on the 1st and 16th of every month.
Once the bill is generated, an SMS & email is sent to the user reminding them to pay their Simpl bill. Users get 10 days from the date of bill generation to settle their Simpl bill.
Obviously, we wanted to give users flexible and longer billing cycles, but that added a lot of complication in the product, which was not viable for the launch.
How are we going to underwrite customers?
Here is where we want to begin our differentiation. We will not ask users for any of their financial data. We will work with partner merchants to identify low-risk users and begin by underwriting them. Learn from that and scale up to build a robust system.
How are we going to convince merchants to partner with Simpl?
A: For the Simpl payment option to be present on any merchant app, firstly, the merchant has to agree to integrate Simpl on their platform.
Obviously, we had no users and, therefore, no data to convince merchants. Simpl being different from traditional payment methods, it was difficult to explain how Simpl functions and what benefits merchants can get.
To aid the selling process, we created prototypes(using Marvel) of how a user flow will look like on a merchant’s app when a user chooses to pay using Simpl. This helped merchants envision how Simpl can work on their platform.
For example, below is a marvel prototype that we created for Grofers to showcase how Simpl can let their users place an order from the order details page itself instead of going to the payment page.
We all know COD (Cash on Delivery) is a problem in India. Particularly for merchants, it is a logistical pain and an added cost.
A couple of reasons why a user prefers COD is that it’s convenient, quick, and users want to pay for goods only after receiving them.
Simpl covers these aspects. With Simpl placing an order is super quick and convenient. And since the user has to pay for their order later, more often than not, that means paying after they have received their order.
So we also created a flow where when a user chooses COD as their payment mode, we prompt them to use Simpl.
This way, the merchants can convert COD customers into online paying customers, reducing their operating costs. And customers get the benefits of COD.
We created these prototypes for every merchant to help convince them and move things faster.
Tweet to merchants
(Although we built this feature after the launch, I’m mentioning it here.)
To further convince merchants, we built a feature inside our Simpl app where users can tweet to their favorite merchant, asking them to integrate Simpl. Utilizing the power of social media. ;)
LAUNCH
Faasos was the first merchant that agreed to integrate Simpl into their system.
Although our product was decently functional at that time, we hadn’t covered all aspects of the entire product experience.
Knowing that we also didn’t want to miss the opportunity to go live on our first merchant as soon as possible. And what’s better than testing your product with real users?
“If you are not embarrassed by the first version of your product, you’ve launched too late.”- Reid Hoffman
So we buried our illusion of making everything perfect and went live with Faasos.
Faasos positioned Simpl as a service that is exclusive to their loyal users. They called it ‘Faasos Elite.’ This way, Faasos created a loyalty program powered by Simpl and offered special service to their Elite users, resulting in customer stickiness and retention.
This was a perfect start for Simpl and time for celebrations. 🎉
MAKING SIMPL EVEN SIMPLER
In the next few months, we went live on 10+ merchants and got 10,000+ active users. Having these many active users was ideal for testing how the product performs and making it better.
Below are some of the many problems that we faced after the launch. And -what we did to rectify it.
Problem:
Only 55% of users are completing the Onboarding. 45% of users are dropping off.
Our Onboarding flow had 3 screens(showed earlier). Intro, Validate, and Confirm. There was approximately a 45% drop-off on the Intro screen. 20% drop off on the Validate screen. 12% drop off on the Confirm screen.
So clearly, we had to do something on the Intro screen first, which had the maximum drop-off.
What we did:
Initially, we changed the copy of the intro screen and did A/B testing. The idea was to try a few different approaches to communicate about Simpl and see which performs better.
Below are some of the other screens that we tested, with separate copies and subtle design tweaks.
All these screens had similar conversion rates with marginal differences. This made us realize that the first transaction screen is not adding much value.
So we decided to remove the first screen altogether and merge the first (Intro) and second (Validate) screen into one.
This reduced the number of steps of Onboarding from 3 steps to 2 steps. Which resulted in notably improved conversions.
Problem:
Users are not knowing or forgetting when they have to pay their Simpl bill.
Even though we send SMS and Email to notify our users to pay their Simpl bill, many of our users were not paying their bill on time.
What we did:
We didn’t want to simply levy a late fee before understanding why aren’t the users paying their Simpl bill on time.
We spoke to some of our users to understand the reason. The majority of them said they simply don’t know when they’ve to pay their Simpl bill.
We realized, SMS & Email have limited impact. Also, in the age of WhatsApp, iMessage, Messenger, etc., very few people check their SMS and Email.
So we decided to communicate the repayment date to users while they are transacting. To do this, we added the repayment date on the Confirm screen. Now, every time a user is transacting using Simpl, they will see the repayment date on the Confirm screen.
This improved our repayments numbers. But not considerably. People were still missing that information and simply placing their orders without noticing the date of repayment.
To ensure that the users don’t miss seeing the repayment date, we added an extra step. On the confirm screen, to complete the transaction, users have to explicitly agree to repay on a specific date by tapping on a button that said ‘I Agree.’ (shown below)
This reduced the issue of users not knowing when they have to pay their Simpl bill drastically.
Problem:
Users are dropping off when trying to pay their Simpl bill. 40% of our users were dropping off from the repayment flow.
What we did:
After analyzing why this is happening, we discovered that most users are dropping off because to pay their Simpl bill; first, a user has to login to the Simpl.
Since we don’t ask users to register while Onboarding, we asked them to register when they login to the Simpl dashboard to pay their Simpl bill.
This resulted in a lot of drop off. Many users were simply not willing to make the effort of logging into the Simpl dashboard to pay their bill.
To address this problem, we decided to not ask users to register to pay their Simpl bill.
When the Simpl bill is generated, we create a unique link for each user to access their Simpl bill without signing in. Using this unique link (which we call ‘Quick pay link’), users can see their Simpl bill’s details and make the payment. Resulting in improved repayments.
CONCLUDING
It’s been a crazy experience working at Simpl, being part of a fantastic team where every individual is passionate about what they do and have fun while doing it.
I’ve learned immensely throughout this journey, not only about product design but also about many other aspects of building a digital product.
I can talk a lot about what it is to be like a designer at an early-stage startup. But that will make this post even longer.
I’ve shared my thoughts about that here.
User’s love Simpl.
