Return-to-Sender Retouren automatisch erkennen und in Xentral erfassen

Es ist Montagmorgen. Du öffnest dein Xentral und siehst 15 offene Aufträge, die angeblich zugestellt wurden. Aber gestern trudelte eine Nachricht vom Kundenservice rein: "Kunde XY hat sein Paket nie erhalten." Du checkst das Tracking - "Unzustellbar, zurück an Absender". Das Paket ist schon seit vier Tagen auf dem Rückweg zu dir, aber in deinem System steht immer noch "versendet".

Klingt bekannt? Dann bist du nicht allein. Return-to-Sender Sendungen - kurz RTS - sind eines der versteckten Probleme im E-Commerce, das erstaunlich viele Händler manuell lösen. In diesem Artikel zeige ich dir, warum das teuer ist, wie eine automatische Lösung aussieht, und wann sich die Investition lohnt.

Das versteckte Problem: RTS-Sendungen

Return-to-Sender klingt nach einem Randproblem. Aber die Zahlen sprechen eine andere Sprache.

Je nach Branche, Zielgruppe und Versandregion liegt die RTS-Quote bei zwei bis fünf Prozent aller Sendungen. Bei 1.000 Paketen im Monat sind das 20 bis 50 Sendungen, die unzustellbar zurückkommen. Bei 10.000 Paketen sprechen wir von 200 bis 500 Stück.

Das Problem ist nicht nur die reine Menge. Das Problem ist, dass diese Sendungen meist erst auffallen, wenn es zu spät ist - wenn der Kunde sich beschwert, wenn das Paket nach zwei Wochen wieder im Lager auftaucht, oder wenn bei der monatlichen Inventur Diskrepanzen auftauchen.

Die Folgen sind vielfältig: Der Kundenservice verbringt Zeit mit Nachforschungen. Der Lagerbestand stimmt nicht, weil Retouren nicht erfasst wurden. Artikel werden als verfügbar verkauft, obwohl sie eigentlich noch unterwegs zurück sind. Und die Buchhaltung hat offene Posten, die nie geschlossen werden.

Was genau ist Return-to-Sender?

Bevor wir weitermachen, eine wichtige Unterscheidung: RTS-Sendungen sind keine normalen Kundenretouren.

Bei einer Kundenretoure entscheidet sich der Kunde aktiv, die Ware zurückzuschicken. Er fordert ein Retourenlabel an, verpackt das Paket, und schickt es zurück. Das ist ein geplanter, dokumentierter Prozess.

Bei einer RTS-Sendung hingegen kommt das Paket zurück, ohne dass der Kunde es je erhalten hat. Die häufigsten Gründe sind falsche oder unvollständige Adresse, Empfänger unbekannt verzogen, Annahme verweigert, wiederholte Zustellversuche ohne Erfolg, oder Paket konnte nicht in Filiale abgeholt werden und wurde nach der Lagerfrist zurückgeschickt.

Der entscheidende Unterschied: Bei einer Kundenretoure weißt du Bescheid. Bei einer RTS-Sendung erfährst du es oft erst, wenn das Paket wieder bei dir auftaucht - oder wenn der Kunde sich meldet.

Warum manuelles Tracking nicht skaliert

Die naheliegende Lösung ist: Jeden Tag alle offenen Sendungen durchgehen und den Tracking-Status prüfen. Manche Händler machen das tatsächlich. Aber diese Lösung hat fundamentale Probleme.

Zunächst der Zeitaufwand. Bei 100 offenen Sendungen und einer durchschnittlichen Prüfzeit von 30 Sekunden pro Sendung bist du 50 Minuten am Tag nur mit Tracking beschäftigt. Bei 500 offenen Sendungen über vier Stunden. Und das jeden Tag.

Dann die Fehlerquote. Manuelles Prüfen ist monoton. Menschen machen Fehler, übersehen Einträge, werden abgelenkt. Ein RTS-Status, der morgens um 6 Uhr vom Carrier gemeldet wird, ist leicht zu übersehen, wenn du um 10 Uhr prüfst und das Tracking mittlerweile auf "In Zustellung zum Absender" gewechselt hat.

