Fügen Sie einen neuen Status nur für eine geschäftlich relevante Phase hinzu, die das Team filtern, messen oder automatisieren muss. Legen Sie für jeden Status Eintrittsbedingungen, zulässige Übergänge, Verantwortliche, die Kundenmitteilung und die Auswirkungen auf Lagerbestand oder Zahlung fest. Technische Details speichern Sie besser als Metadaten oder Notiz.
Benutzerdefinierte Bestellstatus in WooCommerce sind hilfreich, wenn das Standardmodell einen wichtigen betrieblichen Schritt nicht abbilden kann, etwa die Prüfung von Unterlagen oder eine Auftragsfertigung. Ohne durchdachtes Konzept entsteht jedoch schnell eine lange Liste von Bezeichnungen, die jeder anders versteht. Mitarbeitende ändern Status manuell, Automatisierungen werden mehrfach ausgelöst und Kunden erhalten Nachrichten, die nicht der Realität entsprechen.
Ein Status soll eine präzise Information über den Lebenszyklus einer Bestellung sein, keine Notiz, keine Aufgabe und kein Ersatz für jedes Detail des Versands. Bevor ein neuer Status hinzugefügt wird, müssen daher seine Bedeutung, die zulässigen Ein- und Übergänge, die Zuständigkeit sowie die Auswirkungen auf Lagerbestand und Zahlung definiert werden. Der Artikel zeigt den Entwurf eines Statusmodells und dessen sichere Einführung in Administration, Integrationen und Reports.
Unterscheiden Sie Status, Flag, Aufgabe und Notiz
Der Status beantwortet die Frage, in welcher Hauptphase sich eine Bestellung befindet. Ein Kennzeichen kann eine Priorität oder einen Prüfbedarf markieren, ohne die Phase zu ändern. Eine Aufgabe gehört einer bestimmten Person und hat eine Frist, während eine Notiz den Kontext festhält. Werden alle vier Bedeutungen in Status gepresst, wächst die Liste um Kombinationen wie bezahlt-priorisiert-adresse-prüfen.
Nehmen Sie eine Stichprobe von Bestellungen und fragen Sie bei jeder gewünschten Bezeichnung, ob sie den zulässigen nächsten Schritt verändert. Falls nicht, handelt es sich wahrscheinlich um ein Feld, ein Tag oder eine Aufgabe. Ein neuer Status sollte über Versand und Zahlung hinweg eine stabile Bedeutung haben. Übernehmen Sie die vorübergehende Situation eines einzelnen Produkts nicht in das globale Modell aller Bestellungen.
Definieren Sie das Zustandsdiagramm und die Übergänge
Halten Sie für jeden Status fest, aus welchen Status er erreicht werden kann und wohin es weitergehen kann. Legen Sie für jeden Übergang Bedingungen fest, etwa eine bestätigte Zahlung oder eine abgeschlossene Prüfung. Das Verbot unzulässiger Übergänge schützt davor, den Versand zu überspringen, doch der Administrator muss einen dokumentierten Weg haben, um eine falsch eingeordnete Bestellung zu korrigieren.
Denken Sie an Rücksprung- und Endzweige. Eine Bestellung kann zur Ergänzung von Angaben aus der Produktion zurückgegeben, vor der Ausführung storniert oder nach dem Abschluss teilweise erstattet werden. Versuchen Sie nicht, jede Kombination in einer einzigen linearen Abfolge abzubilden. Das Zahlungsergebnis und der Sendungsstatus können eigenständige Daten sein, die der Hauptstatus lediglich zusammenfasst.
- Bedeutung und Verantwortlicher des Status
- Zulässige Eingangsübergänge
- Prüfungen vor dem Verlassen eines Zustands
- Verhalten bei Korrektur und Rücknahme
Behandeln Sie Automatisierungen und Nebeneffekte
Eine Statusänderung kann eine E-Mail versenden, den Lagerbestand reduzieren, ein Dokument erstellen oder eine externe API aufrufen. Erfassen Sie alle Auswirkungen, einschließlich derjenigen, die Plugins hinzugefügt haben. Wird derselbe Status ein zweites Mal gesetzt, darf ohne Prüfung keine erneute Sendung ausgelöst werden. Der Handler prüft, ob das gewünschte Ergebnis bereits existiert, und speichert dessen Kennung.
Unterscheiden Sie Übergänge, die von einem Menschen, einem Zahlungsgateway oder einer Integration ausgelöst werden. Halten Sie Quelle, Zeitpunkt und Grund in einem sicheren Audit-Eintrag fest. Scheitert eine Automatisierung nach teilweiser Ausführung, muss die Wiederholung an einem verifizierten Punkt fortsetzen. Das bloße Zurücksetzen des Status erstattet nicht unbedingt Geld zurück und stellt den Lagerbestand nicht automatisch wieder her.
Konzipieren Sie die Administration und die Kundenkommunikation
Bezeichnungen in der Administration sollten kurz und handlungsorientiert sein, dürfen aber nicht mehr versprechen, als der Zustand belegt. Zeigen Sie Verantwortlichen, Alter des Zustands und fehlende Voraussetzung direkt in der Bestellliste an. Erlauben Sie Filter und Massenaktionen nur dort, wo eine gemeinsame Änderung sicher ist. Farbige Labels sind eine Hilfe, nicht der einzige Bedeutungsträger.
Der Kunde muss nicht jeden internen Schritt sehen. Eine externe Bezeichnung kann mehrere interne Status zu einer verständlichen Information zusammenfassen, zum Beispiel „Wir bereiten Ihre Bestellung vor“. Versenden Sie E-Mails nur bei Ereignissen, die für den Kunden nützlich sind. Der Inhalt der Nachricht, die Kontoseite und die Antwort des Supports müssen dieselbe Darstellung verwenden.
Migrieren und testen Sie anhand bestehender Bestellungen
Bereiten Sie vor dem Deployment eine Zuordnung der alten und neuen Status vor. Migrieren Sie bestehende Bestellungen anhand überprüfbarer Daten, nicht nur nach dem Datum. Testen Sie im Staging Zahlungen, Nachnahme, Stornierung, Rückerstattung, Lagerbestand, Kundenkonto, E-Mails, Export und Integrationen. Probieren Sie gesondert einen wiederholten Webhook und einen manuellen Eingriff während der automatischen Verarbeitung aus.
Beobachten Sie nach dem Deployment Anzahl und Alter der Bestellungen in jedem Status, unzulässige Übergänge und Fehler bei Nebeneffekten. Dokumentieren Sie die Bedeutungen in der Administrationsoberfläche und schulen Sie eine Vertretung. Wenn ein Status weder für Entscheidungen noch für Messungen genutzt wird, entfernen Sie ihn per kontrollierter Migration, statt die Liste weiter zu erweitern.
Häufige Fragen
Wie viele eigene Bestellstatus sind angemessen?
Es gibt keine universelle Zahl. Jeder Status soll eine eigene Geschäftsphase mit einem eigenen nächsten Schritt darstellen. Wenn der Name nur eine Notiz, eine Priorität oder einen technischen Fehler beschreibt, verwenden Sie einen anderen Datentyp.
Kann eine Statusänderung automatisch eine E-Mail senden?
Ja, aber die Regel muss den ersten gültigen Statuswechsel von einem wiederholten Speichern unterscheiden. Die Nachricht sollte auf einem tatsächlich abgeschlossenen Ereignis beruhen, und der Versand sollte nachvollziehbar sein.
Reicht es, den Status zurückzusetzen, um die Bestellung zu stornieren?
Nicht immer. Zahlung, Lager, Dokumente und Sendung können eigene Prozesse haben. Legen Sie vor einem Rückwärtsübergang fest, welche Auswirkungen kompensiert werden sollen und welche eine separate, bestätigte Aktion erfordern.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
