| Note |
|---|
This is a template that should be used to document each feature. It’s meant to be easy, not prescriptive - change it at will! |
Table of contents
| Table of Contents |
|---|
Definition
Status |
| ||||||||||||||||||||||
RBIberia Owner | |||||||||||||||||||||||
RBI Owner |
❓ Open questions
| Info |
|---|
We need to constantly make this section empty. |
MAIN QUESTIONS TO START DISCOVERYBusiness questions
What is the usage of this method payment in BK PT?
Do you have any demographic or customer data related to those who make payments with card at home?
Is this payment method used in PLK ES and/or BK ES?
What has been the decrease in sales after the launch?
What is the flow in Airtouch?
Are there any regulatory or legal considerations that might impact the implementation of card payments at home?
Tech Questions
What are the API endpoints of integrations?
Is there any official technical documentation?
What are the security/compliance concerns?
ALTERNATIVE SOLUTION
Considering the problem “user preference is the payment at home compared with the other ones for several reason (trust, simplicity, speed)”, we could explore more options like:
Prioritize MBWay as it’s the main payment method and it’s fast, simple and trusted in the Portuguese market
Offer discounts to use the online payment method
Add “pago seguro” and other logos to the payment page
ANSWERBusiness answer
-
-
No, just BK PT
-
-
--
Tech answer
-
Requirements
Problem statement
BK PT customers are facing limitations and inconveniences when making payments. To address this, we aim to implement a feature that allows users to make card payments at home (with POS owned by the driver?). The goal is to maintain the existing user experience avoiding impact on sales.
Acceptance criteria
Success metrics
🤔 Assumptions
Scope:
1 - Change the color of the “Rewards“ header
3 - Create a carrossel based on the quantity of crow
4 - Food image and button with disabled aspects when crows aren´t sufficient to buy the product
Solution
Scenarios
| Info |
|---|
Note: these are high-level scenarios that must pass testing before we can release the feature. They should also be used to drive design. Note that we do not specify user interface details in these steps - that is deliberate so that we focus on the process and not on the UI since the UI can change throughout design and development. |
Scenario 1: xxx
Steps | Expected results |
|---|---|
Do this | Expect that |
Design
Figma design here: [insert link]
Today in the Airtouch solution, on the user side we have the following flow:
