Integrace v e-commerce: jak zjednodušit klíčové procesy.

Každý e-shop začíná jednoduše. Jeden e-shop, jedna platební brána, jeden dopravce, jedna osoba obsluhující objednávky. Systémy jsou oddělené, ale při několika desítkách objednávek měsíčně stačí disciplína a pár záložek v prohlížeči.

Pak přijde růst. Druhý prodejní kanál, třetí dopravce, ERP systém, fakturační program, nástroj pro email marketing, fulfillmentová platforma. Každý systém řeší jeden konkrétní problém. Každý vyžaduje samostatné přihlášení, samostatnou aktualizaci dat, samostatnou obsluhu chyb.

A najednou majitel e-shopu zjistí, že má deset systémů, které spolu nemluví — a pět lidí trávících půl dne přepisováním dat z jednoho do druhého.

To je bod, kdy integrace přestávají být „příjemným vylepšením" a stávají se existenční nutností. Problém je, že většina majitelů e-shopů přistupuje k integraci systémů reaktivně a bez plánu — propojují systémy jeden k jednomu, plugin po pluginu, skript po skriptu. Výsledkem je to, co inženýři nazývají „spaghetti integration" — spletenice propojení, která funguje do té doby, než se změní jedno API, neaktualizuje jeden systém nebo nepřibude jeden nový prodejní kanál.

Tento článek je o něčem jiném: o tom, jak přemýšlet o architektuře integrací ještě před tím, než začnete propojovat, které procesy integrovat jako první, a jak vybudovat ekosystém systémů, který je rozšiřitelný, ne křehký.

Proč jsou integrace v e-commerce těžší, než vypadají

Problém „bod-k-bodu" — jak 5 systémů generuje 20 propojení

Představte si, že máte pět systémů: e-shop WooCommerce, Base.com (OMS), účetní systém (ABRA Flexi), Brevo (email marketing) a velkoobchod dodavatele. Pokud je propojujete přímo — každý s každým — potřebujete:

• E-shop ↔ Base.com
• E-shop ↔ Brevo
• Base.com ↔ ABRA Flexi
• Base.com ↔ velkoobchod
• ABRA Flexi ↔ Brevo

To je pět propojení pro pět systémů. Při deseti systémech roste počet potenciálních propojení na 45. Při patnácti — na 105.

Při integraci bod-k-bodu každý nový systém často vyžaduje propojení s několika stávajícími. Počet integrací roste exponenciálně spolu s rozrůstáním technologického stacku a proměňuje zvládnutelné prostředí v „integrační spaghetti".

Každé propojení je samostatný kód, samostatná konfigurace, samostatný bod selhání. Když velkoobchod změní formát svého API — je nutné aktualizovat všechna propojení s velkoobchodem. Když PrestaShop vydá novou verzi — každá integrace s e-shopem vyžaduje ověření.

Skutečné náklady špatné architektury integrací

Firmy průměrně využívají 897 aplikací, přičemž pouze 2 % jich integrovala více než polovinu. Integrační mezera má konkrétní příčiny: každý nový systém násobí počet propojení. Co bylo zvládnutelné při 3 systémech, se stává nekontrolovatelným při 10. Když jeden systém změní API, všechna připojená rozhraní se lámou současně.

Prakticky: e-shop s pěti neintegrovanými nebo špatně integrovanými systémy ztrácí:

• Čas — pracovníci přepisují data mezi systémy
• Peníze — chyby způsobené neaktuálními daty (overselling, chybné faktury, záměny zásilek) stojí přímo
• Škálovatelnost — každý nový kanál, každý nový systém je nutné připojit ke všem stávajícím
• Odolnost vůči změnám — jedno přerušené propojení může zastavit celý tok objednávek

Architektura, která funguje: hub-and-spoke místo spaghetti

Koncept centrálního hubu

Řešením není „integrovat méně". Řešením je změna architektury z propojení bod-k-bodu na model hub-and-spoke — kde jeden centrální systém (hub) řídí tok dat mezi všemi ostatními.

V e-commerce je takovým hubem nejčastěji:

Varianta A — OMS jako hub (Base.com): Všechny systémy komunikují s Base.com. E-shop posílá objednávky do Base.com. Base.com posílá data do ERP, k dopravcům, do emailového systému. ERP vrací skladové zásoby do Base.com. Base.com aktualizuje e-shop.

