Context

When the customer places orders through the kiosk in the restaurant, the order can be associated to their account. To do that, the customer uses the app and a temporary short loyalty code is generated:

Open

Kiosk screen explaining how to use the loyalty ID to connect this transaction to customer account

Open

The customer can use the app to generate the loyalty short code and the uses it in the Kiosk

This code will be associated to the transaction ID. In this case, in the POS system, the customer account is identified through the Loyalty ID. This is the only customer identifier available in this system. In the POS frontend , it’s possible to get the transaction information associated to the OTP (short loyalty ID); for PLK it’s a 6 digit code, for BK it’s 9 digit code. In the POS backend system, it’s possible to get the corresponding long loyalty ID.

(Note: currently the POS only has the short loyalty code available on the front-end. when the team needs to get the long code, they must contact the backend team to get this information, which is not an efficient process. This POS tool will change in order to support the long loyalty ID code in frontend to ensure that this identifier can help to aggregate and search all transactions associated to the same customer).

If there is any customer support request related with these transactions, searching for the Loyalty ID is the only way to do it. This is the only common identifier between the Admin tool and the POS tool.

Request ID: https://rbictg.atlassian.net/browse/IREQ-1639

Problem Statement

The loyalty ID is the only common identify between the Admin tool and the POS system.

The most common and relevant use case:

The restaurant employee register customers orders with the same loyalty ID, when the customer doesn’t inform or require that a certain order is associated to their account.

In these cases, the management team might find a suspicious behavior when there are too many transactions associated to a specific loyalty ID in the POS system.

Expected Outcome

Fraudulent accounts tracking

When the customer support team identifies a suspicious behavior associated to a customer account, they need to get all the details and information about this account. For example: if they find that there are too many transactions associated with an employee’s account, they need to collect all data of this employee’s account by searching/checking this information in the Admin tool.

In order to find out the account details, they must search by loyalty ID, as this is the only common identifier between the different tools (POS, DTIQ, and Admin tool). Searching by Loyalty ID allows the identification of the fraudulent employee.

Acceptance criteria:

• Be able to search the customer account using the loyalty ID (long version)

• Currently, it’s possible to search customer by Email, Cognito ID, Order ID, Store number, Sanity ID, Address and Card Number. Now the customer can choose the Loyalty ID variable from the dropdown menu.

(Note: in this deliverable, we’ll also add the “phone number” as an additional variable in the dropdown menu. It’s already possible to search by phone number, but the variable isn’t visible to the user).

Success Metrics

Open questions

There are two different loyalty ID codes:

• long: it’s one per customer and remains always the same.

• short one: this code is the OTP and it could be related to 1 or more customer because the OTP expires and it´s only used to do the loyalty login. Currently, this is the code associated to each transaction ID on the POS. In the future, the POS will support the long code only.

Which of these codes will we use to search by customer? Short, long or both?

The long loyalty ID code should be used, as this is the known ID in this app and this is the actual loyalty ID. The short code is an OTP that expires and it isn’t directly linked to the customer account.ANSWERED

Insights

Stakeholder Interviews

[Document here the main insights from the interview if applicable]

Analytics

[Document here the main insights from analytics if applicable]

User Research

[Document here the main insights from research if applicable]

Competitor Landscape

[Document here the main insights from what the competition is doing if applicable]