Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

High-level estimates Eng. team: include technical discovery, refinement and development.

  • Small (S) - up to 2 sprints (2 to 4 weeks)

  • Medium (M) - 3 to 4 sprints (6 to 8 weeks)

  • Large (L) - > = 5 sprints (10 weeks or more)

High-level estimates Design team: include design planning.

  • Small (S): 1 week

  • Medium (M): 2 weeks

  • Large (L) : > 2 weeks

These estimates do not include QA testing, production release and roll out plan.

title

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.

Priority

Title

IREQ

Discovery status

Status
colourGreen
titleCLEAR
Status
colourYellow
titlePENDING INFO

Status
colourRed
titleNO DETAILS YET

Description

Stakeholder

INTL Team

(to align with)

Comments

High level estimates Engineering

High-level estimates Design

Status

Jira Legacy
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIBFEC-2422

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

Jira Legacy
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIBFEC-2256

IREQ-2303

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

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

Dev in progress

Jira Legacy
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIBFEC-2268

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

Jira Legacy
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIBFEC-2775

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

Jira Legacy
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIBFEC-1943

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

Status
colourRed
titleEstimates

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

Status
colourRed
titleEstimates

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.

This has a dependency on the email update from Homeria, needs to align dates to prevent blocks.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

Status
colourRed
titleEstimates

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

Status
colourRed
titleEstimates

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

Status
colourRed
titleEstimates

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

Status
colourRed
titleEstimates

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

Status
colourRed
Estimates

8M-L (depends on the solution)

M

Not started

7

Allow massive time updates in RAM

IREQ-1828

Status
colourRed
titleEstimates

Ability to configure store open/close times in bulk.

This feature already exists in RAM.

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

Not started

Priority

Topic

Notes

High-level estimates Design

Status

1

Redesign loyalty and offer page in

Admin

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

Jira Legacy
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIREQ-1495

Status
colourRed
titleEstimates

Redesign the loyalty and offer page in the admin tool where the operator can have a better visualization of the key info related to loyalty and offers.

10

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

pending

Status
colourRed
titleNO DETAILS YET

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

11

4

Show refunded Orders on Order History

pending

StatuscolourRedtitle

NO DETAILS YET

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.

Capacity Limit

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

Support documents:

...

Admin tool requirements: https://docs.google.com/spreadsheets/d/1-rhdorDhPsSGoVbzDnikjt8nH2D4iz3-TLsrvk9o4mc/edit?gid=0#gid=0

High-level roadmap with capacity allocation:

...