V předchozím článku o SaaSu jsem psal, že za některé nástroje platím, i když jejich rozhraní skoro neotevírám. Používá je za mě agent. Služba mi pořád dodává hodnotu, jen se změnil způsob, jak se k ní dostávám.
Jenže pak mě napadla druhá otázka: co se stane s ekonomikou té služby, když ji za stejnou cenu začnu používat úplně jinak? A pokud dnes stavím nový produkt, který budou obsluhovat agenti, podle čeho ho mám nacenit?
Tohle mi přijde jako důležitá otázka pro go-to-market strategii. Ceník totiž říká, jakou práci zákazník kupuje, jak snadno ji dokáže rozpočtovat a jestli se mi vyplatí, když produkt opravdu začne používat.
Jeden člověk, stejná licence, jiný provoz
Vezměme můj second brain v Notionu. Můžu si do něj občas něco zapsat sám. Nebo agentovi zadat, aby ukládal důležité poznatky, dohledával souvislosti a aktualizoval existující záznamy. Pořád jsem jeden zákazník. Jedna moje věta ale může spustit několik hledání, čtení a zápisů.
Tady řeším práci externího agenta v běžném SaaSu. Model platím jeho poskytovateli. Notion ale dál musí obsloužit požadavky, uložit změny a zpřístupnit aktualizovaná data. Podobný princip platí pro CRM, projektový nástroj nebo dokumentové úložiště.
Zkusme jednoduchý modelový výpočet. Automatizace běží každých pět minut, nepřetržitě, a při každém spuštění udělá šest API volání:
288 spuštění denně × 30 dní × 6 volání = 51 840 volání měsíčně.
Průměrně je to jen 1,2 volání za minutu. Za měsíc se přesto nasčítá přes padesát tisíc operací. Je to ilustrace, nikoliv měření mého provozu nebo typického zákazníka Notionu. Jedno volání nástroje přes MCP navíc nemusí odpovídat jedinému API požadavku.
Notion má ochrany už dnes: průměrně tři API požadavky za sekundu na připojení a společný limit workspace odstupňovaný podle tarifu. Malý průměr sám o sobě nezaručuje, že se do limitů vejdou špičky a ostatní integrace. Ukazuje ale rozdíl mezi rychlostí provozu a jeho dlouhodobým objemem. Dokumentace Notionu
Člověk nikdy nebyl jediným zdrojem SaaS provozu. Integrace a automatizace existují roky. Agenti ale mohou zpřístupnit intenzivní automatizaci mnohem větší části zákazníků. Počet licencí pak může hůř vysvětlovat, kolik práce aplikace pro konkrétní firmu vykonává.
Agent nemusí přijít přes API
Agent může otevřít prohlížeč, vyhledávat, upravovat záznamy a spouštět exporty přes stejné rozhraní jako člověk. Provozovatel agenta platí běh prohlížeče a modelu. SaaS přesto obsluhuje hledání, ukládá změny a připravuje výsledky. Veřejné API je jen jedna z cest, kterou k této práci dostaneme přístup.
Z toho neplyne, že browser use automaticky obchází kvóty. GitHub například výslovně zahrnuje do některých sekundárních limitů vytváření obsahu jak webové rozhraní, tak REST a GraphQL API. Jiné služby mohou mít hranice nastavené jinak. GitHub: sekundární limity
Pokud dodavatel zdraží pouze veřejné API a obdobnou práci nechá zahrnutou přes UI, může zákazníka motivovat k použití browser agenta. Není jisté, že tím zákazník ušetří: musí započítat i rychlost, spolehlivost a cenu ovládání prohlížeče. Pro dodavatele je to ale důvod měřit práci napříč vstupními cestami. Samotný počet kliknutí nebo requestů pořád neříká, kolik tato práce stojí.
A někdy agent aplikaci vůbec neovládá
Ještě zajímavější mi přijde pravidelný odběr výstupů. Člověk jednou nastaví rozesílání reportů a agent potom zpracovává e-mailové přílohy. Aplikace nemusí mít MCP ani vědět, že její výstup čte stroj.
Představme si, že člověk zvládal projít jeden souhrn týdně. Agent dokáže porovnávat dvacet variant reportu každý den, hledat odchylky a předávat mu jen to podstatné. Za čtyři týdny jsou to 4 souhrny versus 560 reportů, tedy 140× více výstupů. Jde o modelový scénář zvýšené objednávky reportů, nikoliv o měření provozu nebo růstu nákladů.
Takové distribuční cesty už existují. Power BI podporuje plánované e-mailové odběry reportů a dashboardů se snímkem, odkazem nebo přílohou. Dokumentace uvádí až 24 odběrů na report či dashboard; možnosti závisejí na oprávněních, licenci a kapacitě. To dokládá existenci kanálu, nikoliv růst jeho využití kvůli agentům. Power BI: e-mailové odběry
Podobně si umím představit více pravidelných CSV exportů do sdílené složky, jemněji nastavené notifikace nebo více sledovaných objektů. Lidská pozornost může přestat být hranicí toho, kolik výstupů má smysl si objednávat. Aplikace pak může vykonávat víc práce, i když se do ní zákazník přihlašuje méně a agent jí neposílá žádné přímé požadavky.
Důležitá je podmínka: když agent jen přečte stejné e-maily, které už chodily člověku, zdrojovému SaaSu tím nemusí přibýt vůbec žádná práce. Změna nastává, když si díky nové schopnosti zpracování objednáme větší rozsah, častější výstupy nebo další varianty.
Ani potom není e-mail správnou jednotkou nákladů pro všechno. Vygenerovat dvacet odlišných reportů může znamenat jinou práci než dvacetkrát rozeslat jeden hotový soubor. Potřebuji rozlišit výpočet, renderování, přenos a uchovávání. Další kopie se mohou hromadit v poště, úložišti i indexu agenta; část nákladů tak vznikne až u dalších služeb.
Dobře navržený odběr přitom může spotřebu i snížit. Oznámení změny může nahradit opakované dotazování, sdílený export opakované generování stejného výsledku. Pro nový produkt bych proto zvažoval strukturované výstupy, doručování jen změn a identifikátor s časem vytvoření, podle kterého agent pozná duplicitu nebo starý report. Smyslem je dodat použitelnou informaci s rozumným množstvím práce.
Google už oznámil placenou nadlimitní spotřebu
Nejpřímější doklad jsem našel u Googlu. Dne 1. května 2026 otevřel vývojářské preview Workspace MCP a oznámil nový model úrovní používání API a agentních nástrojů. Výslovně ho spojil s rozsáhlými agentními operacemi a riziky vysokého objemu přístupu k datům. Oznámení Google Workspace
Aktuálně dostupná dokumentace říká, že později v roce 2026, po oznámení s 90denním předstihem, bude používání nad standardní denní hranice vytvářet poplatky na Google Cloud účtu. K 8. září jsem v těchto podkladech nenašel jednotkové ceny ani potvrzení plošného spuštění. Je to oznámená změna, kterou nelze popsat jako poplatek už účtovaný každému uživateli Workspace. Model kvót a připravované fakturace
Google zároveň odhaduje, že nad standardní úroveň bude potřebovat jít méně než 1 % aktivních Workspace vývojářů. Je to odhad dodavatele a týká se vývojářů, nikoliv podílu koncových uživatelů nebo provozu. Je dobré ho uvést: osobní automatizace nemusí automaticky znamenat velkou novou fakturu. Oznámení Googlu
Zajímavé je také to, co Google měří. Drive API používá vážené jednotky:
| Operace v Drive API | Jednotky kvóty |
|---|---|
Čtení položky, například files.get |
5 |
Úprava položky, například files.update |
50 |
Výpis položek, například files.list |
100 |
Stažení, například files.download |
200 |
Stažení tedy spotřebuje 40× více jednotek než uvedené jednoduché čtení. Není to důkaz čtyřicetinásobných nákladů Googlu. Je to důkaz, že samotný počet requestů nemusí být dostatečnou jednotkou pro řízení spotřeby. Dokumentace obsahuje také přechodová pravidla pro existující projekty. Limity Drive API
Plánovaná fakturace vede přes Cloud projekt integrace. Pro návrh vlastního produktu z toho plyne praktická otázka: kdo ten projekt provozuje a komu následně promítne náklady? Předplatné agenta nemusí být jediný účet v celém workflow.
SaaSy nezačínají od nuly
Salesforce popisoval dokupování API kapacity už v listopadu 2024. Jeho dokumentace pracuje se sdíleným limitem organizace a nabízí mimo jiné navýšení o 10 000 API volání denně. Monetizace automatizace tedy existovala před dnešní vlnou agentů. Salesforce: API limits and monitoring
Linear ukazuje jinou možnost. U workspace OAuth aplikací s Actor Authorization dynamicky zvyšuje limity podle počtu placených uživatelů. Počet lidí může dál fungovat jako obchodní jednotka a současně určovat kapacitu pro jejich automatizace. Linear navíc měří složitost GraphQL dotazů. Limity Linearu
Z těchto příkladů mi nevychází jeden univerzální budoucí ceník. Poskytovatel může prodávat další kapacitu, upravit zahrnuté limity nebo přijmout vyšší spotřebu jako náklad na hodnotnější produkt. Více operací samo o sobě nedokazuje zhoršení marže ani nutnost zdražit. Bez interních dat nevíme, kolik dodatečná práce stojí a co firmě přináší.
Když nový produkt bude používat agent
Pro foundera je tahle druhá část možná ještě důležitější. Pokud stavím službu pro zpracování dokumentů, vyhledávání nebo monitoring a předem počítám se strojovým používáním, počet lidí nemusí být dobrým základem ceny.
Začal bych otázkou: jakou srozumitelnou jednotku práce ode mě zákazník kupuje? U dokumentů to může být zpracovaná stránka, u vyhledávání dotaz, u monitoringu sledovaný objekt s určitou frekvencí kontrol. Každá má ale slabé místo, které potřebuji vyřešit už při návrhu nabídky.
| Typ produktu | Jednotka, kterou bych ověřoval | Co musí nabídka vysvětlit |
|---|---|---|
| Zpracování dokumentů | Stránka nebo dokument | Rozdíl mezi jednostránkovou fakturou a stostránkovým skenem |
| Vyhledávání | Dotaz s definovaným rozsahem | Kolik výsledků a jak hluboké zpracování zahrnuje |
| Monitoring | Objekt × frekvence kontrol | Co se stane při změně intervalu a opakovaném ověřování |
| Reporty a exporty | Vygenerovaný výstup s definovaným rozsahem | Rozdíl mezi novým výpočtem, opakovaným stažením a rozesláním kopie |
| Automatizace v prohlížeči | Minuta běhu nebo dokončená úloha | Timeouty, souběh a neúspěšné pokusy |
| Zákaznická podpora | Definovaný výsledek konverzace | Kdy je případ vyřešený a kdy se platba vrací |
Tohle je můj návrh rozhodování, nikoliv univerzální standard. Dobrá jednotka musí být srozumitelná zákazníkovi, měřitelná na faktuře a musí udržet náklady v rozumném vztahu k příjmům. Nemusí přesně kopírovat interní infrastrukturu. U stejné práce bych také prověřil, zda cena zbytečně nezvýhodňuje klikání proti API nebo e-mail proti stažení. Rozdílné ceny mohou mít důvod, ale neměly by zákazníka nutit do méně efektivní cesty jen kvůli ceníku.
Firecrawl například v ceníku uvádí jeden kredit za stránku u základního scrape, dva kredity za deset výsledků vyhledávání a dva kredity za minutu interakce s prohlížečem. Prodává různé druhy práce přes společné kredity. Zákazník si ale pořád musí umět přepočítat kredity na svůj scénář. Ceník Firecrawl
Interně bych měřil náklady jednotlivých typů operací včetně opakovaných pokusů a navazujících služeb. Zákazníkovi bych nabízel jednotku, se kterou dokáže plánovat. Kredity jsou obal; jejich srozumitelnost určuje převodník.
Objem práce a rychlost jsou dvě různé věci
Sto tisíc operací rozložených do měsíce je přibližně 2,3 operace za minutu. Stejný objem za patnáct minut znamená přibližně 6 667 operací za minutu. To je 2 880× vyšší průměrné tempo. Jde o modelový výpočet pro třicetidenní měsíc, ne o srovnání nákladů konkrétní infrastruktury.
Proto bych oddělil, kolik práce zákazník kupuje a jak rychle ji může čerpat. V ceníku se vedle zahrnutého objemu může objevit počet souběžných úloh, rychlost zpracování nebo rezervovaná kapacita.
Browserbase to ukazuje přímo: plán Developer za 20 USD měsíčně zahrnuje 100 hodin prohlížeče, dalších za 0,12 USD za hodinu, a 25 souběžných prohlížečů. Startup za 99 USD zahrnuje 500 hodin, další za 0,10 USD, a souběh 100 prohlížečů. Jde o výřez nabídky, která má i další účtované služby. Ceník Browserbase
Výběr tarifu tak vyjadřuje i požadovaný způsob provozu. Firma může mít malý měsíční objem a přesto potřebovat rychle odbavit velkou špičku.
„Zaplatíte za výsledek“ potřebuje přesnou definici
U výsledkového pricingu se mi líbí, že zákazník kupuje něco blízkého vlastnímu cíli. Jenže slovo „výsledek“ musí přežít skutečný provoz i spor o fakturu.
Fin ve své dokumentaci uvádí sazbu 0,99 USD za účtovaný výsledek; popisovaný základní plán pro použití s vlastním helpdeskem stojí 49 USD měsíčně a zahrnuje 50 vyřešení. Mezi placené výsledky patří vyřešení i nakonfigurované předání postupu člověku. Vyřešení může být potvrzené zákazníkem nebo předpokládané, když po odpovědi dál nežádá pomoc. Pokud se vrátí do stejné konverzace pro další pomoc, dokumentace popisuje odečtení takového vyřešení. Fin: definice a účtování výsledků
Ten detail je pro mě podstatnější než samotných 99 centů. Výsledkový pricing potřebuje pravidla pro úspěch, reklamaci a atribuci. U „zpracovali jsme dokument podle definovaného zadání“ se dají stanovit poměrně konkrétně. U „zvýšili jsme produktivitu firmy“ bude výrazně těžší oddělit přínos produktu od všeho ostatního.
U nového produktu bych také předem rozhodl, kdo platí neúspěšné pokusy. Jestli jedno zadání kvůli chybě systému proběhne třikrát, zákazník potřebuje vědět, zda kupoval pokus, výpočetní čas, nebo hotový výstup. Opakované doručení stejného požadavku by nemělo bez vysvětlení vytvářet další fakturovanou práci.
Pricing patří do prvního použití produktu
Pro řadu takových služeb bych jako výchozí hypotézu zkusil paušál se zahrnutým objemem a jasně omezenou další spotřebou. Paušál může pokrýt průběžnou hodnotu platformy a základní obsluhu zákazníka. Zahrnutý objem mu umožní odhadnout běžný měsíc. Další spotřeba propojí růst používání s příjmy.
Není to automatická volba pro každý produkt. Čisté pay-as-you-go může sedět občasnému API použití. Předplacený závazek může vyhovovat velkému stabilnímu odběru. Cena za uživatele může dál dávat smysl tam, kde hodnotu vytváří spolupráce lidí. Hybrid má zase vlastní nevýhodu: zákazník platí minimum i v měsíci, kdy službu skoro nepoužije.
A hlavně, předvídatelná minimální faktura není předvídatelná konečná faktura. Bez limitu může nadspotřeba překvapit i u paušálu.
Firecrawl umožňuje nastavit měsíční limit automatického dokupování kreditů v násobcích pěti dolarů nebo ho vypnout. Ručně zakoupené kredity se do tohoto limitu nepočítají. Je to dobrý příklad toho, proč musí být rozsah limitu zřejmý. Pravidla Firecrawl pay-as-you-go
Při uvedení produktu bych chtěl zákazníkovi ukázat tři věci: kolik stojí jeho běžný scénář, co udělá desetinásobný provoz a co se přesně stane na rozpočtovém stropu. Zda se práce zastaví, počká ve frontě, nebo vyžádá schválení dalšího čerpání. Stejné informace by mělo umět vrátit i API, aby je mohl respektovat agent.
Tady se pricing potkává s onboardingem. Když se zákazník bojí úspěšně spustit automatizaci, protože neví, kolik bude stát, mám problém v produktu i v prodeji.
Co bych si ověřil před stanovením ceny
Nečekal bych na dokonalý pricing. Před spuštěním bych ale prošel jednu konkrétní zákaznickou úlohu od zadání po fakturu:
- Popsat kupovanou práci. Co přesně znamená dokument, vyhledání nebo hotový výsledek a co už je další jednotka?
- Změřit skutečné náklady. Napříč API, prohlížečem i plánovaným doručováním výstupů. Vedle běžných případů i velké vstupy, chyby, opakování a služby třetích stran. Průměr může zakrýt malou skupinu velmi drahých úloh.
- Spočítat tři scénáře. Běžný měsíc, úspěšný růst a chybnou smyčku. U každého příjem, náklady a okamžik zastavení.
- Ukázat nabídku zákazníkovi. Dokáže z ní odhadnout vlastní účet a říct, jestli za tuto jednotku chce platit? Nákladová kalkulace sama neprokáže ochotu zaplatit.
- Ověřit účtování v provozu. Stejnou úlohu propojit s přehledem spotřeby i fakturou, včetně vrácených plateb a opakovaných požadavků.
Moje sázka je, že agenti oslabí vztah mezi počtem lidí a množstvím spotřebované práce — přímým ovládáním aplikací i tím, kolik jejich výstupů dokážou zpracovat. U některých služeb výrazně, u jiných skoro vůbec. Pro foundera z toho plyne velmi praktický úkol: navrhnout cenu, při které je intenzivnější užitečné používání dobrá zpráva pro zákazníka i pro firmu.
Začal bych jednou otázkou: kdyby můj nejlepší zákazník zítra připojil agenta a začal produkt používat desetkrát víc, chtěl bych mu gratulovat, nebo vypnout přístup?
Zdroje a ceníky ověřeny 8. září 2026. Článek kombinuje autorovu zkušenost, veřejné produktové dokumentace a výslovně označené modelové výpočty. Dokumentace dokládají pravidla služeb; neposkytují měření dopadu externích agentů na jejich marže. Doporučení pro návrh pricingu jsou autorovou interpretací.