JTL Status verstehen & nutzen: Versand optimal steuern

JTL Status bezeichnet die Zustandsinformationen deiner Versandprozesse in JTL-Wawi, JTL-Shipping und Track&Trace. Diese Status zeigen dir in Echtzeit, ob Versandlabels erfolgreich erstellt wurden, Pakete übergeben sind oder ob Probleme bei der Zustellung auftreten – und wirken direkt auf Conversion, Kundenzufriedenheit und Kundenservice-Kosten.

Im operativen E-Commerce-Alltag ist der Versandstatus kein Nice-to-have, sondern dein Frühwarnsystem für Umsatzrisiken, WISMO-Anfragen (Where is my order) und Eskalationen im Support. Wer Status richtig liest und interpretiert, erkennt Störungen schneller, reduziert Retouren und stabilisiert Lieferzusagen – besonders in Peak-Zeiten und bei komplexen Multi-Carrier-Setups.

Welche „JTL Status" sind in diesem Beitrag gemeint?

Der Begriff „JTL Status" wird in der Praxis für verschiedene Bereiche verwendet. Für diesen Beitrag konzentrieren wir uns auf folgende Statustypen:

• Versandstatus in JTL-Wawi und JTL-Shipping: Zeigt an, ob Versandlabels erstellt, Daten an den Dienstleister übermittelt und Übergaben oder Manifeste erfolgreich abgeschlossen wurden.
• Sendungsstatus (Track&Trace): Informiert über den aktuellen Zustand des Pakets beim Logistikdienstleister – etwa „Erstellt", „Unterwegs", „Zugestellt" oder „Problem".

Nicht im Fokus dieses Beitrags stehen Bestellstatus im Shop-Frontend oder tiefgreifende Infrastruktur- und Security-Themen. Diese werden nur am Rande erwähnt, wenn sie für die Versandprozesse relevant sind.

Wo du den JTL Status in der Praxis prüfst

Im Alltag gibt es zentrale Ansichten, die dir sofort zeigen, wie es um deine Versandprozesse steht. Diese Übersichten solltest du regelmäßig kontrollieren:

Versand- und Auslieferungsbereich in der Wawi

In JTL-Wawi findest du unter Versand > Übersicht Versandaufträge alle Aufträge, die bereit für den Versand sind. Hier siehst du, ob Labels erstellt wurden und ob die Übergabe an den Logistikdienstleister erfolgt ist. Bei Setups mit Packtisch-Umgebung oder Worker-Automatisierung wird hier auch angezeigt, ob Hintergrundprozesse korrekt arbeiten. Der Bereich Versand > Versandjournal zeigt dir die Historie aller Versandaktionen inklusive Fehlermeldungen und ermöglicht eine schnelle Fehlersuche.

Track&Trace-Übersicht mit Ordnerlogik

JTL-Track&Trace bietet die Möglichkeit, Sendungen in vier Ordner zu sortieren: Erstellt, Unterwegs, Zugestellt und Problem. Diese Ordnerlogik hilft dir, auf einen Blick Probleme zu identifizieren und gezielt zu reagieren. Filter nach Lieferadresse, Sendungsnummer oder Kundennummer beschleunigen die Suche nach einzelnen Aufträgen. Die Ansicht findest du unter Verkauf > Track&Trace.

JTL-Shipping Labels und Status

In JTL-Shipping siehst du unter Versand > Labels den aktuellen Status der Label-Erstellung. Hier wird angezeigt, ob Labels erfolgreich erzeugt wurden, ob Übermittlungsfehler aufgetreten sind oder ob Manifeste noch offen sind. Die Spalte Status zeigt dir konkret: „Erstellt", „Übermittelt", „Fehlgeschlagen" oder „Manifest offen".

Empfehlung: Eine feste Versand-Status-Routine

Richte dir eine tägliche Routine ein, um Versandstatus zu prüfen. Typische Fixpunkte:

• Morgens: Problem-Sendungen im Track&Trace + P0/P1-Status kontrollieren
• Vor Cut-off/Abholung: Label- und Übergabe-Backlog prüfen
• Abends: Offene Workflows und wartende Prozesse checken

