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 dál odvádí svou práci. Co se ale stane s její ekonomikou, když jeden zákazník začne za stejnou cenu zadávat mnohem víc práce?
Pro tvůrce nového produktu z toho plyne druhá otázka: co má zákazník kupovat, aby rozuměl ceně a intenzivnější používání se vyplatilo oběma stranám? Nejdřív se podívám na změnu provozu. Pak na to, jak ji promítnout do nabídky.
Jeden zákazník může zadat víc práce
Můj druhý mozek v Notionu je dobrý příklad změny způsobu používání. Agentovi zadám, aby uložil poznatek, dohledal souvislosti a aktualizoval záznam. Pořád jsem jeden zákazník. Jedna věta ale může spustit několik hledání, čtení a zápisů. Model platím jeho poskytovateli; Notion musí dál obsloužit svou část práce.
Objem si ukážeme na vymyšlené automatizaci. 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ěr je jen 1,2 volání za minutu. Za měsíc je to přesto přes padesát tisíc operací. Nejde o měření mého provozu ani 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 k 2. říjnu 2026 uvádí na jedno připojení 600 požadavků za minutu u tarifů Business a Enterprise, tedy průměrně 10 za sekundu. U ostatních tarifů je to 180 za minutu, průměrně 3 za sekundu. Platí také společný limit celého workspace. Nízký průměr proto nezaručuje, že se do limitů vejdou špičky a ostatní integrace.
Integrace a automatizace existují roky. Moje sázka je, že agenti zpřístupní intenzivnější používání více zákazníkům. Počet licencí pak může hůř vystihovat, kolik práce pro ně aplikace dělá. Vyšší počet operací ale sám o sobě nedokazuje vyšší náklady, horší marži ani nutnost zdražit. K tomu potřebujeme údaje z konkrétního provozu.
Počítejte práci i mimo veřejné API
Agent může ovládat aplikaci přes prohlížeč. SaaS přitom dál vyhledává, ukládá změny a připravuje exporty. Náklady na model a prohlížeč hradí provozovatel agenta; náklady na samotnou aplikaci tím nezmizí.
Prohlížeč ale automaticky neobchází kvóty. GitHub do některých sekundárních limitů vytváření obsahu zahrnuje web i REST a GraphQL API. Pokud dodavatel zdraží jen API, může zákazníka motivovat k jiné cestě. Zda na ní zákazník ušetří, závisí také na ceně a spolehlivosti ovládání prohlížeče.
Jindy agent aplikaci vůbec neovládá. Zpracovává reporty, které mu chodí e-mailem. Power BI například podporuje plánované odběry reportů a dashboardů; uvádí až 24 odběrů na report či dashboard podle oprávnění, licence a kapacity.
Když agent přečte stejné zprávy, které už dostával člověk, zdrojové službě nemusí přibýt žádná práce. Změna nastane až s dalšími objednanými výstupy. Ve vymyšleném příkladu přejdeme z jednoho souhrnu týdně na dvacet variant denně. Za čtyři týdny jsou to 4 souhrny proti 560 reportům, tedy 140× více výstupů. Neznamená to 140× vyšší náklady.
Rozlišujte nový výpočet od opakovaného stažení a rozeslání kopie. Dvacet různých reportů nemusí stát totéž jako dvacet kopií jednoho souboru. Strukturovaný výstup nebo oznámení změny naopak může nahradit opakované dotazování a spotřebu snížit.
Co už měří a prodávají dodavatelé
Google oznámil model kvót pro Workspace API a agentní nástroje, včetně připravované placené nadlimitní spotřeby. Dokumentace k 2. říjnu stále popisuje účtování později v roce 2026 po oznámení s 90denním předstihem. Neuvádí jednotkové ceny ani potvrzení plošného spuštění. Google odhaduje, že nad standardní úroveň půjde méně než 1 % aktivních vývojářů Workspace. Jde o odhad dodavatele pro vývojáře, ne pro koncové uživatele.
Drive API už rozlišuje váhu operací:
| Operace | 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í spotřebuje 40× více jednotek než uvedené čtení. To není měření nákladů Googlu. Ukazuje to, proč samotný počet požadavků nemusí stačit k řízení spotřeby. Plánované účtování povede přes Cloud projekt integrace, takže je potřeba vědět, kdo ho provozuje a komu náklady předá.
Ostatní dodavatelé také mají nástroje pro řízení automatizací. Salesforce popisoval dokoupení kapacity už v listopadu 2024, například o 10 000 API volání denně. Linear u workspace OAuth aplikací s Actor Authorization zvyšuje limity podle placených uživatelů a měří složitost GraphQL dotazů. Cena za člověka tedy může dál dávat smysl a zároveň určovat prostor pro jeho automatizace.
Spotřebu hlídejte už při používání agenta
Jako uživatel bych si hlídal, co agent spouští. Může rychle zadat víc databázových dotazů, nahrát víc dat nebo použít víc služeb, než bych stihl ručně. Část té práce může být zbytečná. Proto chci přehled spotřeby a upozornění při dosažení domluvených úrovní útraty.
Upozornění a strop mají odlišný účel. Zpráva mi řekne, že spotřeba roste. Rozpočet omezí až pravidlo, které další placenou práci zastaví nebo si vyžádá souhlas. Potřebuji vědět, na jaké službě každé z těchto pravidel platí, včetně služeb, které agent volá dál.
Jak porovnávat jednotky ceny
Konkrétní jednotku pro vlastní produkt zatím vybranou nemám. Přizval bych člověka, který se cenotvorbě věnuje, a podrobně prozkoumal současné nabídky i chování zákazníků. Zkušenosti s cenami softwaru jsou užitečné, ale intenzivní používání prostřednictvím agentů přidává nové otázky. Následující možnosti proto beru jako podklady k ověření.
Začal bych prací, kterou zákazník kupuje. U dokumentů může rozumět zpracované stránce, u vyhledávání dotazu s určeným rozsahem, u monitoringu sledovanému objektu a četnosti kontrol. Nabídka musí vysvětlit také výjimky: stostránkový sken, hlubší hledání nebo opakovaný pokus.
Kredity mohou různé operace převést na jednu jednotku. Firecrawl například uvádí jeden kredit za stránku základního scrape, dva za deset výsledků hledání a dva za minutu interakce s prohlížečem. Zákazník ale stále potřebuje převod na svou úlohu. Interní náklady mohou mít jinou strukturu než jednotka na faktuře.
Vedle objemu bych oddělil rychlost čerpání a souběh. Sto tisíc operací za třicetidenní měsíc znamená průměrně asi 2,3 operace za minutu. Stejný objem za patnáct minut znamená asi 6 667 za minutu: 2 880× vyšší tempo, nikoli stejný násobek nákladů.
Browserbase toto rozlišení ukazuje v nabídce: Developer za 20 USD měsíčně zahrnuje 100 hodin prohlížeče, další po 0,12 USD, a souběh 25 prohlížečů. Startup za 99 USD zahrnuje 500 hodin, další po 0,10 USD, a souběh 100. Jde o část nabídky s dalšími účtovanými službami. Malý měsíční objem může stále potřebovat velkou kapacitu v krátké špičce.
Výsledek a neúspěšný pokus nejsou stejná jednotka
Cena za výsledek je blízká cíli zákazníka. Potřebuje ale přesnou definici. Fin uvádí 0,99 USD za účtovaný výsledek; popsaný základní plán s vlastním helpdeskem stojí 49 USD měsíčně a zahrnuje 50 vyřešení. Mezi výsledky patří i nakonfigurované předání postupu člověku. Vyřešení může být potvrzené nebo předpokládané, když zákazník dál nežádá pomoc. Pokud se vrátí do stejné konverzace pro další pomoc, dokumentace popisuje odečtení vyřešení.
Na podobných pravidlech záleží víc než na názvu cenového modelu. Zákazník potřebuje vědět, zda kupuje pokus, čas, nebo dokončený výstup. Když systém kvůli vlastní chybě zopakuje úkol třikrát, musí být jasné, kdo tyto pokusy zaplatí. Také opakované doručení stejného požadavku potřebuje pravidlo, aby bez vysvětlení nevznikla další fakturovaná práce.
Ukažte cenu na jednom celém příkladu
Jednou z možností k ověření je paušál se zahrnutým objemem a omezeným dalším čerpáním. Paušál sám ale konečnou fakturu neomezuje. Firecrawl například nabízí u placených tarifů automatické dokupování po pěti dolarech až do nastaveného měsíčního limitu.
Následující nabídka je zcela vymyšlená pro vysvětlení účtování. Nejde o ceník skutečného produktu ani doporučení těchto částek: 500 Kč měsíčně zahrnuje 1 000 úspěšně zpracovaných stránek. Další stránka stojí 0,50 Kč. Zákazník nastaví celkový měsíční strop 1 500 Kč; při jeho dosažení nové stránky čekají na schválení dalšího rozpočtu.
| Situace | Co zákazník uvidí |
|---|---|
| Běžný měsíc: 1 000 stránek | Účet 500 Kč. |
| Desetinásobný objem: 10 000 stránek | Bez stropu by účet byl 5 000 Kč. Se stropem se zpracují nejvýše 3 000 stránek za 1 500 Kč; zbývajících 7 000 čeká. |
| Chyba vyvolá další pokusy nad stejnou stránkou | Nabídka účtuje úspěšný výstup jednou. Interní náklady pokusů nese dodavatel a hlídá jejich počet. |
Tento model ještě neříká, zda je služba zisková nebo zda za ni lidé chtějí platit. Ukazuje, co má zákazník pochopit před spuštěním agenta. Přehled spotřeby i API musí sdělit zbývající rozpočet a stav čekající práce. Technické omezení pokusů musí zastavit chybnou smyčku také tehdy, když zákaznická faktura neroste.
Paušál není jediná možnost. Občasnému API použití může sedět platba podle spotřeby, stabilnímu velkému odběru předplacený závazek. Cena za uživatele může odpovídat spolupráci lidí. Vybral bych model podle kupované hodnoty a nákladů, nikoli podle toho, který je právě populární.
Co bych ověřil před spuštěním
Prošel bych jednu zákaznickou úlohu od zadání až po fakturu:
- Vymezit práci. Co je jedna jednotka a co už další? Jak se liší nový výpočet, kopie a opakovaný požadavek?
- Změřit náklady. Zahrnout běžné i velké vstupy, chyby, pokusy a služby třetích stran. Rozlišit API, prohlížeč a plánované výstupy.
- Spočítat běžný měsíc, růst a chybnou smyčku. U každého příjem, náklady a bod zastavení.
- Dát nabídku zákazníkovi. Umí odhadnout účet a chce za tuto práci platit? Kalkulace nákladů ochotu zaplatit neprokáže.
- Porovnat spotřebu s fakturou. Ověřit také opakované požadavky a vrácené platby.
Pokud zákazník váhá spustit automatizaci, protože neví, kolik zaplatí, je potřeba upravit nabídku i první použití produktu. Chtěl bych, aby jeho intenzivnější užitečné používání bylo dobrou zprávou pro obě strany. Začal bych otázkou: co se stane, když můj nejlepší zákazník zítra připojí agenta a zadá desetkrát víc práce?
Původní článek vyšel 8. září 2026; podklady byly znovu prověřeny při úpravě 2. října. Text rozlišuje autorovu zkušenost, veřejná pravidla služeb a vymyšlené výpočty. Veřejné podklady neukazují dopad externích agentů na marže dodavatelů. Návrh ceny a pravidel účtování je autorovou interpretací.