Schließlich die Verzögerung. Selbst wenn du gewissenhaft prüfst - du prüfst maximal einmal am Tag. Der RTS-Status wird aber irgendwann im Laufe des Tages oder der Nacht gesetzt. Im Schnitt vergehen 12 bis 24 Stunden, bis du davon erfährst. In dieser Zeit könnte der Kundenservice bereits eine Anfrage erhalten haben.

Die Wahrheit ist: Manuelles RTS-Tracking ist eine Notlösung für kleine Volumen. Sobald du mehr als ein paar hundert Sendungen im Monat hast, wird es zum Engpass.

Die technische Lösung: Webhook-basierte Erkennung

Die gute Nachricht: Die meisten großen Versanddienstleister bieten mittlerweile Webhooks oder Push-Benachrichtigungen an. Das bedeutet: Der Carrier meldet sich bei dir, wenn sich ein Status ändert - nicht umgekehrt.

Ein Webhook funktioniert vereinfacht so: Du hinterlegst beim Carrier eine URL. Jedes Mal wenn sich der Tracking-Status einer deiner Sendungen ändert, schickt der Carrier eine Nachricht an diese URL. Die Nachricht enthält die Tracking-Nummer, den neuen Status, und oft zusätzliche Details wie Grund der Unzustellbarkeit.

Damit hast du alle Bausteine für eine automatische RTS-Erkennung. Ein System, das diese Webhooks empfängt und verarbeitet, alle Sendungsinformationen in einer Datenbank speichert, RTS-relevante Status-Codes erkennt (jeder Carrier verwendet andere Codes), und automatisch eine Retoure in Xentral erstellt.

Das Ergebnis: Sekunden nachdem der Carrier den RTS-Status meldet, weißt du Bescheid. Automatisch, zuverlässig, 24 Stunden am Tag, sieben Tage die Woche.

So funktioniert die automatische Retouren-Erstellung

Lass mich den Prozess konkret beschreiben, wie ich ihn bei meinen Kunden umsetze.

Alles beginnt damit, dass ein Paket das Lager verlässt. Die Sendung wird in Xentral verbucht und die Tracking-Nummer wird erfasst - das passiert ohnehin schon. Neu ist, dass diese Tracking-Nummer zusätzlich an das RTS-Erkennungssystem übermittelt wird.

Ab diesem Moment überwacht das System den Versandstatus. Jede Statusänderung, die der Carrier meldet, wird empfangen und ausgewertet. Die meisten Meldungen sind uninteressant - "In Transit", "Out for Delivery", "Delivered". Diese werden protokolliert, aber lösen keine Aktion aus.

Interessant wird es, wenn ein RTS-relevanter Status eintrifft. Das kann je nach Carrier unterschiedlich aussehen. Bei DHL beispielsweise sind das Codes wie "Unzustellbar" oder "Zurück an Absender". Bei DPD wiederum andere Bezeichnungen. Das System muss alle diese Varianten kennen und korrekt interpretieren.

Wird ein solcher Status erkannt, erstellt das System automatisch eine Retoure in Xentral. Dabei werden mehrere Dinge konfiguriert: Der Retourenstatus, etwa "RTS - erwartet". Der Retourengrund, automatisch befüllt basierend auf dem Carrier-Code. Eine interne Notiz mit den Tracking-Details für spätere Nachverfolgung.

Optional kann gleichzeitig eine E-Mail-Benachrichtigung an das Lager oder den Kundenservice gehen. So weiß das Team sofort Bescheid und kann bei Bedarf proaktiv auf den Kunden zugehen.

Wenn das Paket dann physisch im Lager eintrifft, ist die Retoure bereits im System. Das Lager prüft die Ware, bucht die Retoure ab, und der Bestand wird wieder erhöht. Alles dokumentiert, alles nachvollziehbar.

