Status | DISCOVERY |
RBIberia Owner | Paula Winter |
RBI Owner | |
DMP/DOP owner | |
Designer | |
Other SMEs | |
IREQ ticket | https://rbictg.atlassian.net/jira/servicedesk/projects/IREQ/issue/IREQ-1109 |
ACTION ITEMS
@Cunha, Ricardo @Ferreira Gomes, Raphael Find out how the information stored in LaunchDarkly gets transferred into a PLU
@Ferreira Gomes, RaphaelValidate if the “Glovo Service fee” effort made by Gui can be reused; or expand that effort to make it generic and accept the New Service Fee
@paula.winter@rbiberia.com Validate that Homeria is currently connected with Food Aggregators and Winrest to read the new service fee
@paula.winter@rbiberia.com doublecheck internally if it's planned a more granular setup of the fees -> this will generate a huge dependency on CI&T
Problem statement (generic)
Delivery fee is considered a critical aspect on the competition with 3rd party players. The evolution during the last years has brought the industry to structure the delivery cost in a more granular way to optimize efficiency and enhance competitiveness.
This includes dissecting the delivery process to identify specific costs such as the drivers and their allocations, implementing advanced route optimization algorithms, and considering a different number of factors that are impacting the delivery itself.
As a result, RBI can minimize expenses and ultimately offer more competitive delivery fees connected with a better transparency.
Fees definition
Delivery Fee: The basic cost to provide a delivery service. It has several possibilities and factors that can impact the calculation.
Service Fee: It can includes several variables. Examples are: small cart, payment method, tier loyalty, company priorities, etc.
The scope of this discovery is to work exclusively on the Service Fee
Problem statement (Iberia)
Looking at the /wiki/spaces/IN/pages/3863838850 document, there are a few concerns:
a) Basket size
In the actual formula, the basket size has a progressive discount mechanism.
In the Iberia markets, where the Average Check is BK ES 12.10€, BK PT 10.18€, PLK ES 14.83€, the high delivery fee (4.99€) for the purchase <10€ and the lack of a specific cost section for small basket size brings to show an extremely expensive delivery fee without providing the right information.
Considering the small basket size a variable and not a discount will help to explain better the cost structure of the fee
b) Free delivery fee
Connected to the previous point, there is the fact that splitting the cost of the delivery fee and basket size can facilitate the marketing strategy of offering free delivery fee - a key competitive advantage. Considering the Average Check and the fact that the free delivery fee is a strategic marketing action (campaigns, partnerships), having a lower base delivery fee (ex: 1.99€) and having the basket size cost splitted, could allow the company to push for a “free delivery fee” strategy without impacting the financial part of the company.
Analyzing at the actual solution, we could find an easy workaround without generating impact
c) Connecting PLUs
Today is missing a relationship with a PLU that will facilitate the analysis and the job of the accountants on the new delivery fee structure (see example below). Generating a specific PLU for both fees (delivery and management) could be a good approach.
d) Other variables to be considered (IMPROVEMENTS)
Today the delivery cost calculation is not taking into account other critical aspects of the delivery and management process that are impacting negatively the logistic and financial part of the delivery.
More informations here: https://www.figma.com/file/Bp8vIQlnoJMLyONqVQ4ACG/2023---Q4---%5BIBFEC-1137%5D---Dynamic-delivery-fees?type=whiteboard&node-id=0%3A1&t=rku4BIAcK07yt1pF-1
Data on % of orders within each average check bucket:
I’m grouping into 3 buckets according to what I saw in the figma file: orders < 10 EUR, 10 EUR < orders < 16 EUR and orders > 16 EUR
Looking monthly at the past 6 months, on average:
i. 71% of all delivery orders have an avg check > 20 EUR
ii. 26% have an avg check between 10 and 20 EUR
iii. 3% have an avg check < 10 EUR
A higher avg check could be being incentivized through the free delivery campaign but nevertheless data shows that majority of the users will already benefit from a free service fee.
Given the avg check of delivery in PLK ES is 25 EUR, new service fees buckets would need to be defined to get a more optimized solution from a financial standpoint.
Amplitude chart for reference: https://app.eu.amplitude.com/analytics/rbiberia/chart/e-q93tmghy
Success Metrics
Average check increase (primary KPI)
Conversion from cart > payment
Conversion from cart > purchase
Events - draft
Add property on Button Click event to account for Component.
i. This way we would be able to differentiate the CTR of add items button at end of order summary and add items at the service fees component and really understand feature engagement towards the intention to contribute to better check.
Add a property on BE event eCommerce checkout called service fee tier where we would know what the tier users are are when they go to checkout (service fees labeled as tiers allows to be agnostic of financial model, whether is basket size, price, etc)
Create an event called Service Fee Updated (TBD complexity and need) that would trigger when users add more items to cart which will allow them to move up on the service fee tier and pay less. This way we would know the feature success on improving check as well.
Acceptance Criteria
The new Service Fee will operate for Home delivery in app, web, call center and aggregators (with differentiated costs)
Web/App:
The two rates applied to each order will be shown in the order checkout and order details.
The checkout will show a breakdown of the management fee applied to each order.
It will be shown at checkout how much the customer is saving on handling and shipping fees when:
The creation of promotions will be allowed for all customers or from promotional codes at one or both rates, without losing the price information configured by default.
applied promotions at a general level (informing the application of the promo)
applied promotional code promotions (informing the application of the promo)
Ticket POS: print the two fees added to the order
The order total is greater than the first range defined at the shipping rate, when there are no promotions
The order total is greater than the first range defined at the management rate, when there are no promotions
The recommendations carousel will be added at checkout
Web/App Config:
Editable by channel
Editable by price range
Editable by restaurant
DMP and DOP: update all screens where the shipping rate information is already presented to also show the management rate
Ticket Home delivery: print the two rates added to the order
Home delivery report: update it to send the new management fee
Solution
There should be an additional fee to be shown, indipendently from the potential other ones existing.
SERVICE FEE is a variable fee that is related to factors that can impact indirectly the delivery. Factors can be various; for the MVP we will include the small cart size, a factor that is variable depending on the basket size.
IMPORTANT to mention regarding PLUS:
Check with Winrest if they are controlling PLUs and which architecture is needed from our side to guarantee the split of different PLUs
PLUs prices are split by price range and the cost can change for the PLU
Same PLUs are used for all the different restaurants if in the same range.
It will be possible to show the Service Fee for each type of service, not only delivery, and it should be possible to customize by restaurant.
In case of a discount code, fees should be calculated on the value of the discounted amount. Example:
Cart with 24€, discount 50%, final amount paid 12€ → the fees should be calculated on the value of 12€
A unique modal should communicate the different fees ranges and should be dynamic (considering that there could be restaurants with different fees ranges)
In case of a promotion, the delivery fee information should be updated accordingly
Both fees should be shown in the receipt page and the confirmation page - with or without the potential discounts applied (following the existing patterns)
To configurate the fees the solution should be indipendent from the tech team and need to be managed by the Iberia market. Today there are potential solutions for that:
a) LaunchDarkly - APPROVED for V.1 - it maintains the depedency on the Dedicated team
b) Sanity
b) Ops Portal
The Service Fee will be shown also in the Call Center - to be worked once it will be released
The Service Fee will be shared with the Food Aggregators as well as per the image - OUT OF OUR SCOPE
Design
0 Comments