# OLO - Consumer Requirements

## Existing Slice features to look out for
* Coupon/promo codes
* GFO
* Scheduled orders

## New features needed
These obviusly have implications outside of consumer backend and apps and web front end, but let's address "our" changes:
* Inventory validation when user adds to cart (not when order is submitted)
* Inventory validation related to scheduled orders (limited availability items).
* Scheduled time errors (related to `earliestreadytime` and `leadtimeestimateminutes`)
* Special Olo error codes
* Restaurant capacity (throttling)
* GFO menu refresh?

## App Changes

* remote shopping cart
* will require making each clients cart structure consistent with each other/backend
* knock on impact of this will be any touch points in the app for cart data may need to be updated, and will need to be able to handle network loading and error states (eg review order screens item list)
* shopping cart screen will need to be entirely network driven, with loading/error states
* state of floating cart button

* adding/editing/removing items from cart will require network request
* means having loading state while waiting for the request to complete
* handling errors that may occur (network failures, validation errors)

*small*

*X-Large, going to be particularly difficult to manage alongside other development work, as the interface to the carts wrapper is large and utilised across a significant portion of the app*

* rewards
* it looks like we need to inform olo of loyalty programs. Means they will need to hold some logic of whether a point is earned/reward is valid
* means messaging around earning piza points and redeeming a reward will also need to be network driven, rather than logic being done on the client
* is also another dependency if we want to change that logic
* adding reward item will also have the same network request dependency as other items

*medium?*

* order schedules
* currently the apps are determining whether they can place an order based on the shops schedule locally, will we still be able to do this?

*small or medium?*

* reorder
* may need a new endpoint for reorder, as we now need to either make a network request for each item from the app and group the responses, or utilise the create basket from order functionality. Either way reorder needs a network request now.

*small*

* magic cart changes similar to reorder

*small*

* cant create a basket until a user starts an order
* may not be an issue, but potentially some clients are creating the basket when a user browses to a shop rather than waiting for them to add an item. Might impact basket handling on the application

*small to medium?*

* coupons
* currently being validated locally, will need a network request to validate

*small*

* promo codes
* dont see any mention, maybe bundled in with coupons? will now also need a network request. need to better understand how strictly they are validated in an in progress basket

*small to medium*

* automated testing
* the changes to make the code dependant on network requests will have a massive impact on the test suite (likely both unit and UI regression)
* the tests themselves will need rewritten to support the new code structure as the interface between the tests and the application code will need to change dramatically. This means they cannot be utilised to confirm product behaviour is consistent and automatically test edge cases.

*large and scary, will likely need to be done incrementally as part of the other pieces, but with the massive changes to a lot of the interface points across the application, it introduces a lot of risk*

* addresses
* server side cart will likely need to manage its own address
* means separation of cart and search address on the clients, otherwise an update on the search will also require an address update on olos cart, which may be invalid
* means making more elements of the review order screen network driven
* app currently always using the one address for everything, along with never having the address be network driven, mean this is going to be pretty complex

*medium (maybe large), also going to be challenging to do alongside other dev work*

* app redesign work
* we currently have a third party coming up with an app redesign, this change could not coincide with an app redesign at the same time.

* questions
* promo codes/coupons - i only see coupons in the docs, will it support our current structure
* will we need an additional order tracking provider, if olo is handling some order status stuff
* does our current reward item in the menu work with olo's loyalty structure?
* suggested items, will they now need to be fed from olo's upsell endpoint?

## Web changes

Estimate: **XL (Quarter + )**

It’s my understanding that an OLO integration will change the UX and backend integration for everything involving the user’s cart.

In that sense we share a number of impacts with the apps:

* adding/editing/removing items from cart will require network request
* means having loading state while waiting for the request to complete
* Add Ons now require a network request to add to the cart
* handling errors that may occur (network failures, validation errors)
* UX redesign likely needed to accommodate
* automation tests will need to be substantially changed
* Question: If this boils down to just calling the shopping_cart endpoint every time we make any kind of change to the cart, then it may not be too huge an impact, as we do already do that to generate the receipt.

* remote shopping cart
* will require making each clients cart structure consistent with each other/backend
* knock on impact of this will be any touch points in the app for cart data may need to be updated, and will need to be able to handle network loading and error states (eg review order screens item list)
* shopping cart screen will need to be entirely network driven, with loading/error states
* Magic Cart functionality will need to be replaced or updated; if the cart is being moved to the server then in a way we get a superior Magic Cart than we have now.

* rewards
* all the same impacts as the app - but seems like a mostly backend change, hopefully the endpoints exposed to clients could be the same

* reorder
* Same impact as apps
* Invalid items will need to be filtered earlier
* OLO’s “create basket from previous” endpoint could help

* coupons
* these are validated locally on the web - becomes a network request

* promo codes
* this is already a network request on the web to the validate promo code endpoint, so no change in flow needed there for web

* Cart persistence
* We persist a user’s cart on the web for up to a day - it looks like OLO carts can last a week. And instead of being able to store this locally, it will now become an extra network request when we load a menu
* Adding additional page load calls negatively impacts our TBT (Total Blocking Time) and therefore our SEO

* Payment
* Web payment is either by paypal (billing agreement or single authorisation token) or stripe token. We are adding a native payment flow with Stripe PaymentIntents - so the billing and payment integration would also need to be able to support this.

* Scheduled orders

* Item level availability UX changes

* Delivery address validation

## Backend changes
* Basket endpoint (new):
* basket with uuid
* validation on addition of item
* validation of coupon/promo on addition
* validation of reward item on addition
* validation of reward redemption at time user redeems
* This endpoint will have massive impact on core api and admin

*XXL*

* GFO:
Depending on certification and/or other Olo requirements, we might need to change how/when restaurant entities are shared with Google.
* Gfeed:
* Publish new entity JSON any time hours, menu, item availability, or ETAs change.
* Gfood:
* use new basket endpoint to place orders
* report errors ASAP, not only on order submit

*L-XL*

* Menu:
* Menu Service will need to subscribe to the "VendorMenuExportComplete" and "MenuItemAvailabilityChanged" webhooks and update menus as necessary.
* Will Olo support our concept of a reward item?
* Slice has no concept of item level time restrictions. This would need to be added.

*L? Need more input from menu service to size*

* Rewards:
* Olo already has a loyalty program. This would need to be integrated with Slice's program. Docs don't have a lot of information on the Olo loyalty program, but it seems _very_ different than ours.

*L-XL*

* General:
* seems unreasonable to handle Olo shops "separately" so these changes impact _all_ shops.
* CSE: customer service would need to handle Olo shops differently.
* What happens if we send an order to Olo with items that have been changed (availability, timing etc) since last time Olo and Slice synced? Seems like this is something Olo is not psyched on.
* ETA: Slice currently doesn't handle ETA for individual shops well. This will be a huge change. (**L**)
* Olo integration would add quite a bit of load due to the validations happening every time user adds to cart. (**S**)
* Search Service will be implicated. (**S**)
* Implement upsell endpoint for Olo shops (**S**)

---

# What does this mean?

* Best case: 2 quarters
* Expected case: at least 3 quarters (possibly infinity)
* Build:
1. Create API v2
2. Apps/web v2 rebuild
3. Huge flip-the-switch "release" (i.e. terrifying)
* We would be rebuilding our *entire* eco system to accommodate Olo shops.

# Comparable projects
* Remember auth0? This is *much* bigger.
* Removing GraphQL: over a year
* Shopping cart: a year