Ein Dashboard mit relevanten Status-Informationen spart Zeit und gibt dir sofort Überblick über den Zustand deines Versandbetriebs.

Status-Mapping: So interpretierst du die wichtigsten Status korrekt

Die folgende Tabelle zeigt dir die häufigsten Status in JTL-Wawi und JTL-Shipping, ihre Bedeutung, mögliche Auswirkungen auf dein Geschäft und den nächsten sinnvollen Schritt. Diese Tabelle ist dein zentrales Werkzeug, um Status ohne Missverständnisse zu interpretieren:

Was Status NICHT bedeutet

Eine häufige Fehlannahme: „Übermittelt" bedeutet nicht „zugestellt". Der Status zeigt nur, dass die Daten an den Dienstleister übergeben wurden – das Paket kann noch im Lager sein oder auf dem Weg zum ersten Scan. Ebenso bedeutet „Label erstellt" nicht automatisch, dass das Paket den Versandprozess verlassen hat. Wer diese Unterscheidung nicht kennt, gibt Kunden falsche Informationen und riskiert Beschwerden.

Priorisierung: P0/P1/P2-Logik für schnelle Reaktion

Nicht jedes Problem ist gleich dringend. Mit einer klaren Priorisierung stellst du sicher, dass dein Team richtig reagiert und kritische Probleme sofort angeht:

P0 – Kritisch: Versand steht oder viele Aufträge betroffen

Beispiele: Keine Labels möglich, Übergabe oder Übermittlung dauerhaft fehlgeschlagen, Queue staut sich, alle Dienstleister betroffen. Cut-off wird gerissen, direkte Umsatzwirkung.

Wer reagiert: Sofort Operations + ggf. IT/Setup-Verantwortliche
Bis wann: Innerhalb von 10 Minuten erste Analyse, Workaround definieren
Info an Support/CS: Klare Lage kommunizieren, welche Versandarten betroffen sind, ETA für Lösung

P1 – Hoch: Teilmenge betroffen, Kundenwirkung innerhalb kurzer Zeit

Beispiele: Ein Dienstleister oder eine Versandart betroffen, viele Track&Trace-Probleme, Abholung erforderlich, wiederholte Zustellversuche. WISMO-/CS-Kosten steigen, mehr Stornos/Retouren möglich.

Wer reagiert: Operations + Support
Bis wann: Innerhalb von 60 Minuten Ursache eingrenzen, Kommunikation an Kunden vorbereiten
Info an Support/CS: Betroffene Aufträge identifizieren, Standardantworten bereitstellen

P2 – Beobachten: Meist temporär, geringe Auswirkung

Beispiele: Tracking noch ohne ersten Scan im normalen Zeitfenster, vereinzelte Info-Warnungen ohne Prozessstopp.

Wer reagiert: Operations im regulären Check
Bis wann: Im Rahmen der täglichen Status-Routine
Info an Support/CS: Nur bei Eskalation oder Überschreitung von Schwellenwerten

SLA- und Schwellenwerte: Wann gilt ein Status als „hängend"?

Ohne klare Schwellenwerte ist unklar, ab wann ein Status problematisch wird. Diese Defaults kannst du als Startpunkt nutzen und an deine Abholzeiten, Carrier und Peaks anpassen:

• Label/Übermittlung länger als 10 Minuten ohne Fortschritt: Intern prüfen (Queue/Job/Verbindung)
• Track&Trace „Erstellt" länger als 24 Stunden ohne ersten Scan: Übergabe/Abholung/Abfahrt prüfen (Peak ggf. 36–48 Stunden)
• „Problem"-Status länger als 6 Stunden ohne Aktion: Eskalation + Kundenkommunikation
• Manifest offen länger als 2 Stunden vor Cut-off: Manifest schließen, sonst Abholung verzögert

Diese Werte sind abhängig von deinem Setup – ein täglicher Abholrhythmus braucht andere Schwellen als ein Setup mit mehreren Abholungen pro Tag. Wichtig ist, dass du Schwellenwerte definierst, kommunizierst und konsequent anwendest.

Die häufigsten Ursachen – als Entscheidungsbaum

Wenn ein Problem auftritt, hilft dir dieser Schnelltest bei der Eingrenzung:

Betrifft es alle Versandarten/Dienstleister?

Dann ist die Ursache eher intern: Netzwerk, Credentials, Jobs oder Worker-Prozesse.

Betrifft es nur einen Dienstleister?

Dann ist die Ursache eher extern (API-Störung, Wartung beim Carrier) oder eine spezifische Konfiguration (Schnittstellen-Setup, Versandarten-Regeln).

Betrifft es nur einzelne Aufträge?

Dann liegt meist ein Daten-, Adress- oder Regelproblem vor (fehlerhafte PLZ, fehlende Telefonnummer, Gewichts-/Maßfehler).

Typische externe Ursachen:

• API oder Service nicht erreichbar (Prüfung: Status-Seite des Carriers)
• Wartungsfenster beim Dienstleister (oft angekündigt, selten dokumentiert in JTL)
• Verzögerungen im Transport (Wetter, Streik, Peak-Zeiten)

Typische interne Ursachen:

• Zugangsdaten oder Tokens abgelaufen (Prüfung: unter Admin > Versandarten > Einstellungen)
• Schnittstellen- oder Versandarten-Konfiguration inkonsistent (Prüfung: Versandarten > Carrier-Einstellungen)
• Pflichtdaten fehlen (Adresse, Land/PLZ-Format, Telefonnummer, Gewicht, Produktdaten) – sichtbar im Versandjournal als Fehlermeldung
• Hintergrundprozesse/Automatisierung arbeitet nicht ab (Worker, Jobs) – Prüfung: Admin > Worker > Status
• Netzwerk/DNS/Firewall/Proxy limitiert Kommunikation (selten in JTL sichtbar, eher Server-/IT-Check nötig)

Carrier-spezifische Root-Causes und konkrete Gegenmaßnahmen

Jeder Carrier hat typische Fehlermuster. Hier sind die häufigsten Ursachen und konkrete Lösungswege für DHL, DPD und Hermes:

DHL: Manifest/Abholung und API-Limits

Typische Fehlermeldung: „Manifest nicht geschlossen" oder „Tagesabschluss fehlt"
Ursache: DHL erwartet einen täglichen Manifest-Abschluss. Ohne diesen werden Pakete nicht abgeholt oder es erfolgt kein erster Scan.
Lösung: Unter Versand > Manifeste manuell Manifest schließen. Richte einen täglichen Workflow ein, der das Manifest automatisch vor Cut-off schließt. Prüfe in Admin > Workflows, ob ein entsprechender Trigger existiert.
API-Limit: DHL begrenzt die Anzahl der Label-Anfragen pro Zeiteinheit. Bei Überschreitung erscheint die Meldung „Too many requests".
Lösung: Batchverarbeitung einrichten oder Zeitabstände zwischen Label-Erstellung erhöhen. Bei wiederholten Limits Kontakt mit DHL-Geschäftskundenservice aufnehmen.

DPD: Adressformat und Benachrichtigungspflicht

Typische Fehlermeldung: „Telefonnummer fehlt" oder „Adresse ungültig"
Ursache: DPD erwartet bei bestimmten Services (z. B. Predict) zwingend eine Telefonnummer oder E-Mail-Adresse.
Lösung: Prüfe unter Verkauf > Aufträge > [Auftrag öffnen], ob Telefonnummer und E-Mail vorhanden sind. Richte eine Validierung ein, die vor Label-Erstellung prüft, ob Pflichtfelder gefüllt sind. Nutze JTL-Workflows, um fehlende Daten automatisch nachzufordern.
Adressformat: DPD lehnt Labels ab, wenn Hausnummer fehlt oder PLZ/Ort-Kombination ungültig ist.
Lösung: Adressvalidierung vor Versand aktivieren (z. B. via JTL-Erweiterungen oder Drittanbieter-Plugins).

Hermes: Gewichts- und Maßangaben

