⏮️ 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
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.
📈 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? Only WL?
Should we block the user to create a new account with the same email? Is this part of the scope?
What is the email confirmation message?
Should we send a notification message when the account is unblocked?
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]
Add Comment