Wie oft prüfst du von Hand, ob ein Kunde schon einmal bei dir bestellt hat, bevor du einen Neukunden anlegst? Wie oft druckst du eine Rechnung manuell aus, nur weil sie gerade fertig geworden ist? Genau solche Kleinigkeiten sind es, für die JTL-Workflows gebaut wurden — und die meisten Händler nutzen davon nur einen Bruchteil, obwohl die Werkzeuge längst in JTL-Wawi eingebaut sind.

Die Workflow-Engine arbeitet nach einem einfachen Prinzip: Ereignis löst aus, Bedingung prüft, Aktion passiert. Kein Coding, keine externe Software — alles direkt in JTL-Wawi unter Admin > JTL-Workflows. Wir zeigen dir anhand von fünf konkreten, offiziell dokumentierten Workflow-Beispielen, wo sich der Einstieg am meisten lohnt, und worauf du beim Aufbau achten musst, damit ein Workflow nicht mehr Chaos stiftet als er verhindert.

Das Baukastenprinzip: Ereignis, Bedingung, Aktion

Jeder JTL-Workflow besteht aus denselben drei Bausteinen. Das Ereignis ist der Auslöser — zum Beispiel „Kunde angelegt“, „Rechnung erstellt/festgeschrieben“ oder „Lieferschein erstellt“. Die Bedingung entscheidet, ob der Workflow wirklich greifen soll, etwa „E-Mail-Adresse ist nicht leer“ oder „Zahlungsart ist bezahlt = Falsch“. Die Aktion ist das, was am Ende tatsächlich passiert: eine E-Mail versenden, einen Wert setzen, ein Dokument drucken oder ein weiteres Workflow-Ereignis auslösen.

Diese letzte Möglichkeit — Workflows, die andere Workflows auslösen — ist der Punkt, an dem viele Händler erst richtig einsteigen. JTL selbst zeigt das am Beispiel eines automatisierten Mahnlaufs: Ein erster Workflow prüft nach 11 Tagen, ob eine Rechnung bezahlt wurde, und löst bei „Nein“ den eigentlichen Mahnlauf aus. Ein zweiter, unabhängiger Workflow stoppt die Kette nach 60 Tagen automatisch und informiert einen Mitarbeiter per Mail, damit nichts endlos weiterläuft. Drei einfache Bausteine, aber zusammengesetzt zu einem Prozess, der sonst wochenlange manuelle Kontrolle bräuchte.

Fünf Workflows, die sich in der Praxis sofort auszahlen

Doppelte Kunden prüfen. Beim Anlegen eines neuen Kunden vergleicht der Workflow automatisch E-Mail-Adresse, Telefonnummer oder die Kombination aus Nachname, Postleitzahl und Ort mit bestehenden Datensätzen. Findet er eine Übereinstimmung, bekommt ein Mitarbeiter automatisch eine E-Mail mit beiden Kundennummern. Gerade wenn Bestandskunden ohne Login über den Shop oder über Marktplätze bestellen, verhindert das dauerhaft doppelte, unsauber gepflegte Kundendaten.

Zahlungserinnerung bei Vorkasse. Der Workflow prüft in einem festen Intervall — im offiziellen Beispiel alle fünf Tage —, ob eine Vorkasse-Zahlung eingegangen ist. Ist sie das nicht, verschickt er automatisch eine Erinnerungsmail an den Kunden und setzt sich selbst wieder in die Warteschlange für die nächste Prüfung. Für Händler mit hohem Vorkasse-Anteil spart das täglich manuelles Nachhaken.

Rechnungsdruck automatisieren. Sobald eine Rechnung erstellt bzw. festgeschrieben wird, druckt der Workflow sie automatisch nach einem hinterlegten Vorlagenset — inklusive der Möglichkeit, bestimmte Plattformen gezielt auszuschließen. Im offiziellen Beispiel etwa alle Rechnungen außer denen von Amazon, weil dort ohnehin andere Belegprozesse greifen.

DHL-Leitcodierung prüfen. Nach dem Import der DHL-Leitcodierungsdatei kann ein Workflow bei jedem neuen Auftrag automatisch prüfen, ob die Lieferadresse leitcodierbar ist. Bei fehlender Übereinstimmung wird der Auftrag automatisch zurückgehalten und ein Mitarbeiter informiert — bevor ein Paket mit falscher oder unvollständiger Adresse überhaupt das Lager verlässt. Wichtig zu wissen: Das funktioniert nur für deutsche Adressen und nicht für Packstationen.