Praxis-Beispiel: Vorher und Nachher

Ein Kunde von mir betreibt einen Online-Shop für Heimtextilien und versendet etwa 3.000 Pakete im Monat, primär über DHL und DPD. Die RTS-Quote lag bei etwa drei Prozent - also rund 90 Sendungen im Monat.

Vor der Automatisierung sah der Prozess so aus: Jeden Morgen ging eine Mitarbeiterin alle Sendungen der letzten 14 Tage durch, deren Tracking-Status nicht "zugestellt" war. Bei etwa 200 bis 300 offenen Sendungen dauerte das gut eine Stunde. RTS-Sendungen wurden händisch notiert und dann manuell als Retoure in Xentral erfasst. Die durchschnittliche Zeit von der Carrier-Meldung bis zur Erfassung in Xentral: etwa zwei bis drei Tage.

Das Problem dabei: In dieser Zeit meldeten sich regelmäßig Kunden, deren Pakete als "unzustellbar" zurückgingen. Der Kundenservice musste dann erst recherchieren, was mit der Sendung los war - obwohl die Information theoretisch schon seit Tagen beim Carrier verfügbar war.

Nach der Automatisierung läuft der Prozess vollautomatisch. Die Zeit von der Carrier-Meldung bis zur Retouren-Erstellung in Xentral: unter einer Minute. Die Mitarbeiterin, die vorher eine Stunde täglich mit Tracking verbracht hat, kann diese Zeit jetzt für wertschöpfende Tätigkeiten nutzen.

Der Kundenservice kann bei RTS-Fällen sofort sehen, dass das Paket zurückkommt, und proaktiv auf den Kunden zugehen. "Wir haben gesehen, dass Ihr Paket nicht zugestellt werden konnte. Möchten Sie, dass wir es erneut versenden oder die Bestellung stornieren?" Das kommt bei Kunden gut an.

Zusätzlicher Bonus: Die gesammelten RTS-Daten ermöglichen jetzt eine Analyse. Welche Regionen haben hohe RTS-Quoten? Welche Produkte sind häufiger betroffen? Welche Gründe werden am häufigsten genannt? Diese Erkenntnisse helfen, die RTS-Quote langfristig zu senken.

Welche Carrier werden unterstützt

Die gute Nachricht ist, dass alle großen Carrier im DACH-Raum mittlerweile Webhook-basiertes Tracking anbieten.

DHL bietet eine umfangreiche Tracking-API und Webhook-Funktionalität. Die Integration ist gut dokumentiert und zuverlässig. RTS-Status werden klar kommuniziert, inklusive Grund der Unzustellbarkeit.

DPD hat ebenfalls eine solide API mit Push-Benachrichtigungen. Die Statuscodes unterscheiden sich von DHL, aber alle relevanten RTS-Szenarien werden abgedeckt.

GLS bietet Tracking-Updates via Webhook. Die Granularität der Informationen ist teilweise etwas geringer als bei DHL oder DPD, aber für die RTS-Erkennung ausreichend.

Hermes hat seine API in den letzten Jahren deutlich verbessert. Webhook-Support ist vorhanden und funktioniert zuverlässig.

Österreichische Post bietet für Business-Kunden ebenfalls Tracking-APIs an. Die Integration erfordert etwas mehr Aufwand, ist aber machbar.

Für Spezialsendungen wie Speditionsware oder internationale Carrier muss man im Einzelfall prüfen, was möglich ist. Die meisten bieten zumindest eine Tracking-Abfrage an, auch wenn aktive Push-Benachrichtigungen nicht immer verfügbar sind.

Wann sich die Automatisierung lohnt

Die ehrliche Antwort: Nicht für jeden. Hier ist meine Einschätzung, ab wann sich die Investition rechnet.

Bei unter 500 Sendungen im Monat ist die manuelle Lösung oft noch praktikabel. Der Zeitaufwand ist überschaubar, die Fehlerquote bei kleinen Mengen niedriger. Die Investition in ein automatisches System amortisiert sich hier möglicherweise nicht.

