R2
With few information about the case, I worked on the creation of a business model to later apply it in the proposed scenario of Dodo Doritos.
Asigned role
UX Designer
Timeline
Feb. 2022 - 3 days
Tools
Let's star the journey with some information:
About the company
R2 provides a 'capital as a service' solution for a technology platform offering mobile point-of-sale (mPOS) solutions. This empowers their users, typically SMEs like grocery stores, specialty shops, and restaurants, to accept credit and debit card payments.
About the product
Sales Advances, a type of short-term loan, use the user's transaction history on the platform to determine a personalized credit limit.
Dodo Doritos
Dodo Doritos, a small restaurant, applied for a Sales Advance (short-term loan) directly through the partner platform. After R2 approved their application, Dodo Doritos received the $80,000 loan within 12 hours. They have 8 months to repay it.
Business Strategy
Customer Platform (Desktop)
Data Visualization
Information Architecture
Product Strategy
Prototyping Tools | Figma
Team talk (Presentation)
Visual Design Principles
Wireframing | Figma
The case
Dodo Doritos repays the loan through a percentage of their transaction volume automatically deducted each time they use their mobile point-of-sale terminal.
It's been 3.5 months since Dodo Doritos received the Sales Advance. They've already repaid 32% of the total amount. However, there haven't been any transactions for the past 30 days.
As part of the Sales Advance agreement, Dodo Doritos needs to process a minimum of $2,000 in monthly sales through their payment terminal. A 12% commission from these transactions goes towards repaying the loan.
What we know
Loan
$80,000.00
Final payed
$85,000.00
Deadline
8 months
Business rules
Since I lacked access to existing business and product rules, I defined them to analyze potential scenarios. This simplified the process, assuming consistent monthly sales.
Scenario 1
Scenario 1
The ideal scenario: The user pays the loan before the maximum term of 8 months expires.
Scenario 2
The user isn’t late any month: the sales of his restaurant allows him to complete the loan month by month.
Use the possibility of injecting money from an external account.
At month 8 (maximum term) complete 100% of the payment.
Scenario 3
The user doesn’t sell enough during the months that he has to pay the loan.
We suggested to deposit money from another account to pay.
Default management: increase collection rate (from 12% to 25% for example). This case can be manage by a collection’s team.
Scenario 4
The user doesn’t complete the minimum payment month by month.
Default management: increase collection rate (from 12% to 25% for example). This case can be manage by a collection’s team.
Research
I had information from a research provided by R2: what do our users need to see on their dashboard?
Status payment: advance.
Amount paid.
How much do they have to pay?
How much time they have to finish the advance.
The characteristics of its advance.
Their payment history.
The part of the transactions that they’ll actually receive in their bank account and the part used to pay the advance.
Building the product
Definitions about the product based on the information collected:
✅ Platform that we’ll use: Web-app within the partner's product.
In this way, we don’t force the users to download a new application on their cell phone. You can view the status of the loan quickly and easily from an access (widget) from the partner's app that you’re already using.
✅ Communications about payment status
We’ll send a monthly notification via WhatsApp or e-mail to inform the user the current status of the account and payment.
The tone of the communications will vary according to the status of the payment: if our user is close to the payment deadline and we see a very large gap between what he sells and what he has to pay, we will use an urgency tone. In the event that the user is up to date, the tone to be used will be more relaxed.
✅ Money-in
We’ll enable the option to "Deposit money" in the account from the dashboard. This will allow the user not to tie the loan payment exclusively to the sales of their restaurant.
✅ Frequency of information to display on the dashboard
Is it useful for our user to see their expenses by day, month or year? We need to see metrics to define this.
The case
This user's chart would look stagnant: 0 sales in the last 30 days.
It’s no longer up to date, we need to notify the user about its status.
It’s not meeting the minimum payment for the month (therefore it doesn’t reach the ideal payment either).
The merchant already paid 32% of the loan.
What we know about the status:
Total to pay: $85,000.00
Already payed 32% ($27,200)
30 days with no activity on partner’s platform
Way to pay: 12% of daily sells
Month number: 3 and a half (day 105)
Deadline: 8 months
Minimum transaction per day: $2.000
Drafts
Final design
I wanted to keep it simple: minimalist design + correct information’s hierarchy, without losing the insights of the research and the model bussines.
Final thoughts
I completed this project as part of a selection process challenge. While I was subsequently offered the position, I decided to remain at Mercado Libre. However, this project provided me with the opportunity to apply my knowledge of product, business, and visual design.
