Co musí SaaS smlouva řešit, aby byla skutečně použitelná
U SaaS neprodáváte jednorázový produkt, ale průběžně poskytovanou službu. To zásadně mění strukturu smlouvy: nestačí popsat licenci, ale je nutné přesně vymezit rozsah služby, dostupnost, podporu, bezpečnost, zpracování dat i ukončení spolupráce. V praxi se vyplatí vycházet z jednoduchého pravidla: čím více je software napojený na provoz zákazníka, tím detailnější musí být smluvní rámec.
Nejčastější chyba bývá používání generické licenční smlouvy pro cloudový nástroj. Ta obvykle neřeší SLA, incident management, zálohování ani export dat při ukončení. U B2B SaaS je přitom standardem, že smlouva obsahuje minimálně obchodní podmínky, zpracovatelskou smlouvu podle GDPR a přílohu se SLA. Podle typu služby se doplňuje i DPA, bezpečnostní politika nebo pravidla subdodavatelů.
Jak správně vymezit předmět plnění a rozsah služby
Nejdůležitější část smlouvy je přesný popis toho, co zákazník dostává. Nestačí napsat „přístup k softwaru“. Uveďte název služby, funkční moduly, limity účtů, úložiště, počet integrací, API přístupy, jazykové mutace a případné geografické omezení. Pokud má balíček více tarifů, musí být jasné, co je v ceně a co už je placený nadstandard.
Praktický příklad: pokud nabízíte CRM jako SaaS, specifikujte například:
- počet uživatelských licencí v tarifu,
- limit kontaktů nebo záznamů v databázi,
- kapacitu úložiště pro přílohy,
- zda je součástí automatizace e-mailů,
- jaké integrace jsou nativní a jaké přes API,
- zda služba zahrnuje onboarding a migraci dat.
V praxi je vhodné oddělit funkční specifikaci do přílohy, aby bylo možné ji aktualizovat bez nutnosti měnit celý kontrakt. To je důležité hlavně u rychle se vyvíjejících produktů, kde se funkce mění každých několik týdnů. Pokud máte product roadmapu, promítněte do smlouvy i to, že některé funkce mohou být dočasně beta a bez garance dostupnosti.
SLA, dostupnost a podpora: čísla, která musí být konkrétní
U SaaS je SLA často rozhodující část smlouvy. Zákazník chce vědět, jaká je dostupnost služby, jak rychle reagujete na incidenty a jak se řeší výpadky. Obecné formulace typu „poskytovatel vynaloží maximální úsilí“ jsou v B2B praxi slabé a často vedou ke sporům. Mnohem lepší je pracovat s měřitelnými parametry.
Typická SLA metrika vypadá takto:
- dostupnost služby: 99,5 % měsíčně,
- reakční doba na incident P1: do 30 minut,
- reakční doba na incident P2: do 4 hodin,
- čas obnovy provozu: do 8 hodin u kritické závady,
- údržbové okno: například neděle 01:00–05:00 CET,
- kanály podpory: e-mail, ticketing, telefon pro kritické incidenty.
Pro měření dostupnosti využijte nástroje jako UptimeRobot, Pingdom, Better Stack nebo Datadog. Pokud smlouvu stavíte profesionálně, definujte i to, co se do výpadku nezapočítává: plánovaná údržba, zásah třetích stran, chyba zákazníka, nedostupnost internetu na straně klienta nebo vyšší moc. Součástí SLA by mělo být i kompenzační schéma, například servisní kredit ve výši 5–15 % měsíčního poplatku při překročení limitu nedostupnosti.
Velmi užitečné je rozlišit podporu podle priority. Například P1 znamená úplné odstavení služby, P2 omezenou funkčnost a P3 drobné chyby bez dopadu na provoz. Tím nastavíte realistická očekávání a zároveň se vyhnete tomu, že zákazník bude reklamovat i kosmetické problémy jako incidenty kritické povahy.
Data, GDPR a bezpečnost: část smlouvy, která chrání obě strany
U SaaS je zpracování dat často jádrem celé služby, a proto musí být právní i technické podmínky velmi přesné. Pokud zákazník do systému ukládá osobní údaje, je potřeba mít jasně definované role správce a zpracovatele. Zpracovatelská smlouva by měla řešit účel zpracování, kategorie údajů, dobu uchování, subzpracovatele, zabezpečení i postup při porušení bezpečnosti.
Bezpečnostní příloha by měla obsahovat minimálně:
- šifrování dat při přenosu pomocí TLS 1.2+ nebo 1.3,
- šifrování dat v klidu,
- dvoufaktorové ověření pro administrátory,
- role-based access control,
- logování přístupů a administrátorských akcí,
- pravidla pro zálohování a test obnovy,
- oznámení bezpečnostního incidentu například do 24 hodin od zjištění.
Pokud pracujete s citlivějšími daty, přidejte i informace o datové lokalitě. Zákazník často vyžaduje, aby data zůstala v EU, případně v konkrétní zemi. V takovém případě je vhodné uvést i cloudového providera a seznam subdodavatelů. U větších klientů bývá standardem bezpečnostní dotazník a někdy i audit podle ISO 27001 nebo SOC 2. Pokud certifikaci máte, uveďte to ve smlouvě nebo v příloze jako důkazní rámec důvěryhodnosti.
Nezapomeňte na pravidla pro export a smazání dat po ukončení smlouvy. Praktický standard je 30denní lhůta na stažení dat po skončení služby, následovaná řízeným výmazem a potvrzením o likvidaci dat. Tohle je oblast, která bývá podceňovaná, ale v praxi rozhoduje o tom, zda klient službě důvěřuje i po skončení spolupráce.
Cena, fakturace, změny podmínek a ukončení spolupráce
Obchodní část smlouvy by měla být stejně přesná jako technická. U SaaS je ideální uvést způsob účtování, periodicitu, splatnost, měnu, indexaci ceny a pravidla pro navýšení počtu uživatelů nebo spotřeby. Pokud používáte více tarifů, jasně definujte, co se stane při překročení limitu: automatický upgrade, doplatek podle ceníku, nebo omezení služby.
V praxi doporučuji přidat tyto body:
- fakturace měsíčně nebo ročně předem,
- splatnost 14 dní,
- automatické prodloužení smlouvy o 12 měsíců, pokud není vypovězena,
- výpovědní lhůta 30 dní u měsíčních tarifů nebo 3 měsíce u ročních smluv,
- indexace ceny podle inflace nebo růstu nákladů na infrastrukturu,
- pravidla pro změnu ceníku s oznámením předem, například 30 dní.
Velmi důležité je také ukončení služby. Smlouva musí odpovědět na to, jak dlouho bude data možné exportovat, v jakém formátu je zákazník obdrží a zda pomoc s migrací stojí extra. Typický a praktický standard je export do CSV, JSON nebo ZIP archivu přes administraci nebo API. Pokud je řešení složitější, můžete nabídnout placenou exit assistance, například 5 hodin konzultací za fixní cenu. Tím minimalizujete konflikty při odchodu klienta a zároveň vytvoříte profesionální dojem.
Jak smlouvu připravit tak, aby fungovala i v praxi, ne jen na papíře
Nejlepší SaaS smlouvy vznikají ve spolupráci právníka, produktového manažera, vývojáře a supportu. Právník zajistí soulad s legislativou, ale technické detaily musí dodat tým, který službu skutečně provozuje. Jinak vznikne dokument, který sice dobře vypadá, ale neodpovídá realitě produktu.
Osvědčený postup je tento:
- sepsat funkční specifikaci služby a tarifů,
- definovat SLA podle reálných kapacit týmu,
- připravit DPA a bezpečnostní přílohu,
- nastavit obchodní podmínky včetně výpovědi a fakturace,
- otestovat smlouvu na 2–3 modelových zákaznících,
- pravidelně aktualizovat dokumentaci podle vývoje produktu.
Užitečné jsou také interní nástroje jako Notion nebo Confluence pro správu verzí dokumentace, Juro nebo PandaDoc pro řízení smluvního workflow a DocuSign nebo Signi pro elektronický podpis. Pokud prodáváte SaaS mezinárodně, sledujte i lokalizaci podmínek, rozdíly v právu a měnové nastavení. U enterprise klientů se často vyplatí mít master agreement, objednávku a samostatné přílohy, aby bylo možné jednotlivé části flexibilně upravovat bez přepisování celé smlouvy.
Dobře nastavená SaaS smlouva není jen ochrana proti sporům, ale také obchodní nástroj. Zvyšuje důvěru, zrychluje uzavírání zakázek a snižuje počet nejasností při provozu služby. Když je postavená na konkrétních číslech, jasných odpovědnostech a realistických procesech, pomáhá škálovat produkt bez zbytečných právních i provozních překvapení.