Bei 500 bis 2.000 Sendungen im Monat wird es interessant. Der tägliche Tracking-Aufwand summiert sich auf mehrere Stunden pro Woche. Die RTS-Quote wird spürbar - bei drei Prozent sind das 15 bis 60 Sendungen im Monat. Hier lohnt sich ein genauer Blick auf die Kosten-Nutzen-Rechnung.

Bei über 2.000 Sendungen im Monat ist die Automatisierung fast immer wirtschaftlich sinnvoll. Der manuelle Aufwand ist erheblich, die Fehlerquote steigt mit dem Volumen, und die Zeitersparnis rechtfertigt die Investition schnell.

Neben dem reinen Volumen spielen auch andere Faktoren eine Rolle. Eine hohe RTS-Quote macht die Automatisierung attraktiver, weil der Nutzen größer ist. Wenn der Kundenservice häufig RTS-bezogene Anfragen bearbeitet, ist der indirekte Nutzen durch schnellere Informationsverfügbarkeit erheblich. Und wenn Bestandsgenauigkeit kritisch ist, etwa bei knappen Margen oder Just-in-Time-Nachbestellungen, ist die zeitnahe Erfassung von RTS-Retouren besonders wertvoll.

Häufige Bedenken und wie ich sie adressiere

Wenn ich das Thema bei Kunden anspreche, höre ich regelmäßig ähnliche Bedenken.

"Das klingt kompliziert." - Verständlich. Webhooks, APIs, Carrier-Codes - das klingt nach Technik. Aber du musst das nicht selbst umsetzen. Du brauchst jemanden, der das für dich macht. Für dich ändert sich im Alltag wenig - außer dass RTS-Sendungen plötzlich automatisch als Retouren auftauchen.

"Was ist mit Fehlerkennungen?" - Eine berechtigte Frage. Kein System ist perfekt. Aber die Erkennungsrate bei ordentlich konfigurierten Systemen liegt deutlich über 99 Prozent. Und Fehlerkennungen in beide Richtungen sind möglich: Mal wird eine RTS nicht erkannt, mal wird fälschlicherweise eine erkannt. Letzteres ist unproblematischer - du stornierst einfach die unnötige Retoure, wenn das Paket doch zugestellt wurde.

"Wir haben mehrere Carrier." - Das ist der Normalfall, nicht die Ausnahme. Das System ist so konzipiert, dass es verschiedene Carrier parallel unterstützt. Jeder Carrier hat seine eigenen Statuscodes, aber das System normalisiert diese in ein einheitliches Format.

"Wir versenden auch international." - Internationale Sendungen sind komplexer, weil oft mehrere Carrier beteiligt sind. Die Handover-Punkte zwischen Carriern können die RTS-Erkennung verzögern oder erschweren. Hier muss man im Einzelfall prüfen, was machbar ist.

Fazit und nächste Schritte

Return-to-Sender Sendungen sind ein verstecktes, aber teures Problem im E-Commerce. Manuelles Tracking ist zeitaufwändig, fehleranfällig und skaliert nicht. Die automatische Erkennung via Carrier-Webhooks löst diese Probleme.

Die Technologie ist ausgereift. Die Carrier unterstützen es. Die Integration mit Xentral ist machbar. Die Frage ist nicht ob, sondern wann sich die Investition für dich lohnt.

Meine Empfehlung: Wenn du mehr als 500 Sendungen im Monat hast und regelmäßig Zeit mit RTS-Tracking verbringst, lohnt sich ein genauerer Blick. Nimm dir eine Stunde Zeit und notiere, wie viel Aufwand aktuell in das manuelle Tracking fließt. Dann weißt du, ob ein Gespräch Sinn macht.

---

Nächste Schritte

• Return-to-Sender Erkennung als Add-On - Alle Details zum Tool
• Automatisierung mit Xentral Flows - Weitere Automatisierungsmöglichkeiten
• Anfrage stellen - Kostenloses Erstgespräch vereinbaren