Typische Fehlermeldung: „Gewicht fehlt" oder „Maße ungültig"
Ursache: Hermes erwartet bei allen Sendungen Gewichts- und Maßangaben. Fehlen diese, wird das Label nicht erstellt.
Lösung: Prüfe im Artikel-Stamm (Artikel > [Artikel öffnen] > Reiter Versand), ob Gewicht und Maße hinterlegt sind. Richte Standard-Werte für Artikel ohne Angaben ein. Nutze JTL-Workflows, um fehlende Daten vor Versand zu ergänzen.
Maßüberschreitung: Hermes hat strikte Limits für Länge + Umfang (typisch: Länge max. 120 cm, Länge + 2x(Breite+Höhe) max. 300 cm).
Lösung: Bei Überschreitung alternative Versandart (z. B. Spedition) wählen oder Auftrag manuell prüfen.

Konkrete Log- und Fehlermeldungsbeispiele mit Gegenmaßnahmen

Im Versandjournal erscheinen konkrete Fehlermeldungen. Hier sind die häufigsten Beispiele und ihre Lösungen:

„Adresse ungültig: PLZ/Land-Kombination nicht erkannt"

Ursache: PLZ passt nicht zum Ländercode (z. B. deutsche PLZ mit Ländercode AT).
Lösung: Auftrag öffnen, Lieferadresse prüfen und korrigieren. Bei wiederkehrenden Fehlern Adressvalidierung im Shop-Checkout aktivieren.

„API-Timeout: Verbindung zum Carrier unterbrochen"

Ursache: Netzwerkproblem oder Carrier-API nicht erreichbar.
Lösung: Prüfe Status-Seite des Carriers. Wenn Carrier erreichbar ist: Netzwerk/Firewall/Proxy im eigenen Setup prüfen. Retry nach 10 Minuten.

„Gewicht fehlt oder ungültig"

Ursache: Artikel hat kein Gewicht oder Gewicht = 0.
Lösung: Artikel-Stamm öffnen (Artikel > [Artikel öffnen] > Reiter Versand), Gewicht eintragen. Richte Standard-Gewicht für neue Artikel ein.

„Manifest offen: Tagesabschluss fehlt"

Ursache: Manifest wurde nicht geschlossen, Carrier kann Pakete nicht abholen.
Lösung: Unter Versand > Manifeste manuell schließen. Workflow für automatischen Tagesabschluss einrichten.

„API-Key ungültig oder abgelaufen"

Ursache: Zugangsdaten sind veraltet oder Produktivmodus nicht aktiviert.
Lösung: Gehe zu Admin > Versandarten > [Carrier] > Einstellungen. Prüfe API-Key, Kundennummer, Abrechnungsnummer. Stelle sicher, dass Produktivmodus (nicht Testmodus) aktiv ist.

Troubleshooting-Playbook: Schritt für Schritt zum Fix

Dieses Playbook führt dich strukturiert durch die Fehlersuche und hilft dir, Probleme schnell zu beheben:

0) Impact klären

Wie viele Aufträge sind betroffen? Welche Versandarten? Seit wann tritt das Problem auf? Setze die Priorität (P0/P1/P2) und bewerte das Risiko: Cut-off, Lieferdatum, WISMO-Anfragen. Prüfe im Versandjournal und in Track&Trace > Problem, wie viele Aufträge in welchem Status hängen.

1) Extern vs. intern abgrenzen

Ist nur ein Dienstleister betroffen? Gibt es bekannte Störungen (Status-Seiten der Carrier prüfen)? Wenn ja, ist die Ursache wahrscheinlich extern. Wenn nein, weiter mit internem Check.

2) Datencheck bei betroffenen Aufträgen

Häufigster Quick Win: Prüfe Adressfelder, Hausnummer, PLZ/Land, Packstations-Logik, Artikel-/Gewichts-/Maßdaten, Versandart-Regeln. Oft fehlt eine Pflichtangabe oder ein Format ist inkonsistent. Öffne den Auftrag in der Wawi und prüfe unter Versand > Versanddetails, ob alle Pflichtfelder ausgefüllt sind.

3) Schnittstellencheck

Prüfe Credentials, Berechtigungen, Endpunkte, ggf. Zertifikate. Sind alle Zugangsdaten aktuell? Ist die Schnittstelle korrekt konfiguriert? Gehe zu Admin > Versandarten > [Carrier] > Einstellungen und prüfe API-Key, Kundennummer, Abrechnungsnummer und Test-/Produktivmodus.

4) Prozesscheck

