Why is it needed?
To make your Customers even happier, we want to help you improve the time when we send an Order to the Store, using their location.
With the current Timed Fire Flow, Customers specify a Pickup Time when placing their Order and the Order is sent to the Store based on that and on the Venue’s Minimum Preparation Time (e.g. at Pickup Time - Minimum Preparation Time).
The thing is - if Customers are late, the Order is prepared and waiting for the them, getting cold & impacting quality.
Having their satisfaction in mind, you probably will re-make the dish when the Customer arrives, leading to food waste & higher costs. To avoid this, some restaurants have decided to only start preparing the Order when the Customer is already in the restaurant, which means that the speed of service gains from ordering digitally are lost.
What's the goal?
With Trip Tracking on the Mobile App, the goal is to track the Customer’s location in the background while they're on their the way to the Store and continuously re-calculate the ETA (Estimated Time of Arrival) to decide when the Order should be sent to the restaurant for preparation.
Additionally, once the Order has been sent to the Store, we want to keep crew members up-to-date on the Customer’s ETA via the Tablet, as well as notify them when the Customer has arrived.
How does it work?
In short: next to the Timed Fire Flow, the MENU platform supports a Trigger Fire order workflow. With Trigger Fire, the API client can submit ETA updates after placing the Order.
When the first ETA is received, the platform will calculate the send_at time (when the Order will be sent to the Store), based on the ETA and the Minimum Preparation Time. With every subsequent ETA update, the send_at time will be updated.
As soon as the send_at time is reached or the ETA is equal to or lower than the Store's Minimum Preparation Time, the Order is automatically sent to the restaurant.
Two things to note here:
When the Order is placed, the payment amount is authorized. As soon as the order is sent to the Store, the payment is captured. If no ETA update is received until 5 hours after the specified Pickup Time, the Order will be automatically cancelled.
Unsupported POS Integrations
POS integrations where pre-orders need to be sent to the POS at the time of ordering and the POS takes care of when the order is sent to the Store do not support Trigger Fire orders. Today this is only the case for Toast.
How does the ETA get calculated?
There are two approaches here:
We can use Open Street Maps to calculate the travel time between the Customer’s geo-coordinates and the Store's geo-coordinates.
We host an OSRM server on AWS and it is accessed by the Mobile App via a REST API.
Please note: this is currently supported in Europe only. North and South Americas are being worked on.
We can leverage the Trip Tracking feature of Radar’s SDK to calculate the Customer’s ETA.
Please note: Radar requires a separate subscription that is not part of the MENU SaaS package and is currently only supported in combination with mParticle. Reach out to the Mobile Team if there is a need to make this available independently from mParticle.
Flow on the Mobile App
Let's see what happens, step by step, on the Mobile App:
Customer places Order with Trip Tracking enabled (and chosen travel mode)
When the Customer leaves to the restaurant, they tap on I’m on my way
The app tracks the Customer’s location in the background, continuously re-calculates the ETA and sends it to the API
As soon as the ETA is equal to or lower than the Store's Minimum Preparation Time, the Order becomes ACTIVE and is sent to the Store
The ETA continues to be calculated and is shown on the Tablet for crew members
When the Customer arrives at the Store, crew members are notified via the Tablet
Crew member marks the Order as Ready, which sends a push notification to the Customer
You can have a look at the flow here.
On both iOS and Android, the While in Use permission is sufficient for Smart Orders to function. During the trip, the operating system will make the User aware that the app is tracking their location in the background. On iOS, this is accomplished through the 'blue pill', similar to when using a GPS app.
Precise location is required on both platforms. When enabling Smart Orders, the app will check whether required location permissions are granted and in case they are not, take the User through a flow to ensure they are enabled first.
To control the availability of the Trip Tracking feature, two feature flags are available. In order for Trip Tracking to be shown as an option to Customers on the Order Summary Screen, both flags need to be enabled for the Customer’s current context.
Please note: Trip Tracking is enabled at a Store-level through the CMS. This allows the feature to be tested with individual stores before rolling it out to the entire brand.
Trip Tracking is enabled through Firebase Remote Config, allowing for the feature to be turned on for certain user groups and / or small parts of the user base. (string: smart_orders)
Let's see how this flows on Tablet, so your crew can be informed:
When Order is first placed, it is shown in the ON HOLD section with the Customer-specified Pickup Time
When the Customer starts their trip, the ETA is shown on the Tablet (and continuously updated)
When the ETA becomes smaller or equal to the Minimum Prep Time, the Order becomes active (and moves to the ACTIVE section, notification sound can be set up)
When Customer arrives, notification is shown on Tablet (sound is played and notification is shown until crew member interacts with Tablet)
Order can be marked as Ready and the Customer receives a push notification
You can have a look at the flow here.
Customer is already in the Store
If we identify that the Customer is already in the Store, the Trip Tracking feature is hidden, since the Order should always be sent to the Store immediately (or based on Pickup Time) in this case.
If the Customer had not given location permissions yet, so they enable Trip Tracking and give the correct location permissions, we’ll display a dialog on the Order Summary, as soon as we realize that the Customer is in the store, letting them know why Trip Tracking is not available.
Estimated Time of Arrival < Venue’s Minimum Preparation Time
If the Customer’s ETA is lower than the Minimum Preparation Time, the use of Trip Tracking doesn’t make sense, cause it will make the Customer wait in the store for their Order. This is because they will only tap on I’m on my way when they leave to the Store, which will immediately trigger the Order to be sent to the Store (since ETA < Minimum Preparation Time), but the Customer will arrive at the Store quicker than the time it takes to prepare the Order.
Customer is 5 minutes away from restaurant
Current time is 11:00
Venue’s Minimum Preparation Time is 15 minutes
Customer orders for 13:00
Customer leaves their place at 12:55 and taps on “I’m on my way”
Order is sent to the Venue (at 12:55), since ETA < Minimum Preparation Time
Customer arrives at the Venue at 13:00, but order is only ready at 13:10 (because it takes the Venue 15 minutes to prepare)
If the Customer is placing their first Trip Tracking Order, we will show the Customer a dialog recommending not to use Trip Tracking (and explaining the issue) if we notice that ETA < Minimum Prep Time for the selected travel mode.
For subsequent Orders, we save the Customer’s chosen travel mode. If the ETA < Minimum Prep Time for the pre-selected travel mode, Trip Tracking will be disabled by default and the Customer will receive the same dialog when enabling it.
Not covered scenario
If the cstarts their trip, but never goes to the Store, the Order will stay ACTIVE for as long as the app is sending ETA updates.
As soon as the app stops sending ETA updates, the Order will be fired based on the calculated Pickup Time.
This case needs to be handled between the Store and Customer directly.