Document Status | IN PLANNING |
|---|---|
Document Owner(s) | Garozzo de Sobral, Wellington Paula Winter |
Contributors |
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)
These estimates do not include QA testing, production release and roll out plan.
Priority | Title | IREQ | Discovery status CLEAR PENDING INFO NO DETAILS YET | Description | Stakeholder | INTL Team (to align with) | Comments | High level estimates Engineering | High-level estimates Design | Status |
|---|---|---|---|---|---|---|---|---|---|---|
IBFEC-2422 - Getting issue details... 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. | |||||||||
IBFEC-2256 - Getting issue details... STATUS | Show more detailed information for each payment error (paycomet). Rolled over from Q3. Estimated to finish in early October. | |||||||||
IBFEC-2268 - Getting issue details... STATUS | 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. | ||||||||
IBFEC-2775 - Getting issue details... STATUS | 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. | ||||||||
IBFEC-1943 - Getting issue details... STATUS | 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. | |||||||||
1 | AdminTool Integration with Homeria API for Email Data Synchronization | ESTIMATES | 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 | ESTIMATES | 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 | ||||
3 | Integrating Loyalty Data into BookingAll Order Flows | ESTIMATES | 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 | ||||
4 | Admin tool - add information of customer tier | ESTIMATES | 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 | ||||
5 | Show Order Phone Number in AdminTool | ESTIMATES | 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 | ||||
Capacity Limit | ||||||||||
6 | Ability to audit per store available and unavailable products (DOP) and show for how long the product is disabled | ESTIMATES | 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 | |||||
7 | Allow massive time updates in RAM | ESTIMATES | Ability to configure store open/close times in bulk. | |||||||
8 | Redesign loyalty and offer page in Admin Tool to include more records per page to facilitate the operator job | ESTIMATES | 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 | |||||
9 | Show all Order Status on Order History | pending | NO 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. | 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 | |||
10 | Show refunded Orders on Order History | pending | 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. | Q: When a reimbursement is done does the Order status change to Refund Requested? | M-L | can be done with 10 | |||
Support documents:
High-level roadmap with capacity allocation: https://docs.google.com/presentation/d/1wW-EmERUYg-F8Ib8Agk4blt-iXG-Qcs6jyNKQ2qm2RI/edit#slide=id.p
Add Comment