Queue/Backlog kontrollieren: Was ist „wartend", was „fehlgeschlagen"? Gibt es Fehlerdetails in Logs? Prüfe im Versandjournal die Spalte Fehlermeldung für konkrete Hinweise (z. B. „PLZ ungültig", „Gewicht fehlt", „API-Timeout"). Retest/Retry nach Fix durchführen – kontrolliert, nicht blind mehrfach.

5) Eingrenzen

Mandant, Standort, Versandlager, Benutzerrechte, Arbeitsplatz – manchmal liegt das Problem nur in einem bestimmten Teil deines Setups. Teste mit einem anderen Benutzer oder an einem anderen Arbeitsplatz, ob das Problem reproduzierbar ist.

6) Stabilisieren

Monitoring und Alerts einrichten, klare Eskalationswege definieren, damit das Problem nicht erneut auftritt. Nutze JTL-Workflows (siehe nächster Abschnitt) oder externe Tools für E-Mail-Benachrichtigung bei Status „Fehlgeschlagen" im Versandjournal.

Handlungsrahmen: In 10 / 60 Minuten / heute noch

Du brauchst klare Zeitfenster, um zu wissen, was du wann tun kannst:

In 10 Minuten

• P0/P1/P2 setzen und Backlog quantifizieren (Anzahl betroffener Aufträge im Versandjournal)
• Betroffene Versandarten isolieren (Filter im Versandjournal nutzen)
• Stichproben: 3–5 problematische Aufträge → Datencheck (Adresse/Pflichtfelder)

In 60 Minuten

• Schnittstellen-Konfiguration/Credentials prüfen (siehe Troubleshooting-Playbook)
• Retry sauber durchführen (nur nach Fix, nicht blind)
• Workaround definieren (z. B. alternative Versandart, manuelle Labels)
• Support/CS mit klarer Lage versorgen: Was ist betroffen, was ist ETA

Heute noch

• Schwellenwerte definieren und dokumentieren (intern im Team kommunizieren)
• Workflow/Benachrichtigung einrichten (siehe nächster Abschnitt)
• Verantwortlichkeiten fixieren (wer reagiert bei P0/P1/P2)
• Regelmäßige Versand-Status-Routine als Standardprozess etablieren

Typische Problemfälle aus dem Versandalltag mit JTL-spezifischen Lösungen

Hier sind reale Szenarien mit konkreten Lösungspfaden:

Verbindungsstörung – Labels stoppen – Backlog wächst (P0)

Ursache: Schnittstelle/Netzwerk/Jobs nicht erreichbar oder gestört.
Sichtbar in JTL: Versandjournal zeigt „Fehlgeschlagen" oder „Timeout", Worker-Status zeigt „Nicht aktiv" unter Admin > Worker.
Lösung: Schnittstelle prüfen (Credentials, Endpunkt), Netzwerk/Jobs checken, Worker neu starten, Workaround definieren (z. B. manuelle Labels oder alternativer Dienstleister), Support informieren.

Einzelne Labels schlagen fehl (P1/P2)

Ursache: Meist Daten- oder Adressproblem (fehlende PLZ, falsche Hausnummer, fehlendes Gewicht).
Sichtbar in JTL: Versandjournal zeigt Fehlermeldung wie „Adresse ungültig", „Gewicht fehlt", „PLZ/Land-Kombination ungültig".
Lösung: Pflichtfelder/Regeln korrigieren (Auftrag öffnen, Adresse/Gewicht/Maße prüfen und anpassen), Retry durchführen.

Track&Trace „Erstellt" bleibt lange ohne Scan

Ursache: Übergabe/Abholung/Scan fehlt.
Sichtbar in JTL: Track&Trace Ordner „Erstellt", Sendung steht dort länger als Schwelle (24–48 Stunden).
Lösung: Schwelle prüfen (24–48 Stunden), Carrier-spezifische Prozesse beachten, ggf. Abholung manuell anstoßen oder bei Carrier nachfragen, ob Paket tatsächlich übergeben wurde.

Track&Trace „Problem: Abholung erforderlich"

