AI automatizace procesů: velký průvodce

Chat s AI je ruční práce: vy nosíte data dovnitř a výsledky ven. Automatizační platforma tuhle chůzi zruší — data doputují k modelu sama a výsledek skončí tam, kde ho potřebujete. Nemusíte umět programovat, skládáte kroky jako stavebnici. Celý trik je v tom, že AI není celý automat, ale jeden krok uprostřed: něco ho spustí, model z toho něco vytáhne nebo napíše, a výsledek putuje dál do tabulky, CRM nebo do složky Koncepty.

Návod je stavěný tak, aby se dal číst od nuly i přeskakovat. Začíná úplným začátkem pro netechniky — co je trigger, akce, větvení a běh a proč se běhy počítají — a slovníčkem pojmů, které uvidíte v každém editoru. Pak přijde otázka, kterou většina lidí přeskočí (jestli vůbec potřebujete platformu, nebo stačí naplánovaná rutina), srovnání Zapieru, Make, n8n, Power Automate a Apple Zkratek, anatomie scénáře a kapitola o procesní automatizaci ve firmě: jak vybrat, co automatizovat první, a kdo za proces odpovídá. Jádrem je deset hotových automatizací krok za krokem — od poptávky do CRM přes faktury, newsletter, přepis schůzky a hlídání termínů až po zálohu příloh. Konec patří tomu nejméně zábavnému a nejdůležitějšímu: co dělat, když se scénář rozbije, jak ošetřit přístupy a osobní údaje, a kdy je správná odpověď neautomatizovat vůbec.

Pokud automatizujete poprvé, čtěte popořadě a stavějte až od kapitoly s deseti scénáři. Pokud už scénáře máte, jděte rovnou na srovnání platforem, procesní automatizaci a kapitolu o rozbití — tam je většina toho, co v návodech chybí.

A protože se bavíme o automatu, který sahá na vaši poštu, faktury a klientská data, platí od první minuty jedno pravidlo: AI navrhuje, člověk schvaluje. Odeslání, platba, smazání, podpis — vždycky člověk. Všechny scénáře tady končí návrhem ke kontrole, nikdy hotovým činem.

Vzorová situace

Freelancerka Klára dostává poptávky z webového formuláře, průměrně deset týdně. U každé udělá tentýž rituál: přečte, přepíše jméno, firmu, typ zakázky a rozpočet do tabulky, založí si úkol „ozvat se“ a napíše úvodní odpověď. Zabere jí to zhruba dvanáct minut na poptávku, tedy dvě hodiny týdně — a ani jednou při tom nemusela nic rozhodnout, jen přenášet. Horší než čas je rozptýlení: formulář chodí v náhodných chvílích a Klára ho otevírá hned, takže se jí den tříští.

Po postavení jednoho scénáře je to jinak. Nová poptávka spustí automat: model z textu vytáhne jméno, firmu, typ zakázky, rozpočtový rámec a termín, přiřadí poptávce známku od A do C podle toho, jak sedí na Klářino zaměření, zapíše řádek do tabulky, založí úkol se štítkem „ke schválení“ a připraví koncept odpovědi ve schránce. Klára otevře poštu dvakrát denně, projde koncepty, dva upraví, jeden smaže.

Po měsíci: z dvou hodin týdně zbylo dvacet minut a hlavně přestal formulář rozbíjet den. Odesílá pořád Klára — jen už netráví čas přepisováním.

Automatizace lidsky: co se pod tím slovem skrývá

Slovo „automatizace“ zní jako něco pro IT oddělení. Přitom je to nejjednodušší myšlenka v celé počítačové práci: popíšete jednou postup, který jinak děláte rukama, a program ho pak dělá za vás. Nic víc. Nepotřebujete k tomu programovací jazyk, potřebujete umět popsat, co po sobě následuje — a to umíte, jinak byste tu práci nedělali.

Tahle kapitola je pro každého, kdo nikdy neotevřel editor scénářů. Pokud už automatizujete, přeskočte ji a pokračujte srovnáním platforem. Pokud ne, přečtěte ji celou: bez těchhle šesti pojmů budete v každém návodu tápat a budete si myslet, že za to může vaše nešikovnost. Nemůže. Ty pojmy prostě nikdo nevysvětluje, protože se autorům zdají samozřejmé.

Automat je jedna věta: „když se stane tohle, udělej tamto“

Každá automatizace, jakkoli složitá, je rozvinutím jedné věty. Když přijde nová poptávka, zapiš ji do tabulky. Když přistane faktura, ulož přílohu do složky. Když je pátek ráno, pošli mi přehled týdne. První polovina věty je spouštěč, druhá je akce. Všechno ostatní — větvení, podmínky, opakování — je jen jemnější popis téhož.

Tomuhle celku se v různých nástrojích říká různě: Zapier mu říká „Zap“, Make „scénář“, n8n „workflow“, Power Automate „tok“, Apple „zkratka“ nebo „automatizace“. Je to totéž. V tomhle návodu budeme mluvit o scénáři, protože to je nejsrozumitelnější české slovo — a protože scénář opravdu vypadá jako filmový scénář: očíslovaný sled kroků, o kterých se dá vyprávět.

Než začnete cokoli stavět, zkuste svůj postup vyslovit nahlas jako jednu takovou větu. Když se to nepovede, nemáte ještě proces, máte zvyk. To není hanba, ale automatizovat se to nedá — zvyk se nedá popsat kroky, protože polovinu rozhodnutí děláte podvědomě. K tomu, jak zvyk převést na popsatelný postup, se dostaneme v kapitole o mapování procesu.

Trigger: co scénář probudí

Trigger (spouštěč) je událost, po které se scénář probudí. Do té doby nedělá nic a nic nestojí. Existují tři druhy a rozdíl mezi nimi je to první, co byste měli u každého scénáře vědět.

• Událost v aplikaci — přišel mail se štítkem, přibyl řádek v tabulce, někdo odeslal formulář, změnil se stav v CRM, nahrál se soubor do složky. Tohle je nejběžnější spouštěč a stojí za devíti z deseti scénářů.
• Čas (rozvrh) — každý den v 7:00, každé pondělí, poslední den v měsíci. Nikdo nic neudělal, jen uplynul čas. Pozor: když je spouštěčem čas a data jsou dostupná přes konektor, možná nepotřebujete platformu vůbec a stačí naplánovaná rutina v Claude.
• Zavolání zvenčí (webhook) — cizí systém sám zaklepe na adresu, kterou mu dáte. Je to nejrychlejší a nejlevnější varianta, protože scénář se probudí přesně tehdy, kdy se něco stalo, a ani o vteřinu dřív.

U prvních dvou druhů se často schovává čtvrtý pojem: dotazování (polling). Znamená, že se platforma každých pár minut sama ptá „přibylo něco nového?“. Vypadá to jako událost, ale ve skutečnosti je to časovač, který běží pořád dokola — a každý ten dotaz se vám může počítat, i když se nic nestalo. Proto se u služeb, které umí webhook, webhook vždycky vyplatí.

Akce: co scénář udělá

Akce je krok, který něco vykoná v nějaké aplikaci. Zapiš řádek, ulož soubor, vytvoř úkol, pošli zprávu do kanálu, vytvoř koncept mailu. Scénář jich může mít jednu i patnáct a provádějí se v pořadí shora dolů — výstup jednoho kroku je vstupem dalšího.

Akce se dělí na dvě skupiny a stojí za to je v hlavě odlišovat. Neškodné akce něco přidávají: nový řádek, nový soubor, nový koncept. Když se scénář splete, uklidíte to smazáním. Nevratné akce něco mění nebo posílají ven: odeslaný mail, přepsaný záznam, zaplacená faktura, smazaný soubor. Tady se chyba neuklízí, tady se omlouvá. Celý tenhle návod stojí na tom, že do scénářů dáváte jen akce z první skupiny — a druhé necháváte na sobě.

Filtr, větvení a smyčka

Tři nástroje, kterými se z lineárního seznamu kroků stane skutečný scénář:

• Filtr je závora hned za spouštěčem. „Pokračuj jen tehdy, když je vyplněný e-mail.“ „Pokračuj jen u faktur nad určitou částku.“ Když podmínka neplatí, scénář se tiše ukončí. Filtr je nejlacinější krok, který můžete mít, a nejčastěji vynechávaný.
• Větvení je rozcestí. „Když je kategorie fakturace, pošli to účetní; když reklamace, pošli to servisu.“ Každá větev pak pokračuje vlastní řadou kroků. V Make se tomu říká router, v Zapieru cesty, v n8n IF nebo Switch.
• Smyčka (iterace) je opakování stejného kroku nad seznamem. Přišel mail s pěti přílohami — smyčka projde jednu po druhé. Bez smyčky by scénář zpracoval jen tu první a vy byste si toho všimli za měsíc.

K tomu patří dva pomocné kroky, které nic nedělají, ale bez nich se scénáře staví zle. Zpoždění počká, než druhá strana stihne data zapsat. A nastavení proměnné si odloží mezivýsledek stranou, aby se k němu dalo vrátit o pět kroků dál.

Běh: jednotka, kterou platíte

Tady se láme nejvíc rozpočtů, takže pozorně. Běh je jedno probuzení scénáře od spouštěče po poslední krok. Přišla poptávka, scénář se rozjel, doběhl — jeden běh.

Jenže platformy neúčtují stejně. Některé počítají běhy (jedno probuzení = jedna jednotka, jedno je, kolik má scénář kroků). Jiné počítají operace nebo úlohy (každý provedený krok = jedna jednotka, takže scénář o osmi krocích spotřebuje osm). Ten rozdíl je desetinásobný a poznáte ho, až vám dojde měsíční příděl třetí týden.

Z toho plynou tři praktická pravidla, která platí všude:

1. Filtrujte hned za spouštěčem. Krok, který se nespustí, nic nestojí. Scénář, který teprve v pátém kroku zjistí, že tuhle položku neměl zpracovávat, zaplatil čtyři kroky za nic.
2. Nepoužívejte dotazování tam, kde stačí webhook. Kontrola schránky každou minutu je čtyřicet tři tisíc probuzení měsíčně, z nichž drtivá většina nenajde nic.
3. Neposílejte modelu víc textu, než potřebuje. AI krok se účtuje podle množství textu na vstupu i výstupu, a rozdíl mezi „pošli celý mail i s patičkou a citovanou historií“ a „pošli jen tělo zprávy“ bývá pětinásobný.

Kde v tom všem je AI

A teď to důležité, kvůli čemu je tenhle článek o AI automatizaci a ne jen o automatizaci: model je jeden krok uprostřed scénáře, ne scénář sám.

Klasická automatizace umí přesouvat data, která už mají tvar. Řádek do řádku, pole do pole. Na čem vždycky ztroskotala, je volný text: člověk napíše do formuláře odstavec, ve kterém je jméno, rozpočet, termín i obava — a žádné pravidlo z toho ta čtyři pole nevytáhne. Tohle je přesně místo, kde AI krok mění hru. Dostane odstavec, vrátí strukturu.

Prakticky se AI krok hodí na čtyři věci a na nic jiného:

• Vytáhnout strukturu z textu — z poptávky, faktury, zprávy, přepisu. Nejspolehlivější použití vůbec.
• Zařadit do kategorie z předem daného seznamu — priorita, oddělení, typ požadavku.
• Shrnout dlouhý text do dvou vět, které se vejdou do notifikace.
• Napsat návrh textu — koncept odpovědi, draft newsletteru, komentář k číslům.

Naopak: AI krok není počítadlo, není databáze a není rozhodčí. Nenechávejte ho sčítat čísla (od toho je tabulka), vyhledávat fakta z paměti (od toho je vyhledávání) ani rozhodovat o penězích a lidech. A hlavně: výstup AI kroku je vždycky návrh, ne rozsudek. Do CRM, do tabulky, do konceptu — ano. Do odeslaného mailu bez čtení — nikdy.

Slovníček: patnáct pojmů, které uvidíte v každém editoru

• Scénář (Zap, workflow, tok, flow) — celý automat od spouštěče po poslední krok.
• Trigger (spouštěč) — událost, která scénář probudí.
• Akce (action, modul, node, uzel) — jeden krok, který něco vykoná v aplikaci.
• Běh (run, execution) — jedno probuzení scénáře od začátku do konce.
• Operace / úloha (task) — jednotka, kterou platíte; podle platformy jeden krok nebo jeden běh.
• Webhook — internetová adresa, na kterou cizí systém zavolá, když se něco stane.
• Dotazování (polling) — pravidelná otázka „přibylo něco?“ tam, kde webhook není.
• Filtr — podmínka, která scénář zastaví, když se nemá pokračovat.
• Router / větvení — rozcestí, kde scénář pokračuje podle podmínky jednou z cest.
• Iterátor / smyčka — opakování kroků nad seznamem položek.
• Mapování polí — přiřazení „tenhle údaj ze spouštěče patří do tohohle sloupce“. Tady vzniká víc chyb než v AI kroku.
• Konektor / integrace — hotové propojení platformy s konkrétní aplikací.
• Autorizace (připojení, connection) — uložené oprávnění, kterým scénář vstupuje do vašeho účtu.
• API klíč / token — heslo pro stroje. Nesdílí se, nelepí do dokumentů, dá se zneplatnit.
• JSON — textový formát, ve kterém si kroky předávají strukturovaná data. Vypadá jako seznam dvojic „klíč: hodnota“ a nemusíte mu rozumět do hloubky, jen ho poznat.
• Log (historie běhů) — záznam o tom, co scénář kdy udělal a s jakými daty. První místo, kam se díváte, když něco nesedí.
• Sandbox / testovací režim — režim, ve kterém scénář běží nanečisto a nesahá na ostrá data.

Když si nejste jistí, jestli vůbec máte proces, který se dá popsat kroky, nechte si ho přeložit do jazyka automatizace dřív, než otevřete jakýkoli editor:

Popíšu ti postup, který dělám ručně. Přelož mi ho do jazyka
automatizace, abych viděl, jestli se to vůbec dá postavit.

MŮJ POSTUP (tak, jak ho dělám dnes):
[popiš krok za krokem, klidně neuspořádaně, včetně toho, kdy
to děláš a co tě k tomu vyzve]

Vrať mi:
1. Jednu větu ve tvaru „když se stane X, udělej Y“ — jádro celého
   postupu
