⏮️ Context

What is the context and status quo of the opportunity

In Iberia, the operations teams had the flexibility to manage the available payment methods through the previous tools (homeria and airtouch). Teams were used to request these changes and to get 24/7 support to implement them very fast, to adjust to the business requests.

Changing to RBI tools, there is no 24/7 support for the payment methods configurations. This can be an issue, especially when the team needs to disable a specific payment method very fast due to restaurants' requests.

As Iberia could lose flexibility to activate/deactivate the payment methods, this was identified as a migration gap.

🎯 Problem Statement

Summary of the opportunity’s main findings and what is going to be addressed

Restaurants need to activate/deactivate the payment methods to adjust to different business scenarios. Usually restaurants request to deactivate the offline payment methods (cash, voucher and terminal at home).

These are the most common use cases:

Restaurants located in dangerous regions: they don’t want to use this payment method in-store, to avoid thefts.
- some restaurants might disable these payment methods for all working hours;
- some restaurants only disable these payment methods during the night period.
When there are only external drivers (catcher) available for the home delivery (combination 1.B, image below) : the external driver don’t accept offline payment methods, so these must be deactivated to avoid order cancelations.
- Example: In PLK ES they had 35 transactions cancelations last month related to this issue. Offline payment method was available, but only external drivers were available and they didn’t accept the orders.
When the order will be delivered by other external drivers, like Uber direct or Glovo on demand (combinations 1.C and 1.D - image below): these service delivery options might not accept offline payment methods in some regions, so these must be deactivated to avoid order cancelations.

Moreover, having the flexibility to configure the offline payment methods will allow the FZ to start using more payment methods.

Example: Terminal at home payment method is available in BK PT, but it’s disabled. As the team can’t configure the payment methods per restaurant, they preferred to disable the payment method for all the restaurants to avoid issues in places where it can’t be used.

❔ Expected Outcome

What are the goals the opportunity is going to address

#	Requirement	MoSCow matrix (Must, Should, Could)	Comments
1	As the FZ Operations team I want to be able to activate/deactivate offline payment methods by restaurant and delivery service options, So that I can manage and adapt to the different business rules.	MUST	The payment methods configurations must be set by the FZ operations team; restaurants shouldn’t be able to apply this type of changes. In Portugal, this configuration doesn’t change frequently. Example: if the restaurant is located in a dangerous region, the offline payment methods will always be disabled. In BK ES, they might need to change it more frequently. On average these changes happen once or twice a week per restaurant. Usually, they need to disable offline payment methods when there are only external drivers available. These configurations must be possible: by restaurant: be able to choose the payment methods active for each restaurant For home delivery service mode, they might need to add configurations for specific delivery service options.
2	As The Operations team I want to activate/deactivate other payment methods (besides offline payment methods) by restaurant, So that I can manage and adapt to the different business rules.	SHOULD	Currently, the Homeria system allows the configuration of cash and Amazon pay payment methods. As we are enabling new payment methods (like Bizum, Waylet and MBWAY), which have a similar behavior as Amazon pay, we can add those payment methods to this configuration. If we implement this requirement, we must consider that: some payment methods shouldn’t be disabled, such as credit card or paypal; the restaurant must have at least one online payment method available.
3	As The Operations teams I Want to automatically deactivate offline payment methods, for specific schedules, by restaurant and channel So that I avoid issues in restaurants located in dangerous regions.	COULD	BK PT shared that it would be good to deactivate offline payment methods every day after mid-night for some restaurants. This configuration won’t change frequently.
4	As The Operations teams I want to activate/ deactivate offline payment methods for mobile ordering service modes (eat-in, take away, table service, etc) So that I can have full autonomy to adjust to different business rules and scenarios.	COULD	For mobile ordering service modes (eat in, take away, table service, etc), the offline payment methods should be permanently deactivated. This doesn’t change regularly and it’s possible to manage this in the backend, by the technical team, if necessary. In the long run, if we can add this flexibility to manage this scenario by the operations team, it’s a nice to have to give them full autonomy about payment methods configurations.
5	As The Operations teams I want to activate/ deactivate offline payment methods for scheduled orders, So that I can have full autonomy to adjust to different business rules and scenarios.	COULD	The offline payment methods are permanently deactivated for scheduled orders. Teams don’t change this configuration. It’s possible to manage this as a permanent rule, without configuration. In the long run, as the business can change, it would be nice to have this option configurable.

Additional notes:

Offline payment methods = cash, voucher and terminal at home.
Cash is the most relevant payment method, compared to the other offline payment methods.
For example, in BK ES they have never disabled vouchers. Although this may cause problems, it’s a corner case, as very few customers use this payment method.
Stakeholders that shared these requirements (all from operations teams):
- BK PT: José Gomes and Diamantino Carvalho
- BK ES: Jose Angel Lezama Mendoza
- PLK ES: Iñigo Pellejero Rovira

📈 Success Metrics

List here which are the metrics to look at to define success for the solution implemented. Use those KPIs to define the current status

Reduce canceled orders associated with offline payment methods
Start using new payment methods
Number of payment methods in use
Payment method store coverage
Payment conversion rate (to avoid reduced conversion due to payment methods disablement)
Logs related to payment change (which user and when they enable disable some payment method)

❓ Open questions

We need to constantly make this section empty.

What should be the tool to do these configurations - Sanity or DOP?
- There were some discussions back in March and the team decided to move forward with the DOP solution as the first option to do these configurations. We’ll analyze if it’s possible, if not, we’ll move on with the second option, which is Sanity.

Insights

1️⃣ Stakeholder Interviews

[Document here the main insights from interview if applicable]

2️⃣ Analytics

[Document here the main insights from analytics if applicable]

3️⃣ User Research

[Document here the main insights from research if applicable]

4️⃣ Competitor Landscape

[Document here the main insights from what the competition is doing if applicable]

[Opportunity] Allow Payment methods by DOP