„Wo ist meine Bestellung?“ klingt nach einer kleinen Supportanfrage. Jemand öffnet das Shopsystem, prüft den Versand, kopiert den Tracking-Link und antwortet. Kurz darauf fragt der nächste Kunde dasselbe.
Am Ende eines vollen Nachmittags hat dein Team viel Zeit damit verbracht, vorhandene Informationen zu übersetzen. Die Kunden haben auf diese Informationen gewartet.
Bestellstatus-Anfragen zu automatisieren ist ein brauchbarer erster Schritt, weil die Aufgabe klar ist: die Bestellung eines berechtigten Kunden zuordnen, den verfügbaren Stand lesen, verständlich erklären und Ausnahmen weitergeben. Gerade die Ausnahmen verdienen etwas Planung.
Welche Frage steckt hinter „Wo ist meine Bestellung?“
Im E-Commerce heißt diese Anfragegruppe häufig WISMO, kurz für „Where is my order?“. Dahinter stecken verschiedene Anliegen. Wurde die Bestellung verschickt? Warum zeigt die Sendungsverfolgung nur ein erstelltes Label? Kommt ein Artikel später? Der Zusteller meldet eine Lieferung, aber das Paket ist nicht da?
Ein Tracking-Link beantwortet einen Teil davon. Für andere Fragen brauchst du den Bearbeitungsstand im Shop, Angaben zu Teilsendungen oder eine Meldung des Versanddienstleisters. Schau dir eure tatsächlichen Anfragen an und trenne diese Fälle.
Prüfe außerdem den normalen Bestellablauf. Ist der Tracking-Link leicht zu finden? Werden Versandzeiten verständlich erklärt? Zeigt das Kundenkonto hilfreiche Informationen? Ein Chatbot kann fehlende Sendungsdaten oder dauerhaft verwirrende Nachrichten nicht ausgleichen.
Ein externer Kundencase: Skullcandy
DigitalGenius berichtet in seiner veröffentlichten Skullcandy-Fallstudie, 80 Prozent der WISMO-Anfragen bearbeitet und Antworten auf Status-, Fehlerbehebungs- und Garantiefragen beschleunigt zu haben. Das sind Anbieterangaben zu dieser Umsetzung. Sie sind keine Prognose für andere Shops und keine Ergebnisse meines Plugins. Interessant ist der gezielt abgegrenzte Umfang der Supportaufgaben.
Für euren Pilot würde ich mit einer Bestellabfrage und klaren Ausnahmefällen beginnen. Das lässt sich anhand echter Anliegen beurteilen, bevor Änderungsaktionen dazukommen.
Aus technischen Zuständen verständliche Antworten machen
Ein interner Status kann für die Lagerverwaltung eindeutig sein und beim Kunden neue Fragen erzeugen. Lege fest, welche Aussage aus welchem Ereignis folgt.
| Vorhandene Information | Verständliche Erklärung | Was damit noch nicht bekannt ist |
|---|---|---|
| Bestellung angenommen, kein Versandereignis | Die Bestellung wird vorbereitet | Ein Versandtermin, sofern der Shop keinen liefert |
| Versandlabel erstellt | Das Versandetikett wurde vorbereitet | Ob der Zusteller das Paket abgeholt hat |
| Übernahmescan des Zustellers | Das Paket wurde dem Versanddienstleister übergeben | Ein Liefertermin ohne dessen Schätzung |
| Ein Teil der Artikel versandt | Die Bestellung kommt in mehreren Sendungen | Der Stand der übrigen Artikel ohne weitere Daten |
| Als zugestellt gescannt, Kunde widerspricht | Der Zusteller meldet eine Lieferung | Was vor Ort passiert ist; der Fall braucht Prüfung |
Ein voraussichtlicher Liefertermin bleibt eine Schätzung. Nenne bei Bedarf die Quelle und den Zeitpunkt des letzten Updates. Ein fehlender Scan beweist weder einen Verlust noch eine pünktliche Zustellung. Ein Label belegt lediglich, dass ein Label erstellt wurde.
Für einen Laravel-Shop würde ich nur die benötigten Felder freigeben: eine kundenlesbare Bestellreferenz, den Sendungsstand, betroffene Artikel, einen erlaubten Tracking-Link und vorhandene Zeitangaben. Adressdaten und interne Lagernotizen brauchen eigene Regeln für ihre Sichtbarkeit.
Die Bestellnummer ist keine Zugriffsberechtigung
Mit der Bestellnummer findest du einen Datensatz. Damit weißt du noch nicht, wer ihn lesen darf. Die Anwendung muss die Abfrage an eine vertrauenswürdig ermittelte Kundenidentität oder einen bewusst eingerichteten Verifikationsprozess binden.
Im angemeldeten Kundenkonto kann sie den Zugriff auf die Bestellungen dieses Kunden begrenzen. Bei einem Widget auf einer getrennten Website hilft serverseitig ausgestellter, vertrauenswürdiger Kontext. Eine im Chat eingetippte Kundennummer darf keine Berechtigung erzeugen.
Wenn die Identität nicht geklärt werden kann, führe zum normalen Login oder zu einem Supportmitarbeiter. Gib dabei keine Auskunft darüber, ob die Bestellung einer fremden Person existiert. Diese Entscheidung gehört in die Anwendung und ihren Zugriffsvertrag.
Ein Dialog, nach dem der Kunde weiterkommt
Das folgende Gespräch ist ein Beispiel mit erfundenen Bestelldaten:
Kunde: Meine Bestellung steht noch auf Bearbeitung. Ist sie schon verschickt?
Assistent: Eine Sendung wurde dem Zusteller übergeben. Die zweite wird noch vorbereitet. Ich kann dir zeigen, welche Artikel in welcher Sendung liegen.
Hilfreich ist die Antwort, weil sie beide Sendungen berücksichtigt. Meldet der Kunde anschließend ein Adressproblem, beginnt eine andere Aufgabe. Die Statusabfrage ist abgeschlossen; eine mögliche Bestelländerung braucht einen gesondert erlaubten Prozess.
Bei „zugestellt, aber nicht erhalten“ sammelt der Assistent die benötigten Angaben und übergibt Bestellreferenz, Sendungsereignis und Kundenbeschreibung. Der Support sollte die bisherigen Fragen nicht noch einmal stellen müssen.
Die Formulierung kann dabei ganz schlicht bleiben: „Ein Versandetikett wurde erstellt, aber es gibt noch keinen Abholscan.“ Das erklärt den verfügbaren Stand, ohne einen Versandtermin zu erfinden.
Tracking-Seite und Chat sinnvoll kombinieren
Eine Statusseite eignet sich für schnelle Routineabfragen. Ein Gespräch hilft, wenn etwas erklärt werden muss, mehrere Sendungen beteiligt sind oder ein Problem gemeldet werden soll.
Gorgias dokumentiert ein Bestellportal, bei dem die angebotenen Optionen von der konkreten Bestellung abhängen. Die übertragbare Idee: Zeig passende nächste Schritte aus den tatsächlichen Bestelleigenschaften. Welche Aktion erlaubt ist, entscheiden eure Geschäftsregeln.
Platziere den Assistenten zunächst im Kundenkonto, auf der Bestellseite oder im Hilfebereich. Dort entstehen die Fragen, und der Pilot bekommt einen nachvollziehbaren Einstiegspunkt.
Die Umsetzung in einer Laravel-Anwendung
Mit Filament Agentic Chatbot würde ich einen Agent mit freigegebenem Wissen zu Versandregeln und einer kundenbezogen begrenzten Data Resource für Bestelldaten einrichten. Ein API Connector kann einen getrennten Bestell- oder Versanddienst lesen, sobald diese Anbindung konfiguriert ist.
Identität, Zugriffsregeln und Geschäftsdaten bleiben Aufgabe der Host-Anwendung. Die Anbindung an einen Versanddienstleister muss eingerichtet oder entwickelt werden; das Plugin stellt nicht automatisch für jeden Anbieter eine fertige Verbindung bereit.
Der erste Umfang bleibt bei lesenden Abfragen und einer bewusst vorgesehenen Supportübergabe. Für spätere Änderungen zeigst du den konkreten Vorschlag und lässt ihn vor der Ausführung bestätigen. Ein optionales Playbook kann einen festgelegten Eskalations- oder Ausnahmeprozess abbilden.
Wenn euch vor allem der laufende Betrieb interessiert, behandelt der vorhandene Guide zum Laravel AI Support Bot in Produktion Qualität und Conversation Review ausführlicher. Hier geht es um die engere Aufgabe, Sendungsdaten in eine korrekte Antwort zu übersetzen.
Die unangenehmen Bestellungen vor dem Saisonansturm testen
Lege Testdaten für eine normale Sendung, eine Teillieferung, eine stornierte Bestellung, ein Label ohne Abholscan und eine veraltete Zustellerauskunft an. Prüfe außerdem die Bestellung eines anderen Kunden. Sie muss außerhalb des erlaubten Zugriffs bleiben.
Lass die Carrier-API gezielt fehlschlagen. Der Assistent sollte erklären, dass der aktuelle Stand nicht geprüft werden konnte, und einen passenden nächsten Schritt anbieten. Unbemerkt eine alte Antwort zu verwenden wäre irreführend.
Teste widersprüchliche Zustände zwischen Shop und Zusteller. Lege fest, welches System für welche Information zuständig ist. Prüfe schließlich, ob die menschliche Übergabe den nötigen Kontext enthält und ob später ergänzte Schreibaktionen nach einem Timeout oder zweiten Klick doppelt ausgeführt werden könnten.
Gelöste Anliegen zählen, auch die erneuten Kontakte
Erfasse zuerst den WISMO-Anteil eurer Supportanfragen und den Aufwand einer manuellen Abfrage. Nach dem Start prüfst du korrekte Antworten, Übergabegründe und Kunden, die sich zur gleichen Bestellung erneut melden.
Ein geschlossener Chat ist noch kein gelöstes Anliegen. Vielleicht ist der Kunde gegangen, weil die Antwort nicht geholfen hat. Bewerte deshalb eine Stichprobe der Gespräche und wiederholte Kontakte zusammen mit euren Automatisierungszahlen.
Trenne gewöhnliche Statusfragen von verlorenen Paketen und anderen Ausnahmen. Eine einzige Erfolgsquote für alles verdeckt schnell, welcher Teil des Ablaufs Aufmerksamkeit braucht. Vergleiche ähnliche Zeiträume und Anfragearten.
Eine verlässliche Abfrage, ehrliche Statustexte und eine vorbereitete menschliche Übergabe ergeben einen brauchbaren ersten Umfang. Mehr Verantwortung kann folgen, wenn diese Teile mit echten Bestellungen funktionieren.
Häufige Fragen zur Bestellstatus-Automatisierung
Braucht jede Tracking-Anfrage KI?
Nein. Für einfache Abfragen genügt oft eine Statusseite oder ein festes Formular. KI hilft beim Verstehen der Frage, beim Erklären der verfügbaren Fakten und beim Erfassen von Ausnahmefällen.
Darf ein Kunde seine Bestellnummer im öffentlichen Chat nennen?
Er kann eine Referenz angeben. Der Datenzugriff braucht trotzdem eine vertrauenswürdig festgestellte Identität oder euren eingerichteten Verifikationsprozess. Die Nummer allein ist keine Berechtigung.
Soll der Assistent direkt stornieren oder erstatten?
Beginne mit Statusinformationen. Jede weitere Aktion benötigt eigene Voraussetzungen, Berechtigungsprüfungen, Bestätigungsregeln und einen Umgang mit unklaren Ergebnissen.