2. Spouštěč: co přesně tu práci spouští v reálném světě a jestli
   je to událost v aplikaci, čas, nebo zavolání zvenčí
3. Seznam kroků v pořadí, u každého: v jaké aplikaci se odehrává
   a jestli jde o přidání (neškodné), nebo o změnu či odeslání
   (nevratné)
4. Rozhodnutí, která v postupu dělám hlavou — vypiš je zvlášť
   a u každého napiš, jestli se dá popsat pravidlem, nebo jde
   o úsudek, který musí zůstat na mně
5. Místa, kde je vstupem volný text, který někdo musí přečíst
   a pochopit — tam patří AI krok
6. Upřímné hodnocení: dá se tenhle postup automatizovat, dá se
   automatizovat jen zčásti, nebo je to zvyk, který se nejdřív
   musí ustálit?

U bodu 6 mi neříkej, co chci slyšet.

Vrátí popis, který můžete rovnou přenést do editoru — a hlavně bod 4 a 6, kvůli kterým se prompt vyplatí pustit. Typický výsledek u prvního pokusu je „automatizovat jde šest kroků z devíti, dva jsou úsudek a jeden nemá stabilní vstup“. To je přesně ta odpověď, kterou potřebujete slyšet, než utratíte odpoledne.

Kdy stačí rutina v Claude a kdy potřebujete platformu

Nejdražší chyba začátečníků je postavit scénář na sedm kroků tam, kde stačila jedna věta v rutině. A stejně tak druhá strana — cpát do rutiny něco, co potřebuje reagovat na událost v cizím systému.

Rutina v Claude stačí, když…

• Spouštěčem je čas: každé ráno v 6:30, každý pátek v 15:00.
• Data jsou tam, kam vede konektor: pošta, kalendář, Drive, Notion — viz konektory vysvětlené.
• Zadání se často mění a je vágní. Rutinu upravíte přepsáním jedné věty, scénář v platformě znamená přemapovat pole.
• Výstupem je text pro člověka: koncept, přehled, seznam ke schválení.

Typický zástupce je sada rutin nad poštou a kalendářem, celý postup je v tipu rutiny v Claude. Když vaše zadání sedí do všech čtyř bodů, postavte to jako rutinu a ušetřete si jednu službu navíc.

Platformu potřebujete, když…

• Spouštěčem je událost v jiném systému: odeslaný formulář, nová faktura, změna stavu v CRM, platba. Tohle se nedá naplánovat na čas, to se musí nechat zavolat.
• V řetězu je víc než dvě aplikace: formulář → AI → tabulka → CRM → notifikace do týmu.
• Potřebujete webhook, protože chcete reagovat do vteřin, ne do rána.
• Potřebujete spolehlivý běh nad objemem: dvě stě řádků denně, s logem a s možností opakovat, co spadlo.
• Data nesmějí opustit vaši infrastrukturu — pak přichází na řadu n8n na vlastním serveru.

Jak se rozhodnout za pět minut

Napište si tři věci: co to spustí, kolik aplikací se toho účastní a jak rychle to musí být hotové. Jedna aplikace plus čas jako spouštěč znamená rutinu. Dvě a víc aplikací nebo událost jako spouštěč znamená platformu. Hraniční případy řešte tím jednodušším — přestavět rutinu na scénář je za odpoledne, opustit rozjetý scénář bolí.

Než začnete stavět, nechte si vybrat, co má být první scénář. Tenhle prompt pusťte v běžném chatu:

Popíšu ti svoji opakovanou práci a ty mi z ní vybereš první scénář
k automatizaci.

Co dělám opakovaně:
[vypiš 8–12 činností, u každé: jak často, kolik minut zabere,
odkud data přicházejí a kam je ukládám]

Nástroje, které používám: [vypiš]

Vrať mi:
1. Pořadí těch činností podle poměru ušetřený čas / náročnost stavby
2. U tří nejlepších rozkresli scénář: co ho spustí, jaké kroky
   následují, kde v tom je AI a kam jde výsledek
3. U každého ze tří napiš, jestli na to stačí naplánovaná rutina
   v AI asistentovi s konektory, nebo je potřeba automatizační
   platforma — a proč
4. Které z těch činností NEautomatizovat a proč (málo opakování,
   moc výjimek, příliš vysoká cena chyby)

U bodu 4 buď přísný, nechci automatizovat věci, které dělám dvakrát
za měsíc.

Vrátí seřazený seznam, ve kterém bývá první scénář jiný, než jste čekali — lidé podceňují nudné přepisy a přeceňují viditelné, ale vzácné úkoly. Bod 4 čtěte pozorně: automatizace činnosti, kterou děláte dvakrát měsíčně, se nezaplatí, i když je technicky snadná.

Srovnání platforem: co si vybrat a proč

Otázka „jaká automatizační platforma je nejlepší“ nemá odpověď, protože nejlepší je ta, která má hotové propojení s aplikacemi, které používáte, a editor, ve kterém se neztratíte. Tahle kapitola vám nedá vítěze — dá vám mapu, ze které poznáte, kam patříte.

Jedno upozornění, které v podobných srovnáních chybí a mělo by tam být tučně: podmínky se mění rychleji, než stačí zastarat článek. Bezplatné příděly se zvětšují i zmenšují, způsob účtování se přepočítává, AI funkce přibývají každé čtvrtletí. Co následuje, je stav v době psaní a hlavně logika, podle které se rozhoduje — tu si ověřte přímo u zdroje ve chvíli, kdy budete platit. Konkrétní ceny tady schválně nenajdete, protože by za půl roku lhaly.

Jak číst tohle srovnání

U každé platformy sledujte čtyři věci a nic jiného:

1. Máte tam své aplikace? Bez hotového propojení se scénář postaví taky, ale přes obecné kroky a s prací navíc. Podívejte se do katalogu integrací dřív, než se rozhodnete.
2. Rozumíte editoru? Někomu vyhovuje seznam kroků pod sebou, jinému plátno s čarami mezi bloky. Není to malichernost — v editoru, který vám nesedí, přestanete scénáře udržovat.
3. Jak se počítá spotřeba? Za běh, nebo za každý krok? U scénáře o deseti krocích je mezi tím řádový rozdíl.
4. Kde běží vaše data? V cizím cloudu, ve vaší firemní doméně, na vašem serveru, nebo přímo v telefonu? U zákaznických dat je tohle první otázka, ne poslední.

Zapier — nejrychlejší cesta k prvnímu funkčnímu scénáři

Zapier je nejstarší a nejrozšířenější a jeho hlavní devízou je počet propojení: pravděpodobnost, že tam vaši aplikaci najdete, je nejvyšší ze všech. Editor je jednoduchý seznam kroků pod sebou, provede vás mapováním polí za ruku a první scénář vám poběží do dvaceti minut.

Kde to skřípe: bezplatná úroveň je v době psaní opravdu jen na vyzkoušení — omezený počet úloh měsíčně a scénáře pouze o dvou krocích, tedy jeden spouštěč a jedna akce. To vylučuje skoro všechno, co v tomhle návodu stavíme, protože už samotné „spouštěč, filtr, AI krok, zápis“ jsou čtyři kroky. Zapier také účtuje po úlohách, takže vícekrokové scénáře spotřebovávají příděl rychleji, než čekáte. A složitější logika — větvení, smyčky, práce se seznamy — je tu méně přehledná než u konkurence.

AI a MCP: Zapier má vlastní AI kroky i asistenty a provozuje MCP server, kterým se jeho akce dají zpřístupnit AI asistentovi jako nástroje. Pozor na jednu věc, která překvapí: spotřeba přes MCP se v době psaní počítá do stejného přídělu jako běžné scénáře, takže si AI asistent umí příděl vyčerpat sám.

Berte ho, když: chcete první výsledek dnes, máte netypickou aplikaci, kterou jinde nenajdete, a scénáře budou jednoduché.

Make — vizuální editor, ve kterém je vidět tok dat

Make staví scénář na plátno jako řetěz kolečkových modulů propojených čarami. Zní to jako kosmetický rozdíl, ale není: u větvení, filtrů a smyček je Make podstatně čitelnější a po spuštění vidíte přímo na plátně, kolik položek kterou větví prošlo a co v nich bylo. Pro člověka, který se učí, je tohle nejrychlejší způsob, jak pochopit, co se ve scénáři vlastně děje.

Kde to skřípe: účtuje se po operacích, tedy zhruba po krocích, takže bohatý scénář spotřebovává rychle. Bezplatná úroveň v době psaní dovolí řádově tisíc operací měsíčně, malý počet současně aktivních scénářů a nejkratší interval spouštění v řádu čtvrthodiny — na naučení bohatě stačí, na provoz ne. A práce se strukturami dat (kolekce, pole, agregátory) je mocná, ale má vlastní křivku učení.

AI a MCP: Make má hotové kroky pro velké jazykové modely, vlastní agenty a napojení na MCP. Pro naše účely stačí obyčejný krok „zeptej se modelu“, do kterého vložíte prompt a dostanete text nebo JSON.

Berte ho, když: scénáře budou mít větvení a podmínky, chcete vidět, kudy data tečou, a nevadí vám počítat operace.

n8n — otevřená platforma, kterou můžete provozovat u sebe

n8n je jiná kategorie. Je to otevřený software, který si můžete pustit na vlastním serveru, a v téhle variantě je zdarma bez omezení počtu běhů — platíte jen server, na kterém to běží. Editor je uzlový jako Make, ale s jedním zásadním navíc: kdykoli můžete vložit krok s vlastním kódem a udělat věc, na kterou v hotových blocích není tlačítko. Existuje i placená cloudová varianta pro ty, kdo nechtějí spravovat server, a ta se účtuje po celých bězích, ne po krocích — u dlouhých scénářů je to velký rozdíl v její prospěch.

Kde to skřípe: samohostovaná varianta znamená, že správcem jste vy. Aktualizace, zálohy, obnovení po pádu, certifikát, dostupnost — to všechno je najednou vaše práce. Když server spadne v pátek večer, scénáře stojí do pondělí. Hotových propojení má n8n méně než Zapier, i když u běžných aplikací to nepoznáte, a chybějící se dají dohnat obecným krokem přes API.

AI a MCP: tady je n8n nejdál. Má uzel pro AI agenta, uzly pro modely a paměť, umí se připojit k externím MCP serverům jako klient a umí i opačný směr — zveřejnit vlastní workflow jako MCP nástroj, který si pak zavolá AI asistent. Když chcete stavět něco na pomezí automatizace a agenta, je tohle nejotevřenější hřiště. Co jsou MCP konektory a proč na nich záleží, rozebírá tip konektory jako USB-C pro AI.

Berte ho, když: data nesmějí opustit vaši infrastrukturu, máte objem, na kterém by se počítání kroků prodražilo, nebo potřebujete krok s vlastním kódem.

Power Automate — když už jste celí v Microsoftu

Power Automate je automatizační platforma zabudovaná do Microsoft 365 a její největší výhoda je, že ji nejspíš už máte. Když firma běží na Outlooku, SharePointu, Teamsech a Excelu v cloudu, máte propojení na dosah ruky, přihlašování řeší firemní účet a správce IT vidí, co kdo postavil.

Kde to skřípe: rozdělení na standardní a prémiové konektory je past, do které se šlápne vždycky až v půlce stavby. Se základní licencí postavíte scénáře nad Microsoft službami, ale v okamžiku, kdy sáhnete na databázi nebo na cizí obchodní systém, jste v jiné cenové kategorii. Bezplatný příděl běhů, který přichází s Microsoft 365, je v době psaní v řádu stovek měsíčně — na osobní scénáře dost, na firemní provoz ne. Editor je rozvláčnější než u konkurence a chybové hlášky umí být záhadné.

AI a MCP: vestavěné AI schopnosti (AI Builder, asistenti) jsou z větší části za placenou hranicí a způsob jejich účtování se v době psaní přepracovává. Nic vám ale nebrání použít v toku obyčejné volání jazykového modelu přes API a mít AI krok tímhle způsobem.

Berte ho, když: firma je celá v Microsoftu, IT chce mít nad automatizacemi dohled a scénáře nepotřebují sáhnout ven.

Apple Zkratky — automatizace, kterou máte v kapse

Zkratky jsou jediná položka v tomhle srovnání, která neběží v cloudu, ale na vašem zařízení. Spouštěčem může být čas, poloha, připojení k nabíječce, otevření aplikace, příchozí zpráva, režim soustředění nebo prosté klepnutí na tlačítko na ploše. To je něco, co žádná cloudová platforma neumí — a naopak.

AI krok tady existuje taky: v novějších verzích systému je k dispozici akce, která pošle text jazykovému modelu a vrátí výsledek jako proměnnou pro další krok, s volbou mezi modelem přímo v zařízení, výpočtem v Apple cloudu, nebo napojením na externího asistenta. Prakticky to znamená, že si můžete udělat zkratku „vezmi text ze schránky, přepiš ho do zdvořilé odpovědi a ulož do poznámek“ bez jediné externí služby.

Kde to skřípe: je to osobní nástroj, ne firemní. Neexistuje sdílení scénářů týmem, historie běhů je chudá, ladění je otravné a když je telefon vypnutý, nic neběží. Serverové věci typu „hlídej formulář na webu“ tímhle nepostavíte. Podrobněji se zkratkám věnuje tip zkratky a automatizace na iPhonu.

Berte je, když: jde o vaši osobní rutinu na telefonu nebo Macu a data nemají důvod opouštět zařízení.

Vestavěné automatizace, které už máte

Než přidáte další službu, projděte, co umí nástroje, které platíte dnes. Překvapivě často to stačí:

• Pravidla v poště roztřídí, archivují, přeposílají a označují — a nic navíc nestojí; postup je v tipu pravidla v Outlooku.
• Automatizace v Notionu umí při změně stavu založit úkol, přiřadit člověka nebo poslat upozornění.
• Rutiny v Claude s konektory zvládnou celý blok „vezmi data z pošty a kalendáře, napiš mi z toho přehled“ bez jediného scénáře.
• Tabulkové skripty dokážou přepočítat a rozeslat report podle rozvrhu.

Pravidlo zní: další služba v řetězu znamená další účet, další heslo, další místo, kde se něco rozbije. Když se rozhodujete mezi „přidat platformu“ a „doladit, co už mám“, začněte tím druhým.

Kdy se vyplatí samohostovaný n8n — a kdy je to past

