Žádost o dovolenou odešle zaměstnanec v pondělí ráno. Ve středu stále čeká. Schvalovatel ji viděl, ale měl jiné věci – odpověděl si odložit. Ve čtvrtek přichází upomínka e-mailem, která se ztratí ve vlákně o něčem jiném. V pátek to řeší telefonátem. Tohle není výjimka. Tohle je týdenní standard ve stovkách českých firem.
Práce, kterou nikdo nechce dělat
Interní schvalování není složité. Je opakující se. Někdo něco potřebuje – volno, nákup nad limit, výjimku z ceníku pro klienta. Správná osoba musí říct ano nebo ne. Výsledek musí být někde zapsán. Tři kroky. A přesto to průměrně trvá tři až pět pracovních dní, pokud se celé odehrává v e-mailu.
Problém není vůle schvalovatele. Problém je kontext a viditelnost. Žádost se ztratí mezi dvaceti jinými e-maily. Schvalovatel neví, kde stojí rozpočet oddělení. Žadatel neví, jestli to vůbec dorazilo. Výsledek – ať jakýkoliv – musí někdo ručně přepsat do HR systému nebo ERP. A pokud to zapomene, začíná znovu.
Schválil jsem to v e-mailu. Ale v systému to není. Kdo to tam měl zapsat?
— Typické úterní ráno, malá výrobní firma
Co to znamená mít Claude propojený se systémem
Propojení neznamená, že Claude přebírá schvalování. Znamená, že Claude ví, co čeká, kdo to má schválit a co říkají relevantní pravidla – a dokáže to říct správné osobě ve správný čas. Technicky jde o MCP server, který nese identitu uživatele do systémů, které firma již provozuje: HR modul, ERP, sdílený kalendář, firemní databáze pravidel. Claude nevidí víc, než by viděl sám zaměstnanec s příslušnými právy.
Žádná data se nekopírují do cloudu třetí strany. Schvalovací stav žije tam, kde žil vždy – v systému firmy. Rozdíl je v tom, že Claude ho dokáže číst, vyhodnotit a iniciovat upozornění bez toho, aby kdokoliv musel otevřít e-mailového klienta.
Konkrétně: firma s Pamicou a Google Workspace
Představte si účetní firmu o třiceti lidech. Dovolené spravují v Pamice, ostatní komunikace běží přes Google Workspace. Žádost o volno přijde e-mailem, vedoucí ji schválí odpovědí, asistentka přepíše do Pamiky. Tento tok má tři ruční přechody a jeden zapomenutelný krok. Claude propojený s oběma systémy přes MCP server tento tok zkrátí: žádost dorazí do systému, Claude identifikuje schvalovatele podle firemní struktury, připraví upozornění s kontextem (zbývající dovolená žadatele, plán oddělení v daném týdnu) a po schválení zaznamená výsledek přímo do Pamiky – bez asistentčina ručního přepisu.
- Claude zkontroluje, kdo je podle organizační struktury schvalovatelem konkrétního zaměstnance.
- Připraví upozornění se všemi relevantními daty: zbývající dovolená, obsazenost týmu, případná kolize s jinou nepřítomností.
- Odešle strukturované upozornění schvalovateli (e-mail, Slack nebo jiný kanál, který firma používá).
- Po obdržení rozhodnutí zaznamená výsledek do zdrojového HR systému s časovým razítkem a jménem schvalovatele.
- Žadatele informuje o výsledku – bez dalšího přepisu nebo přeposílání.
Totéž schéma funguje pro nákupní požadavky (Claude zkontroluje zbývající rozpočet v ERP před tím, než upozorní schvalovatele), pro výjimky z ceníku (Claude přiloží historii zákazníka z CRM) nebo pro schválení smluvních dodatků (Claude připraví diff oproti původní verzi dokumentu). Každý případ je jiný. Schéma je stejné.
Co AI schvalování neudělá – a proč je to dobře
Claude neschválí žádost za manažera. Nevydá výjimku z ceníku bez vědomí obchodního ředitele. Nepodepíše dokument. Nerozhodne o výdaji nad rámec pravomocí. Tato omezení nejsou technická chyba – jsou záměrná. Odpovědnost za rozhodnutí musí ležet na člověku, který má příslušnou pravomoc. Systém tuto pravomoc eviduje; Claude ji respektuje.
Praktický důsledek: pokud schvalovatel není dostupný, Claude to nezástupně nevyřeší. Upozorní, že žádost čeká, a případně eskaluje podle předem definovaných pravidel – ale eskalační pravidla musí firma nastavit a odsouhlasit předem. Claude je bude následovat, ne vymýšlet za běhu.
Co by to obnášelo
Nejde o roční implementační projekt. MCP server pro schvalovací workflow je jeden fokusovaný konektor: mapuje organizační strukturu firmy, napojuje se na HR systém a na komunikační kanál, který schvalovatelé už používají. Běží na infrastruktuře firmy, ne na cloudu třetí strany. Audit trail – kdo co schválil a kdy – zůstává v systémech firmy.
Co zbývá
Model není bottleneck. Bottleneck je mezera mezi tím, co Claude umí, a daty, která vaše firma už má: kdo schvaluje co, jaký je stav rozpočtu, kolik dovolené komu zbývá. Tuto mezeru zavírá MCP server, který nese identitu a oprávnění – ne kopie dat, ne nový software pro zaměstnance, ne školení.
Pokud chcete vědět, co by takový konektor vyžadoval ve vaší konkrétní situaci – jaké systémy zapojit, jak dlouho to trvá, co zůstane na vás – napište nám. Krátký hovor stačí.