Když totéž zboží prodáváte na více e-shopech, každá administrace si vede vlastní stav a o prodeji na té druhé se nedozví. Řešení jsou tři: rozdělit zásobu pevně mezi e-shopy (jednoduché, ale prodáte méně), synchronizovat stavy nadřazeným systémem (nejspolehlivější), nebo držet rezervu a rozdíly řešit ručně (funguje do několika desítek objednávek měsíčně). Rozhodující je, zda synchronizace běží v reálném čase, nebo v dávkách — při dávkovém přenosu vzniká okno, ve kterém lze prodat zboží, které už není.
Proč se stavy vůbec rozcházejí
Každý e-shop je samostatný systém s vlastní databází. Když zákazník koupí kus na slovenské doméně, česká administrace o tom neví — pokud jí to někdo neřekne. Dokud prodáváte na jedné doméně, není co řešit. U druhé domény se objeví první rozdíl, u čtvrté je to denní záležitost.
Rozdíl se neprojeví hned. Projeví se až tehdy, když zákazník objedná poslední kus na doméně, která o jeho prodeji nevěděla — tedy v okamžiku, kdy už mu musíte napsat, že objednávku stornujete. To je nejdražší moment celého řetězce: zaplatili jste za návštěvu, za konverzi, a místo tržby máte nespokojeného zákazníka.
Možnost 1: rozdělit zásobu pevně
Nejjednodušší řešení. Ze sta kusů dáte čtyřicet na slovenskou doménu, třicet na českou, dvacet na polskou a deset na mezinárodní. Každý e-shop má vlastní zásobu a nikdy se nepotkají.
Nevýhoda je zřejmá: když se slovenská zásoba doprodá a polská leží, přijdete o prodeje na Slovensku, přestože zboží máte. U pomaluobrátkového zboží je to přijatelné. U sezónního nebo rychloobrátkového to znamená citelnou ztrátu.
Možnost 2: nadřazený systém, který stavy sladí
Nad e-shopy stojí systém, který drží jeden skutečný stav. Prodej kdekoli sníží dostupnost všude. Zboží tak může být nabízeno v plném množství na všech doménách najednou.
U tohoto řešení jsou podstatné dvě věci, na které se vyplatí ptát dřív než na cenu: jak rychle se změna přenese a co se stane při výpadku spojení. Přenos v dávkách — například každých patnáct minut — nechává okno, ve kterém lze prodat to, co už není. Přenos vyvolaný událostí z e-shopu (webhook) toto okno téměř uzavře.
Druhá věc je původ pohybu. Systém, který zaznamená jen „stav se změnil ze 40 na 39", vám u rozdílu nepomůže. Systém, který zaznamená „−1 prodej na CZ doméně, objednávka #4718", umožní rozdíl dohledat za minutu.
Možnost 3: rezerva a ruční kontrola
Držíte rezervu — například nikdy nepustíte poslední tři kusy do prodeje — a rozdíly řešíte ručně. Funguje to u desítek objednávek měsíčně a nulových nákladů na nástroj.
Přestane to fungovat tehdy, když ruční kontrola zabere víc času, než kolik stojí nástroj. Hranici si umíte spočítat: kolik minut denně trávíte kontrolou stavů, vynásobte hodinovou sazbou.
Na co se ptát při výběru nástroje
- Přenáší se změna okamžitě (webhook), nebo v dávkách? Pokud v dávkách, jak často?
- Zaznamenává se PŮVOD pohybu, nebo jen nová hodnota?
- Co se stane, když spojení s jedním e-shopem vypadne — zastaví se všechno, nebo jen ten jeden?
- Lze nastavit rezervu, která se nikdy nepustí do prodeje?
- Vidím, které produkty se rozešly nejvíc — tedy kde mám skutečný problém?
- Podporuje varianty produktu, nebo jen hlavní produkt?
Jak to řeší MitoOps
MitoOps drží jeden stav pro všechny napojené e-shopy a aktualizuje ho z událostí e-shopu, ne z nočního importu. Historie pohybů zaznamenává původ každé změny — prodej, ruční úprava, nebo automatické sladění mezi e-shopy — takže lze rozdíl dohledat i zpětně.
Zapojený je Shoptet i WooCommerce; Shopify a PrestaShop jsou rozpracované. Modul sladění skladů běží v ostrém provozu na čtyřech e-shopech ve čtyřech zemích.