Table of content

Avoid major budget over-utilization by revamping the Rebate management tool

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.

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.

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.

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.

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 suppliers, reports rebate amounts, and decides how to use them. The Finance team approves submitted amounts and the use of rebates.

More context

At that time, 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.

Note: Click “Create New Rebate” to see the Create page.

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.

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.

Understand more about the problem through user interview & focus group

I met some representatives from the Procurement team to discuss the issue. It appears that the team faced several unclear elements in the system when inputting rebate information using the tool.

The PM and I held several meetings with the Procurement team to gain a deeper understanding of their problems. Some meetings were individual sessions where users demonstrated the issues they encountered. Other meetings involved a group of people.

(We chose to alternate between conducting interviews with a single person and holding focus groups. This approach allowed us to understand how users utilize the tool and listen to their proposed solutions or ideas. It also provided us with an opportunity to hear the users' desires when bouncing ideas back and forth in informal conversations. Furthermore, during the group discussions, users presented opposing perspectives, which allowed us to filter out the most essential information, not just surface-level problems.)

Filter the collected information

Because we understand that there is often a major gap between what users say and what they actually do, we do not make product changes based solely on their words during interviews. Instead, the PM and I review the findings together and summarized the 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 lack of guidance and clear explanations makes it difficult for users to input information and wastes time on error correction.

Solution

All of the aforementioned problems are addressed in the new design below 👇

New 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.

🎉 The project was a huge success, with the following outcomes:

  • The amount of user requests for help decreased significantly, as they no longer needed to contact the team regularly for assistance.

  • The speed of rebate approvals increased rapidly every day after the new design was released.

  • Additionally, the budget over-utilization was significantly reduced from tens of billions of VND to just a few billion VND.

  • Finally, Tiki Trading saw a positive profit for the first time in its history. This outcome was not solely due to the redesigned design, but also to other parallel projects.

  • Within only one month of releasing the new design, the rebate approval process was completely transitioned to our tool.