Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

\uD83D\uDDD3 Date

\uD83D\uDC65 Participants

\uD83E\uDD45 Goals

  • First Iteration scope review

  • Alignment on objectives for BK Pay

\uD83D\uDDE3 Discussion topics

  1. FE First iteration scope- MVP
    https://www.figma.com/file/qcUazs7MiACbph9lLVSejN/2023-Q3%3A-%5BTRX-837%5D---BK-Pay---Bluecode?type=whiteboard&node-id=0-1&t=JVreFQ00U56BiVFh-0

  2. Objectives:

Revised by the market:

FZ: Reduce cash transactions by 5.2% 

User: BK Pay app is no longer available in the app store. Only usable for old app downloads. 60% of the completed downloads and installations of the old app used it in the past. 

Costs: BK Pay is not cheaper than credit card. We can decrease cash-handling cost but we do not have a clear feedback from finance here. Overall reducing cost is not the main advantage for us, more to reduce cash orders in total. 

Loyalty programmes aspect: should offer members various added values. Service-related added values are particularly important for long-term customer relationships. A payment function within a loyalty programme is a trend that we should recognise early on and with which we can differentiate ourselves from the competition. We conducted an online survey in August that also showed that users would appreciate a payment function. We asked: "Suppose Burger King were to launch a loyalty programme. How likely are the following benefits to encourage you to sign up to Burger King's loyalty programme?" Almost 50% of respondents said that a payment function would make it very likely that they would sign up. 

  • Decrease time to place an order for BK Pay customers - We do not have clear data for SOS in the payment process. But we made assumption that we could reduce the time in that process: 

    • Scan a coupon: 12 sec (per coupon if you have to scan them separately) + 

    • Pay with Cash avg + 18.7 sec 

    • Pay with physical Credit Card + 25.7 sec if you have to insert the card 

    • Pay with physical credit card without insert the card + 19.3 sec 

    • Pay with online banking seperate app + 14.0 sec 

    • Pay with BK Pay in the same app with one scan + 4sec 

  • Increase monthly sales by 1.35% per restaurant (5.2% BK Pay, 50% Cash, 44.8% Credit Cards) 

    • Check increase Cash to Credit Card: +29% 

    • Increasing purchase frequency to 5.2%

Proposed by Magdalena based on the conversation with the market:

Fz:
Currently German FZs struggle with cash-handling issues as well as high processing credit card fees, which is why they’d like to reduce % of transactions completed with both of those methods.

User:

BK Pay is currently available as a separate app which hinders discovery, adoption and creates friction for users who’d like pay with BK Pay. Moreover, users may be confused seeing both apps, as they are tring to download the main Burger King app.

Hypothesis

 

Primary:

  1. Introducing BK Pay as a payment method to web/app will increase MARU by X% by the end of <date> by introducing another convenient way to of payment method in-restaurant by accommodating all users with a checking account in Germany that are not able to use Apple or Google Pay. Since the vast majority of banks don‘t support Apple Pay with Girocard (the local debit card) and almost none Google Pay, BK Pay will have an advantage over other digital payment wallets on the market.

  2. Introducing BK Pay as a payment method to web/app will Increase an average check value for a restaurant customer by X% by <date>, assuming X% of current cash payers will transition to BK Pay, based on the fact that non-cash payers tend to have a higher average check by X%.

 

Secondary:

  1. Introducing BK Pay as a payment method to web/app will decrease overhead cost by X% by <date> , assuming that X% of cash payers and X% of credit card payers will transition to BK Pay.

✅ Action items

  •  

⤴ Decisions

  • No labels