E-shop WooCommerce ──┐
Allegro.cz           ├──► Base.com ──► ERP (ABRA Flexi)
Allegro.sk           ┘         └──► Dopravci (Zásilkovna, PPL)
                               └──► Brevo (email)
                               └──► Velkoobchod

Místo N×(N-1)/2 propojení máte N propojení. Každý systém rozumí pouze jednomu rozhraní: Base.com.

Varianta B — Middleware/iPaaS jako hub (n8n, Make): Pro složitější ekosystémy nebo když Base.com nepokrývá všechny potřeby — middleware plní roli „překladatele" mezi systémy. n8n nebo Make.com fungují jako centrální automatizační vrstva: naslouchají událostem z každého systému a odpovídajícím způsobem reagují.

Událost: nová objednávka ve WooCommerce
    ↓
n8n (middleware)
    ├── Vytvoř kontakt v Brevo + tag "nový zákazník"
    ├── Pošli data objednávky do ERP
    ├── Aktualizuj stav skladu u velkoobchodu
    └── Odešli potvrzení přes Base.com

Kdy zvolit kterou variantu

Pět procesů, které integrace zjednodušuje nejvíce

Proces 1: Tok objednávky od podání po odeslání

Toto je operační jádro každého e-shopu — a nejčastější místo, kde vše padá při absenci integrací.

Jak vypadá bez integrace: Objednávka přijde z Allegro.cz → ruční přepis do systému dopravce → ruční aktualizace stavu v e-shopu → ruční vystavení faktury → ruční email zákazníkovi s číslem zásilky. Při 200 objednávkách měsíčně je to 40–60 pracovních hodin.

Jak vypadá se zintegrovaným ekosystémem: Objednávka z Allegro.cz se objeví v Base.com → automatická akce vygeneruje zásilku a štítek → ERP vystaví fakturu → Brevo pošle email se sledovacím číslem → e-shop aktualizuje stav objednávky. Čas: několik sekund na automatiku, nulová lidská intervence.

Klíčové technické úskalí: mapování stavů objednávek. Každá platforma má vlastní stavy. Allegro.cz má „READY_FOR_PROCESSING", WooCommerce má „processing", Base.com má vlastní sadu. Pokud nenakonfigurujete mapování správně — automatické akce se nespustí ve správný okamžik.

Pravidlo: než spustíte jakoukoliv automatizaci — nakreslete na papír celý tok objednávky z každého prodejního kanálu a identifikujte každý stav po cestě. Mapování je nudné, ale klíčové.

Proces 2: Synchronizace skladových zásob v reálném čase

Druhý nejdůležitější proces — a druhý nejčastější zdroj problémů. Overselling (prodej zboží, které není na skladě) je jedním z hlavních důvodů negativního hodnocení prodejce na marketplace.

Tři vrstvy synchronizace, o nichž málokdo přemýšlí:

Vrstva 1 — Uvnitř e-shopu: Pokud máte více variant produktu (barva, velikost), každá varianta má vlastní SKU a vlastní stav. Synchronizace musí fungovat na úrovni varianty, ne produktu.

Vrstva 2 — Mezi kanály: Jeden produkt, více kanálů (e-shop + Allegro.cz + Allegro.sk). Prodej na jednom kanálu musí v reálném čase aktualizovat dostupnost na ostatních. Zpoždění i 5 minut může při populárním produktu způsobit overselling.

Vrstva 3 — Mezi skladem a kanály: Pokud provozujete vlastní sklad řízený ERP nebo WMS — ERP je „zdrojem pravdy" o zásobách. Tok by měl vypadat takto: příjem zboží do skladu v ERP → aktualizace v Base.com → aktualizace na všech prodejních kanálech. Ne naopak.

Bezpečnostní buffer: Vždy nastavuji u zákazníků bezpečnostní rezervu. Pokud je v ERP 10 kusů — prodejní kanály zobrazují 8. Buffer chrání před situací, kdy je zboží rezervováno zároveň z více kanálů.

Proces 3: Automatizace dokumentů — faktury, dodací listy, dobropisy

Fakturace je oblast, kde e-shopy ztrácejí nepřiměřeně mnoho času a kde chyby mají reálné daňové důsledky.

Integrovaný tok faktur: Data z objednávky (adresa, IČO/DIČ, produkty, hodnoty) automaticky putují do ERP/fakturačního programu. Faktura se generuje automaticky po změně stavu objednávky na „zaplaceno". PDF dorazí zákazníkovi e-mailem a do archivu. Položky faktury jsou automaticky mapovány na správné sazby DPH podle kategorie produktu.

