V každém e-shopu existuje databáze, která zná každý produkt do posledního detailu. A pak existují lidé (obchodníci, pracovníci podpory, kolegové z marketingu), kteří tuto databázi potřebují, ale nemají ji v hlavě. Pokaždé, když přijde dotaz na konkrétní produkt, otevřou admin, přihlásí se, proklikají se na správné místo a najdou odpověď. Pak zavřou záložku a postup se za hodinu opakuje.
Práce, kterou nikdo nechce dělat
Není to složitá práce. Ale je to pomalá práce. Přihlášení do adminu trvá třicet sekund, orientace v katalogu dalších třicet, a pokud hledáte konkrétní SKU nebo variantu produktu, snadno se dostanete na dvě minuty za dotaz. Při deseti dotazech denně jsou to dvacet minut ztracených ne na myšlení, ale na klikání.
U středně velkého e-shopu s tisíci položkami v katalogu a týmem pěti lidí v zákaznické podpoře a obchodu se tento čas sčítá do hodin za týden. Nejde o chybu platformy. Shoptet nebo Upgates fungují dobře. Jde o to, že administrační rozhraní je navržené pro správu katalogu, ne pro rychlé prohledávání za pochodu.
„Přihlásím se, vyhledám, zkopíruju číslo, přepnu tab, vložím a pak totéž za dvacet minut pro jiný produkt."
— Pracovník podpory, e-shop s elektrem, průměrný pracovní den
Co to znamená v praxi: Claude s přímým přístupem ke katalogu
AI stack postaví mezi Claude a vaši produktovou databázi jeden MCP server. Server má čtecí přístup ke katalogu: produkty, varianty, skladové stavy, ceny, popisy, kategorie. Ale přistupuje k nim pod vaší identitou a s vašimi oprávněními. Claude nikdy nevidí víc, než by viděl člověk, který se ptá.
Výsledek: obchodník napíše do Clauda „Kolik kusů černé verze modelu XY ve velikosti L máme na skladě?" a dostane odpověď do pěti sekund. Žádné přihlašování. Žádné přepínání tabů. Katalog zůstane tam, kde je. Přibyde pouze čtecí vrstva, která ho zpřístupní přirozeným jazykem.
Konkrétně: Shoptet nebo vlastní databáze
Většina středních e-shopů na českém trhu běží na Shoptetu, Upgates nebo vlastním řešení s SQL databází v pozadí. MCP server se napojí na produktové API nebo přímo na databázi. Katalog zůstane přesně tam, kde je, nepřesouvá se nikam, nekopíruje se do žádného externího systému. Jeden MCP server zvládne katalog s desítkami tisíc položek; pro ilustraci: e-shop s pěti tisíci SKU a denním objemem padesáti interních dotazů může ušetřit odhadem dvě až tři hodiny týdně jen na čase stráveném prohledáváním.
- Dotaz přirozeným jazykem: „Jaká je nejlevnější varianta produktu X s dopravou zdarma?" Claude prohledá katalog a odpoví.
- Porovnání variant: „Jaký je rozdíl mezi modelem A a modelem B v kategorii zahradní technika?" Bez ruční navigace v adminu.
- Skladová dostupnost: „Které produkty z kategorie zimní obuv mají skladem méně než deset kusů?" Přehled v jedné větě.
- Interní onboarding: nový obchodník se nemusí učit strukturu adminu, aby našel číslo produktu nebo EAN kód.
- Podpora zákazníků: pracovník odpoví na specifický technický dotaz během hovoru, aniž by zákazníka přepínal nebo žádal o chvilku.
Ilustrativní případ: menší český e-shop s elektronikou, tříčlenný tým podpory. Každý den vyřídí přibližně třicet interních dotazů na produktové specifikace: dostupnost, kompatibilitu, varianty. Před napojením MCP serveru odhaduje vedoucí podpory průměrně čtyři minuty na dotaz. Po nasazení bridge: odpověď do deseti sekund, bez přihlašování. Celkem ušetřeno přibližně hodinu a půl denně: čas, který tým přesunul na složitější tikety.
Co AI katalogové vyhledávání neudělá a proč je to dobře
Claude prostřednictvím MCP serveru katalog čte. Necení. Neobjednává zásoby. Nepřidává produkty. Nepublikuje úpravy. Každá změna v katalogu (nová cena, nový produkt, aktualizovaný popis) vyžaduje člověka s editačními právy v adminu.
Tato hranice není nedostatek. Je to záměr. Bridge je navržen tak, aby byl spolehlivý pro každodenní provoz bez dohledu. Pokud by mohl zapisovat, potřeboval by schvalovací proces, audit trail, rollback mechanismus. Čtecí vrstva nic z toho nepotřebuje a přitom odstraní devadesát procent friction, kvůli které lidé do adminu chodí.
Co by to obnášelo
Nasazení bridge nevyžaduje migraci dat, novou platformu ani roční projekt. MCP server se připojí k vaší stávající produktové databázi nebo API katalogu (Shoptet, Upgates, vlastní SQL) a běží na vaší infrastruktuře. Vaše data nikam neodcházejí, nekopírují se do žádného externího cache. Identita a oprávnění každého uživatele se přenášejí přes bridge: obchodník vidí, co smí vidět obchodník; pracovník podpory vidí, co smí vidět pracovník podpory.
Co zbývá
Model není bottleneck. Claude umí prohledat katalog s desítkami tisíc položek rychleji a přesněji, než to zvládne člověk proklikávající admin. Bottleneck je gap mezi Claudem a vaší produktovou databází: ta mezera, přes kterou se musí každý den přihlásit, proklikat a odpovědět. Tuto mezeru zavíráme.
Pokud máte e-shop a tým, který denně hledá produkty v adminu, napište nám. Krátký hovor stačí na to, abychom odhadli, jak velký je váš katalog, kde bridge sedí nejlépe a co by nasazení obnášelo. Žádný dlouhý projekt, žádná migrace: jen čtecí vrstva, která zpřístupní katalog všem, kdo ho potřebují.