aistack
Sjednat konzultaci →
← Všechny články
Nákup a schvalování

Objednávka schválená dřív, než si stihnete uvařit kávu

Nákupní požadavky se zasekávají ve frontě e-mailů a zdržují celou firmu. Claude propojený s vaším systémem pozná kontext, ověří limit a posune schválení správné osobě – bez čekání.

červen 2026·7 min read·Milan Janoštík·
ClaudeMCPNákupSchvalování
Schématická infografika: vlevo stylizovaná obálka e-mailu s nákupním požadavkem, uprostřed MCP propojení s ikonou identity, vpravo schvalovací panel se zeleně zvýrazněným řádkem čekajícím na potvrzení.

Ve firmě o patnácti lidech přijde denně pět až deset nákupních požadavků. Část z nich je rutina – kancelářský materiál, obnova předplatného. Část vyžaduje srovnání s předchozí objednávkou, ověření, jestli dodavatel byl spolehlivý, nebo kontrolu, jestli celková útrata za měsíc nepřesahuje schválený limit. Schvalovatel to všechno dělá ručně. Mezitím požadavek čeká.

Práce, na kterou nikdo nemá čas

Zaměstnanec pošle e-mail: „Potřebujeme objednat nový toner, 1 800 Kč, dodavatel ABC." Schvalovatel – ekonom nebo sám majitel – otevře Pohodu, ověří stav závazků, přepne do tabulky se schvalovacím logem, dohledá poslední objednávku u téhož dodavatele, zkontroluje měsíční limit oddělení. Pak odpíše e-mailem. Celé to trvá osm minut. Na toner.

Vynásobte to pěti požadavky denně, dvaceti pracovními dny v měsíci. Dostanete přes sto čtyřicet minut čistého administrativního času – každý měsíc – věnovaných věcem, kde se fakticky nic nerozhoduje. Kontext se jen dohledává. A ve frontě zároveň čekají věci, které opravdu rozhodnutí potřebují.

Než jsem si dohledal historii objednávek u toho dodavatele, uplynul mi celý dopolední slot. Rozhodnutí samotné trvalo deset sekund.

Ekonom v obchodní firmě, třicet zaměstnanců – ilustrativní scéna

Co propojení systémů ve skutečnosti znamená

AI stack postaví pro vaši firmu malý MCP server. Ten se napojí na systémy, které už máte – Pohoda, Outlook, případně tabulky v Google Workspace nebo interní schvalovací registr. Claude pak při každém novém požadavku přečte potřebný kontext přesně s tím oprávněním, které má schvalovatel. Nic víc, nic míň.

Výsledek: místo čtyř e-mailů a tří záložek dostane schvalovatel jednu zprávu. V ní je shrnutí požadavku, stav měsíčního limitu oddělení, poslední objednávka u téhož dodavatele a doporučení, zda jde o rutinní schválení nebo o případ, který stojí za pozornost. Schvalovatel řekne ano nebo ne. Claude nezáleží.

Pravidlo mostu
Claude nikdy nepotvrdí objednávku sám.
MCP server nese vaši identitu a vaše oprávnění. Claude vidí jen to, co by viděl schvalovatel při ručním dohledávání. Objednávku v systému potvrdí vždy člověk – to není omezení funkce, je to záměrný design.
Tok dat: e-mailový požadavek → MCP server (identita schvalovatele) → Pohoda + schvalovací log → přehled připravený k rozhodnutí

Konkrétně: Pohoda a Outlook

Pohoda.cz běží v tisících českých firem jako hlavní evidence závazků, dodavatelů a nákupních objednávek. Outlook drží historii komunikace. MCP server přidaný k tomuto párování umí – v rámci jednoho dotazu – vytáhnout stav limitu z Pohody, poslední tři objednávky u dodavatele z databáze a případnou dřívější e-mailovou komunikaci. Celé dohledávání, které schvalovatel dělal ručně, proběhne během sekund ještě před tím, než schvalovatel vůbec zprávu otevře.

  • Ověření, zda požadavek nepřesahuje schválený měsíční limit oddělení.
  • Zobrazení posledních objednávek u stejného dodavatele včetně cen a termínů.
  • Označení požadavků, které kombinují více položek nebo překračují interní prahy pro vyšší schválení.
  • Automatické přesunutí schváleného požadavku do fronty v Pohodě nebo do schvalovacího logu.
  • Notifikace žadateli ve chvíli, kdy je rozhodnutí hotové – bez dalšího pingování.

Představte si situaci v e-shopu s deseti zaměstnanci: obchodní ředitel schvaluje nákup zboží od tří různých dodavatelů, každý týden pět až osm požadavků. Po propojení dostane každé ráno přehled čekajících schválení s kontextem připraveným z Pohody – schválení celé fronty mu zabere deset minut místo hodiny. Ilustrativní příklad, ale přesný ve svém mechanismu.

Co Claude v nákupu nedělá – a proč je to dobře

Claude nepodepisuje smlouvy. Nepotvrzuje objednávky v systému bez explicitního souhlasu schvalovatele. Nevybírá dodavatele. Nerozhoduje o výjimkách z firemní politiky. Vše, co má obchodní nebo právní důsledek, zůstává na člověku.

Toto ohraničení není slabina – je to důvod, proč celé řešení funguje. Schvalovatel se na přehled může spolehnout právě proto, že Claude nikdy nepřekročí svůj rozsah. Audit trail ukazuje, kdo schválil a kdy. Odpovědnost je jasná. Systém nevznikne situace, kdy „to schválil automat".

8–12 dní
průměrný P2P cyklus bez automatizace (ilustrativní, odvozeno z APQC benchmarků)
~140 min
administrativního času měsíčně na dohledávání kontextu při 5 požadavcích denně (ilustrativní)
< 30 s
čas sestavení přehledu pro schvalovatele přes MCP (ilustrativní, závisí na systému)

Co by to obnášelo

Jeden MCP server – napojený na Pohodu nebo jiný ERP, na váš mailový účet, případně na tabulku se schvalovacím logem. Celé řešení běží na vaší infrastruktuře, ne na naší. Žádný nový nástroj pro zaměstnance, žádné přihlašování na cizí platformu, žádné sdílení firemních dat s externím serverem.

Požadavek v e-mailu nebo SlackuMCP server (identita schvalovatele)Pohoda / ERP + schvalovací logPřehled pro schvalovateleSchválení nebo zamítnutí člověkem

Co zůstane

Model není bottleneck. Bottleneck je mezera mezi Claudem a daty, která vaše firma už má – v Pohodě, v mailu, v tabulce. Jakmile tu mezeru zavřeme MCP serverem, schvalovací fronta přestane být místem, kde se věci zasekávají, a stane se místem, kde se věci řeší.

Napište nám – krátký hovor stačí. Ukážeme vám, jak takové propojení vypadá na datech, která už máte.