Vyplatí se ve třech situacích. Když data nesmějí do cizího cloudu — zdravotní údaje, osobní data klientů ve větším objemu, obchodní tajemství, cokoli, kde by převod dat mimo firmu znamenal právní problém. Když máte objem, při kterém by se počítání jednotlivých kroků prodražilo; hranice bývá kolem tisíců běhů měsíčně. A když potřebujete kroky, na které jinde není tlačítko — vlastní výpočet, práce se soubory, napojení na interní systém bez veřejného API.

Past je to ve dvou situacích. Když nemáte, kdo by ten server spravoval. Automatizační platforma je infrastruktura: potřebuje aktualizace, zálohy, hlídání místa na disku a někoho, kdo v neděli večer zjistí, proč se scénáře zastavily. Když tuhle roli nikdo nemá, je samohostování falešná úspora — ušetříte předplatné a zaplatíte výpadky. A když si to berete jen proto, že je to zdarma, i když by vám bohatě stačil bezplatný příděl u cloudové služby.

Střední cesta existuje a málokdo o ní mluví: n8n si můžete pořídit i jako placenou cloudovou službu a k samohostování přejít později, protože scénáře jsou přenositelné. Začít v cloudu a přestěhovat se, až to bude dávat smysl, je poctivější postup než začínat správou serveru.

AI kroky a MCP: co dnes platformy umí

Krátké shrnutí, protože se tenhle obrázek mění nejrychleji ze všeho:

• AI krok (pošli text modelu, dostaň text nebo JSON) má v době psaní každá vážně míněná platforma. Tohle je devadesát procent toho, co k automatizaci potřebujete, a je to nejnudnější a nejspolehlivější varianta.
• AI agent (model, který sám rozhoduje, které nástroje zavolá) má většina platforem taky. Je to mocné a je to zároveň místo, kde se nejsnáz ztratí kontrola nad tím, co se stalo. Pro první scénáře ho nechte být — vysvětlení, jak agentní smyčky fungují a čím jsou zrádné, najdete v tipu co jsou loopy.
• MCP je standard, kterým se aplikace hlásí AI asistentovi jako sada nástrojů. Prakticky to znamená dva směry: platforma jako klient (scénář si sáhne na cizí MCP server) a platforma jako server (váš scénář se stane nástrojem, který si zavolá asistent). Nejdál je v tomhle n8n, ale podpora přibývá všude.

Pravidlo pro začátek zní: postavte to jako pevný scénář s jedním AI krokem. Agent i MCP jsou vrstvy navíc a přidávají se do něčeho, co už funguje a co umíte zkontrolovat.

Jak vybrat za deset minut

Napište si tři věci — které aplikace v tom budou, kolik položek denně a jestli mezi nimi tečou osobní údaje — a nechte si z toho udělat doporučení:

Pomoz mi vybrat automatizační platformu. Nechci obecné srovnání,
chci doporučení pro moji konkrétní situaci.

Aplikace, které musí být propojené: [vypiš všechny, včetně těch
českých a méně známých]
Kolik položek denně: [odhad]
Jak rychle to musí reagovat: [do vteřin / do hodiny / stačí ráno]
Osobní nebo citlivá data v řetězu: [ano/ne, jaká]
Kdo to bude udržovat: [já sám / kolega z IT / nikdo]
Co už dnes platíme: [Microsoft 365, Google Workspace, Notion,
Slack, …]

Vrať mi:
1. Doporučení jedné platformy a jednu větu proč
2. Druhou volbu a za jakých okolností by byla lepší
3. Jestli tohle zvládnu bez nové služby — pravidly v poště,
   automatizacemi v nástrojích, které už mám, nebo naplánovanou
   rutinou v AI asistentovi
4. Odhad spotřeby: kolik běhů nebo kroků měsíčně to podle mých
   čísel bude a jestli se to vejde do bezplatné úrovně
5. Tři otázky, které si musím ověřit přímo u poskytovatele,
   protože se podmínky mění

U bodu 3 buď přísný: když to jde bez nové služby, řekni to.

Vrátí doporučení včetně odhadu spotřeby, což je ten údaj, který lidi zpětně nejvíc překvapí. Bod 5 berte vážně — model má znalosti k nějakému datu a bezplatné příděly se mění; ověřte si je na stránkách poskytovatele, ne v odpovědi.

Přenositelnost: jak se nezamknout

Scénáře se mezi platformami nepřenášejí kliknutím, ale logika ano — a právě proto se vyplatí mít ji zapsanou mimo platformu. Ke každému scénáři si veďte krátký dokument: co ho spouští, jaké kroky následují, jaká pole se kam mapují a jaké prompty se používají. Zabere to dvacet minut a je to jediná věc, která z vás dělá vlastníka automatizace místo nájemníka.

Prompty držte v knihovně promptů, ne jen v poli uvnitř kroku. Když se rozhodnete přestěhovat, přenášíte pak jen kliknutí, ne přemýšlení.

Anatomie scénáře: trigger, AI krok, akce

Každý scénář, ať už v Zapieru, Make nebo n8n, má stejnou kostru. Když jí porozumíte jednou, přenesete ji mezi platformami během odpoledne.

Trigger: co to spustí

Spouštěče jsou tři druhy a rozdíl mezi nimi rozhoduje o rychlosti i o tom, kolik operací spotřebujete. Webhook je adresa, na kterou cizí systém zavolá ve chvíli, kdy se něco stane — nejrychlejší a nejlevnější varianta, protože neplýtvá běhy naprázdno. Dotazování (polling) znamená, že se platforma každých pár minut ptá, jestli přibylo něco nového; používá se tam, kde služba webhook neumí, a platíte za něj zpožděním i běhy, při kterých se nic nestalo. Rozvrh je prostý časovač — a tady se sluší zpozornět: když je spouštěčem čas a data jsou dostupná přes konektor, možná nepotřebujete platformu vůbec.

Ať zvolíte cokoli, hned za spouštěč patří filtr: jen poptávky s vyplněným e-mailem, jen faktury nad určitou částku, jen zprávy s daným štítkem. Scénář, který teprve v AI kroku zjišťuje, že položku nemá zpracovávat, plýtvá operacemi i penězi.

AI krok: jeden úkol, jeden výstup

Krok s modelem má tři části: co mu pošlete, co má udělat a v jakém tvaru to má vrátit. Nejčastější začátečnická chyba je poslat mu všechno a chtít po něm všechno naráz. Dva menší AI kroky za sebou jsou spolehlivější než jeden velký — hlavně proto, že když se něco pokazí, poznáte kde.

Zásadní rozdíl proti chatu: výstup nečte člověk, výstup čte další krok. Nechte si proto vracet JSON s pevně danými klíči a v platformě ho rozparsujte do polí:

{
  "jmeno": "Jana Nováková",
  "firma": "Stavebniny Sever",
  "typ_zakazky": "web na míru",
  "rozpocet": "neuvedeno",
  "termin": "do konce října",
  "znamka": "B",
  "zduvodneni_znamky": "obor sedí, rozpočet neznámý",
  "chybi": ["rozpocet", "telefon"]
}

Dva detaily dělají rozdíl mezi hračkou a provozem. Klíč chybi je seznam toho, co v podkladu nebylo — poznáte podle něj neúplnou poptávku, aniž byste ji četli. A hodnota neuvedeno je povinná náhrada za vymýšlení: bez ní model chybějící rozpočet doplní odhadem, který vypadá jako fakt.

Akce: výstup vždycky jako návrh

Poslední krok rozhoduje o tom, jestli je scénář pomocník, nebo riziko. Tři pravidla bez výjimky: koncept místo odeslaného mailu, úkol se štítkem „ke schválení“ místo úkolu v ostrém projektu, nový řádek místo přepsání existujícího. Automat nesmí odesílat, platit ani mazat — a právo zápisu dávejte do oddělené tabulky, ne doprostřed ostré agendy.

Než začnete klikat, nechte si scénář rozkreslit včetně mapování polí:

Chci postavit automatizační scénář a potřebuju plán, než začnu klikat.

Co scénář dělá: [popis jednou větou]
Spouštěč: [nová položka ve formuláři / webhook z CRM / nový soubor…]
Aplikace v řetězu: [vyjmenuj v pořadí]
Co má být výsledek: [řádek v tabulce, koncept mailu, úkol…]

Vrať mi:
1. Seznam kroků scénáře v pořadí, u každého: co dostane na vstupu,
   co udělá, co pošle dál
2. Kde přesně patří filtr, aby se scénář nepouštěl zbytečně
3. Mapování polí: které pole ze spouštěče jde do kterého pole
   v cílové aplikaci — jako tabulka
4. Které kroky mohou selhat a co má scénář udělat v každém z těch případů
5. Jestli se dá počet kroků snížit — a jak

Nepiš návod na konkrétní platformu, chci logiku scénáře.

Vrátí plán, který v editoru jen naklikáte. Bod 3 je ten, kvůli kterému se prompt vyplatí: většina chyb v prvních scénářích nevzniká v AI kroku, ale v přehozeném mapování polí — telefon se zapisuje do sloupce s rozpočtem a nikdo si toho měsíc nevšimne.

Procesní automatizace ve firmě: čím začít

Osobní automatizace je snadná: rozhodnete se, postavíte, používáte. Firemní automatizace je jiný živočich, protože proces nepatří vám — prochází několika lidmi, každý z nich má vlastní představu, jak správně vypadá, a nikdo nemá celý obrázek. Tahle kapitola je o tom, co udělat, než kdokoli otevře editor.

Selhání firemní automatizace mají skoro vždycky stejnou příčinu a není technická. Zautomatizuje se proces, kterému nikdo nerozuměl celý; postaví ho jeden nadšenec, který za půl roku odejde; a nikdo nedefinoval, jak se pozná, že to funguje. Technika je ta lehčí polovina.

Co automatizovat první: frekvence krát doba krát chybovost

Kandidátů bývá dvacet a čas na jeden. Vybírá se podle tří čísel, která si u každého procesu odhadnete — přesnost není potřeba, řádová správnost ano.

• Frekvence — kolikrát měsíčně to někdo dělá. Pětkrát? Dvěstěkrát?
• Doba — kolik minut zabere jeden průchod, včetně hledání podkladů a přepínání mezi aplikacemi. Lidé to podceňují zhruba o třetinu, protože si nezapočítávají rozjezd.
• Chybovost a její cena — jak často se v tom udělá chyba a co ta chyba stojí, když se objeví. Překlep v přepsané částce je jiná kategorie než překlep v příjmení.

Součin těch tří vám dá pořadí. Do něj pak vstoupí dva korektory, které pořadím zamíchají:

• Stabilita procesu. Postup, který se za poslední rok třikrát změnil, spadne o řadu dolů, i kdyby se dělal denně. Automatizovat nestabilní proces znamená přestavovat scénář pokaždé, když se změní.
• Náročnost stavby. Proces, ve kterém figuruje systém bez rozhraní pro stroje, papírový podpis nebo aplikace, kterou ovládá jen dodavatel, je drahý bez ohledu na to, jak vysoko skončil v součinu.

Praktické doporučení: první automatizace ať je nudná, denní a bez rizika. Ne ta nejefektnější, kterou pak ukážete na poradě. Nudný proces vám dá zkušenost, na které postavíte ty další, a když se pokazí, nikoho to nebolí.

Jsme [popis firmy: obor, počet lidí, hlavní nástroje] a chceme
začít s procesní automatizací. Pomoz mi vybrat, co první.

PROCESY, KTERÉ DĚLÁME OPAKOVANĚ:
[u každého napiš: název, kdo to dělá, kolikrát měsíčně,
kolik minut jeden průchod, jak často se v tom udělá chyba
a co ta chyba způsobí, v jakých aplikacích se to odehrává]

Vrať mi:
1. Tabulku: proces | odhad ušetřených hodin za rok | náročnost
   stavby (nízká/střední/vysoká) | riziko chyby | doporučené
   pořadí
2. U tří nejvýš postavených procesů rozepiš, kde přesně by AI krok
   dával smysl a kde by naopak stačila obyčejná pevná pravidla
3. Které z těch procesů jsou podle popisu nestabilní nebo špatně
   popsané a měly by se nejdřív ustálit
4. Které z nich se vůbec nemají automatizovat a proč
5. Návrh úplně prvního procesu: nudný, častý, s nízkým rizikem,
   na kterém se to naučíme

Nesnaž se najít efektní projekt. Hledám první, ne nejlepší.

Vrátí pořadí, ve kterém bývá nahoře něco jiného, než co firma zvažovala — typicky přepis údajů mezi dvěma systémy, který nikoho netrápí, protože „to je jen na chvilku“, a přitom se dělá padesátkrát měsíčně. Bod 4 čtěte nahlas na poradě; je to nejužitečnější část odpovědi.

Mapa procesu, než začnete klikat

Nejlepší investice v celé firemní automatizaci stojí devadesát minut a nepotřebuje žádný nástroj: nakreslete proces tak, jak opravdu běží. Ne jak je popsaný ve směrnici, ne jak by měl běžet — jak běží.

Postup, který funguje:

1. Projděte proces s tím, kdo ho dělá, a nechte si ho předvést naživo. Ne popsat, předvést. Rozdíl mezi popisem a předvedením bývá tři kroky, o kterých dotyčný ani neví, že je dělá.
2. Zapisujte každé přepnutí aplikace. Každé přepnutí je místo, kde se ztrácí čas a kde vzniká chyba z přepisování. Automatizace je z devadesáti procent o rušení přepnutí.
3. Označte rozhodovací body. Kde se člověk na něco podívá a rozhodne? U každého si poznamenejte, podle čeho se rozhoduje. Když to nedokáže vyslovit, je to úsudek a ten ve scénáři zůstat nemůže.
4. Označte čekání. Kde proces stojí a čeká na někoho jiného? Čekání se neautomatizuje, ale dá se automaticky připomínat.
5. Označte výjimky. Co se stane, když chybí příloha, když je klient ze zahraničí, když je částka nulová? Výjimky rozhodnou o tom, jestli se to vyplatí.

Skoro vždycky se při tomhle cvičení najdou dva kroky, které se dělají ze setrvačnosti a nikdo z nich nic nemá. Zrušit krok je lepší než ho zautomatizovat — a je to zdarma. Kdo chce mapu udělat pořádně a sdílet ji s týmem, najde postup v tipu mapy firemních procesů; kdo chce jen ustálit postup, ať z něj udělá checklist a měsíc ho používá.

