⏮️ 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

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
- by service mode: the restaurant can disable offline payment methods for home delivery, but this method is available for mobile ordering (pick-up, eat-in, etc);
- For home delivery service mode, they might need to add configurations for specific delivery service options: the restaurant can also disable this method for the external drivers and activate it for the own drivers.

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.

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

TBC: payment methods configurations for scheduled deliveries

📈 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