Kritické mapování: Položky objednávky v e-shopu musí být namapovány na správné sazby DPH. Pokud prodáváte produkty s 21 %, 15 % a 10 % DPH — každá kategorie produktu musí mít přiřazenou správnou sazbu. Chyba v mapování znamená chybnou sazbu DPH na faktuře a potenciální nutnost hromadně vystavovat opravné doklady.

Specifika pro Shoptet: Shoptet nemá nativní integraci s většinou česky localizovaných účetních systémů (Pohoda, ABRA Flexi, Money S3). Propojení je možné přes Make.com (trigger: nová objednávka v Shoptetu → akce: vytvoř fakturu v iDokladu nebo pošli data do Pohody přes XML import). Tato vrstva middleware je pro české e-shopy na Shoptetu klíčová.

Proces 4: Obsluha vrácení zboží a reklamací (reverzní logistika)

Reverzní logistika je nejhůře integrovaný proces ve většině e-shopů. Zatímco tok objednávky „dopředu" bývá dobře automatizovaný, vrácení zboží je často skok v čase: zákazník napíše email, pracovník odpoví, zákazník tiskne štítek (pokud ho dostal), balík se vrátí, někdo ho zkontroluje, někdo vystaví opravný daňový doklad, někdo provede refundaci — každý krok ručně.

Přitom rozsah vrácení je závažný: téměř každý třetí nákup v e-commerce končí vrácením. Více než 40 % nakupujících záměrně objednává více velikostí nebo variant s úmyslem vrátit alespoň jednu. 67 % spotřebitelů zkontroluje podmínky vrácení zboží před dokončením nákupu.

Co znamená integrovaná obsluha vrácení: Zákazník přejde na web e-shopu → vyplní formulář pro vrácení (číslo objednávky, důvod, vybraný produkt) → systém automaticky vytvoří RMA (Return Merchandise Authorization) → vygeneruje návratový štítek → pošle zákazníkovi instrukce emailem → po přijetí vrácení sklad naskenuje zboží → systém automaticky vystaví opravný doklad a iniciuje refundaci.

Integrace vrácení s ERP: Klíčové je, aby vrácení neskončilo pouze vystavením opravného dokladu. Vrácené zboží musí vrátit do skladových zásob (pokud je plnohodnotné) nebo putovat na samostatnou lokaci „zboží k ověření". Bez integrace s WMS/ERP je stav skladu po vrácení neaktuální.

EU direktiva 2023/2673: Od 19. června 2026 musí e-shopy v EU umožnit zákazníkům vrácení zboží jedním kliknutím bez nutnosti psát emaily nebo hledat telefon. Pro WooCommerce existuje modul wc-one-click-return, pro PrestaShop ps_oneclickreturn — oba vyvíjím a udržuji. Toto není jen otázka komfortu, ale zákonná povinnost.

Proces 5: Tok produktových dat — od dodavatele do všech kanálů

Produktová data jsou jedním z největších úzkých hrdel při škálování.

Integrovaný tok produktových dat:

Velkoobchod (XML feed/API)
    ↓
PIM nebo Base.com (centrální repozitář produktových dat)
    ├── E-shop WooCommerce/PrestaShop/Shoptet (ceny, zásoby, popisy)
    ├── Allegro.cz (nabídky, ceny, zásoby)
    ├── Allegro.sk (nabídky, ceny, zásoby)
    └── ERP (kartotéka produktů, nákupní ceny)

Integrace PIM systému s ERP zajišťuje různým týmům — marketingu a obchodu — přístup ke klíčovým produktovým datům, což umožňuje efektivní správu objednávek na všech e-commerce platformách.

Tři úrovně synchronizace produktových dat:

Úroveň 1 — Zásoby a ceny (častá aktualizace, priorita): Zásoby a ceny se musí synchronizovat co nejčastěji — ideálně v reálném čase. Nákupní cena vzrostla o 15 % → cenové pravidlo přepočítá marži → prodejní cena se automaticky aktualizuje na všech kanálech.

Úroveň 2 — Základní data (řídká aktualizace): Názvy, popisy, kategorie, technické parametry. Synchronizuje se při přidání nového produktu nebo jeho úpravě.