Pomoz mi zmapovat proces, než ho začneme automatizovat.
Chovej se jako analytik, který se ptá na to, co lidé zapomínají
říct.

PROCES: [název]
Jak mi ho popsal ten, kdo ho dělá:
[vlož popis, klidně neuspořádaný]
Aplikace, které se v tom používají: [vypiš]
Kdo do toho vstupuje: [role]

Udělej tři věci:
1. Přepiš proces do očíslovaných kroků, u každého uveď: kdo,
   v jaké aplikaci, co je vstup, co je výstup, kolik to zabere
2. Vypiš patnáct doplňujících otázek, které se musím zeptat,
   protože z popisu nejsou jasné — zaměř se na výjimky, na
   rozhodovací body a na to, co se stane, když něco chybí
3. Označ u každého kroku jednu ze značek: PŘEPIS (přenášení dat
   mezi aplikacemi), ROZHODNUTÍ (někdo se rozhoduje), ČEKÁNÍ
   (proces stojí na někom jiném), KONTROLA (někdo něco ověřuje),
   ZBYTEČNÝ (podle popisu z toho nic neplyne)

Na konec připoj: které kroky bych měl zrušit ještě předtím,
než začnu cokoli automatizovat.

Vrátí strukturovaný proces a hlavně seznam otázek, který je ta cenná část — bez něj se na výjimky přijde až v provozu. Značka ZBYTEČNÝ bývá kontroverzní a stojí za diskusi s týmem, ne za tiché smazání kroku.

Kdo proces vlastní

Automatizace bez vlastníka umře do půl roku. Ne dramaticky — jen se jednoho dne zjistí, že už tři týdny neběží a nikdo neví proč.

Ke každému nasazenému scénáři patří jedno jméno a čtyři povinnosti. Vlastník procesu je člověk, kterému ta práce patří obsahově, ne technicky — obvykle ten, kdo ji dělal ručně. Jeho čtyři povinnosti:

1. Kontrola výstupů — jednou týdně se podívá, co scénář vyrobil, a řekne, jestli je to dobře.
2. Rozhodnutí o změnách — když se proces změní, ohlásí to dřív, než se scénář rozbije.
3. Příjem chybových hlášení — chodí mu denní souhrn a on je ten, kdo si všimne, že přišlo prázdné.
4. Právo scénář vypnout — bez schvalování, kdykoli mu to přijde nesprávné.

Vedle vlastníka existuje správce scénáře — člověk nebo role, která umí sáhnout do editoru. Ti dva nemusí být jeden člověk, ale musí o sobě vědět. Nejhorší uspořádání je „postavil to kolega z marketingu a už tu nepracuje“.

Sepište si k tomu jednu stránku na scénář: co dělá, kdo je vlastník, kdo správce, jaké účty používá, kam padají chyby a jak se vypíná. Ta stránka je celá dokumentace, kterou potřebujete, a zachrání vám den, kdy někdo onemocní.

Pilotní provoz: tři týdny a dvacet případů

Nasazení „od pondělí to jede ostře“ je nejjistější cesta k tomu, že se automatizace za měsíc vypne. Funguje tohle:

• Týden nula — nanečisto. Scénář běží nad starými daty a zapisuje do testovacích cílů. Porovnáváte, co vyplivl, s tím, co tehdy udělal člověk. Cíl: chytit hloupé chyby v mapování polí.
• Týden jedna a dva — souběh. Scénář běží ostře, ale člověk dělá práci dál taky a porovnává. Otravné, nutné. Tady se najdou výjimky, na které nikdo nepomyslel.
• Týden tři — ostrý provoz s dohledem. Člověk už práci nedělá, ale každý den kontroluje výstupy. Na konci týdne rozhodnutí: pokračujeme, doladíme, vypínáme.

Během celého pilotu si veďte jednoduchý záznam: kolik případů prošlo bez zásahu, u kolika jste museli sáhnout a co bylo důvodem. To je jediné číslo, které vám později řekne, jestli se to vyplatilo — a je to zároveň jediné, které přesvědčí vedení.

Jak to říct týmu

Automatizace vzbuzuje dvě obavy a obě jsou legitimní: „přijdu o práci“ a „bude to dělat chyby, které pak budu opravovat já“. Zamlčení obou je nejrychlejší cesta k tomu, že vám tým scénář potichu obejde.

Co funguje: říct dopředu, co se automatizuje a co ne, a proč. Konkrétně: automatizuje se přepis a třídění, nezautomatizuje se rozhodování a komunikace se zákazníkem. Říct, že poslední kliknutí zůstává člověku, a hlavně to dodržet. A dát člověku, který tu práci dělal, roli vlastníka — ne proto, aby se cítil líp, ale proto, že o tom procesu ví nejvíc a bez něj to nepostavíte správně.

Co nefunguje: sliby o ušetřených úvazcích, nasazení bez pilotu a scénář, který začne rozesílat maily jménem lidí, kteří o tom nevěděli.

Jak poznat, že to fungovalo

Tři čísla, změřená před a po, a žádné dojmy:

• Doba průchodu — kolik hodin nebo dní uplyne od vstupu do dokončení. Tohle je číslo, které vidí zákazník.
• Podíl případů bez lidského zásahu — kolik procent projde od začátku do konce bez toho, aby někdo něco přepisoval. Když je pod polovinou, scénář zatím nešetří, jen přesouvá práci.
• Počet oprav po scénáři — kolikrát týdně někdo opravoval, co automat vyplodil. Rostoucí číslo znamená, že se proces změnil a scénář to neví.

K tomu jedno měkčí, ale důležité: kolikrát se scénář zastavil a nikdo si toho nevšiml. Tohle se měří jedině tak, že si jednou měsíčně schválně pustíte umělý případ a čekáte, jestli projde. Bez toho testu nevíte nic, jen doufáte.

Deset hotových automatizací krok za krokem

Následuje deset scénářů, které se dají postavit na kterékoli platformě z předchozí kapitoly. U každého najdete spouštěč, kroky v pořadí, prompty k okopírování a poznámku, na čem to nejčastěji spadne. Nejsou seřazené podle užitečnosti, ale zhruba podle náročnosti stavby — první tři jsou dobrý první projekt, poslední tři počítají s tím, že už víte, co děláte.

Přes všechny deset platí totéž pravidlo: poslední krok je vždycky návrh, ne čin. Koncept místo odeslaného mailu, úkol se štítkem „ke schválení“ místo úkolu v ostrém projektu, nový řádek místo přepsání existujícího.

1. Příchozí poptávka → záznam v CRM a koncept odpovědi

Cíl: z každé nové poptávky vznikne strukturovaný záznam se známkou kvality a koncept odpovědi, aniž by se toho do chvíle schválení dotkla lidská ruka.

Kroky scénáře

1. Trigger: webhook z webového formuláře (nebo nový řádek v tabulce, kam formulář zapisuje).
2. Filtr: jen když je vyplněný e-mail a text má aspoň dvacet znaků. Tím odpadnou spamy a nedokončená odeslání.
3. AI krok A — extrakce: z volného textu udělej strukturovaná data.
4. AI krok B — hodnocení: přiřaď poptávce známku A/B/C a vypiš rizika.
5. Akce 1: zapiš řádek do tabulky nebo do CRM ve stavu „nový, nezpracováno“.
6. Akce 2: založ úkol se štítkem „ke schválení“ a lhůtou do 24 hodin.
7. Akce 3: vytvoř koncept odpovědi v poště. Nikdy neodesílej.

AI krok A: extrakce

Jsi extraktor údajů z poptávek. Dostaneš surový text poptávky
z webového formuláře.

TEXT POPTÁVKY:
[vstup z formuláře]

Vrať výhradně JSON s těmito klíči, bez komentáře a bez uvozovacího textu:
jmeno, firma, email, telefon, typ_zakazky, rozpocet, termin,
strucne_zadani (max 200 znaků), chybi (pole názvů klíčů, které
v textu nebyly)

Pravidla:
- Když údaj v textu není, napiš do klíče hodnotu neuvedeno
  a přidej název klíče do pole chybi.
- NIC nedomýšlej. Rozpočet neodhaduj z typu zakázky, termín
  neodvozuj z formulace „co nejdřív“ — to je neuvedeno.
- typ_zakazky vyber z: [web, e-shop, grafika, konzultace, jiné].
  Když se to nedá zařadit, napiš jiné.
- Text neopravuj ani nestylizuj, přebíráš fakta.

Vrátí čistý JSON, který v platformě rozparsujete do polí. Hlídejte dvě věci: jestli model vrací opravdu jen JSON (občas přidá vysvětlující větu a rozbije parser — pomůže krok, který vezme jen text mezi první a poslední složenou závorkou) a jestli respektuje neuvedeno u rozpočtu, kde je pokušení domýšlet největší.

AI krok B: obohacení a známka

Dostaneš strukturovaná data o poptávce a informace o mém podnikání.
Tvůj úkol je poptávku ohodnotit, ne prodat.

POPTÁVKA:
[JSON z předchozího kroku]

MOJE ZAMĚŘENÍ:
Dělám [obor], typická zakázka je [popis], nedělám [co odmítám].
Nejmenší zakázka, která mi dává smysl: [hranice].
Ideální klient: [popis].

Vrať JSON s klíči: znamka, zduvodneni, rizika, prvni_otazky.
- znamka: A (sedí na moje zaměření a je realistická), B (sedí,
  ale něco chybí nebo je nejasné), C (mimo obor, nereálný termín
  nebo zjevně mimo rozsah)
- zduvodneni: dvě věty, konkrétně, žádné fráze
- rizika: pole 1–3 vět — co může být problém (nejasné zadání,
  nereálný termín, klient chce něco, co nedělám)
- prvni_otazky: 3 otázky, které se musím zeptat, než dám cenu

Když jsou data neúplná, hodnoť podle toho, co je — nedomýšlej si,
jak asi zakázka vypadá.

Vrátí hodnocení, které rozhoduje o pořadí ve frontě. Známky nepoužívejte na automatické odmítání — céčko znamená „podívej se na to jako na poslední“, ne „zahoď“. Model nezná kontext, který máte vy.

Akce: koncept odpovědi

Poslední krok skládá odpověď z toho, co zjistily kroky před ním — a záměrně počítá s tím, že data budou neúplná:

Napiš koncept první odpovědi na poptávku. Píšu jako [jméno, obor],
tón: [věcný a přátelský, vykání, bez marketingových frází].

DATA O POPTÁVCE:
[JSON z kroku A]
HODNOCENÍ:
[JSON z kroku B]

Pravidla:
- Maximálně 150 slov, tři odstavce.
- Poděkuj, shrň jednou větou, jak jsem zadání pochopil, a polož
  ty nejdůležitější dvě otázky ze seznamu prvni_otazky.
- Cenu ani termín NEUVÁDĚJ, ani orientačně.
- Když je v datech chybi neprázdné, požádej o doplnění právě těch
  údajů, jmenovitě.
- Když je známka C, napiš zdvořilou variantu, která nabídne
  doporučení jinam — ale nikoho neodmítej definitivně, to udělám já.
- Na konec připoj podpis [podpis].

Vrať jen text mailu, žádné vysvětlování.

Vrátí koncept, který většinou odešlete po jedné úpravě. Nejdůležitější řádek je zákaz uvádět cenu a termín: to je informace, kterou model rád doplní přijatelně znějícím odhadem — a která vás pak drží v pasti při vyjednávání.

2. Příchozí požadavky a pošta → kategorie, priorita, notifikace

Druhý scénář je jednodušší a nasazuje se nejčastěji: příchozí požadavky roztřídit a poslat správnému člověku. Funguje na interní helpdesk, reklamace i požadavky z výroby.

Kroky scénáře

1. Trigger: nová odpověď ve formuláři (webhook nebo nový řádek).
2. AI krok: kategorizace, priorita a shrnutí do dvou vět.
3. Větvení podle kategorie: každá kategorie má svého adresáta.
4. Akce 1: zpráva do týmového kanálu, čitelná na mobilu.
5. Akce 2: zápis do tabulky pro statistiku.
6. Akce 3 (jen u vysoké priority): upozornění služebnímu telefonu.

AI krok: kategorizace

Jsi třídič příchozích požadavků. Kategorie jsou pevně dané, žádné
jiné nevymýšlej.

POŽADAVEK:
Odesílatel: [jméno a role]
Text: [text z formuláře]
Přílohy: [názvy souborů, pokud jsou]

Kategorie: [technický problém, fakturace, reklamace, obchodní dotaz,
personální, ostatní]

Priority:
- vysoká: něco nefunguje a blokuje to práci, nebo hrozí zmeškání
  zákonné či smluvní lhůty
- střední: potřebuje reakci do dvou pracovních dnů
- nízká: informativní, snese počkat

Vrať JSON: kategorie, priorita, shrnuti (max 2 věty, věcně,
bez opisování celého textu), kdo_by_to_mel_resit (odhad role),
chybejici_informace (co se musí doptat, než se to dá vyřešit),
citlivost (ano/ne — jestli text obsahuje osobní nebo zdravotní
údaje, mzdy nebo něco pod mlčenlivostí).

Když si nejsi jistý kategorií, dej ostatní a do shrnuti napiš proč.
Nikdy neurči vysokou prioritu jen proto, že odesílatel píše
velkými písmeny nebo použil slovo urgentní.

Vrátí zařazení přesnější, než jaké svede unavený člověk v pátek odpoledne. Poslední odstavec brání eskalaci podle tónu — bez něj se z každé rozčilené zprávy stane vysoká priorita. A klíč citlivost je pojistka: když je ano, ať scénář do kanálu pošle jen zprávu „přišel citlivý požadavek, otevři ho v systému“.

Akce: notifikace, kterou jde přečíst na mobilu

Ze zařazeného požadavku sestav zprávu do týmového kanálu.

DATA:
[JSON z předchozího kroku]
Odkaz na původní požadavek: [odkaz]

Formát:
První řádek: priorita velkými písmeny, kategorie, od koho
Druhý řádek: shrnutí, maximálně 20 slov
Třetí řádek: co je potřeba udělat jako první krok
Čtvrtý řádek: odkaz

Pravidla:
- Žádné pozdravy, žádné emotikony, žádné uvozovací věty.
- Když je v datech citlivost ano, místo shrnutí napiš jen
  „citlivý obsah — otevři přímo v systému“ a nic z textu necituj.
