Warum ist das notwendig?
Um deine Kunden noch glücklicher zu machen, möchten wir dir helfen, die Zeit, in der eine Bestellung an den Laden übermittelt wird, anhand des Standorts des Kunden noch weiter zu verbessern.
Beim derzeitigen Timed Fire Flow, also dem zeitgesteuerten Ablauf, geben die Kunden bei der Bestellung eine Abholzeit an und die Bestellung wird basierend auf dieser Zeit sowie der Mindestzubereitungszeit des Ladens an den Laden geschickt (z.B. zur Abholzeit - Mindestzubereitungszeit).
Die Sache ist die: Wenn ein Kunde zu spät kommt, steht die Bestellung bereits fertig herum und wird kalt, was die Qualität beeinträchtigt.
Im Hinblick auf seine Zufriedenheit wirst du das Essen wahrscheinlich neu zubereiten, sobald der Kunde eintrifft, was wiederum zu Lebensmittelverschwendung und höheren Kosten führt. Um das zu vermeiden, haben sich einige Restaurants dazu entschlossen, die Bestellung erst dann vorzubereiten, wenn der Kunde bereits im Restaurant ist. Das führt dazu, dass die Schnelligkeit des Services, die durch digitale Bestellungen gewonnen wird, verloren geht.
Was ist das Ziel?
Das Ziel des Trip Tracking in der mobilen App ist es, den Standort des Kunden im Hintergrund zu verfolgen, während er auf dem Weg zum Laden ist. Die geschätzte Ankunftszeit (ETA) wird immer wieder neu berechnet, um zu entscheiden, wann die Bestellung zur Vorbereitung an das Restaurant geschickt werden soll.
Sobald die Bestellung an den Laden gesendet wurde, werden die Mitarbeiter über das Tablet über die geschätzte Ankunftszeit des Kunden auf dem Laufenden gehalten und benachrichtigt, wenn der Kunde eingetroffen ist.
Wie funktioniert‘s?
Kurz gesagt: Neben dem Timed Fire Flow,, also dem zeitgesteuerten Ablauf, unterstützt die MENU-Plattform auch den Trigger Fire-Bestellablauf. Mit Trigger Fire ist es dem API-Client möglich, die geschätzte Ankunftszeit (ETA) auch nach der Platzierung der Bestellung zu übermitteln.
Sobald die erste geschätzte Ankunftszeit (ETA) eingeht, berechnet die Plattform auf Basis der ETA sowie der Mindestzubereitungszeit die send_at-Zeit (also wann die Bestellung an den Laden gesendet wird). Bei jeder nachfolgenden ETA-Aktualisierung wird auch die send_at-Zeit aktualisiert.
Sobald die send_at-Zeit erreicht ist oder die geschätzte Ankunftszeit (ETA) gleich oder niedriger ist als die Mindestzubereitungszeit des Ladens, wird die Bestellung automatisch an das Restaurant gesendet.
Zwei Dinge sind hier zu beachten:
Zahlung
Wenn die Bestellung aufgegeben wird, wird der Zahlungsbetrag genehmigt. Sobald die Bestellung an den Laden gesendet wird, wird die Zahlung erfasst. Falls bis 5 Stunden nach der angegebenen Abholzeit keine ETA-Aktualisierung eingeht, wird die Bestellung automatisch storniert.
Nicht unterstützte POS-Integrationen
POS-Integrationen, bei denen Vorbestellungen zum Bestellzeitpunkt an den POS gesendet werden müssen bzw. der POS sich darum kümmert, wann die Bestellung an den Laden gesendet wird, unterstützen keine Trigger Fire-Bestellungen. Derzeit gilt das nur für Toast.
Wie wird die geschätzte Ankunftszeit (ETA) berechnet?
Hier gibt es zwei Möglichkeiten:
OSRM
Wir können Open Street Maps nutzen, um die Reisezeit zwischen den Geokoordinaten des Kunden und den Geokoordinaten des Ladens zu berechnen.
Wir hosten einen OSRM-Server auf AWS, auf den die mobile App über eine REST-API zugreift.
Bitte beachte: Dies wird derzeit nur in Europa unterstützt. Nord- und Südamerika sind in Arbeit.
Radar
Wir können die Trip Tracking-Funktion des Radar-SDK nutzen, um die geschätzte Ankunftszeit des Kunden zu berechnen.
Bitte beachte: Radar erfordert ein separates Abonnement, das nicht Teil des MENU SaaS-Pakets ist, und wird derzeit nur in Kombination mit mParticle unterstützt. Wende dich an das Mobile Team, wenn du diese Funktion unabhängig von mParticle zur Verfügung stellen möchtest.
Ablauf in der mobilen App
Schauen wir uns an, was Schritt für Schritt in der mobilen App passiert:
-
Kunde gibt Bestellung mit aktiviertem Trip Tracking (und gewähltem Reisemodus) auf
-
Sobald der Kunde zum Restaurant geht, tippt er auf Ich bin auf dem Weg.
-
Die App verfolgt den Standort des Kunden im Hintergrund, berechnet die geschätzte Ankunftszeit kontinuierlich neu und sendet sie an die API
-
Sobald die geschätzte Ankunftszeit (ETA) gleich oder niedriger als die Mindestzubereitungszeit des Ladens ist, wird die Bestellung AKTIV und wird an den Laden gesendet.
-
Die ETA wird weiterhin berechnet und auf dem Tablet für die Mitarbeiter angezeigt.
-
Wenn der Kunde im Laden ankommt, erhalten die Mitarbeiter eine Benachrichtigung über das Tablet.
-
Der Mitarbeiter markiert die Bestellung als Fertig, woraufhin der Kunde eine Push-Benachrichtigung erhält.
Du kannst dir den Ablauf hier ansehen.
Standortberechtigungen
Sowohl unter iOS als auch unter Android reicht die Erlaubnis „Während der Nutzung“ aus, damit Smart Orders (intelligente Bestellungen) funktionieren. Während der Fahrt macht das Betriebssystem den Benutzer darauf aufmerksam, dass die App seinen Standort im Hintergrund verfolgt. Unter iOS wird dies über das „blaue Pillensymbol“ gemacht, ähnlich wie bei der Verwendung einer GPS-App.
Auf beiden Plattformen ist eine exakte Ortung erforderlich. Wenn du intelligente Bestellungen aktivierst, überprüft die App, ob die erforderlichen Berechtigungen für den Standort vorhanden sind. Falls dies nicht der Fall ist, führt die App sie den Benutzer durch einen Prozess, in dem sicherstellt wird, dass die Berechtigungen zuerst aktiviert werden.
Funktionseinstellungen
Um die Verfügbarkeit der Trip Tracking-Funktion zu steuern, sind zwei Funktionseinstellungen verfügbar. Um Kunden die Option Trip Tracking auf dem Bestellübersichtsbildschirm anzeigen zu lassen, müssen beide Funktionseinstellungen für den aktuellen Kontext des Kunden aktiviert sein.
Bitte beachte: Das Trip Tracking wird auf Laden-Ebene über das CMS aktiviert. So kann die Funktion in einzelnen Läden getestet werden, bevor sie für die gesamte Marke eingeführt wird.
Das Trip Tracking wird über die Firebase Remote Config aktiviert und ermöglicht es, die Funktion für bestimmte Benutzergruppen und/oder kleine Teile der Benutzerbasis zu aktivieren. (string: smart_orders)
Tablet
Lass uns mal sehen, wie das Ganze auf dem Tablet läuft, damit deine Mitarbeiter gut informiert sind:
-
Wenn die Bestellung zum ersten Mal aufgegeben wird, wird sie im Abschnitt ON HOLD (in der Warteschleife) mit der vom Kunden angegebenen Abholzeit angezeigt.
-
Sobald der Kunde seine Reise beginnt, wird die geschätzte Ankunftszeit auf dem Tablet angezeigt (und ständig aktualisiert).
-
Wenn die geschätzte Ankunftszeit (ETA) kleiner oder gleich der Mindestzubereitungszeit ist, wird die Bestellung aktiviert (und wechselt in den Abschnitt AKTIV, wo ein Benachrichtigungston eingestellt werden kann).
-
Wenn der Kunde eintrifft, wird eine Benachrichtigung auf dem Tablet angezeigt (ein Ton wird abgespielt und die Benachrichtigung wird angezeigt, bis das Personalmitglied mit dem Tablet interagiert)
-
Die Bestellung kann als Ready (Fertig) markiert werden und der Kunde erhält eine Push-Benachrichtigung
Du kannst dir den Ablauf hier ansehen.
Besondere Szenarien
Der Kunde ist bereits im Laden
Solltest du feststellen, dass der Kunde bereits im Laden ist, wird die Funktion Trip Tracking ausgeblendet, da die Bestellung in diesem Fall immer sofort (oder basierend auf der Abholzeit) an den Laden geschickt werden sollte.
Falls der Kunde noch keine Standortberechtigungen erteilt hat, er aber das Trip Tracking aktivieren und die korrekten Standortberechtigungen erteilen möchte, wird ihm in der Bestellübersicht ein Dialog angezeigt, der ihn darüber informiert, warum das Trip Tracking nicht verfügbar ist. Dies geschieht, sobald wir feststellen, dass der Kunde im Laden ist.
Geschätzte Ankunftszeit < Mindestzubereitungszeit des Ladens
Wenn die geschätzte Ankunftszeit (ETA) des Kunden unter der Mindestzubereitungszeit liegt, macht der Einsatz der Trip Tracking-Funktion keinen Sinn, da der Kunde dann im Laden auf seine Bestellung warten müsste. Der Grund dafür ist, dass der Kunde erst auf I’m on my way (Ich bin unterwegs) tippen wird, wenn er bereits am Weg zum Laden ist. Dadurch wird die Bestellung sofort an den Laden geschickt (weil geschätzte Ankunftszeit < Mindestzubereitungszeit). Der Kunde wird jedoch im Laden ankommen, noch bevor seine Bestellung fertig zubereitet wurde.
Beispiel:
-
Kunde ist 5 Minuten vom Restaurant entfernt
-
Aktuelle Zeit ist 11:00 Uhr
-
Mindestzubereitungszeit des Ladens beträgt 15 Minuten
-
Kunden bestellt für 13:00 Uhr
-
Der Kunde verlässt die Wohnung um 12:55 Uhr und tippt auf „Ich bin auf dem Weg“.
-
Bestellung wird an den Laden geschickt (um 12:55), da geschätzte Ankunftszeit < Mindestzubereitungszeit
-
Der Kunde kommt um 13:00 Uhr im Laden an, aber die Bestellung ist erst um 13:10 Uhr fertig (weil der Laden 15 Minuten für die Vorbereitung braucht)
Wenn der Kunde seine erste Trip-Tracking -Bestellung aufgibt, wird ihm ein Dialog angezeigt, in dem empfohlen wird, das Trip-Tracking nicht zu verwenden (und das Problem zu erklären). Dies trifft nur zu, wenn wir feststellen, dass die geschätzte Ankunftszeit (ETA) unter der Mindestzubereitungszeit für die gewählte Reiseart liegt.
Bei späteren Bestellungen wird die vom Kunden gewählte Reiseart gespeichert. Liegt die geschätzte Ankunftszeit (ETA) unter der Mindestzubereitungszeit für den ausgewählten Reisemodus, wird Trip Tracking standardmäßig deaktiviert und der Kunde sieht denselben Dialog, wenn er sie aktiviert.
Nicht abgedecktes Szenario
Sollte der Kunde seine Reise starten, aber nie im Laden erscheinen, bleibt die Bestellung so lange auf ACTIVE (Aktiv), bis die App aufhört ETA-Aktualisierungen zu senden.
Sobald die App keine ETA-Aktualisierungen mehr übermittelt, wird die Bestellung basierend auf der berechneten Abholzeit abgewickelt.
In diesem Fall müssen der Laden und der Kunde direkt miteinander kommunizieren.
Kommentare
0 Kommentare
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.