⏮️ Context
Enhancing User Autonomy
Currently, users are unable to update their email addresses directly through the app, relying instead on Support Operators for this task. This not only places a burden on our support team but can also lead to outdated email data, affecting our communication efforts.
By introducing a self-service email update feature, we aim to empower users to manage their own profiles more efficiently. This change will enhance the user experience and reduce the workload on Support Operators. Additionally, up-to-date email addresses will ensure better communication with our customers.
❔ Expected Outcomes
1. Self-Service Email Update Functionality
Description: Allow users to update their email addresses directly within the Guest App.
Rationale: Directly addresses the primary problem of user inconvenience and need for support.
Business Value: High - Improves user experience, reduces support workload, and ensures data accuracy.
2. Real-Time Email Format Validation
Description: Implement real-time email format validation to ensure users enter a valid email address during the update process.
Rationale: Prevents incorrect email entries, ensuring data integrity.
Business Value: High - Ensures reliable communication by maintaining accurate and valid email addresses.
3. OTP Email Verification
Description: Implement an OTP verification process to ensure users have access to the email provided in the update process.
Rationale: Ensures Guest has access to the provided email address.
Business Value: High - Ensures reliable communication by maintaining accurate and valid email addresses.
4. User Confirmation Notification
Description: Send a confirmation email to both old and new email addresses when an update is made.
Rationale: Notifies users of changes to their profile, ensuring they are aware of any updates.
Business Value: Medium - Increases user trust and security by confirming changes.
5. Observability log for Email Updates
Description: Maintain a simple log of success/error instances of email changes for observability purposes.
Rationale: Enables observability of the feature health and fast action in case of problems.
Business Value: High - Enhances feature reliability.
6. Analytics on Email Update Feature Usage
Description: Track and analyze user interactions with the email update feature to gain insights into its adoption and effectiveness.
Rationale: Provide data-driven insights to evaluate the feature's success and identify areas for improvement.
Perceived Business Value: Medium. Useful for long-term analysis and continuous improvement but not immediately necessary for the feature launch.
📈 Success Metrics
Metric Title | How to Measure: | Success Criteria: |
|---|---|---|
Email Updates on Guest App | Qty of successful email updates process executed. | High rate of successful email updates. |
|
|
|
|
|
|
|
|
|
...
Optimizing Revenue with Dynamic Delivery Fees
Our current delivery fee model allows the fee to change based on the total value of the Order but it does not consider other influencing factors. As a result, markets miss out on opportunities to optimize their revenue. There is a need to investigate this opportunity in more depth and understand the viability of a possible solution to this new pricing strategy. This document proposes some initial hypotheses to be validated, where fees are adjusted based on specific conditions like weather, payment method, customer loyalty tier, etc. This change aims to create a more adaptive and efficient pricing strategy.
❔ Hypothesis
These are some of the hypotheses to be validated in Discovery:
Revenue Growth
Modifiers can have a positive impact on revenue
RBE has revenue growth goals that will benefit from value modifiers to delivery fees.
Additional delivery costs will not impact current revenue streams.
Reach
All restaurants from the Iberia region will benefit from this new pricing model
Fees modifiers setup
Allows creation of delivery fee modifiers that adjust the fee value based on the modifier configuration.
The market should be able to define its own modifiers and how they impact the fee value.
The Modifier value can be nominal or percentual.
The Modifier Value can increase or decrease the fee value.
All restaurants in a given market will have the same available modifier options.
Any changes done to modifiers must be reflected immediately in the Guest App.
Modifiers examples: Bad Weather, Reduced Restaurant Capacity, High Demand Period, Reduced Delivery Capacity, Guest Loyalty Tier, Payment Method, and Seasonal Period.
Fee Modifiers Management
Markets should have a dashboard to monitor and configure dynamic delivery fees.
Must allow modifiers to be activated/deactivated to one or many restaurants.
Must allow modifiers to be enabled or disabled indefinitely.
Must allow scheduling to automatically enable and disable a modifier.
While a modifier is enabled all Orders created during that period will contain the active modifiers.
Modifiers can still be applied to specific Orders even if the modifiers is not currently active for a given restaurant.
Managers should be able to respond to changing conditions in real-time.
Delivery Fee Transparency
Show current modifiers added to the Delivery Fee on the Cart.
Increase clarity and transparency for guests.
Users want to know the details of the fees they are paying.
RBI wants to be transparent with guests regarding detailed costs.
Detailing costs has a positive impact on guests' perception.
Analytics Tracking of Fee Modifiers on Orders
Must be able to track and analyze Orders created with fee modifiers to gain insights into their adoption and effectiveness.
Analytics must contain all modifiers added to the fee, their configured value, and the value added to the Order Total.
Audit Trail for Fee Modifiers changes
Must have a log of modifier changes for auditing purposes.
Must be clear if the change was manual or automatic (scheduled)
Changes include:
Modifier created
Modifier removed
Modifier value configuration updated
Modifier activated or deactivated for a given restaurant (manual or automatic changes).
Show Fee Modifiers on the Support Tool
Support Operators need all detailed information on Guests Orders
Fee modifiers applied on Orders must be shown in the Support Tool.
❓ Open Questions
1. General Scope and Setup
Are the new fees going to affect how the Service and Delivery Fee tiers currently work (e.g., different tiers based on cart value)?
Are these new fees part of the existing Delivery Fee, or will they be displayed as individual line items (e.g., Service Fee, Delivery Fee, High Demand Fee)?
How are the new fees going to be set up and managed? Will this be handled through Sanity/DOP or Homeria?
...
2. Fee Structure and Dynamics
What is the relationship between the new fees and the existing tiers?
Will each new fee have its own tiers (similar to Service and Delivery fees), or are they fixed amounts?
Are there conflicts between the fees? For instance, if one fee is active, does activating another override or deactivate it?
Should we establish a maximum limit on how many fees can be charged simultaneously to avoid discouraging purchases (e.g., bad weather, a city event, a weekend surcharge, and long-distance delivery all at once)?
...
3. Activation and Application
Under what conditions should the system activate each fee?
Are there ways for users to avoid specific fees (e.g., adding more items to their cart)? If so, how should this be communicated to the user?
Are there exceptions for loyalty users? Do loyalty members still incur these fees?
How will third-party purchases (e.g., orders from other platforms) handle these fees? Will they apply the same way?
Can individual restaurants set their own fee amounts within a defined range?
...
4. User Communication and Transparency
Should we inform users about fees individually (e.g., itemized as Service Fee, Delivery Fee, High Demand Fee) or group them together in just one?
Should fees be disclosed only in the cart, or earlier in the user journey?
Are we confident that displaying all details about dynamic fees (tiers and types) won't negatively impact user behavior? Should we test this before rolling it out?
...
5. Legal and Compliance Considerations
Do all the rates have legal backing?
Is charging a fee for cash payments legally allowed?
...
6. Pricing and Specifics
What is the exact price for each fee?
Are there any modifiers for these fees, and how will their setup and management work?
NEW FEES (In scope)
Service Fee for Cash Payments (To be defined)
An additional fee would be charged for delivery orders paid in cash due to the associated costs and effort. Paula is not sure if thats legal to charge.
Late Night Fee
An extra fee would apply during late-night hours, for example, starting at midnight, due to the higher operational costs during these times.
Delivery Fee - Weather Conditions
An additional fee would be charged during adverse weather conditions affecting certain regions, as operational costs increase in such situations.
Delivery Fee - Distance
An extra fee would be added based on the distance between the user and the restaurant. Customers farther from the restaurant would pay more than those closer.
FUTURE DEVELOPMENT (Out of scope)
Priority Fee / Fast-Track Order
An additional fee for prioritizing the order’s preparation and delivery.
BK Prime
A separate feature, not being explored now, where users would pay a monthly subscription fee to receive greater discounts on delivery fees.