- Celé to musí být čitelné na mobilu bez rolování.

Vrátí zprávu, kterou tým skutečně čte, protože je krátká. Zákaz pozdravů a emotikonů tam není z nevrlosti — notifikace, která začíná „Ahoj týme, přišel nám nový požadavek“, se po dvacáté přeskakuje očima.

Varianta pro poštu místo formuláře

Tentýž scénář se dá postavit nad příchozí poštou a je to jedno z nejvděčnějších použití vůbec — schránka je jediné místo, kam vám chodí všechno naráz. Spouštěčem je nový mail v určité složce nebo se štítkem, filtr odsune newslettery a automatické zprávy, AI krok zařadí a shrne, a výsledkem je štítek plus řádek v přehledu. Nikdy odpověď.

Dvě odlišnosti proti formuláři: mail obsahuje patičku, podpis a často celou citovanou historii, takže do AI kroku posílejte jen tělo poslední zprávy — jinak model odpovídá na něco, co se řešilo před měsícem. A štítkování je jediná změna, kterou smí scénář v poště provést; přesouvání do archivu, mazání ani odpovídání do scénáře nepatří. Kompletní postup ručního třídění, ze kterého se dá vyjít, je v tipu třídění inboxu s AI.

Jsi třídič příchozí pošty. Dostaneš jednu zprávu a zařadíš ji.

ZPRÁVA:
Od: [jméno a adresa odesílatele]
Předmět: [předmět]
Tělo poslední zprávy (bez citované historie a bez patičky):
[text]
Má přílohy: [ano/ne, názvy]

Kategorie (jiné nevymýšlej): [poptávka, dotaz existujícího klienta,
faktura nebo účetnictví, smluvní a právní, schůzka a termín,
newsletter nebo oznámení, osobní, spam]

Vrať JSON s klíči:
- kategorie
- vyzaduje_odpoved (ano/ne)
- do_kdy (dnes / do dvou dnů / bez lhůty / lhůta uvedená v textu)
- shrnuti (max 20 slov, věcně, bez opisování předmětu)
- pozadovana_akce (co konkrétně po mně odesílatel chce, jednou větou)
- prilohy_dulezite (ano/ne — jestli je v příloze něco, co si musím
  uložit: faktura, smlouva, podklad)
- citlivost (ano/ne — osobní údaje, zdravotní informace, mzdy,
  obchodní tajemství)

Pravidla:
- Automatické zprávy ze systémů zařaď podle obsahu, ne podle
  odesílatele.
- Lhůtu uveď jen tehdy, když je v textu opravdu napsaná.
  Neodvozuj ji z tónu.
- Když si nejsi jistý kategorií, dej osobní a do shrnutí napiš proč.

Vrátí zařazení, které v platformě převedete na štítek a na řádek v přehledu. Nejčastější problém je klíč do_kdy: bez posledního pravidla model rád vyrobí lhůtu z formulace „co nejdřív“, a vy pak máte v přehledu deset falešných termínů na dnešek.

3. Sledované zdroje → draft newsletteru

Třetí scénář ukazuje jiný vzorec: sběr přes celý týden a jeden souhrnný výstup na konci. Právě tady se nejvíc vyplatí rozdělit AI práci na dva kroky v různém čase. Automatizace newsletteru je zároveň nejčastěji poptávaný scénář vůbec a jediný z desítky, u kterého bývá pokušení nechat automat i odeslat. Nedělejte to: jedna vymyšlená věta ve veřejném textu napáchá víc škody než měsíc nevydaných čísel. Postup od začátku je v tipu newsletter od nuly.

Kroky scénáře

1. Trigger A (průběžně): nová položka v RSS kanálech, které sledujete.
2. Filtr: jen položky s vašimi klíčovými slovy v titulku nebo perexu. Bez filtru se scénář utopí v objemu.
3. AI krok A: u každé položky shrnutí a rozhodnutí, jestli je relevantní.
4. Akce: zápis do tabulky „kandidáti na newsletter“ s hodnocením.
5. Trigger B (čtvrtek 9:00): rozvrh.
6. AI krok B: z nasbíraných položek sestav draft newsletteru.
7. Akce: ulož draft jako koncept — do rozesílky, dokumentu nebo pošty. Nikdy neodesílat.

AI krok A: shrnutí jedné položky

Shrň jeden článek pro potřeby mého newsletteru.

Newsletter píšu pro: [cílová skupina] a zajímá je [témata].
Nezajímá je: [co vynechat].

ČLÁNEK:
Titulek: [titulek]
Zdroj a datum: [zdroj, datum]
Text: [obsah nebo perex]

Vrať JSON: relevance (0–10), shrnuti (3 věty, co se stalo a proč
to čtenáře zajímá), citace (jedna doslovná věta z článku, která
stojí za odkaz — když žádná taková není, napiš prázdný řetězec),
pro_koho (komu z mé cílové skupiny to nejvíc pomůže), zdroj_typ
(původní zpráva / komentář / přetištěná tisková zpráva / reklama).

Pravidla:
- Vycházej výhradně z textu článku, nedoplňuj kontext z paměti.
- Když je článek jen přetištěná tisková zpráva nebo skrytá reklama,
  dej relevanci maximálně 3 a napiš to do zdroj_typ.
- Čísla a jména opisuj přesně, nezaokrouhluj.

Vrátí hodnocení, podle kterého tabulka sama seřadí kandidáty. Klíč zdroj_typ je tam schválně: bez něj se do newsletteru dostanou tiskové zprávy, protože znějí informativně. Čísla z druhé ruky pak ověřujte v původním zdroji, viz ověřování faktů.

AI krok B: draft newsletteru

Sestav draft newsletteru z nasbíraných položek za tento týden.

POLOŽKY (seřazené podle relevance):
[vlož řádky z tabulky: titulek, shrnutí, odkaz, relevance, pro_koho]

Newsletter má: [jméno], vychází [frekvence], píše se [tón: věcný,
lehce osobní, bez superlativů], délka [cca 400 slov].

Struktura:
1. Úvodní odstavec (3 věty) — co bylo tenhle týden hlavní téma
   napříč položkami. Když žádné společné téma není, napiš to na rovinu.
2. Tři hlavní položky — u každé nadpis, dvě až tři věty vlastními
   slovy a odkaz. Nepřepisuj shrnutí doslova, přepiš je do mého tónu.
3. Krátký blok „také stojí za pohled“ — zbytek jako odrážky
   s jednou větou.
4. Závěrečná otázka na čtenáře, jedna věta.

Pravidla:
- Používej jen položky, které jsem ti dal. Nic nedoplňuj z paměti,
  žádné „jak známo“.
- Žádné tvrzení, které není v podkladech, ani kdyby vypadalo samozřejmě.
- U každé položky nech odkaz přesně tak, jak ti přišel.
- Na konec připoj seznam KONTROLA: čísla a jména z draftu, která
  mám ověřit v původních článcích.

Vrátí draft, který přepíšete a doplníte vlastním komentářem — a hlavně seznam KONTROLA na konci, díky kterému vám v newsletteru nezůstane špatné číslo. Nikdy nerozesílejte bez čtení: jedna vymyšlená věta je ve veřejném textu vidět víc než deset dobrých.

4. Faktury z pošty → složka, tabulka a kontrola

Přijaté faktury jsou učebnicový případ: chodí v příloze, obsahují vždycky stejné údaje na vždycky jiném místě a přepisují se ručně do tabulky. Scénář z nich udělá pojmenovaný soubor ve složce a řádek v přehledu. Co scénář neudělá nikdy: nezaplatí, neschválí a nepošle do účetnictví jako hotové.

Kroky scénáře

1. Trigger: nový mail s přílohou v určité složce nebo se štítkem.
2. Filtr: má přílohu ve formátu dokumentu a odesílatel není na seznamu ignorovaných.
3. Smyčka: projdi všechny přílohy jednu po druhé, ne jen první.
4. AI krok: přečti dokument a vrať údaje z faktury jako JSON.
5. Kontrola rozumnosti: je částka číslo v očekávaném rozsahu? Je datum splatnosti v budoucnosti nebo v posledních měsících? Je vyplněné číslo faktury? Když ne, položka jde do ruční fronty, ne do tabulky.
6. Kontrola duplicity: existuje už řádek se stejným dodavatelem a číslem faktury? Pak nic nezapisuj a jen upozorni.
7. Akce 1: ulož soubor do složky podle roku a měsíce, s názvem podle jednotného vzoru.
8. Akce 2: zapiš řádek do přehledu se stavem „k odsouhlasení“.
9. Akce 3: jednou denně souhrn: co přibylo, co spadlo do ruční fronty.

Jsi extraktor údajů z přijaté faktury. Dostaneš text nebo obrázek
dokumentu.

DOKUMENT:
[obsah přílohy]

Vrať výhradně JSON s klíči: dodavatel, ico, dic, cislo_faktury,
datum_vystaveni, datum_splatnosti, datum_zdanitelneho_plneni,
castka_bez_dph, sazba_dph, castka_dph, castka_celkem, mena,
variabilni_symbol, cislo_uctu, predmet_plneni (max 100 znaků),
je_to_faktura (ano/ne), chybi (pole názvů klíčů, které v dokumentu
nebyly).

Pravidla:
- Data piš ve tvaru RRRR-MM-DD. Když je v dokumentu jiný formát,
  převeď ho, ale nedomýšlej chybějící část.
- Částky piš jako číslo s tečkou jako desetinným oddělovačem,
  bez měny a bez mezer v tisících.
- Když údaj v dokumentu není, napiš neuvedeno a přidej klíč
  do pole chybi. NIC nepočítej dopředu: když chybí DPH,
  nedopočítávej ji z celkové částky.
- Když dokument není faktura (dodací list, upomínka, nabídka,
  potvrzení objednávky), nastav je_to_faktura na ne, vyplň jen
  dodavatele a předmět a zbytek nech jako neuvedeno.
- Když je na dokumentu víc faktur, zpracuj jen tu první a napiš
  to do predmet_plneni.

Vrátí strukturovaná data, která zapíšete do tabulky. Dvě věci hlídejte od prvního dne: částky si nikdy nenechávejte dopočítávat modelem (od toho je vzorec v tabulce a rozdíl mezi „přečti“ a „spočítej“ je tady rozdíl mezi spolehlivostí a náhodou) a klíč je_to_faktura — bez něj se vám do přehledu dostanou upomínky a zálohové listy a měsíční součet nebude sedět. Skeny nižší kvality bývají problém u variabilního symbolu; když je v chybi, ať položka jde do ruční fronty automaticky.

Druhý prompt pusťte jednou měsíčně nad hotovým přehledem. Nehledá chyby v přepisu, hledá věci, které v tabulce nemají být:

Přikládám přehled přijatých faktur za měsíc. Chovej se jako
pečlivý účetní, který kontroluje, jestli něco nesedí.

PŘEHLED:
[vlož řádky: dodavatel, číslo faktury, datum vystavení, splatnost,
částka celkem, předmět plnění, stav]

Obvyklé měsíční náklady vypadají takhle: [popiš, co je normální —
pravidelní dodavatelé a přibližná úroveň částek]

Vrať mi:
1. Faktury, které vypadají jako duplicita (stejný dodavatel,
   podobná částka, blízké datum)
2. Faktury od dodavatelů, kteří se v předchozích měsících
   neobjevovali
3. Částky, které jsou výrazně mimo obvyklou úroveň u daného
   dodavatele
4. Faktury po splatnosti nebo se splatností kratší než obvyklou
5. Předplatná a opakující se platby, které v přehledu vidíš —
   a otázku, jestli je všechna ještě používáme

Nepočítej součty, ty mám v tabulce. Hledej podivnosti.

Vrátí seznam podezřelých položek, ze kterého bývá polovina planý poplach a druhá polovina užitečná. Bod 5 je vedlejší efekt, kvůli kterému se prompt vyplatí sám o sobě — nepoužívaná předplatná se jinak nacházejí těžko. Podobnou logiku nad výpisem z účtu popisuje tip rozpočet z bankovního výpisu.

5. Hlídání zmínek o značce

Scénář, který nahradí ruční googlení sebe sama. Sbírá zmínky ze sledovaných zdrojů, roztřídí je podle tónu a typu, a místo nekonečného proudu upozornění vám dá jedno denní shrnutí plus okamžité upozornění na to, co opravdu hoří.

Kroky scénáře

1. Trigger: nová položka ve sledovaném zdroji — vyhledávací upozornění, kanál z diskusního fóra, sledovaný hashtag, přehled recenzí.
2. Filtr: obsahuje název značky nebo jméno; vyřaď vlastní kanály, aby se scénář nechytal na vaše vlastní příspěvky.
3. AI krok: ověř, že jde opravdu o vás, a zařaď zmínku.
4. Větvení: negativní zmínka nebo stížnost jde okamžitě člověku; ostatní se jen zapíšou.
5. Akce 1: řádek do tabulky zmínek.
6. Akce 2: denní souhrn v jedné zprávě.

Jsi analytik zmínek o značce. Dostaneš jednu nalezenou zmínku
a zařadíš ji.

NAŠE ZNAČKA: [název] — [obor a jednou větou, čím se zabýváme]
Slova, která se s naší značkou pletou: [vypiš homonyma, podobné
názvy, běžná slova]

ZMÍNKA:
Zdroj: [web, síť, diskuse]
Titulek nebo úvod: [text]
Obsah: [text]
Odkaz: [odkaz]

Vrať JSON s klíči:
- je_to_o_nas (ano / ne / nejisté) a jednou větou proč
- typ (recenze / stížnost / doporučení / zpráva v médiích /
  dotaz / porovnání s konkurencí / náhodná zmínka)
- ton (pozitivní / neutrální / negativní)
- naléhavost (vysoká — vyžaduje reakci dnes / střední /
  žádná)
- shrnuti (max 25 slov)
- konkretni_vytka (když je zmínka negativní, co přesně jí vadí;
  jinak prázdný řetězec)
- doporuceny_dalsi_krok (jedna věta, co bych měl udělat já —
  nikdy ne text odpovědi)

Pravidla:
- Vysokou naléhavost dej jen tehdy, když je zmínka negativní
  a veřejná zároveň. Rozčilený tón sám o sobě není naléhavost.
