...
Priority | Title | IREQ | Discovery status
| Description | Stakeholder | INTL Team (to align with) | Comments | High level estimates Engineering | High-level estimates Design | Status | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 | ||||||||||||||||||||||||||
| 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 | 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 | 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 | |||||||||||||||||||||||||
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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. 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. | M-L (depends on the solution) | M | Not started | ||||||||||||||||||||||
7 | Allow massive time updates in RAM |
| Ability to configure store open/close times in bulk. | Not started | ||||||||||||||||||||||||
8 | Redesign loyalty and offer page in Admin Tool to include more records per page to facilitate the operator job |
| 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. | M-L (depends on the solution) | L | Not started | ||||||||||||||||||||||
9 | Show all Order Status on Order History | pending |
| 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. | Q: What is the problem exactly Q: Maybe showing all status will not make sense to the User Q: Will the User be able to do anything with Order on non-final status Q: Do we have data on this issue | need more info | M-L | Not started | ||||||||||||||||||||
10 | Show refunded Orders on Order History | pending |
| 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. | Q: When a reimbursement is done does the Order status change to Refund Requested? | M-L | can be done with 10 | Not started | ||||||||||||||||||||
Priority | Topic | Notes | High-level estimates Design | Status |
|---|---|---|---|---|
1 | Redesign loyalty and offer page in the Support Tool to include more records per page to facilitate the operator job | 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 | Show all Order Status on Order History | 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 |
3 | Show refunded Orders on Order History | Understand what is the best way to show to the User that an Order has been refunded. |
| Not started |
Support documents:
High-level roadmap with capacity allocation:
...