Estudo de caso #2: melhorando os KPIs de atribuição de entrega Rappi, diminuindo o tempo gasto entre o pedido do usuário e a aceitação do entregador.
Aviso: Eu não possuo nenhuma relação com Rappi. Esse é um desafio de caso que me foi apresentado como um exercício de Gerenciamento de Produto. Todas as decisões, opiniões e projetos são estritamente meus e não são afiliados à Rappi.
You have been assigned the KPI of making sure 99% of orders have a delivery person assigned within the first 5 minutes of search (current level 85%).
How would you determine what technology would most help improve this KPI?
How it works
In Rappi, when we need to assign a delivery person (rappitendero) to an order, we look for someone nearby and we offer them the order, one delivery person at a time. They see the distance and the price and have 30 seconds to take a yes/no decision to take the order or not.
15% of the orders are taking longer than 5 minutes to get assigned to a Rappitendero.
Assigned within 5 minutes
Assigned after 5 minutes
We need to increase the delivery assignment rate within the first 5 minutes of the order from 85 to 99%.
If 85% of the assignments are made within the first 5 minutes of the order, what is happening with the other 15%? Why are they taking longer than 5 minutes to be assigned? From the start, we can quickly draft a list of probable reasons why this is happening.
Rejection: Rappitenderos are deliberately choosing not to take the orders (reasons being: too busy, too far, not enough money);
Technical problems: request is lapsing because the app has a bug or is timing out;
Usability problems: Rappitenderos are having issues receiving notifications and accepting the order;
Availability: there are not enough Rappitenderos around to take the request.
We have to keep in mind that these are only hypotheses. Only by looking into what the data is saying, we can truly understand where the problems are coming from.
To dig deeper in this case, I would do a research to find out if my list is correct or if there are other problems at hand that have escaped our attention. I would base my research into two fronts:
Talk to rappitenderos to understand what makes them not take requests that come through the app
Reasons for rejecting
What caused the rappitendero to reject the order?
Did the rappitendero try to accept the order but was unable to due to some technical problem?
Was it confusing or unclear how to accept an order?
In-depth look at the data gathered
# of Rappitenderos
Number of delivery persons in the vinicity, especially in areas/hours of higher demand.
% of rate that the delivery person decides YES/NO
Distance rappitenderos are from the order
Now, with the research results at hand, we need to go back to our original list of assumptions and compare them with our findings. By validating which of them are true and which are the most recurring ones, we can proceed to prioritize the ones that are affecting our KPIs the most and understand what is the nature of the issue. It could be a usability problem, it could be a bug in the app or it could be that we need to come up with new features that will help us achieve our goals.
It’s also important to look into our team and understand if we have the technical abilities necessary to pull this off or if we are gonna need any outside help, either from a third party agency, a freelancer that we can bring on board or hire new people.
I’ll go ahead and discuss features at the next part of the answer.
Let’s assume that an important project to help improve this KPI is improving the geographic distribution of delivery people across the city. Making the assumptions necessary, explain what exact features you would develop and why.
FOR THE PURPOSE OF THIS CASE STUDY, we are gonna assume that the research returned the following results, considering only the 15% of deliveries that are not assigned within the first 5 minutes:
Of those 15%:
90% take longer because: all the Rappitenderos in the area were already busy with ongoing deliveries, so the order keeps circling around until a new one enters the delivery area;
10% take longer because: all other reasons
Data is telling us, then, that we need to increase the number of Rappitenderos at any certain location, (especially in locations and/or hours of higher demand), in order to increase our KPI.
Based on the numbers above, we already know that even if we solve this one issue completely, we will still be missing our KPI target by 0,5% of the deliveries, which means that there's still room to improve on the other issues, but for now we will focus our features to solve this one.
There are a few ways that we can assume would solve this issue:
According to our assumptions, I would develop the following features, prioritized according to value vs. effort necessary to develop and implement;
Value: 1 to 5, being 1 of low value and 5 is a high value
Effort: 1 to 5, being 1 a high effort and 5 a low effort (inverse order)
Total score: value x effort
Considering the challenging nature of the task at hand, I would slowly roll-out these features to our Rappitenderos while following the resulting metrics closely to assess the efficacy of the solution and keep improving it for a wider roll-out.
Please detail how you would manage the necessary development efforts.
Development & Implementation Process
Considering that both questions contained a request to detail how I would manage the development and implementation efforts of the features, I’ve decided to answer it in a separate section, considering the methodology used can be the same for both. What follows is an infographic explaining that process:
Links that I used in my research