- Když si nejsi jistý, jestli jde o nás, dej nejisté. Radši
  víc nejistých než falešný poplach.

Vrátí zařazení, které vám z proudu upozornění udělá jeden čitelný přehled. Největší past je shoda jmen: bez vypsaných homonym vám scénář bude hlásit každou zmínku běžného slova. A druhé pravidlo: odpověď na negativní zmínku nikdy nenechte psát scénář. Veřejná odpověď na stížnost je vztah, ne přenos dat — patří do kapitoly o tom, kdy neautomatizovat.

6. Přepis schůzky → zápis a úkoly

Nejrychlejší návratnost ze všech deseti scénářů, protože zápis ze schůzky nikdo nechce psát a všichni ho chtějí mít. Vstupem je textový přepis, výstupem zápis a seznam úkolů — pořád ještě ke schválení, ne v ostrém projektu.

Kroky scénáře

1. Trigger: nový soubor s přepisem ve sledované složce.
2. Filtr: delší než pár set znaků a název odpovídá vzoru pro schůzky.
3. AI krok A: zápis — rozhodnutí, otevřené otázky, kontext.
4. AI krok B: úkoly jako strukturovaná data.
5. Filtr: úkoly s nízkou jistotou nezakládej, jen je vypiš na konec zápisu.
6. Akce 1: ulož zápis jako dokument ke schválení.
7. Akce 2: založ úkoly se štítkem „ze schůzky, ke kontrole“.

Z přepisu schůzky udělej zápis. Píšeš pro lidi, kteří na schůzce
nebyli.

PŘEPIS:
[vlož přepis]
Účastníci a jejich role: [vypiš]
Téma schůzky podle pozvánky: [téma]

Struktura zápisu:
1. Tři věty: o čem to bylo a k čemu se došlo
2. ROZHODNUTÍ — odrážky, u každého: co bylo rozhodnuto a kdo to
   rozhodl. Jen věci, o kterých padlo jasné slovo.
3. OTEVŘENÉ OTÁZKY — co zůstalo nedořešené a na kom to visí
4. KONTEXT — informace, které na schůzce zazněly a hodí se
   zapamatovat, ale nejsou rozhodnutí ani úkol
5. NEJISTÉ — věci, u kterých z přepisu nepoznám, jestli byly
   rozhodnuté, nebo se o nich jen mluvilo

Pravidla:
- Nic nedoplňuj z toho, jak schůzky obvykle probíhají.
  Když to v přepisu není, není to.
- Když si nejsi jistý, kdo co řekl, napiš „někdo z účastníků“.
  Nehádej podle role.
- Zdvořilostní úvod a rozloučení vynech úplně.
- Sekce NEJISTÉ nesmí být prázdná jen proto, aby zápis vypadal
  hotově — když je opravdu prázdná, napiš „nic“.

Vrátí zápis, který po přečtení upravíte za pár minut. Sekce NEJISTÉ je tam schválně: v přepisu se špatně pozná rozdíl mezi „uděláme to“ a „mohli bychom to udělat“, a bez téhle sekce z druhého vznikne rozhodnutí. Druhý prompt vytáhne úkoly:

Ze stejného přepisu vytáhni úkoly. Zajímají mě jen věci, které
někdo někomu zadal nebo které si někdo vzal.

PŘEPIS:
[vlož přepis]
Účastníci: [vypiš jména a role]
Datum schůzky: [datum]

Vrať JSON — pole objektů s klíči:
- ukol (co se má udělat, sloveso na začátku, max 12 slov)
- kdo (jméno účastníka, nebo neuvedeno)
- do_kdy (datum ve tvaru RRRR-MM-DD, nebo neuvedeno —
  „příští týden“ převeď podle data schůzky, „brzy“ ne)
- jistota (vysoká — bylo to řečeno jednoznačně / střední /
  nízká — spíš to jen zaznělo v diskusi)
- doslovna_veta (věta z přepisu, ze které úkol vychází)

Pravidla:
- Úkoly s nízkou jistotou taky vrať, jen je označ. Nefiltruj je.
- Nikdy nedoplňuj, kdo by to logicky měl dělat. Když jméno
  nepadlo, je to neuvedeno.
- Nevymýšlej termíny. Bez termínu je to neuvedeno.

Vrátí úkoly i s doslovnou větou, ze které vycházejí — to je ten klíč, který z kontroly dělá práci na deset vteřin místo hledání v přepisu. Přiřazení lidem je nejméně spolehlivá část, proto úkoly zakládejte se štítkem ke kontrole a nikdy je nepřiřazujte automaticky. Kompletní workflow kolem přepisů rozebírá tip zápisy schůzek automaticky.

7. Report z čísel → komentář pro vedení

Měsíční report je ze dvou třetin mechanika (načíst, spočítat, vykreslit) a z jedné třetiny komentář, proč se čísla pohnula. Automatizuje se ta mechanika — a komentář zůstane návrhem, který přepíšete.

Kroky scénáře

1. Trigger: rozvrh, první pracovní den v měsíci ráno.
2. Akce: načti hodnoty z tabulky nebo z přehledu, kde už jsou spočítané.
3. Kontrola: jsou data kompletní? Chybějící měsíc ať scénář zastaví, ne dopočítá.
4. AI krok: napiš komentář ke změnám.
5. Akce: ulož jako koncept dokumentu a pošli odkaz ke schválení. Nerozesílat.

Napiš komentář k měsíčním číslům. Píšu pro [komu: vedení, majitel,
tým] a chtějí vědět, co se změnilo a co s tím.

ČÍSLA ZA TENTO MĚSÍC:
[vlož tabulku: ukazatel, hodnota tento měsíc, hodnota minulý
měsíc, hodnota stejný měsíc loni, plán]

CO SE TENTO MĚSÍC DĚLO:
[vypiš známé události: kampaň, výpadek, dovolené, nový klient,
změna ceny — klidně stručně]

Napiš:
1. Tři věty na začátek: co je hlavní zpráva tohoto měsíce
2. U každého ukazatele, který se pohnul o víc než [hranice]:
   jednu větu co se stalo a jednu větu možné vysvětlení
3. Co vypadá jako trend přes víc měsíců a co je jednorázový výkyv
4. Tři otázky, na které z těchhle dat neumíme odpovědět
   a měli bychom si je začít měřit

Pravidla:
- NIC nepočítej. Všechna čísla, která použiješ, musí být
  v podkladech; procenta a rozdíly ber odtud, neodvozuj je.
- Vysvětlení označ jako hypotézu, ne jako fakt. Nemáš data
  na to, abys znal příčinu.
- Žádné fráze o silném růstu a výborných výsledcích.
  Popisuj, nehodnoť.

Vrátí komentář, který doplníte tím, co víte jen vy. Zásadní je zákaz počítání: výpočty patří do tabulky, model je od psaní. Když ho necháte spočítat meziroční změnu, dostanete číslo, které vypadá správně a nemusí být. Širší postup reportingu popisuje tip reporting pro vedení.

8. Hlídání termínů a lhůt

Zmeškaná lhůta je nejlevnější chyba na odstranění a nejdražší, když se stane. Scénář hlídá jednu tabulku termínů a včas otravuje — a je to jeden z mála případů, kdy je otravování žádoucí.

Kroky scénáře

1. Příprava: jedna tabulka se sloupci co, kdy (jako datum, ne text), kdo je odpovědný, jaký typ (smlouva, výpověď, revize, zkušební verze, úřední lhůta), odkaz na podklad.
2. Trigger: rozvrh, každý pracovní den ráno.
3. Akce: spočítej v tabulce, kolik dní zbývá — vzorcem, ne modelem.
4. Filtr: jen řádky, kde zbývá třicet, sedm nebo jeden den.
5. AI krok: napiš, co je konkrétně potřeba udělat.
6. Akce 1: jedna souhrnná zpráva denně, seřazená podle naléhavosti.
7. Akce 2: u jednodenní lhůty navíc úkol s vysokou prioritou.

Z přehledu blížících se termínů udělej jednu ranní zprávu.

TERMÍNY:
[vlož řádky: co, datum, kolik dní zbývá, typ, odpovědný, odkaz]
Dnešní datum: [datum]

Formát zprávy:
- Nejdřív blok DNES A ZÍTRA, pak DO TÝDNE, pak DO MĚSÍCE.
  Prázdné bloky úplně vynech.
- Každý řádek: název, počet dní, odpovědný, a jedna věta
  „první krok, který to posune“.
- Na konec jedna věta: kolik termínů celkem je v přehledu
  a kdy je nejbližší po tomhle seznamu.

Pravidla:
- Počet dní ber z podkladů, nepočítej ho sám.
- U typu smlouva nebo výpověď připiš upozornění, že lhůta
  může být počítána jinak, než jak vypadá v tabulce, a že to
  má ověřit člověk.
- Žádné povzbuzování, žádné emotikony. Je to ranní seznam,
  ne motivační zpráva.

Vrátí zprávu, kterou přečtete za deset vteřin. Dvě věci rozhodují o tom, jestli scénář funguje: datum musí být v tabulce jako datum, ne jako text (jinak se dny počítají nesmyslně), a lhůty typu výpovědní doba nebo odvolací lhůta ať scénář jen připomíná, nikdy nepočítá — právní lhůty mají vlastní pravidla, která se do vzorce nevejdou.

9. Onboarding nového klienta

Když podepíšete, spustí se sled úkonů, které jsou pokaždé stejné a pokaždé se na jeden zapomene. Scénář je nepošle za vás, ale připraví je všechny naráz.

Kroky scénáře

1. Trigger: změna stavu v CRM na „podepsáno“ (nebo nový řádek v tabulce klientů).
2. Akce 1: založ složku z šablony a přejmenuj ji podle klienta.
3. Akce 2: založ sadu úkolů z checklistu, s termíny odvozenými od data začátku.
4. AI krok: připrav uvítací mail a seznam podkladů na míru typu zakázky.
5. Akce 3: ulož mail jako koncept.
6. Akce 4: připomínka za sedm dní: dorazily podklady?

Připrav uvítací balíček pro nového klienta. Nic neodesílej,
píšeš koncept, který si přečtu.

KLIENT:
Jméno a firma: [údaje]
Typ zakázky: [popis]
Co jsme si dohodli: [rozsah, termín, forma spolupráce]
Jak se seznámili s námi: [zdroj]

MŮJ STANDARDNÍ POSTUP:
[vypiš, co od klienta na začátku potřebuješ a co mu posíláš]

Vrať tři části:
1. UVÍTACÍ MAIL — max 200 slov, [tón], vykání. Poděkuj,
   shrň jednou větou, na čem jsme se dohodli, popiš, co bude
   následovat, a řekni, co od klienta potřebuju.
2. SEZNAM PODKLADŮ — odrážky, u každé položky jedna věta,
   proč ji potřebuju a v jakém formátu. Jen položky, které
   dávají smysl pro tenhle typ zakázky.
3. INTERNÍ POZNÁMKA — na co si u téhle zakázky dát pozor podle
   toho, co je v zadání, a co si musím ověřit hned na začátku.

Pravidla:
- V mailu neuváděj žádné číslo ani termín, který není v tom,
  co jsme si dohodli.
- Nic neslibuj za mě. Formulace typu „vždy odpovídáme do
  hodiny“ nepoužívej.

Vrátí tři použitelné části, z nichž nejzajímavější bývá ta třetí — interní poznámka občas upozorní na nesrovnalost v zadání, které jste si při podpisu nevšimli. Sledujte, aby se do uvítacího mailu nedostaly sliby: model má sklon dodávat servisní fráze, které pak musíte dodržet. Sousední scénář pro nástup nového člena týmu je v tipu onboarding nováčka.

10. Záloha důležitých příloh

Poslední scénář nic nevytváří, jen uklízí — a ze všech deseti se nejvíc cení ve chvíli, kdy něco hledáte pod tlakem. Bere přílohy, které vám chodí poštou, dává jim jednotný název a ukládá je na jedno místo, ke kterému se dostanete i bez schránky.

Kroky scénáře

1. Trigger: nový mail s přílohou od odesílatelů ze seznamu, nebo se štítkem, který přidáváte ručně.
2. Filtr: typ souboru je dokument nebo obrázek a velikost je nad hranicí, která vyloučí podpisové obrázky z patiček.
3. Smyčka: projdi všechny přílohy.
4. AI krok: urči, co to je, a navrhni název podle jednotného vzoru.
5. Akce 1: ulož do složky podle roku a typu, s navrženým názvem.
6. Akce 2: zapiš řádek do rejstříku: původní název, nový název, odesílatel, datum, odkaz na původní zprávu.
7. Kontrola: existuje už soubor se stejným názvem? Přidej pořadové číslo, nikdy nepřepisuj.

Urči, co je přiložený dokument, a navrhni pro něj název souboru
podle mého vzoru.

DOKUMENT:
Původní název souboru: [název]
Odesílatel: [jméno a adresa]
Předmět zprávy: [předmět]
Obsah dokumentu: [text nebo popis]

MŮJ VZOR NÁZVU:
RRRR-MM-DD_typ_protistrana_kratkypopis
Typy, které používám (jiné nevymýšlej): [faktura, smlouva,
dodatek, potvrzeni, vypis, protokol, nabidka, ostatni]

Vrať JSON s klíči: typ, datum (RRRR-MM-DD, z obsahu dokumentu,
ne z data mailu — když v dokumentu žádné není, napiš neuvedeno),
protistrana (název firmy nebo jméno, bez právní formy a bez
diakritiky), kratky_popis (max tři slova bez diakritiky, spojená
pomlčkami), navrzeny_nazev, jistota (vysoká/střední/nízká),
duvod (jednou větou, podle čeho jsi to určil).

Pravidla:
- Do názvu nepiš nic, co v dokumentu není.
- Když je jistota nízká nebo je datum neuvedeno, navrzeny_nazev
  začni předponou KONTROLA_, ať to nezapadne.
- Nikdy nenavrhuj název, který obsahuje osobní údaje typu
  rodné číslo, číslo účtu nebo adresu.

Vrátí návrh názvu i s odůvodněním, podle kterého poznáte, kdy se model spletl. Původní název vždycky zapisujte do rejstříku — přejmenování je jediná nevratná věc, kterou tenhle scénář dělá, a bez rejstříku ztratíte možnost dohledat, odkud soubor přišel. Kam soubory ukládat a jak z toho udělat skutečnou zálohu, řeší tipy záloha na externí disk a digitální lékárnička dokumentů.

