Projekt srovnan se zasadami v D:\GitHubRepository\CLAUDE.md bez zmeny chovani.
Struktura: scripts/ (skripty konektoru) -> connectors/, src/scripts ->
src/runtime/scripts; src/index.ts jen startuje, novy src/app.ts s createApp();
routes/dashboard.ts a routes/settings.ts rozdeleny do slozek; openapi.ts
rozdelen na openapi/{index,helpers,components} a paths/* (98 cest overeno
shodnych); ticketStore, automationStore a services jsou fasady nad slozkami
data/tickets, data/automations a data/services/catalog. process.env se cte
jen v config.ts. Web: hooky v hooks/, sdilena ui/Table a ui/ServiceIcon,
surove inputy nahrazeny komponentami, sedm velkych souboru rozdeleno.
Nastroje: eslint (typescript-eslint, react-hooks v7), prettier, editorconfig,
nvmrc, .env.example, vitest; skripty lint, format, test. Lint je cisty bez
jedineho eslint-disable (nove hooky useLatest a useSyncFromSource, odvozeny
stav misto setState v effectu). noUncheckedIndexedAccess v obou tsconfig,
84 mist zuzeno bez non-null operatoru; odhalilo zalohu backoffu fronty pri
nule pokusu a Retry-After NaN pri max 0. Cely kod naformatovan prettierem.
Testy: 8 souboru, 105 testu (prava, viditelnost, podminky a opakovani
v executoru, redaktor tajemstvi, sitove guardy, migrace resitelu, tickety,
health a prihlaseni pres supertest). Testy odhalily dve chyby ve vyhodnoceni
podminek, obe opravene: chybejici castka se porovnavala jako nula a podminka
nad vystupem druheho kroku cetla hodnotu prvniho se stejnym nazvem.
Pojmenovane konstanty misto magickych hodnot, ctx.util.base64 pro skripty
konektoru, README a dokumentace aktualizovany vcetne znamych odchylek.
5.4 KiB
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:
- Cena u operace. Do katalogu (
src/data/services/catalog/) přidatpriceCzkkServiceOperation. Chybějící cena znamená 0, ne chybu - nová operace nesmí rozbít odhad. - 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.
- 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.
- 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
- Úč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.
- Účtuje se opakování po chybě? Návrh: první opakování zdarma, další ano.
- Účtují se kroky v testovacím režimu? Návrh: ne, ale s denním limitem, aby se testem ceník neobcházel.