Ursache: Paket wurde nicht zugestellt und muss in Filiale/Station abgeholt werden.
Sichtbar in JTL: Track&Trace Ordner „Problem", Detailinfo zeigt „Abholung erforderlich" oder „Benachrichtigungskarte hinterlassen".
Lösung: Prozess für automatische Kundenmail + interne Wiedervorlage einrichten (JTL-Workflow nutzen), Kunden proaktiv informieren (Mail mit Abholinfos und Frist).

Wiederholter Zustellversuch

Ursache: Kunde nicht angetroffen, Adresse unklar.
Sichtbar in JTL: Track&Trace zeigt mehrere Zustellversuche, Status „Problem" oder „Unterwegs" mit Detailinfo „Kunde nicht angetroffen".
Lösung: Kundenkontakt aufnehmen, Adresse validieren, Alternativzustellung (Nachbar, Packstation) anbieten.

Manifest bleibt offen – Abholung verzögert sich

Ursache: Manifest wurde nicht rechtzeitig geschlossen, Carrier kann Pakete nicht abholen.
Sichtbar in JTL: JTL-Shipping zeigt „Manifest offen" in der Spalte Status.
Lösung: Manifest manuell schließen unter Versand > Manifeste > Manifest schließen, Abholung manuell auslösen oder Carrier informieren.

Track&Trace als Support- und Prozesshebel

Track&Trace ist nicht nur Information für den Kunden, sondern auch ein operatives Werkzeug für dein Team:

Ordner- und Filterlogik

Bündle „Problem"-Sendungen in einem separaten Ordner, damit dein Team gezielt reagieren kann. Filter nach Problemtyp (Abholung, Zustellversuch, Beschädigung) beschleunigen die Bearbeitung. Nutze die Filteroptionen unter Verkauf > Track&Trace > Filter, um nach Status, Datum oder Carrier zu filtern.

Standardantworten und Kommunikationsbausteine

Erstelle für jeden Problemtyp kurze, sachliche, handlungsorientierte Textbausteine. Das spart Zeit und stellt sicher, dass Kunden konsistente Informationen erhalten. Beispiel: „Ihr Paket liegt zur Abholung bereit. Bitte holen Sie es innerhalb von 7 Tagen in der Filiale [Adresse] ab. Ihre Sendungsnummer: [Nummer]."

Proaktive Kommunikation reduziert WISMO

Wenn du Kunden informierst, bevor sie nachfragen, sinkt die Zahl der „Where is my order?"-Anfragen spürbar. Das entlastet deinen Support und verbessert die Kundenerfahrung.

Workflows und Automatisierung in JTL

Statusänderungen kannst du als Trigger nutzen, um Prozesse zu automatisieren. JTL-Workflows (unter Admin > Workflows) bieten hier umfangreiche Anpassungsoptionen. Das JTL Template und die zugehörigen Plugins sind so konzipiert, dass sie Nutzern umfangreiche Anpassungsoptionen bieten, ohne dass Programmierkenntnisse erforderlich sind, was sie für verschiedene Branchen geeignet macht. Diese Flexibilität erleichtert die Integration von Workflows in deine bestehenden Prozesse und ermöglicht es dir, individuelle Automatisierungen aufzubauen – unabhängig davon, ob du im E-Commerce, in der Logistik oder in anderen Bereichen tätig bist.

Beispiele für sinnvolle Workflow-Regeln in JTL:

• Bei Track&Trace „Problem": Workflow auslösen → E-Mail an Verantwortliche senden oder Ticket im internen System erstellen
• Bei „Abholung erforderlich": Workflow auslösen → automatische Kundenmail mit Abholinfos, Frist und Link zur Sendungsverfolgung
• Reminder bei hängenden Sendungen: Workflow auslösen, wenn Sendung länger als Schwelle in „Erstellt" oder „Unterwegs" ohne Änderung bleibt (z. B. nach 48 Stunden)

Konkrete Einrichtung in JTL-Workflows:

Gehe zu Admin > Workflows > Neuer Workflow. Wähle als Trigger z. B. „Statusänderung Sendung" und als Bedingung „Status = Problem". Als Aktion kannst du „E-Mail senden" wählen und Empfänger sowie Template definieren. So wird bei jedem Problem-Status automatisch eine Benachrichtigung versendet.

