Nový stav přidejte pouze pro obchodně významnou fázi, kterou tým potřebuje filtrovat, měřit nebo automatizovat. Ke každému stavu určete vstupní podmínky, povolené přechody, vlastníka, zprávu pro zákazníka a dopady na sklad či platbu. Technické detaily raději ukládejte jako metadata nebo poznámku.
Vlastní stavy objednávek ve WooCommerce pomáhají tehdy, když základní model nedokáže vyjádřit důležitý provozní krok, například kontrolu podkladů nebo výrobu na zakázku. Bez návrhu však rychle vznikne dlouhý seznam názvů, kterým každý rozumí jinak. Zaměstnanci mění stav ručně, automatizace se spouštějí vícekrát a zákazník dostává zprávu, která neodpovídá skutečnosti.
Stav má být přesnou informací o životním cyklu objednávky, nikoli poznámkou, úkolem ani náhradou za každý detail expedice. Před přidáním nového stavu je proto třeba definovat jeho význam, povolené vstupy a výstupy, odpovědnost i dopad na sklad a platbu. Článek ukazuje návrh stavového modelu a jeho bezpečné zavedení do administrace, integrací a reportů.
Rozlišujte stav, příznak, úkol a poznámku
Stav odpovídá na otázku, v jaké hlavní fázi se objednávka nachází. Příznak může označit prioritu nebo potřebu kontroly bez změny fáze. Úkol patří konkrétní osobě a má termín, zatímco poznámka zachycuje kontext. Pokud se všechny čtyři významy nacpou do stavů, seznam roste o kombinace jako zaplacená-prioritní-ověřit-adresu.
Vezměte vzorek objednávek a u každého požadovaného názvu se zeptejte, zda mění povolený další krok. Pokud ne, pravděpodobně jde o pole, tag nebo úkol. Nový stav má mít stabilní význam napříč dopravou i platbou. Dočasnou situaci jednoho produktu nevkládejte do globálního modelu všech objednávek.
Definujte stavový diagram a přechody
U každého stavu zapište, ze kterých stavů do něj lze vstoupit a kam lze pokračovat. U přechodu určete podmínky, například potvrzenou úhradu nebo dokončenou kontrolu. Zákaz nepovoleného přechodu chrání před přeskočením expedice, ale administrátor musí mít zdokumentovanou cestu k opravě chybně zařazené objednávky.
Myslete na návratové a koncové větve. Objednávka se může vrátit z výroby k doplnění údajů, být zrušena před plněním nebo částečně refundována po dokončení. Nesnažte se každou kombinaci vyjádřit jednou lineární řadou. Platební výsledek a stav zásilky mohou být samostatné údaje, které hlavní stav pouze shrnuje.
- Význam a vlastník stavu
- Povolené vstupní přechody
- Kontroly před opuštěním stavu
- Chování při opravě a návratu
Ošetřete automatizace a vedlejší účinky
Změna stavu může odeslat e-mail, snížit sklad, vytvořit doklad nebo zavolat externí API. Sepište všechny účinky včetně těch, které přidaly pluginy. Stejný stav nastavený podruhé nesmí bez kontroly znovu odeslat zásilku. Handler ověří, zda požadovaný výsledek již existuje, a uloží jeho identifikátor.
Odlište přechod provedený člověkem, platební bránou a integrací. Zdroj, čas a důvod zaznamenejte do bezpečného auditního záznamu. Pokud automatizace selže po částečném provedení, opakování musí pokračovat od ověřeného bodu. Samotné vrácení stavu zpět nemusí vrátit peníze ani obnovit sklad.
Navrhněte administraci a zákaznickou komunikaci
Názvy v administraci mají být krátké a akční, nesmí však slibovat víc, než stav dokazuje. Zobrazte vlastníka, stáří stavu a chybějící předpoklad přímo v seznamu objednávek. Filtry a hromadné akce povolte jen tam, kde je společná změna bezpečná. Barevné štítky jsou pomůckou, nikoli jediným nositelem významu.
Zákazník nepotřebuje vidět každý interní krok. Externí pojmenování může seskupit více interních stavů do srozumitelné informace, například „objednávku připravujeme“. E-mail posílejte pouze při události, která je pro zákazníka užitečná. Obsah zprávy, stránka účtu i odpověď podpory musí používat stejný výklad.
Migrujte a testujte na existujících objednávkách
Před nasazením připravte mapu starých a nových stavů. Stávající objednávky migrujte podle ověřitelných údajů, nikoli pouze podle data. Ve stagingu otestujte platby, dobírku, zrušení, refundaci, sklad, zákaznický účet, e-maily, export a integrace. Zvlášť vyzkoušejte opakovaný webhook a manuální zásah během automatického zpracování.
Po nasazení sledujte počty a stáří objednávek v každém stavu, nepovolené přechody a chyby vedlejších účinků. Dokumentujte významy u administračního rozhraní a vyškolte zastupujícího člověka. Pokud některý stav nikdo nepoužívá při rozhodování ani měření, odstraňte jej kontrolovanou migrací místo dalšího rozšiřování seznamu.
Časté dotazy
Kolik vlastních stavů objednávek je přiměřené?
Neexistuje univerzální číslo. Každý stav má reprezentovat odlišnou obchodní fázi s vlastním dalším krokem. Pokud název jen popisuje poznámku, prioritu nebo technickou chybu, použijte jiný typ údaje.
Může změna stavu automaticky odeslat e-mail?
Ano, ale pravidlo musí rozlišovat první platný přechod od opakovaného uložení. Zpráva má vycházet ze skutečně dokončené události a odeslání má být dohledatelné.
Stačí vrátit stav, a tím zrušit objednávku?
Ne vždy. Platba, sklad, dokumenty a zásilka mohou mít vlastní procesy. Před zpětným přechodem definujte, které účinky se mají kompenzovat a které vyžadují samostatnou potvrzenou akci.
Zdroje a další čtení
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.