Úroveň 3 — Marketingový obsah (jednorázově + korekce): Fotografie, marketingové popisy, názvy optimalizované pro SEO každého kanálu. To vyžaduje redakční práci — a to je jediná vrstva, kterou byste neměli plně automatizovat. Popis optimalizovaný pro Allegro.cz se liší od popisu pro e-shop a od popisu pro Amazon.

Cenová pravidla jako samostatný modul: Nákupní cena z velkoobchodu + marže + provize marketplace + pravidlo Repriceru = konečná cena. To by měla být konfigurace, ne ruční kalkulace. Base.com umožňuje definovat cenová pravidla per kanál — Allegro.cz může mít jinou marži než e-shop, Allegro.sk jinou než Allegro.cz.

Jak integrovat — metodika pro e-shopy, které nechtějí zastavit provoz na týden

Pravidlo „vždy jeden zdroj pravdy"

Každý typ dat by měl mít přesně jeden systém, který je jeho „vlastníkem":

• Skladové zásoby → ERP nebo WMS (ne e-shop)
• Produktová data → PIM nebo Base.com (ne Allegro, ne e-shop)
• Zákaznická data → CRM nebo Brevo (ne každý systém zvlášť)
• Objednávky → Base.com (ne Allegro zvlášť, ne e-shop zvlášť)
• Faktury → ERP/fakturační program (ne Base.com, ne e-shop)

Když data mají jeden zdroj pravdy — integrace je jednosměrný tok (od vlastníka ke konzumentům), ne obousměrná synchronizace s rizikem konfliktů.

Sekvence implementace — bez zastavení provozu

Fáze 1 (týden 1–2): Základ

• E-shop ↔ Base.com (objednávky a zásoby)
• První dopravce v Base.com (automatické štítky)
• Test: testovací objednávka celým tokem

Fáze 2 (týden 3–4): Dokumenty

• Base.com ↔ fakturační program (automatické faktury)
• Konfigurace mapování sazeb DPH
• Test: objednávka s fakturou na IČO/DIČ

Fáze 3 (měsíc 2): Produktová data

• Velkoobchod → Base.com (produktový feed)
• Base.com → všechny kanály (zásoby a ceny)
• Konfigurace cenových pravidel

Fáze 4 (měsíc 3): Email marketing a CRM

• Base.com/E-shop ↔ Brevo (kontakty a chování)
• Spuštění automatizací (opuštěné košíky, winback)

Fáze 5 (měsíc 3–4): Reverzní logistika

• Implementace modulu vrácení
• Integrace vrácení s ERP (opravné doklady, zásoby)

Každá fáze je samostatný projekt, který lze otestovat před spuštěním následující. Nikdy neimplementujte vše najednou.

Testování integrací — na co všichni zapomínají

Test 1 — Objednávka end-to-end: Podejte skutečnou objednávku v každém kanálu (e-shop, Allegro.cz, Allegro.sk). Zkontrolujte: objeví se v Base.com? Vygeneruje se štítek? Dorazí faktura zákazníkovi? Klesnou zásoby na všech kanálech?

Test 2 — Hraniční scénáře: Co se stane, když je objednávka zrušena? Co když zákazník změní adresu po podání objednávky? Co když produkt není dostupný (race condition — dva lidé kupují poslední kus současně)?

Test 3 — Odolnost vůči výpadkům: Co se stane, když je API velkoobchodu nedostupné 2 hodiny? Systém neúspěšné synchronizace zařadí do fronty a pokus zopakuje, nebo je jednoduše ztratí?

Absence monitoringu integrací je tikající bomba. Doporučuji Uptime Kuma nebo vlastní alerty v n8n — jednoduchý HTTP check každých 5 minut na klíčové API endpointy. Výpadek integrace bývá neviditelný, dokud zákazník nezavolá s dotazem „kde je moje objednávka".

Nejčastější architektonické chyby — a jak se jim vyhnout

Chyba 1: Obousměrná synchronizace bez arbitráže konfliktů

Obousměrná synchronizace dat (oba systémy mohou upravovat stejný záznam) je recept na konflikty. Co se stane, když se stav skladu mění současně v ERP i v e-shopu? Který je aktuální?

Řešení: Vždy definujte jeden systém jako vlastníka. ERP mění zásoby → Base.com je od ERP načítá. E-shop by nikdy neměl „přepisovat" zásoby z ERP.

Chyba 2: Synchronizace v smyčkách