Leitplanken für Automatisierung:

• Keine Spam-Automation: Deduplizierung einbauen (z. B. nur 1 Mail pro Auftrag), Zeitfenster beachten (z. B. nicht nachts), Eskalationsstufen definieren
• Workflows nur an klare, robuste Trigger koppeln (nicht an zu viele, unklare Status)
• Workflows drosseln, damit Support nicht mit Mails/Tickets zugespammt wird

Monitoring als Operations-Dashboard

Ein tägliches Dashboard mit den wichtigsten KPIs gibt dir sofort Überblick und zeigt, ob Prozesse stabil laufen:

Tägliche Fixpunkte:

• Morgens: Problem-Sendungen (Track&Trace) + P0/P1 prüfen (unter Verkauf > Track&Trace > Problem)
• Vor Cut-off/Abholung: Label-/Übergabe-Backlog kontrollieren (unter Versand > Versandaufträge und Versandjournal)
• Abends: Workflows und wartende Prozesse checken (unter Admin > Workflows > Ausführungsprotokoll)

Eskalationszeiten definieren:

Status X länger als Y → Aktion Z (inkl. Verantwortlichkeit). Beispiel: „Problem"-Status länger als 6 Stunden → Eskalation an Teamleiter + Kundenkommunikation.

Bewährte Setups für Monitoring/Alerts:

Richte E-Mail-Benachrichtigungen ein, wenn kritische Status auftreten. In JTL-Workflows kannst du z. B. eine E-Mail an einen Teamleiter senden, wenn mehr als 10 Aufträge im Status „Fehlgeschlagen" sind. Für erweiterte Dashboards nutze JTL-eigene Reporting-Tools oder Business Intelligence-Lösungen wie Power BI oder Tableau, die per ODBC-Schnittstelle an JTL-Wawi angebunden werden können. Für Ladezeiten und bessere Nutzererfahrung im Shop lohnt sich außerdem eine gezielte JTL Shop Performance Optimierung.

KPIs und Messgrößen für Verbesserungen

Ohne Messung weißt du nicht, ob deine Maßnahmen wirken. Diese KPIs helfen dir, Versandprozesse zu bewerten und kontinuierlich zu verbessern:

Operative KPIs:

• Backlog: Anzahl wartender/fehlgeschlagener Label/Übergaben (täglich im Versandjournal prüfen)
• Durchschnittliche Zeit von „Label erstellt" → „erster Scan" (manuell oder via Export aus Track&Trace berechnen)
• Anteil Sendungen mit „Problem"-Status (Quote = Anzahl Problem-Sendungen / Gesamtsendungen)

Support-KPIs:

• WISMO-Anfragen pro 100 Bestellungen (aus Support-Ticket-System tracken)
• Zeit bis zur ersten Kundeninfo bei Verzögerung (intern messen, z. B. via Workflow-Protokoll)

Qualitätsindikatoren:

• Anteil Adress-/Datenfehler an Versandfehlern (Versandjournal-Export analysieren, Fehlermeldungen kategorisieren)
• Wiederholrate gleicher Fehlerursachen (zeigt fehlende Standardfixes oder Prozesslücken)

Checkliste zur Ursachenabgrenzung bei Setup-Problemen

Manchmal liegt die Ursache nicht im Versandprozess selbst, sondern in der Konfiguration deines Setups:

• Tritt das Problem nach einer Änderung auf (Update, neue Regel, neues Plugin, Template-Anpassung)?
• Betrifft es alle Bestellungen oder nur bestimmte Versandarten/Länder/Zahlarten?
• Gibt es Auffälligkeiten bei Workflows/Automationen (Trigger feuert zu oft/gar nicht)? Prüfe unter Admin > Workflows > Ausführungsprotokoll
• Sind Pflichtdaten/Formate konsistent (PLZ/Land/Telefon), oder werden sie durch Regeln/Plugins verändert?
• Test: eine Bestellung ohne Sonderlogik (Standard-Versandart, Standard-Regeln) → tritt der Fehler dort auch auf?

Do's und Don'ts für typische JTL-Setups

Do:

