Nový stav pridajte iba pre obchodne významnú fázu, ktorú tím potrebuje filtrovať, merať alebo automatizovať. Ku každému stavu určte podmienky vstupu, povolené prechody, vlastníka, zákaznícku správu a účinky na sklad či platbu. Technický detail ukladajte radšej ako metadata alebo poznámku.
Vlastné stavy objednávok WooCommerce pomáhajú vtedy, keď základný model nevie vyjadriť dôležitý prevádzkový krok, napríklad kontrolu podkladov alebo výrobu na zákazku. Bez návrhu však rýchlo vznikne dlhý zoznam názvov, ktorým každý rozumie inak. Zamestnanci menia stav manuálne, automatizácie sa spúšťajú viackrát a zákazník dostáva správu, ktorá nezodpovedá skutočnosti.
Stav má byť presná informácia o životnom cykle objednávky, nie poznámka, úloha ani náhrada za každý detail expedície. Pred pridaním nového stavu preto treba definovať jeho význam, povolené vstupy a výstupy, zodpovednosť aj vplyv na sklad a platbu. Článok ukazuje návrh stavového modelu a jeho bezpečné zavedenie do administrácie, integrácií a reportov.
Rozlíšte stav, príznak, úlohu a poznámku
Stav odpovedá na otázku, v ktorej hlavnej fáze sa objednávka nachádza. Príznak môže označiť prioritu alebo potrebu kontroly bez zmeny fázy. Úloha patrí konkrétnej osobe a má termín, zatiaľ čo poznámka zachytáva kontext. Ak sa všetky štyri významy natlačia do stavov, zoznam rastie kombináciami ako zaplatená-prioritná-overiť-adresu.
Zoberte vzorku objednávok a pri každom požadovanom názve sa opýtajte, či mení dovolený ďalší krok. Ak nie, pravdepodobne ide o pole, tag alebo úlohu. Nový stav má mať stabilný význam naprieč dopravou a platbou. Dočasnú situáciu jedného produktu nevkladajte do globálneho modelu všetkých objednávok.
Definujte stavový diagram a prechody
Pre každý stav zapíšte, z ktorých stavov doň možno vstúpiť a kam sa dá pokračovať. Pri prechode určte podmienky, napríklad potvrdenú úhradu alebo dokončenú kontrolu. Zákaz nepovoleného prechodu chráni pred preskočením expedície, no administrátor musí mať zdokumentovanú cestu na opravu chybne zaradenej objednávky.
Myslite na návratové a koncové vetvy. Objednávka sa môže vrátiť z výroby na doplnenie údajov, byť zrušená pred plnením alebo čiastočne refundovaná po dokončení. Nesnažte sa každú kombináciu vyjadriť jedným lineárnym radom. Platobný výsledok a stav zásielky môžu byť samostatné údaje, ktoré hlavný stav iba sumarizuje.
- Význam a vlastník stavu
- Povolené vstupné prechody
- Kontroly pred opustením stavu
- Správanie pri oprave a návrate
Ošetrite automatizácie a vedľajšie účinky
Zmena stavu môže odoslať e-mail, znížiť sklad, vytvoriť dokument alebo zavolať externé API. Spíšte všetky účinky vrátane tých, ktoré pridali pluginy. Rovnaký stav nastavený druhýkrát nesmie bez kontroly znova odoslať zásielku. Handler overí, či požadovaný výsledok už existuje, a uloží jeho identifikátor.
Rozlíšte prechod vykonaný človekom, platobnou bránou a integráciou. Zdroj, čas a dôvod zaznamenajte do bezpečného auditného záznamu. Ak automatizácia zlyhá po čiastočnom vykonaní, opakovanie musí pokračovať od overeného bodu. Samotné vrátenie stavu dozadu nemusí vrátiť peniaze ani obnoviť sklad.
Navrhnite administráciu a zákaznícku komunikáciu
Názvy v administrácii majú byť krátke a akčné, no nesmú sľubovať viac než stav dokazuje. Zobrazte vlastníka, vek stavu a chýbajúci predpoklad priamo v zozname objednávok. Filtre a hromadné akcie povoľte iba tam, kde je spoločná zmena bezpečná. Farebné štítky sú pomoc, nie jediný nositeľ významu.
Zákazník nepotrebuje vidieť každý interný krok. Externé pomenovanie môže zoskupiť viac interných stavov do zrozumiteľnej informácie, napríklad objednávku pripravujeme. E-mail posielajte len pri udalosti, ktorá je pre zákazníka užitočná. Obsah správy, stránka účtu a odpoveď podpory musia používať rovnaký výklad.
Migrujte a testujte na existujúcich objednávkach
Pred nasadením pripravte mapu starých a nových stavov. Existujúce objednávky migrujte podľa overiteľných údajov, nie iba podľa dátumu. V stagingu otestujte platby, dobierku, zrušenie, refundáciu, sklad, zákaznícky účet, e-maily, export a integrácie. Osobitne skúste opakovaný webhook a manuálny zásah počas automatického spracovania.
Po nasadení sledujte počty a vek objednávok v každom stave, nepovolené prechody a chyby vedľajších účinkov. Dokumentujte významy pri administračnom rozhraní a vyškoľte zastupujúceho človeka. Ak niektorý stav nikto nepoužíva pri rozhodovaní ani meraní, odstráňte ho kontrolovanou migráciou namiesto ďalšieho rozširovania zoznamu.
Časté otázky
Koľko vlastných stavov objednávok je primerané?
Neexistuje univerzálne číslo. Každý stav má reprezentovať odlišnú obchodnú fázu s vlastným ďalším krokom. Ak názov iba opisuje poznámku, prioritu alebo technickú chybu, použite iný typ údaja.
Môže zmena stavu automaticky poslať e-mail?
Áno, ale pravidlo musí rozlišovať prvý platný prechod od opakovaného uloženia. Správa má vychádzať zo skutočne dokončenej udalosti a odoslanie má byť dohľadateľné.
Stačí vrátiť stav a tým zrušiť objednávku?
Nie vždy. Platba, sklad, dokumenty a zásielka môžu mať vlastné procesy. Pred spätným prechodom definujte, ktoré účinky sa majú kompenzovať a ktoré vyžadujú samostatnú potvrdenú akciu.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