Versandkostenflatrate verwalten. Kunden, die eine Versandkostenflatrate erwerben, wechseln über einen Workflow automatisch in eine eigene Kundengruppe mit passender Versandart — ganz ohne manuelles Umstellen durch einen Mitarbeiter. Die Vorbereitung (neue Kundengruppe, neue Versandarten in JTL-Shop) macht man einmalig, danach läuft die Zuordnung automatisch.

Worauf du beim Aufbau eigener Workflows achten musst

Der größte Fehler ist, einen Workflow live zu schalten, ohne ihn vorher zu testen. JTL-Wawi bietet dafür die Funktion „Workflow testen“ direkt im Editor — nutze sie immer, bevor du speicherst, und löse das Ereignis nach dem Speichern einmal manuell aus, um den kompletten Ablauf am echten Fall zu prüfen.

Zweitens: Workflows, die sich selbst erneut in die Warteschlange setzen (wie die Zahlungserinnerung), brauchen zwingend eine Abbruchbedingung. Ohne die Mahnlaufstopp-Logik aus dem Beispiel oben würde ein Workflow theoretisch endlos weiterlaufen und im schlimmsten Fall Kunden wiederholt anschreiben.

Drittens lohnt sich ein Blick auf die „Erweiterten Eigenschaften“ mit eigenen DotLiquid-Skripten, sobald Standard-Bedingungen nicht reichen — etwa um Gesamtsummen individuell zu berechnen, ohne Versandkosten oder Gutscheine einzurechnen. Das ist kein Programmieren im klassischen Sinn, aber ein Einstieg, den man sich in Ruhe anschauen sollte, bevor man live geht.

Ortsnamen und Adressprüfung: ein Workflow, der Retouren vorbeugt

Ein weiteres offiziell dokumentiertes Beispiel zeigt, wie sich Workflows auch für Datenqualität statt nur für Automatisierung nutzen lassen: Enthält die Lieferadresse eines Auftrags Zusätze wie „OT Ortsteil“, die vom Versanddienstleister abgelehnt werden, erkennt ein Workflow das per RegEx-Prüfung automatisch und entfernt oder markiert den Zusatz. Ein zweiter, davon abhängiger Workflow kann den betroffenen Auftrag zusätzlich farblich markieren und mit einem Rückhaltegrund versehen, sodass er nicht versehentlich unbearbeitet durchläuft. Der Aufwand für die Einrichtung ist überschaubar — zwei zusammenhängende Workflows, die aufeinander aufbauen — der Effekt aber spürbar, weil fehlerhafte Adressen sonst häufig erst als Rücksendung oder Nachfrage beim Kunden auffallen.

Workflows richtig benennen und dokumentieren

Ein Punkt, der in keiner Anleitung besonders betont wird, aber in der Praxis viel Zeit spart: Workflows sollten von Anfang an einen präzisen, sprechenden Namen bekommen, der die Aktion mit einschließt — nicht „Workflow 1“, sondern zum Beispiel „Prüfung_Doppelter Kunde“ oder „Erinnerung Vorkasse (wiederholend)“. Sobald ein Unternehmen zehn, zwanzig oder mehr Workflows aktiv hat, wird die Übersicht in der Workflow-Verwaltung schnell unübersichtlich, wenn Namen nichts über ihre Funktion verraten. Das gilt besonders für Ketten aus mehreren Workflows, die aufeinander aufbauen — wie beim Mahnlauf oder der Leitcodierungs-Prüfung — wo auf den ersten Blick erkennbar sein muss, welcher Workflow welchen anderen auslöst.

Ebenfalls praktisch: In der Workflow-Verwaltung lässt sich einschränken, in welchen Anwendungen ein Workflow überhaupt aktiv ist — etwa nur innerhalb von JTL-Wawi, nicht im Shop-Backend. Das verhindert, dass ein Workflow an Stellen auslöst, für die er nie gedacht war, und ist besonders bei sensiblen Aktionen wie automatischem E-Mail-Versand eine sinnvolle zusätzliche Absicherung.

Fazit

JTL-Workflows sind keine Insider-Funktion für Power-User, sondern ein Werkzeug, das in jeder JTL-Wawi-Installation bereits vorhanden ist und in den meisten Fällen ungenutzt bleibt. Schon die fünf Beispiele oben — doppelte Kunden, Zahlungserinnerung, Rechnungsdruck, Leitcodierung, Versandkostenflatrate — decken Prozesse ab, die in fast jedem Multichannel-Shop täglich manuell anfallen. Wenn du nicht weißt, wo du anfangen sollst: Schau dir eine Woche lang an, welche Handgriffe sich bei dir wiederholen — genau dort setzt der erste sinnvolle Workflow an. Wir unterstützen dich gerne beim Aufbau, wenn du nicht alleine loslegen willst.