Der Tech-Stack nach dem Kauf: Sendungsverfolgung, Rücksendungen, Support und wie sie miteinander verbunden sind
Ein Technologie-Stack für die Zeit nach dem Kauf verbindet Sendungsverfolgung, Retourenmanagement, Kundensupport und die Systeme, in denen Bestell- und Zahlungsdaten gespeichert werden. Für E-Commerce-Teams besteht das Ziel nicht darin, für jede Aufgabe eine separate App zu kaufen. Vielmehr sollen Lieferereignisse, Kundenanfragen und Rückerstattungsentscheidungen zwischen den Systemen weitergegeben werden, ohne dass der Kontext verloren geht oder widersprüchliche Aktionen ausgelöst werden.

Dieser Leitfaden erklärt, welche Zuständigkeiten die einzelnen Ebenen übernehmen sollten, wie Informationen zwischen ihnen fließen sollten und wie die Verbindungen vor dem Ausbau des Stacks getestet werden können. Der sinnvollste Ausgangspunkt ist eine einzelne Customer Journey: Eine Bestellung wird versendet, etwas ändert sich, der Kunde benötigt Hilfe und jemand muss entscheiden, wie es weitergeht.
Nach Zuständigkeiten statt nach einer App-Liste aufbauen
Ein Tracking-Tool kann den Versandfortschritt melden, aber eine Versandaktualisierung ist kein vollständiger Bestelldatensatz. Ein Retourenportal kann eine Anfrage erfassen, aber diese Anfrage ist kein Beweis dafür, dass eine Rückerstattung ausgeführt wurde. Ein Supportmitarbeiter kann eine Ausnahme genehmigen, doch die Entscheidung muss weiterhin das System erreichen, das sie ausführt.
Diese Unterscheidungen sind wichtig, weil verbundene Systeme dieselben Informationen anzeigen können, ohne dieselbe Berechtigung zu haben, sie zu ändern. Legen Sie für jeden Datensatz ein führendes System fest und lassen Sie andere Systeme darauf verweisen.
| Ebene | Empfohlene Zuständigkeit | Auszutauschende Informationen |
|---|---|---|
| Commerce-Plattform oder Bestellverwaltungssystem | Bestellidentität, gekaufte Artikel, Fulfillment-Zuordnungen und kommerzieller Bestellstatus | Bestell-IDs, IDs der Einzelpositionen, Mengen, Kundenreferenzen und Versandzuordnungen |
| Sendungsverfolgung | Transparenz über Sendungen und Interpretation von Lieferereignissen | Referenzen des Versanddienstleisters, Trackingnummern, Ereigniszeiten, Status und Ausnahmen |
| Retourenmanagement | Retourenanfragen, Richtlinienprüfungen, autorisierte Artikel und Status des Retourenprozesses | Retouren-IDs, Artikelmengen, Gründe, Genehmigungen und Prüfergebnisse |
| Kundensupport | Kundengespräche, Untersuchungen und genehmigte Ausnahmen | Ticket-IDs, relevanter Bestellkontext, Entscheidungen und Zuständigkeit für Eskalationen |
| Lager- und Zahlungssysteme | Physischer Eingang und Prüfung; finanzielle Ausführung und Abstimmung | Eingangsergebnisse, Artikel disposition, Rückerstattungsreferenzen und Transaktionsergebnisse |
Dies ist ein empfohlenes Zuständigkeitsmodell und keine Vorgabe, fünf separate Produkte zu verwenden. Eine Plattform kann mehrere Zuständigkeiten abdecken. Entscheidend ist, ob jeder wichtige Status einen klaren Verantwortlichen hat und ob andere Systeme eine angeforderte Aktion von einer abgeschlossenen Aktion unterscheiden können.
Die Sendungsverfolgung sollte den Versandfortschritt erklären, ohne kaufmännische Entscheidungen zu treffen
Die Tracking-Ebene verbindet die Aktivitäten des Versanddienstleisters mit der Bestellung des Kunden. Sie sollte Kunden helfen zu verstehen, wo sich ihr Paket befindet, und Mitarbeitern zeigen, wann eine Sendung Aufmerksamkeit erfordert. Bei Postsendungen ist die Sendungsverfolgung von Postsendungen ein Teil dieser Transparenzebene; die umfassendere Architektur muss auch Bestellungen mit mehreren Paketen oder unterschiedlichen Versanddienstleistern berücksichtigen.
Modellieren Sie Bestellungen und Sendungen getrennt. Eine Bestellung mit zwei Paketen kann ein zugestelltes und ein noch unterwegs befindliches Paket haben. Wenn die gesamte Bestellung nach dem ersten Zustellereignis als zugestellt markiert wird, kann dies irreführende Benachrichtigungen, falsche Supportantworten und Unklarheit darüber verursachen, welche Artikel retourniert werden können.
Das ursprüngliche Ereignis neben dem vereinfachten Status beibehalten
Ein kundenorientierter Status wie „unterwegs“ ist leichter zu lesen als ein Ereignis-Feed des Versanddienstleisters. Supportteams benötigen möglicherweise trotzdem den ursprünglichen Ereignistext, den Ort und den Zeitstempel, um ein Problem zu untersuchen. Bewahren Sie nach Möglichkeit beide Ansichten auf und unterscheiden Sie zwischen dem Zeitpunkt, an dem der Versanddienstleister ein Ereignis meldet, und dem Zeitpunkt, an dem Ihr System es empfangen hat.
Eine Tracking-Ausnahme sollte normalerweise eine Prüfung oder einen definierten Prozess auslösen und nicht automatisch eine Rückerstattung genehmigen. Eine Verzögerung, ein Zustellversuch und ein als zugestellt gemeldetes, aber nicht erhaltenes Paket erfordern unterschiedliche Maßnahmen. Die Richtlinie und der Untersuchungsprozess des Händlers sollten die Lösung bestimmen.
Die Zuständigkeit für Benachrichtigungen festlegen
Entscheiden Sie, welches System welche Nachricht versendet. Wenn die Commerce-Plattform, die Tracking-Anwendung und die Support-Automatisierung alle Lieferupdates versenden, kann ein Kunde doppelte oder widersprüchliche Nachrichten erhalten. Führen Sie eine Benachrichtigungsübersicht, die Auslöser, Absender, Zielgruppe, Unterdrückungsbedingungen und Ziellink festlegt.
Eine Nachricht über eine Versandverzögerung sollte beispielsweise keinen Ersatz versprechen, solange ein Ersatz nicht tatsächlich genehmigt wurde. Ihr Zweck kann lediglich darin bestehen, den neuesten Status zu erklären und einen Weg zur Unterstützung bereitzustellen.
Retouren benötigen Kontext auf Artikelebene und einen separaten Finanzstatus
Eine Retoure beginnt mit einem Artikel und einer Richtlinienentscheidung, nicht nur mit einer Trackingnummer. Die Retourenebene muss wissen, was gekauft wurde, welche Mengen noch retourniert werden können und ob eine frühere Retoure oder Rückerstattung die Anfrage bereits beeinflusst.
Definieren Sie vor der Implementierung der Automatisierung die Ereignisse, die eine Retoure voranbringen. Ein praktischer Ablauf kann zwischen „Anfrage eingereicht“, „Anfrage genehmigt“, „Paket übergeben“, „Paket eingegangen“, „Prüfung abgeschlossen“ und „Rückerstattung angefordert“ unterscheiden. Die tatsächlichen Phasen sollten der Arbeitsweise des Unternehmens entsprechen.
Fassen Sie diese Phasen nicht unter einem einzigen Status „retourniert“ zusammen. Ein Zustellereignis des Versanddienstleisters für ein Retourenpaket beweist allein nicht, dass die Lagermitarbeiter den Inhalt geprüft haben. Ebenso beweist eine Rückerstattungsanfrage nicht, dass das Zahlungssystem die Rückerstattung erfolgreich verarbeitet hat.
- Bei Teilretouren: Tauschen Sie IDs und Mengen der Einzelpositionen aus, nicht nur die Bestellsumme.
- Bei Umtauschvorgängen: Legen Sie fest, wer den Bestand reserviert, die Ersatzbestellung erstellt und eventuelle Preisdifferenzen bearbeitet.
- Bei vorzeitigen Rückerstattungen: Bestimmen Sie das qualifizierende Ereignis, Risikoprüfungen, Genehmigungsbefugnisse und den Ausnahmeprozess.
- Bei Ausnahmen von Richtlinien: Erfassen Sie, wer die Ausnahme genehmigt hat und welche nachgelagerte Aktion sie erlaubt.
Verwenden Sie Ihre veröffentlichte Richtlinie und die geltenden Verpflichtungen, um die Berechtigung zu definieren. Die Softwarekonfiguration sollte diese Entscheidungen umsetzen, statt stillschweigend selbst zur Richtlinie zu werden.
Der Support ist die Entscheidungsebene für Ausnahmen
Der Support-Arbeitsbereich sollte genügend Kontext zusammenführen, um einen Fall zu lösen, ohne dass Mitarbeiter die Bestellung über mehrere Dashboards hinweg rekonstruieren müssen. Das bedeutet nicht, dass jeder Datensatz in jedes Ticket kopiert werden muss.
Ein nützliches Bestellpanel enthält Versandzuordnungen, die neuesten relevanten Tracking-Ereignisse, offene Retouren, Rückerstattungsergebnisse und frühere Entscheidungen. Es sollte außerdem anzeigen, wann die Informationen zuletzt aktualisiert wurden. Ein alter Status ohne Zeitstempel kann aktuell wirken und dazu führen, dass ein Mitarbeiter eine falsche Auskunft gibt.
Trennen Sie Lesezugriff und Aktionsberechtigungen. Viele Mitarbeiter müssen möglicherweise die Rückerstattungshistorie einsehen; weniger Mitarbeiter benötigen die Befugnis, eine Rückerstattung auszustellen oder die Retourenberechtigung zu überschreiben. Aktionen, die Geld oder Bestand betreffen, sollten über einen Prüfpfad und Schutzmaßnahmen gegen Wiederholungen verfügen.
Leiten Sie Fälle entsprechend der erforderlichen Arbeit weiter. Eine Sendung ohne aktuelle Bewegung kann eine logistische Untersuchung erfordern. Eine abgelehnte Rückerstattungstransaktion kann an den Zahlungsbetrieb gehen. Eine Retoure mit unerwartetem Inhalt kann eine Prüfung durch das Lager erfordern. Eine Ticketkategorie ist nur dann nützlich, wenn sie zu einem benannten Verantwortlichen und einem nächsten Schritt führt.
Wie die Systeme verbunden werden: Eine Ausnahme von Anfang bis Ende verfolgen
Betrachten wir eine beispielhafte Bestellung mit zwei Artikeln, die in separaten Paketen versendet werden. Ein Paket kommt an, beim anderen tritt eine Zustellausnahme auf. Der Kunde kontaktiert den Support und retourniert später den zugestellten Artikel.
- Das Bestellsystem erstellt die Beziehungen. Jede Einzelposition wird der richtigen Sendung zugeordnet. Der Support kann sehen, dass sich der nicht zugestellte Artikel nicht im zugestellten Paket befindet.
- Die Tracking-Ebene empfängt eine Ausnahme. Sie bewahrt die Sendungsreferenz und die Ereignisdetails auf. Ein Prozess erstellt oder aktualisiert eine Untersuchung, anstatt die gesamte Bestellung als verloren zu behandeln.
- Der Support prüft den Fall. Der Mitarbeiter überprüft die betreffende Sendung und erfasst den vereinbarten nächsten Schritt. Wenn ein Ersatz genehmigt wird, erhält das Bestellsystem eine separate Anweisung, diesen zu erstellen.
- Der Kunde beantragt eine Retoure für den zugestellten Artikel. Das Retourensystem prüft Artikel und Menge anhand der Bestellung und der bereits vorhandenen Retourenaktivitäten.
- Das Lager nimmt die Retoure entgegen und prüft sie. Das Prüfergebnis wird dem Retourendatensatz zugeordnet und nicht ausschließlich aus der Paketverfolgung abgeleitet.
- Der Finanzprozess führt die genehmigte Lösung aus. Das Rückerstattungsergebnis wird zurückgeschrieben, damit Support und kundenorientierte Retourenansicht Genehmigung und Abschluss nicht verwechseln.
Die Verbindungen sind erfolgreich, wenn alle Beteiligten dasselbe Ergebnis sehen, ohne Datensätze außerhalb ihrer Zuständigkeit überschreiben zu können.
Integrationsdetails, die einen Test und keine Annahme aus einer Verkaufsdemo verdienen
Gemeinsame Identifikatoren und Datensatzabgleich
Verwenden Sie stabile interne Identifikatoren, um Bestellungen, Einzelpositionen, Sendungen, Retouren und Tickets zu verbinden. Verlassen Sie sich nicht allein auf eine E-Mail-Adresse oder eine angezeigte Bestellnummer. Ihre Abgleichregeln sollten berücksichtigen, dass Trackingnummern im Kontext des Versanddienstleisters interpretiert werden und ein Kunde mehrere aktive Bestellungen haben kann.
Ereignisübermittlung und Abstimmung
Webhooks können, sofern unterstützt, ein empfangendes System über das Eintreten eines Ereignisses informieren. Sie machen es jedoch nicht überflüssig, mit fehlenden, verzögerten, wiederholten oder außer der Reihenfolge eintreffenden Nachrichten umzugehen. Fragen Sie, wie fehlgeschlagene Übermittlungen erneut versucht werden und wie Ihr Team Ereignisse nach einem Ausfall wiederherstellen kann.
Machen Sie wiederholte Verarbeitung sicher. Wenn beispielsweise dieselbe Retourengenehmigung zweimal eingeht, dürfen nicht zwei Rückerstattungen ausgestellt werden. Ein Abstimmungsprozess sollte außerdem wichtige Datensätze systemübergreifend vergleichen, damit eine verpasste Benachrichtigung nicht dazu führt, dass eine Retoure oder Rückerstattung dauerhaft stecken bleibt.
Authentifizierung und Grenzen von Kundendaten
Eine Tracking-Abfrage, eine Retourenanfrage und eine von einem Mitarbeiter ausgestellte Rückerstattung benötigen unterschiedliche Zugriffsebenen. Entscheiden Sie, wie Kunden nachweisen, dass sie eine Bestellung einsehen oder ändern dürfen, wie Mitarbeiterberechtigungen vergeben werden und welche personenbezogenen Informationen jede verbundene Anwendung tatsächlich benötigt.
Prüfen Sie bei der Implementierung die Webhook-Authentifizierung, die Speicherung von Zugangsdaten, den Widerruf von Zugriffsrechten, Aufbewahrungseinstellungen und Audit-Logs. Vermeiden Sie es, vollständige Kundendatensätze in Protokolle zu kopieren, wenn eine interne Referenz ausreicht.
Wo 17TRACK in die Architektur passt
Beginnen Sie bei einer an 17TRACK orientierten Bewertung mit dem Produkteinstieg, der zur jeweiligen Aufgabe passt. Die Website zur Sendungsverfolgung für Verbraucher ist für die Abfrage einzelner Sendungen relevant. Händler, die eine Anwendung zur Bestellverfolgung bewerten, können den 17TRACK-Eintrag bei Shopify prüfen. Teams, die eine individuelle Verbindung entwickeln, können die Informationen zur Tracking API und die API-Dokumentation konsultieren. Anforderungen an Retouren gehören in eine separate Prüfung von 17RETURNS.
Dies sind relevante Bewertungswege und kein Beleg dafür, dass jede in diesem Leitfaden beschriebene Verbindung sofort verfügbar ist. Bestätigen Sie die konkreten Datenfelder, unterstützten Prozesse, Berechtigungen und kommerziellen Bedingungen des Produkts, das Sie verwenden möchten. Gehen Sie nicht davon aus, dass die Auswahl verwandter Produkte automatisch Supporttickets, Lagerprüfungen oder Zahlungsergebnisse synchronisiert.
Den kleinsten Prozess einführen, der eine echte Lücke schließt
Beginnen Sie mit der kostspieligsten Übergabe in Ihrem bestehenden Betrieb. Wenn Mitarbeiter den Versandstatus wiederholt manuell nachschlagen, priorisieren Sie den Tracking-Kontext im Support. Wenn Kunden nicht erkennen können, ob eine Retoure eingegangen oder erstattet wurde, priorisieren Sie die Verbindung von Retoure, Lager und Zahlung.
Erfassen Sie vor dem Kauf einer weiteren Anwendung die bereits in Ihrer Commerce-Plattform und Ihrem Supportsystem verfügbaren Funktionen. Fügen Sie ein Spezialtool hinzu, wenn es eine klar definierte Lücke schließt, und überprüfen Sie den gesamten Prozess, statt ihn nur anhand der kundenorientierten Seite zu beurteilen.
Ein sinnvoller Abnahmetest sollte Folgendes enthalten:
- Eine Bestellung, die auf mehrere Sendungen aufgeteilt ist.
- Ein Tracking-Update, das nach einem neueren Ereignis eintrifft.
- Ein wiederholtes Ereignis, das keine wiederholte finanzielle Aktion auslösen darf.
- Eine Teilretoure mit einer früheren Rückerstattung für dieselbe Bestellung.
- Eine fehlgeschlagene Rückerstattung, die für den Support sichtbar bleibt.
- Einen vorübergehenden Integrationsausfall mit anschließender Wiederherstellung.
- Eine manuelle Ausnahme, die den normalen Prozess mit einem dokumentierten Grund überschreibt.
Weisen Sie jedem fehlgeschlagenen Test einen Verantwortlichen zu und legen Sie fest, wie Mitarbeiter arbeiten, wenn die Integration nicht verfügbar ist. Ein manueller Fallback ist Teil des Designs und kein Eingeständnis, dass die Automatisierung gescheitert ist.
Ergebnisse über die Übergaben hinweg messen
Erfassen Sie lieferbezogene Kontakte pro versendeter Bestellung, die Bearbeitungszeit von Retouren, ungelöste Integrationsfehler und die Zeit zwischen der Genehmigung einer Rückerstattung und ihrer bestätigten Ausführung. Definieren Sie jede Kennzahl präzise. Unterscheiden Sie beispielsweise die Transportzeit einer Retoure von der Bearbeitungszeit im Lager, damit das zuständige Team auf das Ergebnis reagieren kann.
Vergleichen Sie nach Möglichkeit ähnliche Zeiträume und Kundengruppen. Ein Rückgang der Supportkontakte ist nicht automatisch eine Verbesserung, wenn Kunden gleichzeitig den Zugang zu Hilfe verloren haben. Kombinieren Sie Effizienzkennzahlen mit ungelösten Fällen, wiederholten Kontakten und Belegen dafür, dass Kunden die richtige Lösung erhalten haben.
FAQ
Benötigen kleine Shops separate Tools für Tracking, Retouren und Support?
Nein. Beginnen Sie mit den bereits verfügbaren Funktionen und den betrieblichen Problemen, die Sie identifizieren können. Separate Tools werden nützlich, wenn die aktuelle Einrichtung keine ausreichende Transparenz, Richtlinienkontrolle oder zuverlässige Übergaben ermöglicht. Mehr Anwendungen ohne klare Zuständigkeiten können den manuellen Aufwand erhöhen.
Sollten Tracking-Ereignisse automatisch Rückerstattungen auslösen?
Nur im Rahmen eines ausdrücklich genehmigten Prozesses mit geeigneten Prüfungen. Versandereignisse beschreiben Bewegungen oder Zustellaktivitäten; sie begründen nicht zwangsläufig die Berechtigung für eine Rückerstattung. Halten Sie auslösendes Ereignis, Genehmigungsentscheidung und finanzielle Ausführung getrennt.
Reicht eine API-Verbindung aus, damit zwei Tools zusammenarbeiten?
Nein. Die Verbindung benötigt außerdem kompatible Identifikatoren, Feldzuordnungen, Berechtigungen, Fehlerbehandlung und Regeln für widersprüchliche Aktualisierungen. Bestätigen Sie, welche Datensätze gelesen oder geändert werden können, und testen Sie den Geschäftsprozess von Anfang bis Ende.
Kann eine als zugestellt markierte Retoure als erstattet angezeigt werden?
Nicht allein aufgrund dieses Nachweises. Die Zustellung an eine Retourenadresse, der Wareneingang, die Prüfung, die Genehmigung der Rückerstattung und ihre erfolgreiche Ausführung sind unterschiedliche Ereignisse. Kundennachrichten sollten die tatsächlich bestätigte Phase angeben.
Wer sollte für den Stack nach dem Kauf zuständig sein?
Ein E-Commerce- oder Betriebsleiter ist eine praktische übergeordnete zuständige Person; Support, Logistik, Finanzen und technische Teams sind für ihre jeweiligen Prozesse verantwortlich. Eine Person sollte systemübergreifende Fehler koordinieren, damit Probleme nicht zwischen Abteilungen liegen bleiben.
Quellen
Die folgenden offiziellen Produkt- und Dokumentationsressourcen sind die Ausgangspunkte für die oben beschriebenen 17TRACK-Bewertungswege. Überprüfen Sie implementierungsspezifische Anforderungen anhand der relevanten Dokumentation und Produktbedingungen.