Prompt v AI kroku: proč se píše jinak než v chatu

Prompt v automatu má tři vlastnosti, které v chatu neřešíte. Neuvidíte ho selhat — špatný výstup se tiše zapíše do tabulky. Nemůžete se doptat, model musí trefit napoprvé. A výstup čte stroj, takže na formátu záleží víc než na eleganci.

Z toho plyne pět pravidel. Jeden krok, jeden úkol — extrakce zvlášť, hodnocení zvlášť, formulace zvlášť. Pevný výstupní formát, ideálně JSON s vyjmenovanými klíči. Výslovný zákaz domýšlení: věta „když údaj v textu není, napiš neuvedeno“ ušetří víc problémů než jakákoli jiná. Uzavřené číselníky místo volných kategorií — když necháte model kategorie vymýšlet, dostanete za měsíc čtyřicet variant téhož. A ukázka vstupu i výstupu přímo v promptu, viz ukázky formátu. Prompty si ukládejte mimo platformu, ve svojí knihovně promptů, a verzujte je datem.

Ladit prompt naslepo nemá smysl. Postavte si testovací sadu z reálných dat:

Přikládám prompt, který používám v automatizovaném kroku, a dvacet
reálných vstupů z minulých měsíců i s tím, jak měl výstup vypadat.

PROMPT:
[vlož prompt]

VSTUPY A OČEKÁVANÉ VÝSTUPY:
[vlož 20 dvojic]

Udělej tři věci:
1. Projdi vstupy a najdi ty, u kterých je prompt nejednoznačný —
   tedy kde se dá zadání vyložit dvěma způsoby
2. U každé nejednoznačnosti navrhni konkrétní větu do promptu,
   která ji odstraní
3. Vypiš 5 hraničních případů, které v mé sadě chybí a na kterých
   prompt pravděpodobně selže (prázdný vstup, cizí jazyk, dvě
   poptávky v jedné zprávě, příloha místo textu, spam)

Nepřepisuj celý prompt, chci cílené úpravy s odůvodněním.

Vrátí seznam děr a hraniční případy, na které byste sami nepřišli — první skutečný pád scénáře v provozu bývá právě „dvě poptávky v jedné zprávě“ nebo „formulář odeslaný prázdný“.

Když se to rozbije: testování, monitoring a opravy

Scénář, který se tiše rozbil, je horší než žádný — spoléháte na něj a nevíte, že neběží. Nudná sekce, která rozhoduje o tom, jestli automatizaci za dva měsíce vypnete.

Nejdřív běh naprázdno

Pusťte scénář ručně nad dvaceti starými případy a porovnejte, co vypadlo, s tím, co jste tehdy udělali vy. První týden ať všechny akce míří do zkušebních cílů: testovací tabulka, testovací kanál, koncepty v poště. Ostrý CRM přijde na řadu, až budete výstupu věřit.

Čtyři druhy selhání a co s nimi

Cizí služba neodpoví. Nejběžnější a nejnevinnější. Řešení je automatické opakování s odstupem — dva až tři pokusy, mezi nimi minuty, ne vteřiny.

Model vrátí něco, co se nedá rozparsovat. Tři vrstvy obrany: instrukce „vrať výhradně JSON“, krok, který z odpovědi vytáhne jen část mezi složenými závorkami, a validace — když parsování selže, scénář nezapíše nic a pošle vám položku k ručnímu zpracování.

Model vrátí platný, ale nesmyslný obsah. Nejzákeřnější případ, protože scénář proběhne jako úspěšný. Obrana je kontrola rozumnosti před zápisem: rozpočet mimo očekávaný rozsah, datum v minulosti, kategorie mimo číselník, prázdné povinné pole — cokoli z toho ať vede na ruční frontu, ne do CRM.

Scénář zpracuje totéž dvakrát. Vzniká, když akce jednoho scénáře spustí trigger druhého nebo když se webhook doručí opakovaně. Obrana je značka o zpracování: scénář si u záznamu poznamená, že ho už viděl, a na začátku ji zkontroluje.

Ke každému scénáři patří cesta pro neúspěch: samostatná tabulka, kam padá všechno, co se nepovedlo, a jedno souhrnné upozornění denně, ne u každé chyby zvlášť. Jednou týdně se do ní podívejte — když je prázdná měsíc, buď je scénář výborný, nebo hlášení chyb nefunguje.

Přikládám popis svého automatizačního scénáře. Chci od tebe návrh
ošetření chyb, ne pochvalu.

SCÉNÁŘ:
[vypiš kroky a použité aplikace]
Co se stane, když výstup bude špatný: [dopad, např. zapíše se
špatné číslo do CRM a nikdo si toho nevšimne]

Vrať:
1. Tabulku: krok | jak může selhat | jak to poznám | co má scénář
   udělat | co mám udělat já
2. Kontroly rozumnosti, které mám přidat mezi AI krok a zápis
   (rozsahy hodnot, povinná pole, číselníky)
3. Návrh, jak zajistit, aby se tentýž vstup nezpracoval dvakrát
4. Co má obsahovat denní souhrnné hlášení, aby se dalo přečíst
   za deset vteřin
5. Jeden test, kterým si jednou měsíčně ověřím, že scénář opravdu běží

Buď konkrétní, obecná doporučení typu „monitorujte“ mi nepomůžou.

Vrátí plán, který naklikáte za hodinu a který vám zachrání den, kdy se něco pokazí. Bod 5 nepřeskakujte — pravidelný umělý test je jediný způsob, jak poznat rozdíl mezi „nic se nestalo“ a „scénář týden neběžel“.

Monitoring: tři věci, které musíte vidět

Monitoring zní jako slovo pro serverovnu, ale prakticky to jsou tři čísla, která se dají mít za odpoledne. Bez nich provozujete automatizaci poslepu.

• Kdy scénář naposledy doběhl úspěšně. Nejdůležitější údaj vůbec, protože rozlišuje „dnes nic nepřišlo“ od „scénář je vypnutý“. Prakticky: poslední krok každého scénáře zapíše čas do jedné tabulky a druhý, hlídací scénář jednou denně zkontroluje, jestli tam není nic staršího než dvacet čtyři hodin.
• Kolik běhů skončilo chybou. Absolutní číslo nestačí, zajímá vás podíl a jeho trend. Tři chyby ze čtyř set je provoz, tři chyby z deseti je rozbité.
• Kolik výstupů člověk opravil. Tohle platforma nezměří, tohle musíte zaznamenat vy — jedno zaškrtávátko „schváleno beze změny“ ve frontě ke kontrole. Je to jediné číslo, které měří kvalitu, ne dostupnost.

Nad tím vším postavte jednu stránku nebo jednu tabulku: řádek za scénář, sloupce poslední úspěšný běh, počet chyb za týden, podíl oprav. Pět minut týdně na její přečtení je celá údržba, kterou běžný provoz potřebuje.

Upozornění, které se opravdu čte

Upozornění na chybu má dvě smrtelné podoby. První je záplava: e-mail při každém neúspěšném běhu. Po týdnu si na ně uděláte filtr a přestanete je vidět. Druhá je ticho: nastavíte je tak opatrně, že se neozvou nikdy, a vy si to vyložíte jako důkaz, že vše běží.

Funkční nastavení vypadá takhle:

• Okamžité upozornění jen u toho, co má následek dnes — scénář, který hlídá lhůty, nebo krok, po kterém někdo čeká. Jedna zpráva, jeden kanál, jméno scénáře v prvním řádku.
• Denní souhrn u všeho ostatního, seřazený podle počtu výskytů, ne podle času. Deset stejných chyb je jedna položka s číslem u sebe.
• Týdenní hlídač nečinnosti, který se ozve, když nějaký scénář za celý týden neběžel ani jednou. Právě on chytá tiché úmrtí.
• Do každého upozornění patří odkaz na konkrétní běh v historii. Bez něj strávíte pět minut hledáním, o co šlo.

Napiš z chybových záznamů denní souhrn, který přečtu za deset vteřin.

CHYBY ZA POSLEDNÍCH 24 HODIN:
[vlož řádky: čas, scénář, krok, chybová hláška, vstupní data
zkráceně, odkaz na běh]

Formát:
1. První řádek: kolik chyb celkem, kolik různých druhů, jestli
   je mezi nimi něco, co blokuje práci
2. Pak skupiny podle druhu chyby, seřazené podle počtu:
   název scénáře, kolikrát, jednou větou co se stalo lidsky
   (ne technická hláška), a co s tím mám udělat já
3. Na konec: scénáře, které za posledních 24 hodin neběžely
   ani jednou, ačkoli měly

Pravidla:
- Chybové hlášky přelož do češtiny a do lidské řeči.
- Když se stejná chyba opakuje, je to jedna položka s počtem,
  ne deset položek.
- Nenavrhuj opravu, pokud si nejsi jistý příčinou. Radši napiš,
  co si mám ověřit.
- Žádné uklidňování a žádné omluvy. Je to provozní hlášení.

Vrátí souhrn, který se dá číst na mobilu při ranní kávě. Bod 3 je ten, kvůli kterému se to celé staví — chybějící běh se v žádném seznamu chyb neobjeví, protože chyba nenastala.

Opakování běhů a co s frontou

Když scénář spadne, existují tři možnosti a je dobré vědět dopředu, kterou používáte.

Automatické opakování je správná odpověď na dočasné výpadky cizích služeb. Dva až tři pokusy s odstupem minut, ne vteřin. Pozor na jednu věc: opakovat se smí jen krok, který se dá zopakovat bez následku. Zápis nového řádku ano, odeslání zprávy ne — jinak si vyrobíte trojité oznámení.

Ruční opakování z historie je nejčastější zásah v běžném provozu. Platformy umí spadlý běh spustit znovu se stejnými daty; naučte se, kde to ve vaší platformě je, ještě než to budete potřebovat.

Fronta k ručnímu zpracování je poslední záchrana a nejdůležitější z celé trojice. Cokoli, co neprošlo kontrolou rozumnosti nebo se nedalo rozparsovat, ať skončí v jedné tabulce se čtyřmi sloupci: čas, scénář, původní data, důvod. Tahle tabulka je jediné místo, kde se nesmí ztratit nic — protože v ní končí přesně ty případy, které by jinak zmizely.

Jedno pravidlo, které se v praxi porušuje nejčastěji: když scénář neví, co s položkou, nesmí ji zahodit ani zapsat na půl. Buď kompletní záznam, nebo fronta. Napůl zapsaný řádek v CRM je horší než žádný, protože vypadá jako hotový.

Verzování scénářů: aby se dalo vrátit

Scénáře se upravují za provozu a chyba v úpravě se pozná až po dvou dnech. Tři návyky, které z toho dělají řešitelnou situaci:

1. Export nebo kopie před každou větší změnou. Většina platforem umí scénář vyexportovat do souboru nebo si udělat kopii. Kopii pojmenujte datem a jednou větou, co se mění.
2. Změny po jedné. Když upravíte prompt, přidáte krok a změníte filtr naráz, nemáte jak zjistit, co z toho rozbilo výsledek.
3. Deník změn u scénáře. Jeden řádek: datum, co jsem změnil, proč. Tři měsíce zpět je to k nezaplacení, protože „proč jsem sem dal tenhle filtr“ je otázka, kterou si položíte určitě.

Prompty verzujte zvlášť a mimo platformu — v knihovně promptů s datem u každé verze. Prompt je ta část scénáře, která se mění nejčastěji, a zároveň jediná, kterou platforma nezobrazí v žádném přehledném srovnání.

Když nástroj změní API

Dřív nebo později přijde den, kdy scénář spadne bez toho, že byste na něj sáhli. Cizí služba změnila rozhraní, zrušila pole, přejmenovala kategorii nebo zpřísnila ověřování. Nedá se tomu předejít, dá se to jen přežít s menším rozruchem.

Než se to stane: držte seznam scénářů a služeb, které používají, ať víte, koho se změna týká. Odebírejte oznámení pro vývojáře u služeb, na kterých stojí něco důležitého. A pište scénáře tak, aby chybějící pole vedlo do fronty, ne k zápisu prázdné hodnoty.

Když se to stane: nejdřív se podívejte do historie běhů na konkrétní chybu — devět z deseti případů je vyřešeno jedním přemapovaným polem nebo novým přihlášením. Až pak hledejte, co se změnilo. A než opravu nasadíte, projeďte přes ni pět starých případů z fronty; oprava, která projde jedním testovacím vstupem, umí spadnout na druhém.

Můj automatizační scénář přestal fungovat. Pomoz mi zúžit,
kde je problém, než začnu přestavovat.

SCÉNÁŘ:
[popiš kroky a použité aplikace]
Kdy naposledy fungoval: [datum]
Co jsem od té doby změnil: [seznam, klidně „nic“]

CHYBA:
Krok, na kterém padá: [název kroku]
Hláška: [vlož přesné znění]
Vstupní data toho běhu: [vlož, citlivé údaje nahraď zástupnými]

Vrať mi:
1. Co ta hláška znamená lidsky
2. Tři nejpravděpodobnější příčiny, seřazené podle
   pravděpodobnosti, u každé jak ji ověřím za minutu
3. Jestli to podle popisu vypadá na změnu na straně cizí služby
   (vypršelé přihlášení, zrušené pole, zpřísněný limit)
   nebo na chybu v mém scénáři
4. Nejmenší možnou opravu, kterou to zprovozním
5. Co přidat, aby příště tenhle druh selhání skončil ve frontě
   ke kontrole místo tichého zápisu špatných dat

Nenavrhuj přestavbu scénáře. Hledám nejmenší opravu.

Vrátí zúžený seznam podezřelých a hlavně bod 5, který z jednorázové opravy dělá trvalé zlepšení. Před vložením dat pozor: chybové záznamy obsahují reálné vstupy, takže osobní údaje nahraďte zástupnými hodnotami.

Kolik to spotřebuje

Platformy se účtují podle počtu operací a AI krok podle množství zpracovaného textu. Pohlídejte si proto dvě věci: filtrovat co nejdřív a neposílat modelu víc textu, než potřebuje. Scénář, který dotazováním kontroluje schránku každou minutu a posílá do AI kroku celé zprávy, spotřebuje mnohonásobek toho co scénář s webhookem a filtrem — při stejném výsledku.

Bezpečnost, přístupy a osobní údaje

