csbot-prototype/documentation/16-monetizace.md

Návrh monetizace a cena za krok

Stav: návrh, není naprogramované. Zbytek dokumentace popisuje hotové věci, tenhle soubor ne - viz 99-zmeny.md.

Zadání bylo: chci si napsat vlastní automatizaci a hned vidět, kolik by mě měsíčně stála, když si k jednotlivým krokům zadám ceny (například iDoklad, odeslání objednávky, 0,10 Kč).

Co se dá účtovat

Čtyři věci, každá měří něco jiného:

Základ	Co to znamená	Proč / proč ne
Za uživatele	Kolik lidí má přístup do portálu	Předvídatelné, ale nesouvisí s tím, co aplikace dělá. U automatizací platí zákazník za lidi, kteří tam nemusí chodit.
Za automatizaci	Kolik má zapnutých stromů	Trestá to rozdělení jednoho velkého stromu na tři přehledné. Špatná motivace.
Za krok	Kolik kroků se skutečně vykonalo	Odpovídá naší práci: každý krok je jedno volání služby, jeden zápis, jeden běh skriptu. Zákazník vidí, za co platí.
Za objem dat	Kolik toho proteče	Nesouvisí s náklady, u nás jsou to kilobajty.

Doporučení: paušál plus kroky. Paušál kryje portál, tickety, úložiště a podporu, kroky kryjí provoz automatizací. Bez paušálu je zákazník, který má automatizace vypnuté, zdarma, a přesto mu běží ticketovací systém.

Ceník kroků

Cena patří k operaci v katalogu, ne ke službě. Zápis faktury do iDokladu a jeho dotaz na kontakt stojí jinak, protože nás jinak stojí.

Tři pásma:

Pásmo	Příklady	Návrh ceny
Obecné	pauza, zápis do logu, podmínka, transformace dat	0 Kč. Účtovat podmínku je jako účtovat mezeru v textu.
Naše práce	webhook, plánovač, založení ticketu, přiřazení řešitele, HTTP požadavek	0,02 Kč
Cizí služba	iDoklad, Shoptet, SAP, CRM, hlasová brána, AI	0,05 až 0,50 Kč podle toho, co za to platíme sami

Číslo je jedno pole u operace, takže se dá měnit bez zásahu do kódu. Ceník je verzovaný: změna ceny nepřepíše historii, jinak by se zpětně změnila i vyúčtovaná částka.

Odhad ceny v editoru

Co k tomu je potřeba:

1. Cena u operace. Do katalogu (src/data/services.ts) přidat priceCzk k ServiceOperation. Chybějící cena znamená 0, ne chybu - nová operace nesmí rozbít odhad.
2. Očekávaný počet běhů. Jedno číslo u automatizace, které zadá uživatel ("čekám 400 objednávek denně"). Bez něj nejde nic spočítat a hádat to za uživatele by dalo číslo, kterému nebude věřit.
3. Součet přes strom. Podmínka má dvě větve a projde se vždycky jen jedna. Pro odhad se bere dražší větev, aby výsledek byl horní hranice, ne příjemné číslo, které se pak překročí. Vedle se ukáže i levnější varianta.
4. Zobrazení. V editoru u každého kroku jeho cena, nahoře součet za běh a za měsíc. Jedna funkce, obě čísla, žádný druhý výpočet na klientovi.

Odhad je záměrně jen odhad: skutečná fakturace se počítá ze skutečně vykonaných kroků zapsaných při běhu, ne z toho, co editor předpověděl.

Skutečné vyúčtování

Každý vykonaný krok už teď zapisuje řádek do logu ticketu nebo běhu automatizace. Na fakturaci z toho chybí:

• u řádku evidovat firmu, operaci a cenu platnou v tu chvíli,
• denní součet za firmu (aby se faktura nepočítala přes miliony řádků),
• měsíční uzávěrka, která součty zamkne.

Model je stejný jako u auditu: připisovací tabulka, nic se nepřepisuje. Uzavřený měsíc se nedá změnit, jen opravit dobropisem.

Balíčky

Cena za krok samotná zákazníka děsí, protože nezná svoje čísla. Proto balíčky s předplacenými kroky a stejnou cenou nad limit:

Balíček	Paušál	Kroků v ceně	Nad limit
Start	490 Kč	5 000	0,05 Kč
Provoz	1 900 Kč	40 000	0,04 Kč
Firma	6 900 Kč	200 000	0,03 Kč

Nad limit se nevypíná. Zastavit zákazníkovi fakturaci objednávek kvůli překročení limitu je horší než mu to dofakturovat. Limit hlásí varování v portálu a e-mailem.

Co je potřeba rozhodnout

1. Účtují se kroky, které skončily chybou? Návrh: ne u naší chyby, ano u chyby cizí služby, protože volání jsme opravdu zaplatili. Musí to být v ceníku vidět, jinak to vypadá jako počítání chyb ve svůj prospěch.
2. Účtuje se opakování po chybě? Návrh: první opakování zdarma, další ano.
3. Účtují se kroky v testovacím režimu? Návrh: ne, ale s denním limitem, aby se testem ceník neobcházel.