⏮️ Context

Currently the customer support team can block fraudulent accounts, that they identify as potential suspicious activities. Example: too many transactions in the same day.

They can do this in the existing tool. Moving to the Admin tool, they would like to keep this feature.

Current flow in Homeria:

Request link: IREQ-1494 - Getting issue details... STATUS

🎯 Problem Statement

RBI has a loyalty program that rewards customers for their purchases/transactions. To get more benefits, there are some fraudulent behaviors that were already identified by the company.

Example of a fraudulent behavior:

• Sometimes, the employees register customers transactions in a single account (not the customer’s account) in order to get points and benefit from discounts/rewards.

• The restaurant identifies a customer that only have joke orders (placed orders without payment and then cancel / do not show up)

• The restaurant identifies that the same customer always open a incidence saying he didn't receive the entire order or has problem with the quality. Because the customer expects a refund.

These fraudulent behaviors may jeopardize the company’s financials and it’s important to have controls in place to avoid this type of issue. On average, 10 accounts are blocked per month in Iberia (most of them are restaurant employees).

One of the existing implemented controls is: to allow the customer support team to block a suspicious fraudulent account, to “stop the bleeding” and to avoid this continuous behavior.

❔ Expected Outcome

• Due to GDPR, it’s recommended to use two difference storage instances: one for customer data and another one for user data. The admin tool already has a customer data repository. To store and show the user tracking historical data, it’s necessary to create a new service to save this type of information. As this requires additional scope/ effort, which was not considered during Q2 planning, we decided to move forward splitting this deliverable into different milestones.
• Milestone 1 (end of Q2): Be able to block and unblock customer accounts, without tracking on support/ admin tool. We will only keep technical logs to be consulted if necessary. This is the scope of this first deliverable and will be developed by the Iberia dedicated team
• Next milestones: 2- Be able to change email addresses associated to a customer account (INTL team - Users; ETA: end of Q3); 3 - Create a new service to store the users data, including the email changes (INTL team - Users; ETA: mid of Q4); 4- Be able to track the user data related with (un)blocking customer accounts and show it on Admin/support tool ( Iberia dedicated team; ETA: end of Q4).

Scope for 1st deliverable:

ADMIN TOOL

• Be able to block the account. This account won’t be able to place any more orders this brand. Blocks the account only for one brand. Blocking the account means that: the customer can’t place more orders, can't access the account, can’t use the loyalty benefits and all other features that might be available when they were logged in.

• Confirmation page: to avoid human error, a confirmation page must be shown to the agent, to validate that this is the action that s/he wants to perform.

• Only the customer support team will be able to block customer accounts. NEW

• Be able to unblock the account. If there was a mistake or if the customer requests to unblock the account, the agent must be able to undue it.

EMAIL NOTIFICATION

• When the account is blocked the customer receives an email notification message.

  • Email message: “Estimado cliente

    Le informamos que su cuenta ha sido bloqueada temporalmente al detectar un posible uso fraudulento . Si cree que ha sido un error o desea más información por favor póngase en contacto con Atención al Cliente a través de nuestra web www.burgerking  o nuestra App.”

• When the account is unblocked the customer receives an email notification message.

  • Email message: “Estimado cliente

    Le informamos que una vez revisado el posible uso fraudulento se ha procedido a desbloquear su cuenta.

    Para cualquier información por favor póngase en contacto con Atención al Cliente a través de nuestra web www.burgerking  o nuestra App.”

The message should always include the form to redirect to the contact form

OTHER APPS:

• WL

• Kiosk

• POS

• Call center: there will be an exception as we can’t block customer account through call center.

• Braze

• When the customer/ agent tries to sign in /sign up to this account to place a new order, a message should be shown to let them know that the account exists but it’s blocked. This message should be visible to all types of logins (inclusive through social networks)

Message: “CUENTA BLOQUEADA TEMPORALMENTE

Esta cuenta ha sido bloqueada temporalmente al detectar un posible uso fraudulento. Si cree que ha sido un error o desea más información por favor póngase en contacto con Atención al Cliente a través de nuestra web www.burgerking  o nuestra App”

In this message, the link should redirect the customer to the “contact us” form.

• When the account is blocked, all active sessions for this account should be logged out.

• If the account is blocked, the customer shouldn’t receive any marketing campaigns.

AMPLITUDE:

• The customer account blocking information should be tracked.

• There should be a tracking applied to the blocking message, so we can register that the customer actually got the blocking message notification.

Scope for the 4th deliverable:

• Blocking reason: to block the account, the customer support agent must choose include the blocking reason.

  • List of blocking reasons (mandatory field)

    • fraude cliente

    • fraude empleado

    • incidencia

  • add an open text box (optional field)

    • if the agent wants to explain more details, there will be an open box text to add those details.

• The blocking is visible on the admin tool and data logs, for visibility and traceability:

  • When it was blocked: day and hour.

  • Who blocked: identify the customer support agent who performed the action.

  • Blocking reasons and open text comments.

• Unblocking reason (mandatory field)

  • This is an open text box, so the agent can explain the unblocking reason. As there are many different reasons, there won’t be a predefined list.

• The unblocking is visible on the admin tool and data logs, for visibility and traceability:

  • When it was unblocked: day and hour.

  • Who unblocked: identify the customer support agent who performed the action.

  • Unblocking reason.

📈 Success Metrics

❓ Open questions

• Should the account be blocked for all brands or only for the brand that identified the fraud? (Example: if the fraud was identified for BK ES, should we block this account only for BK ES, even if there is a similar account for PLK ES?) Only for one brand at a time. ANSWERED

• In which systems should the account be blocked? The account is blocked and it’s not possible to login in any system. ANSWERED

• Should we block the user to create a new account with the same email? Is this part of the scope? the account won’t be deleted; only blocked. So the customer always gets the blocking message. ANSWERED

• What is the email confirmation message? Details above. ANSWERED

• Should we send a notification message when the account is unblocked? Yes ANSWERED

• Is it possible to track blocked accounts on amplitude?

• How to ensure that we can block customers who are using a previously generated OTP (KIOSK and POS)

• What is the connection with the DMP (ex: Homeria)?

• How the blocked user request their data or delete their data (DSAR flow)?

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]