Scénář je program, který se za vás přihlašuje do vašich účtů. Většina návodů to odbude větou o bezpečnosti na konec; tahle kapitola je tu proto, že první vážný průšvih s automatizací nebývá technický, ale přístupový.

Přístupy: automat má mít vlastní účet a co nejmíň práv

Nejčastější uspořádání u začátečníků je nejhorší možné: scénář se přihlašuje pod osobním účtem majitele, který má práva na všechno. Když se pak něco stane, nikdo nepozná, co udělal člověk a co automat, a odebrat automatu přístup znamená odebrat ho i sobě.

Lepší postup má tři body:

1. Vlastní účet pro automatizace, kde to služba dovolí — vlastní schránka, vlastní uživatel v CRM, vlastní servisní účet. Poznáte podle něj v historii, kdo co udělal, a odpojíte ho jedním kliknutím.
2. Nejmenší možná práva. Přístup do jedné složky, ne do celé schránky. Právo zápisu do jedné tabulky, ne do celého prostoru. Čtení tam, kde stačí čtení. Automat, který přepisuje poptávky do tabulky, nemá mít právo mazat.
3. Pravidelná revize. Dvakrát ročně projděte v každé službě seznam připojených aplikací a odpojte ty, které už nepoužíváte. Zapomenuté oprávnění je otevřené okno, o kterém nevíte.

Klíče a hesla pro stroje

API klíč je heslo, které nemá majitele a nikdo si ho nepamatuje. Pravidla jsou krátká a nudná, a přesně proto se porušují:

• Klíč patří do trezoru na tajemství, který má platforma zabudovaný, ne do textového pole v kroku a už vůbec ne do dokumentu, tabulky nebo chatu.
• Klíč se nikdy neposílá v příloze ani ve zprávě. Když ho musíte předat, předejte ho cestou, kterou se dá zneplatnit.
• Každá integrace vlastní klíč, ať se dá odebrat jednotlivě.
• Klíč, který se někde mihl — ve screenshotu, v chybové hlášce, v exportu — je kompromitovaný. Zneplatnit a vydat nový je práce na dvě minuty, dohadování je práce na týden.
• Export scénáře obsahuje víc, než čekáte. Než ho někam pošlete nebo uložíte do sdílené složky, projděte ho očima.

Co nikdy nepustit bez schválení člověkem

Tenhle seznam je jádro celého návodu a nemá výjimky:

• Odeslání komunikace ven — mail, zpráva klientovi, veřejný příspěvek, odpověď na recenzi. Vždycky koncept.
• Cokoli s penězi — platba, schválení faktury, vystavení dobropisu, změna ceny, objednávka.
• Mazání a přepisování — smazaný soubor, přepsaný záznam, zrušená položka v kalendáři. Automat přidává, nemaže.
• Právní úkony a lhůty — výpověď, odstoupení, podání, potvrzení souhlasu.
• Rozhodnutí o lidech — hodnocení, výběr uchazečů, cokoli, co se dotýká něčí práce nebo pověsti.
• Sdělování údajů třetí straně — předání kontaktů, sdílení dokumentu ven, zveřejnění čehokoli, co bylo interní.

Praktické provedení je jednoduché a už jste ho viděli u všech deseti scénářů: koncept místo odeslání, úkol se štítkem místo úkolu v ostrém projektu, nový řádek místo přepsání. Když scénář neumí udělat návrh a umí jen čin, není to případ pro automatizaci.

Osobní údaje a GDPR prakticky

Jakmile scénář sahá na jméno, e-mail, telefon nebo cokoli, podle čeho se dá poznat konkrétní člověk, pracujete s osobními údaji — i když jich je pět a jsou to jen kontakty na klienty. Čtyři otázky, na které byste měli umět odpovědět dřív, než scénář zapnete:

1. Kudy ta data tečou? Vypište řetěz: odkud přišla, přes které služby projdou, kde skončí. U každé služby v řetězu si musíte být jistí, že tam ta data smějí být.
2. Potřebuje ten krok opravdu celý údaj? Většinou ne. Do AI kroku, který kategorizuje požadavek, nemusí jít příjmení ani telefon — stačí text a identifikátor, podle kterého si člověk záznam otevře v systému. Tohle je nejúčinnější opatření vůbec a stojí jednu úpravu promptu.
3. Jaký účet používáte u AI kroku? Citlivá data patří jen do nástrojů, které vaše firma schválila, na účty se smluvní ochranou dat. Osobní bezplatný účet není místo pro klientské údaje.
4. Jak dlouho ta data ve scénáři zůstanou? Historie běhů obsahuje vstupní data, často měsíce zpátky. Zjistěte si, jak dlouho, a u citlivých scénářů zkraťte, co jde.

Dvě věci navíc, na které se zapomíná. Zvláštní kategorie údajů — zdravotní stav, náboženství, členství v odborech, biometrie — do automatizovaných scénářů nepatří vůbec, pokud nemáte právní rozbor, který říká opak. A právo na výmaz platí i pro data ve vašich tabulkách a logách: když má někdo právo být zapomenut, musí být zapomenut i v pomocném přehledu, který si vyrobil scénář. Než scénář nasadíte, vězte, kde všude jeho data leží.

Zkontroluj můj automatizační scénář z pohledu přístupů a osobních
údajů. Chovej se jako opatrný kolega, ne jako právník.

SCÉNÁŘ:
[vypiš kroky, aplikace a to, co se v každém kroku přenáší]
Kdo k tomu má přístup: [role]
Účty, pod kterými scénář běží: [popiš]
Typ dat, která tím tečou: [kontakty, obsah zpráv, faktury,
zdravotní údaje, mzdy…]

Vrať mi:
1. Cestu dat: tabulka krok po kroku — jaký údaj vstupuje,
   kde se ukládá, kde zůstává i po doběhnutí
2. Údaje, které v jednotlivých krocích vůbec nemusí být —
   a jak scénář upravit, aby se tam nedostaly
3. Kroky, kde má scénář víc práv, než potřebuje, a jaká
   práva by mu stačila
4. Akce, které by podle mého popisu mohl scénář provést
   nevratně, a jak z nich udělat návrh ke schválení
5. Tři otázky, které si musím zodpovědět dřív, než to zapnu

Nepiš obecné poučení o GDPR. Chci konkrétní úpravy mého scénáře.

Vrátí seznam úprav, ze kterých bývá nejužitečnější bod 2 — obvykle se ukáže, že polovina údajů v AI kroku být vůbec nemusí a scénář funguje stejně. To je nejlevnější možné zlepšení bezpečnosti: údaj, který tam není, nemůže uniknout.

Kdy neautomatizovat

Tahle kapitola je v návodu o automatizaci nejdůležitější, protože jde proti jeho vlastnímu zájmu. Ne všechno, co jde zautomatizovat, se má zautomatizovat — a nejdražší scénáře nejsou ty, které se nepovedly, ale ty, které se povedly a neměly vzniknout. Devět situací, kde je správná odpověď „nechte to být“:

• Děláte to míň než třikrát týdně. Stavba a údržba stojí čas navždy, úspora je úměrná četnosti. U vzácných úkolů se to nevrátí.
• Proces je nestabilní. Postup, který se každý měsíc mění, budete každý měsíc přestavovat. Nejdřív ho ustalte a sepište jako checklist, teprve pak automatizujte.
• Cena chyby je vysoká a chyba není vidět. Cokoli, co sahá na peníze, na právní lhůty nebo na zdravotní údaje. Když už, tak výhradně jako návrh ke schválení.
• Jde o vztah, ne o přenos dat. Odpověď na stížnost, poděkování, kondolence, vyjednávání ceny. Automatizovaná zdvořilost je horší než žádná — příjemce ji pozná.
• Výjimek je víc než pravidel. Když u tří z deseti případů musíte zasáhnout, scénář nešetří čas, jen přidal krok kontroly.
• Scénář by musel dostat práva, která byste nedali ani stážistovi. Odesílat vaším jménem, mazat záznamy, potvrzovat objednávky. Když se rozsah nedá zúžit, nestavte to.
• Zabere to míň než pět minut měsíčně. Klasická past: úkol je otravný, takže vypadá draze. Spočítejte si ho ale poctivě — pět minut měsíčně je hodina za rok a stavba se strávenou hodinou nezaplatí ani za deset let. Otravnost není totéž co náklad.
• Vstupy nejsou stabilní. Když dodavatel posílá faktury pokaždé v jiném formátu, když formulář nemá povinná pole, když se podklady vyskytují jednou v textu a jednou ve fotce, scénář bude selhávat na půlce případů a vy budete opravovat víc, než byste přepisovali. Nejdřív ustálit vstup, pak automatizovat.
• Nikdo to nechce. Proces, o kterém jeho vlastník tvrdí, že žádný problém nemá, se automatizovat nedá — ne technicky, ale lidsky. Bez člověka, který výstupy kontroluje a chce, aby to fungovalo, scénář do měsíce zamrzne.

Když se rozhodujete v hraničním případě, položte si tři otázky a odpovězte nahlas. Kolik hodin ročně to opravdu ušetří? (frekvence krát doba, ne dojem) Co se stane, když to tiše selže a nikdo si toho měsíc nevšimne? (když je odpověď „nic hrozného“, stavte; když ne, stavte to jen jako návrh ke schválení) A kdo to bude udržovat, až budu mít jinou práci? Když na třetí otázku nemáte jméno, nestavte to.

Nejčastější chyby

• Stavět velký scénář na první pokus. Sedm kroků, čtyři aplikace, dvě větvení — a při první chybě nevíte, kde hledat. Postavte tři kroky, zprovozněte je, pak přidávejte.
• Nechat automat odesílat. Koncept vás stojí deset vteřin čtení, jeden nešťastný odeslaný mail stojí klienta.
• Nechat model vymýšlet kategorie. Bez uzavřeného číselníku dostanete za měsíc čtyřicet variant téhož a statistika je k ničemu.
• Nefiltrovat hned za spouštěčem. Scénář, který se pouští na každou položku, plýtvá operacemi i penězi.
• Netestovat na reálných starých datech. Co funguje na vymyšleném příkladu, spadne na prvním skutečném vstupu — typicky na prázdném formuláři.
• Zapomenout na hlášení chyb. Tichý scénář vypadá stejně jako fungující. Rozdíl poznáte, až se někdo zeptá, proč jste nereagovali.
• Nechat model počítat. Součty, procenta a rozdíly patří do vzorce v tabulce. Model vrátí číslo, které vypadá správně, a nikdo ho nepřepočítá.
• Posílat do AI kroku celý mail i s historií a patičkou. Zdražuje to, zpomaluje a hlavně model odpovídá na něco, co se řešilo před měsícem.
• Nemít frontu pro to, co scénář nepobral. Když si scénář neví rady a položku zahodí, ztratíte přesně ty případy, které si zasloužily pozornost.
• Postavit scénář pod svým osobním účtem s právy na všechno. Nepoznáte pak, co udělal člověk a co automat, a odebrat přístup automatu znamená odebrat ho i sobě.
• Nemít proces zmapovaný. Automatizace špatného procesu z něj udělá rychlejší špatný proces — a přidá vrstvu, přes kterou už není vidět, kde se to kazí.

Nejlepší nástroje

• Zapier — nejrychlejší cesta k prvnímu funkčnímu scénáři a největší počet propojení; volba, když je scénář jednoduchý.
• Make — vizuální editor, ve kterém je vidět tok dat; přehlednější u podmínek, větvení a smyček.
• n8n — otevřená platforma provozovatelná na vlastním serveru; volba tam, kde data nesmějí do cizího cloudu nebo kde potřebujete vlastní krok s kódem.
• Power Automate — když firma běží na Microsoft 365 a scénáře se drží uvnitř Outlooku, SharePointu, Teamsů a tabulek; hlídejte hranici mezi standardními a prémiovými konektory.
• Apple Zkratky — osobní automatizace přímo v telefonu nebo na Macu, se spouštěči, které cloud neumí (poloha, režim soustředění, nabíječka) a s AI krokem přímo v zařízení; viz zkratky a automatizace na iPhonu.
• Vestavěné automatizace v nástrojích, které už máte — pravidla v poště, automatizace v Notionu, filtry ve schránce. Když stačí, nepřidávejte další službu.
• Rutiny v Claude s konektory — když je spouštěčem čas a výstupem text pro člověka; postup v tipu rutiny v Claude.
• Claude Code nebo vlastní skript — když scénář potřebuje sáhnout na soubory nebo přepočítat data; viz skripty pro nevývojáře.

Co vám to přinese

• Čas: jeden dobře zvolený scénář ušetří typicky hodinu až dvě týdně — ale jen dokud si nepostavíte pátý, který nikdo nekontroluje.
• Peníze: rychlejší reakce na poptávku zvyšuje šanci na zakázku; scénář, který zkrátí odpověď z druhého dne na dvě hodiny, se zaplatí na jedné zakázce.
• Spolehlivost: automat nezapomene a neudělá překlep v přepisu čísla. Zato udělá stejnou chybu stokrát, když ho špatně nastavíte — proto ta kontrolní kolečka.
• Kvalita: strukturovaný záznam u každé poptávky, jednotně pojmenované soubory, zápis z každé schůzky. Ne proto, že by to člověk neuměl líp, ale proto, že to člověk nedělá pokaždé.
• Klid: přestane vás rozbíjet den každá příchozí položka. Rozhodujete v dávkách, ne po jedné.
• Přehled: po půl roce provozu víte, kolik poptávek přišlo, jak dlouho trvala odpověď a kde se práce zdržuje — protože to všechno leží v tabulkách, které scénáře mimochodem plní.

Pro tip

Postavte si ovládací panel scénářů: jednu tabulku s řádkem za každý běh — čas, scénář, vstup, výsledek a jestli jste ho schválili beze změny, nebo museli opravit. Zápis do ní přidejte jako poslední krok každého scénáře. Po měsíci z ní vyčtete tři věci, které jinak nezjistíte: který scénář nejčastěji přepisujete (tam upravte prompt), který jste nepoužili ani jednou (vypněte) a kolik času vám to celé ušetřilo — ne odhadem, ale počtem řádků.

A pravidlo, kterým se to celé dá shrnout: automat smí připravit cokoli, poslední kliknutí zůstává vaše. V den, kdy vás napadne udělat výjimku a nechat scénář něco odeslat nebo zaplatit, tu výjimku neudělejte.