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 4 Next »

⏮️ Context

What is the context and status quo of the opportunity

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.

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

🎯 Problem Statement

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

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.

These fraudulent behaviors may jeopardize the company’s financials and it’s important to have controls in place to avoid this type of issue.

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

What are the goals the opportunity is going to address

ADMIN TOOL

  • Be able to block the account. This account won’t be able to place any more orders this brand (TBC).

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

    • 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.

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

    • Email message (TBC)

  • 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 reason.

  • 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.

  • 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.

Impacts on other apps:

  • WL

  • Kiosk

  • POS

  • Call center

📈 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

❓ Open questions

We need to make this section empty constantly.

  • 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?)

  • 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?

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

(blue star) 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]

  • No labels