• Retries erst nach Fix: Sonst entsteht eine „Fehlerflut" und die Analyse wird schwieriger. Nutze im Versandjournal die Funktion „Versand wiederholen" erst nach Ursachenbehebung
• Workflow-Trigger drosseln: Zeitfenster/Dedupe einbauen, damit Support nicht zugespammt wird. In JTL-Workflows kannst du Bedingungen wie „nur 1x pro Auftrag" oder „nur zwischen 8-18 Uhr" setzen
• Bei Backlog/P0 zuerst prüfen, ob Worker/Jobs/Queue laufen und ob Fehlversuche in „hängenden" Zuständen bleiben (unter Admin > Worker > Status)

Don't:

• Status „Übermittelt" als „zugestellt" interpretieren (führt zu falschen Kundeninfos)
• Workflows an zu viele, unklare Status koppeln (lieber wenige, robuste Trigger mit klaren Bedingungen)
• Blind mehrfach Retry ohne Ursachenanalyse (verstärkt Probleme und erzeugt Spam beim Carrier)

Wo du typische Fehlermeldungen in JTL findest

Bei Versandproblemen zeigt JTL konkrete Fehlermeldungen an. Hier die wichtigsten Fundstellen:

• Versandjournal (Versand > Versandjournal): Spalte Fehlermeldung zeigt API-Fehler, Daten-/Formatfehler, Timeout-Meldungen
• JTL-Shipping Labels: Status-Spalte zeigt „Fehlgeschlagen" mit Fehlerdetail (z. B. „API-Key ungültig", „Gewicht fehlt")
• Worker-Status (Admin > Worker): Zeigt, ob Worker aktiv sind oder Fehler aufgetreten sind (z. B. „Verbindung fehlgeschlagen")
• Workflow-Ausführungsprotokoll (Admin > Workflows > Ausführungsprotokoll): Zeigt, ob Workflows erfolgreich ausgeführt wurden oder fehlgeschlagen sind

Konkrete Empfehlungen: Was du jetzt umsetzen solltest

Statt einer Optionsliste bekommst du hier klare Handlungsempfehlungen:

Standardisieren:

• Status-Mapping-Tabelle + P0/P1/P2-Definition als Team-Standard dokumentieren und kommunizieren (z. B. als Wiki-Seite oder PDF im internen Bereich)
• Schwellenwerte definieren und Eskalationswege festlegen (wer ist bei P0/P1/P2 zuständig, wann wird eskaliert)

Automatisieren:

• Workflows für „Problem"-Fälle einrichten (siehe Abschnitt „Workflows und Automatisierung in JTL")
• Reminder bei hängenden Status aktivieren (z. B. Workflow für „Erstellt" länger als 48 Stunden)

Messen:

• 3–5 KPIs monatlich tracken und daraus Maßnahmen ableiten (z. B. WISMO-Rate, Backlog-Anzahl, Problem-Quote)

1-Seiten-Checkliste: Wenn X, dann Y

Diese kompakte Entscheidungshilfe kannst du ausdrucken oder als Quick-Reference nutzen:

Fazit: Das setzt du heute um

Der JTL Status ist dein zentrales Werkzeug, um Versandprozesse zu steuern, Probleme frühzeitig zu erkennen und operative Kosten zu senken. Mit der richtigen Interpretation, klaren Schwellenwerten und einer strukturierten Troubleshooting-Routine stellst du sicher, dass dein Versand stabil läuft – auch in Peak-Zeiten.

Setze heute diese drei Schritte um:

1. Definiere deine Status-Schwellenwerte und P0/P1/P2-Logik (dokumentiere sie intern und kommuniziere sie im Team)
2. Richte eine tägliche Status-Routine ein (morgens Problem-Check unter Verkauf > Track&Trace > Problem, vor Cut-off Backlog-Check im Versandjournal)
3. Automatisiere einen ersten Workflow (z. B. Benachrichtigung bei „Problem"-Status unter Admin > Workflows)

Wenn du diese Grundlagen etablierst, reduzierst du WISMO-Anfragen, verbesserst die Kundenzufriedenheit und senkst die Kosten im Kundenservice – messbar und nachhaltig. Wenn du parallel die JTL Shop Performance Optimierung priorisierst, profitieren Conversion und Customer Experience zusätzlich.