...
Table of Contents | ||
---|---|---|
|
...
Problem statement
PLK ES (Iberia) needed to have It was requested the ability to use a loyalty promo code through the checkout page. With that in mind, we extended the loyalty feature that before could only be used on /offers
page to now be available directly at the checkout page.
The idea is to improve the user experience because the user now has the ability to add offers without the need to go back to the /offers
page. Now the feature is available for anyone.
PS: this This feature reused part of the old deprecated/removed CBA Offers code (already deprecated/removed). We are also using part of the loyalty offers logic to control the implementation.
...
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
OUT OF SCOPE: Solution restrictions:
The Item; Offer Activation; Swap are legacy options that came from the US legacy code and will not work now. We received this information from the Loyalty Team.
|
...
The user should not be redirected to the menu page when applying a promotional code directly through the checkout page (for Offer Combo/Picker)
Add the offer item with the default selections for the Combo/Picker
Show the “edit” button on the cart offer item. The edit button should send the user to the menu page for the edited item
The behavior must be closely related to the legacy flow
/offer
page:The item added to the cart should be exactly as we are adding it through the legacy flow /offer (sub-items, price, etc)
The item should be correct at Recent Orders or Email Receipt (like the legacy
/offers
flow). As this is an extension of the loyalty offers feature, we didn’t need to implement anything regarding this (I added a demonstration showing the receipt when adding a Combo/Picker)The offer item should not be available to add again to a new order after being used (blocked by the application by default)
Only one offer item can be added by default. If the user tries to add another offer (Combo, Picker/Offer Discount), a modal will ask if the user wants to replace the current added offer with the new one.
If the user tries to apply the same code twice, the application should block this showing an error about “promo code already applied”
The feature should respect the rules from Sanity or the campaign platform. For example, if the user already finishes an order for a promo code that only has one available, they should not be able to reuse that promo code
The application should show the same errors that we already have for promotional codes (the old deprecated/removed CBA flow):
Unknown exception error
Code expired
Invalid code
Code already redeemed
Invalid Offer ID
Promo code already applied
...
As the user is adding the offer directly to the checkout page, he/she needs the ability to edit the offer item if he/she wants to change some of the items. This can also be used as a “shortcut” to offer up-sells during the edit time.
...
Relationship between /offers page and promo code at checkout and reuse
As our this feature uses the loyalty offer structure in its implementation, we'll have some states and connected behaviors:
Always, when we redeem an offer on the checkout page, this offer will also be available on the
/offers
page to be used later (e.g., when the user, for example, adds the offer on the checkout page but for some reason doesn't finish the order using that promo code)The user can reuse a promo code until he/she finishes the order (as a default). Of course, this can be changed based on the Sanity rules for the configured offer. If the promo code is not valid anymore, an error will alert the user about it
...
Expand |
---|
In the video below, we can see that after replacing an offer, the replaced offer will also be selected on the /offers page as the current selected offer. |
FAQ
Golden rule
Expand |
---|
90% Most of the behaviors will be equal to what we have on the |
...
After adding the offer to the cart, the price is wrong, or I'm receiving an error saying that the offer is not available at the selected restaurant or that the product added is invalid
Expand |
---|
90% Most of the timetimes, we'll have a problem with configurations:
|
...