Shopware automatisieren: die zehn häufigsten Prozesse
Nicht der technisch interessanteste Prozess gehört zuerst automatisiert, sondern der mit der meisten Handarbeit je Woche. Zehn Kandidaten, mit dem jeweiligen Ansatzpunkt im Shop.
Automatisierung im Shop scheitert selten an der Technik. Sie scheitert daran, dass mit dem falschen Prozess angefangen wird — mit dem, der gut aussieht, statt mit dem, der Zeit frisst.
Diese zehn Kandidaten begegnen uns in fast jedem Shopware-Projekt. Die Reihenfolge ist keine Rangliste, sondern eine Liste zum Durchgehen: Wie viele Stunden pro Woche kostet jeder davon bei Ihnen?
Die zehn Prozesse
1. Bestellung ins Warenwirtschaftssystem
Der Klassiker. Auslöser ist ein Ereignis im Shop, Ziel ist ein externes System. Bordmittel: Flow Builder mit einem Webhook, oder eine Anbindung, die die Bestellungen abholt.
Die Stolperstelle ist nicht die Übergabe, sondern der Sonderfall: Gutscheine, Teillieferungen, nachträgliche Änderungen. Klären Sie diese Fälle, bevor Sie die Strecke bauen — sie kommen garantiert.
2. Rechnung erzeugen und versenden
Auslöser ist ein Statuswechsel, meistens „bezahlt". Zwei Fragen entscheiden über die Qualität: Bei welchem Status genau? Und was passiert bei Zahlarten, die erst später bezahlt werden?
Wir haben in einem Kundenprojekt erlebt, dass zwei Abläufe gleichzeitig Rechnungen erzeugt haben — einer bei Autorisierung, einer bei Zahlungseingang. Das Ergebnis waren doppelte Rechnungsnummern über Monate. Wer mehrere Abläufe hat, muss prüfen, ob sie sich gegenseitig ausschließen.
3. Lagerbestand zurückmelden
Wiederkehrend statt ereignisgesteuert: eine geplante Aufgabe holt Bestände und schreibt sie in den Shop. Wichtig ist hier die Frage nach der Wahrheit — welches System hat recht, wenn beide etwas anderes sagen?
4. Produktdaten aus dem PIM
Import oder Sync-API. Der Unterschied ist größer als gedacht: Ein Import arbeitet mit Dateien und Profilen, die Sync-API schreibt gezielt.
Vorsicht bei Varianten: Ein leeres Feld im Import stellt die Vererbung wieder her, statt den Wert zu leeren — wir haben das in Was eine Variante von ihrem Hauptprodukt erbt auseinandergenommen.
5. Kunden ins CRM
Auslöser Registrierung oder erste Bestellung. Hier ist die Doppelpflege der eigentliche Gegner: Wenn beide Systeme Kundendaten ändern dürfen, brauchen Sie eine Regel, welches gewinnt — sonst überschreiben sie sich gegenseitig.
6. Newsletter-Anmeldung an das Marketing-System
Double-Opt-in bleibt im Shop, die Übergabe geht danach. Wichtig ist, dass der Einwilligungsnachweis mitwandert und nicht nur die Adresse.
7. Retourenmeldung ins Ticketsystem
Statuswechsel erzeugt ein Ticket mit Bestell- und Kundendaten. Spart pro Retoure wenige Minuten — bei hoher Retourenquote ist das der Prozess mit dem höchsten Ertrag in dieser Liste.
8. Preispflege aus externen Quellen
Geplante Aufgabe plus Regelwerk. Der kritische Punkt sind die Leitplanken: Ein Preis, der um Faktor zehn abweicht, darf nicht automatisch live gehen. Bauen Sie eine Plausibilitätsgrenze ein, bevor Sie die Strecke scharf schalten.
9. Bewertungsanfrage nach Lieferung
Auslöser ist der Lieferstatus plus eine Frist. Einfach zu bauen, wirkt direkt auf die Bewertungszahl.
10. Tägliches Reporting
Eine geplante Aufgabe sammelt die Zahlen des Vortags und legt sie dort ab, wo sie gelesen werden — Tabelle, Chat, Mail. Kein spektakulärer Prozess, aber der, der am häufigsten dafür sorgt, dass Probleme früh auffallen.
Womit Sie anfangen
Es gibt eine einfache Rechnung, die die Reihenfolge klärt:
| Prozess | Vorgänge/Woche | Minuten je Vorgang | Stunden/Woche |
|---|---|---|---|
| (Ihre Zahlen) |
Füllen Sie diese Tabelle für alle zehn aus, und die Reihenfolge ergibt sich von selbst. Sie wird eine andere sein, als das Bauchgefühl vorgibt — in der Regel stehen Retouren und Rechnungsversand weiter oben als erwartet.
Was jede dieser Automationen braucht
Einen Auslöser, der eindeutig ist. „Bestellung abgeschlossen" ist kein Zustand, sondern eine Familie von Zuständen. Welche Auslöser der Flow Builder tatsächlich kennt, steht in Flow Builder: Auslöser, Aktionen, Grenzen.
Einen Rückweg. Was passiert, wenn das Zielsystem nicht antwortet? Ohne Antwort ist die Automation unfertig. Das Webhook-Protokoll von Shopware hält je Zustellversuch Status, Antwortzeit und Inhalt fest — die Grundlage dafür, Fehler überhaupt zu sehen. Siehe Webhooks in Shopware 6.
Einen laufenden Worker. Die häufigste Ursache für „die Automation tut nichts" ist banal: Die Aufgaben liegen in der Warteschlange und niemand arbeitet sie ab. Was Shopware im Hintergrund erledigt und was dafür laufen muss, steht in Was Shopware im Hintergrund erledigt.
Eine Meldung, wenn es klemmt. Eine Kette, die still stehenbleibt, ist schlimmer als keine — weil sich alle darauf verlassen.
Der häufigste Fehler in der Reihenfolge
Viele Projekte fangen mit Prozess 1 an, weil er der sichtbarste ist. Die Bestellübergabe ist aber auch die mit den meisten Sonderfällen. Wer dort startet, verbringt Wochen mit Randfällen, bevor die erste Stunde Handarbeit eingespart ist.
Fangen Sie mit einem an, der in zwei Tagen fertig ist und sofort wirkt — Bewertungsanfrage, Retourenmeldung, Reporting. Der Rest wird danach leichter, weil die Werkzeuge stehen und alle Beteiligten wissen, wie es aussieht, wenn es funktioniert.
Häufige Fragen
- Womit fängt man bei der Shopware-Automatisierung an?
- Mit dem Prozess, der die meiste wiederkehrende Handarbeit verursacht. Das ist fast nie der technisch spannendste — meistens sind es Bestellübergabe, Rechnungsversand oder Bestandsabgleich.
- Reichen die Bordmittel von Shopware?
- Für viele Fälle ja. Der Flow Builder reagiert auf Ereignisse im Shop, Webhooks melden nach außen, geplante Aufgaben erledigen Wiederkehrendes. Externe Werkzeuge lohnen sich, wenn mehrere Systeme beteiligt sind.
- Warum bleibt eine Automation stehen?
- Am häufigsten, weil kein Worker läuft, der die Warteschlange abarbeitet. Danach kommen abgelaufene Zugangsdaten und Zielsysteme, die nicht antworten.
- Wie merke ich, dass eine Automation nicht mehr läuft?
- Nur, wenn Sie es einbauen. Eine Kette ohne Fehlermeldung verstummt lautlos — die Meldung im Fehlerfall gehört zur Automation dazu, nicht als Nachtrag.