Context

There is the need to minimize operator errors and accelerate the request acceptance process in the drive-thru experience after the order has been requested through the app. On top of it, this solution will facilitate the cross validatation of the data from POS with internal reports for the data team.

Currently, cashiers review the pending orders displayed on their screens and confirm the details verbally with the customer at the moment of order pickup. This manual process requires verifying each order against the customer's information, which not only slows down the workflow but also increases the risk of human error.

To address these challenges, the selected solution aims to automate the drive-thru process by integrating the customer’s Loyalty ID into the order retrieval system. This solution is advantageous because it simplifies the interaction between the customer and the cashier, reducing the time spent on manual order verification. We can efficiently implement this change without a complete overhaul of the system. Additionally, the partner can implement a way to identify the user with the QR Code, as they already have access to the loyalty service and can match the user with the Loyalty ID.

This is the QR Code that customers scan in drive-thru:

Open

Potential Solutions

1. Introduce Loyalty ID into getOrders: This solution involves passing the customer's Loyalty ID to the "get order" endpoint in the partners-api service to automate the drive-thru process. This choice is preferred because streamlining operations and minimizing the need for manual verification. Compared to other options, this approach is simpler to implement and leverages existing system capabilities effectively.

2. Introduce Loyalty ID into QR Code: This option entails sending the Loyalty ID via a QR code that the customer scans at the drive-thru. However, this approach was dismissed due to potential negative impacts on other markets and existing workflows that utilize the loyalty QR code. The risk of disruption outweighed the benefits.

3. Create a new endpoint on partners-api to retrieve user orders: This solution proposes creating a new endpoint in the partners-api that returns the user's orders directly. This approach would allow BookingAll to retrieve orders without the need to manually check each pending order. However, it was disregarded because it would require additional development resources and time. Given the existing capabilities of the current system, and the information that BookingAll could identify the customer with the loyalty API, the simpler approach of modifying the existing "get order" endpoint is more efficient and timely.

Proposed Solution

The selected solution involves passing the customer's loyalty ID to the "get order" endpoint, as the BookingAll claims that doing so will automate the drive-thru process. The endpoint is located in the partners-api service, and we will need to include this field in the mapper of the endpoint's return.

Fortunately, the order entity we store in the database already contains the loyalty ID in the cart object (as an optional parameter), so simply including it in the return mapper will work.

The proposal consists of the following steps:

1. Update the Mapper: Modify the return mapper of the "get order" endpoint in the partners-api service to include the Loyalty ID. This update will ensure that every time an order is retrieved, the associated Loyalty ID is included in the response. This step is crucial for automating the workflow, as it minimizes the need for cashiers to verify order details verbally with customers, thus expediting the process.

2. Testing: Validate that the Loyalty ID is correctly retrieved and passed through the API.

3. Deployment: Roll out the changes to production and monitor for performance

Potential Challenges

During the opportunity definition and evaluation of potential solutions, the following challenges may arise:

• Lack of Clarity: There may be a lack of clarity regarding how the BookingAll process functions, which could lead to misalignment.

• Testing Difficulty: Conducting thorough testing of the feature presents significant challenges. Since the entire flow of the BookingAll system needs to be tested, it may be difficult to ensure that the solution effectively automates the drive-thru process. This complexity could lead to extended testing timelines and the risk of overlooking critical scenarios.

Metrics

• Compare the total drive-thru order times before and after the implementation of the new solution.

• Compare the error rate of drive-thru orders before and after the new solution.

QA Plan

Call-outs