Page Comparison

IREQ-1655

In Iberia one of the main reasons of failed deliveries are wrong delivery addresses being selected by Users. This feature checks the distance between the Delivery Address and the User to alert them if the address seems too distant than where the User is.

Dev in progress

IREQ-2303

Show more detailed information for each payment error (paycomet).

Rolled over from Q3. Estimated to finish in early October.

Dev in progress

IREQ-1655 and

IREQ-2336

There are many complains from customers and restaurants reporting situations of orders placed to distant delivery addresses.

Rolled over from Q3. Estimated to finish in early October.

Dev in progress

IREQ-1655 and

IREQ-2336

UI enhancements for a better experience while choosing the delivery address. Originally part of IBFEC-2268 but was detached to allow for an early release of the most critical part of the solution.

Rolled over from Q3. Estimated to finish in late October.

Dev in progress

IREQ-1649

Allow restaurants to autonomously manage the payment methods availble, by activating/deactivating methods on DOP.

Only Design is being done in Q3, development starts on Q4.

Dev in progress

1

AdminTool Integration with Homeria API for Email Data Synchronization

IREQ-2760

Admin Tool now has the ability to update Customers Emails Address. Now whenever an email is updated, Homeria needs to be updated as well. The goal of this change is to update Admin Tool to call Homeria’s Customer Profile Update endpoint passing the new email value.

This has a dependency on the email update from Homeria, needs to align dates to prevent blocks.

Q: Why Homeria needs the User email?

Q: What about other profile information? Is it already integrated?

Q: What are the tech specs for the new endpoint

Q: Where is the new email update feature in AdminTool? Flow documentation

M-L

S

Estimates in progress

2

Mandatory parameters Visa/Sibs

IREQ-2758

Currently, VISA payments processed through SIBS are at risk. VISA now requires additional customer information to process the payment and SIBS is sending dummy data to make VISA accept the transaction. In this change, we’ll send the correct information to SIBS so it stops sending dummy data.

Need to share the Customer’s Internal ID.

Q: Is Paycomet ready to receive this new information? How?

S-M

S-0

Estimates in progress

3

Integrating Loyalty Data into BookingAll Order Flows

IREQ-2776

Currently, the BookingAll platform does not integrate customer loyalty data, preventing the automation of the order pickup process through Mobile Ordering. Customer identification and order sending to the kitchen rely on manual actions by employees.

Need to send the Customer Loyalty ID

Q: How is this integration working now? What is the trigger point?

Q: Is BookingAll an RBI or Partner tool?

A: It’s a partner tool

Q: Is there a dependency on BookingAll? (new service?)

Q: Does this impact other countries? Is BookingAll used by all Iberia?

Q: Should this be sent to any other partner platform? (autoking?)

S-M

S-0

Estimates in progress

4

Admin tool - add information of customer tier

IREQ-2380

Currently, the Admin Tool does not show the Customer Tier information. This is important for the support team to give adequate support considering the Customer tier. This change will add the Customer Tier to the Admin Tool.

Only BK ES

We can get customer tiers information from here: Loyalty & Offers Events (Conversion) - Franchisee Knowledge Base - Confluence

Q: Does Admin Tool already receive this information?

M - L (12 weeks)

M

Estimates in progress

5

Show Order Phone Number in AdminTool

IREQ-2759

When an Order is placed the User can provide a phone number different to the one registered in his profile. This phone set at Ordering is never shown in the Admin Tool, so if the User needs support on a different phone the team cannot reach the customer. This change will add the Order Phone Number to the Admin Tool.

Q: Is this Order Phone number saved already? where?

S-M

S-M

Estimates in progress

Capacity Limit

6

Ability to audit per store available and unavailable products (DOP) and show for how long the product is disabled

IREQ-1822 + IREQ-1826

Currently, there is no easy way to check which products are unavailable for a given store. This often leads to Store Managers forgetting to make items available again impacting sales.

7

Allow auditing of product deactivation times

IREQ-1826

Currently, it’s not possible to know for how long a product is disabled for a given store, this information can help the Operations Team to check for items that should not be disabled for a long time, minimizing impacts on sales due to incorrect configs.8

M-L (depends on the solution)

M

Not started

7

Allow massive time updates in RAM

IREQ-1828

Ability to configure store open/close times in bulk.9.

This feature already exists in RAM.

Iberia is getting access to this feature to check if it already solves the need.

Not started

1

Redesign loyalty and offer page in

the Support Tool to include more records per page to facilitate the operator job

Currently, Support Operators have a bad experience when looking up customer data. They have some pain points regarding the effort to collect relevant User data and a better experience can help them give more efficient support.

Discovery Goals:

• Research the pain points of the Support Tool Users.

• Design and validate the solutions with input from the Users.

• Since a deeper discovery is necessary no development is committed for the quarter.

 Estimates in progress

2

Delivery Code

Iberia is asking for a Discovery regarding defining a code for each delivery that will have to be informed by the customer at the moment of delivery. Both the customer and driver would have received this code, if the customer fails to give the correct code the delivery will not be made.

Discovery Goals:

• Understand what are the best practices for this kind of delivery validation

• Define the best way to send the code to customers and drivers

• Define the best way that customers and drivers will be able to check the code

• Technical discovery is required to understand the feasibility of creating and retaining this new code.

3

Show all Order Status on Order History

Currently, in the Oder History, only Orders in a final status are shown but sometimes the User wants to know about an ongoing Order or an Order that is stuck in a non-final status. This change will make Order History show Order on any status.

Discovery Goal: Research the best way to show all Orders in the Order History feature. Check the necessity of new filters or controls considering that all statuses will be shown.

Not started

4

Show refunded Orders on Order History

Currently, in the Order History, Users do not know if an Order was refunded or not. Nor all cancelled Orders are refunded and the User can’t check this info. This change will add the refunded information in the Order History

.

Discovery Goal: Understand what is the best way to show to the User that an Order has been refunded taking into consideration impacts on other countries.

 Not started