Systém A změní cenu → pošle do Base.com → Base.com aktualizuje e-shop → e-shop pošle webhook „produkt aktualizován" → čímž spustí novou synchronizaci do Base.com → který znovu aktualizuje e-shop → nekonečná smyčka.

Řešení: Každá synchronizace musí mít příznak „source" — označení, odkud změna pochází. Změna z ERP by neměla vyvolat zpětný webhook do ERP.

Chyba 3: Absence zpracování chyb a fronty

Pokud je API dopravce nedostupné v okamžiku, kdy se pokoušíte vygenerovat štítek — co se stane? Pokud neexistuje mechanismus retry a fronty — objednávka zůstane bez štítku a nikdo o problému neví.

Řešení: Každá integrace musí mít: log každého pokusu (úspěch/chyba), mechanismus retry s exponenciálním backoffem, alert při opakovaném selhání.

Chyba 4: Integrace bez dokumentace

„Implementoval jsem to sám před rokem a teď nevím, jak to funguje." Slyším to pravidelně. Integrace bez dokumentace je technický dluh, který se prodraží při každé změně.

Řešení: Minimum je diagram toku dat a seznam: které systémy jsou propojeny, jakým směrem data plynou, jaký je trigger, co se stane při chybě.

Chyba 5: „Nejnovější plugin" místo promyšlené architektury

Trh pluginů pro WooCommerce, PrestaShop a Shoptet je plný řešení, která integrují dva konkrétní systémy jedním způsobem bez možnosti přizpůsobení. Když změníte dopravce, ERP nebo přidáte marketplace — kupujete další plugin.

Řešení: Investujte do jednoho middleware nástroje (Base.com pro operace, n8n nebo Make pro nestandardní logiku) místo desítek samostatných pluginů. Vyšší počáteční náklady se vrátí při první nutné změně.

Kolik to reálně stojí a kdy se to vyplatí

Náklady na implementaci integrací

Implementace kompletní integrační architektury pro středně velký e-shop (200–1 000 objednávek měsíčně):

Kdy se to vyplatí

Bod rentability závisí na tom, kolik hodin měsíčně zabírají manuální procesy. Při sazbě 150 Kč/h pro provozního pracovníka:

• 50 h/měs. ušetřeno → 7 500 Kč/měs. → návratnost za 2–6 měsíců
• 80 h/měs. ušetřeno → 12 000 Kč/měs. → návratnost za 1–4 měsíce
• Eliminace 1 pracovníka obsluhy objednávek → 25 000–35 000 Kč/měs. → návratnost za 1–2 měsíce

Jak jsem ukázal v předchozím článku této série, při 200 objednávkách měsíčně kompletní automatizace ušetří 86–118 hodin — tedy 13 000–18 000 Kč měsíčně. Investice se vrátí za 1–3 měsíce.

Shrnutí

Integrace v e-commerce nejsou IT projekty — jsou to obchodní projekty, které mění způsob, jakým e-shop operačně funguje. Provedené správně: e-shop škáluje bez lineárního nárůstu fixních nákladů, každý nový kanál je otázka konfigurace a ne dalšího úvazku, a provozní chyby se stávají výjimkou, ne normou.

Provedené špatně: každá změna systému je týdenní projekt, každý výpadek je požár a majitel e-shopu tráví více času laděním integrací než rozvojem byznysu.

Klíčové principy k zapamatování:

• Jeden zdroj pravdy pro každý typ dat
• Hub místo spaghetti — centrální orchestrátor místo propojení bod-k-bodu
• Testujte hraniční scénáře, ne jen „happy path"
• Dokumentujte — integrace bez dokumentace je technický dluh
• Implementujte po fázích — nikdy vše najednou

Jak vám mohu pomoci

Architektura integrací je oblast, kde se skrývají detaily. Mapování stavů, zpracování chyb, fronty, bezpečnostní buffer pro zásoby — to jsou věci, které v dokumentaci vypadají triviálně a v produkci se ukáží jako kritické.

Jako certifikovaný specialista na PrestaShop a WooCommerce s 15+ lety zkušeností s integrací e-commerce systémů navrhuji a implementuji integrační architektury end-to-end — od analýzy obchodních procesů, přes výběr nástrojů, po konfiguraci, testování a dokumentaci. Specializuji se na český a slovenský trh — včetně integrací specifických pro Shoptet, Allegro.cz a Allegro.sk.

Ozvěte se mi — začneme bezplatným auditem vašich stávajících datových toků.