Rebate Management
How my design improvement helped reduce budget over-ultilization from tens to only a few billions VND
Retail
Operational tool
End-to-end design
Summary
Challenge
My role
Result
What I've learnt
Context
Tiki has a retail business where they buy products from suppliers, store them in Tiki's warehouse, and sell them on the Tiki platform under the name Tiki Trading.
Rebate is a discount that Tiki receives from the supplier when purchasing a large quantity of products or money, or meeting certain pre-agreed conditions. The conditions for receiving rebates are diverse and can be very complex. Some examples include:
Buying 1000 products and receiving a 10% discount on the total cost
Or - If Tiki purchases products A, B, and C, they will receive a discount of VND 500,000 for each product.
Tiki often uses rebates to lower product prices on its platform and stay competitive. However, to receive the rebate, Tiki must meet certain conditions in the contract. Therefore in order to offer competitive prices, Tiki has to use its own funds for promotions before receiving the rebate.
Too many words? I hope the illustration below explains the context better 👇
As you can see, this solution carries risks:
If the rebate amounts are overestimated, Tiki may face losses if the selling prices plus rebate amount are less than the cost of acquiring the products.
Conversely, if the rebate amounts are underestimated, Tiki will miss opportunities to invest more in promotions.
The Procurement team contracts with the suppliers, reports rebate amounts, and decides how to use them. The Finance team approves submitted amounts and the use of rebates.
Problem
At that time, our the Retail IQ team has provided the Procurement team with a system (not designed by me) to enter rebate amounts. This tool requires the Procurement team to input the conditions into the system for:
The system to automatically calculate and update whether Tiki has met the conditions for receiving the rebate and how much money they will receive based on the approved information.
The Finance team to double check the conditions entered against the information recorded in the contract.
The tool is the source of truth for all related teams and management levels to update Tiki's rebate budget. And most importantly, it helps the Procurement team accurately identify how much money they will have in the budget to use for discounts, without over-utilizing.
Note: Click “Create New Rebate” to see the Create page.
Problem
However, after 3 months since the release of the first version, the Procurement team has not fully transitioned the process of submitting rebate to our tool and is still using the old method (excel) to manage and work with other teams. Lingering issues from before - tens billion of VND are over-utilizing every month, still remain unresolved.
Identify the causes through user interviews
I met some representatives from the Procurement team to discuss the issue. It appears that the team find the tool hard to use, the interface is unclear and sometimes confusing. They feel like it takes too much effort to figure out, so they’ve pretty much given up on it.
I summarized the findings into following main problems:
1. Bad information structure
Input fields related to each other or that should be grouped for ease of use are scattered throughout the interface. Information is also arranged randomly without distinguishing importance.
The Create page - where user submit the rebate details.
Rebate listing, where all submitted rebates are listed.
This results in poor learnability. Users may get confused about the correspondence between the input fields and the contract when viewing the UI. It is unclear which information is important to input, pay attention to, or interact with.
This also leads to low efficiency. Users often have to navigate up and down or back and forth in the contract to fill in adjacent information or find corresponding information in the tool. This process can sometimes result in incorrect information input, leading to error messages from the system.
There is some information that may not be necessary and can be omitted to simplify the user's task.
2. Lack of visibility of system status
Often, after inputting information, the system shows an error message or rejects the rebate due to incorrect information. However, these messages lack specific details on the error's location or how to fix it. This leaves users stuck and unable to proceed. Examples below.
The Create page - where user submit the rebate details.
The improved design
Improvements in the Listing page
Improvements in the Create page
Improvements in Error Handling
In the Create page, I also define possible error cases and provide a corresponding error message for each case. Then I create guidelines on how to display these error messages for the tech team to follow.
Result
We have enhanced the design of the Rebate tool to facilitate the Procurement and Finance teams in submitting and approving rebates with minimal errors. By approving rebates promptly and accurately, the system can calculate the exact amount that Tiki will receive in the future as soon as possible. The sooner and accurate the calculations are, the lower the risk of over-utilizing the budget. By minimizing budget over-utilization, Tiki Trading's profits are guaranteed to increase.
We carried out this project as a small project in a series of projects aimed at the goal of "Controlling Tiki Trading profit" during the economic crisis period after the Covid pandemic.
🎉 This small project was a huge success, with the following outcomes:
Within only one month of releasing the new design, the rebate approval process was completely transitioned to our tool.
The budget over-utilization was significantly reduced from tens of billions of VND to just a few billion VND.
The speed of rebate approvals increased rapidly every day after the new design was released. We did not track, but this was what the Procurement team reported to us.
