Umowa SaaS

Umowa SaaS określa zasady korzystania z oprogramowania udostępnianego online, najczęściej w modelu subskrypcyjnym. W praktyce nie zawsze jest to jeden klasyczny dokument podpisywany przez strony. W zależności od modelu sprzedaży może to być regulamin SaaS, Terms of Service, umowa B2B, zamówienie, SLA, DPA, polityka prywatności oraz dokumentacja produktowa.

Dobrze przygotowana umowa SaaS powinna odpowiadać na pytania, które wprost wpływają na bezpieczeństwo biznesu: kto może korzystać z usługi, w jakim zakresie, na jakich warunkach płatniczych, co dzieje się przy braku płatności, jak wygląda odpowiedzialność dostawcy, kiedy można ograniczyć dostęp do konta, jak obsługiwane są dane i co dzieje się po zakończeniu współpracy.

W modelu SaaS dokumentacja prawna nie jest dodatkiem formalnym. To część modelu sprzedaży, obsługi klienta i skalowania produktu.

To zależy od sposobu sprzedaży produktu. Jeżeli SaaS jest udostępniany wielu użytkownikom na powtarzalnych zasadach, podstawą często jest regulamin albo Terms of Service. Taki dokument określa zasady rejestracji, korzystania z konta, płatności, subskrypcji, ograniczeń technicznych, odpowiedzialności i zakończenia usługi.

Jeżeli jednak produkt jest sprzedawany klientom B2B, większym organizacjom albo w modelu enterprise, sam regulamin może nie wystarczyć. Wtedy warto przygotować również umowę B2B, formularz zamówienia, SLA, warunki wsparcia technicznego albo indywidualne postanowienia dotyczące wdrożenia, integracji i odpowiedzialności.

Najbezpieczniejszy model często polega na połączeniu kilku dokumentów: Terms of Service jako dokument bazowy, zamówienie jako dokument handlowy, SLA jako załącznik techniczny oraz DPA jako dokument dotyczący przetwarzania danych.

Dobra umowa SaaS powinna być dopasowana do produktu, a nie skopiowana z przypadkowego wzoru. Inaczej wygląda dokumentacja dla prostego narzędzia online, inaczej dla platformy B2B, a inaczej dla systemu, który obsługuje dane klientów, procesy finansowe, sprzedażowe albo operacyjne.

W praktyce umowa SaaS powinna regulować przede wszystkim:

• zakres usługi i funkcjonalności produktu,
• zasady zakładania konta i dostępu użytkowników,
• model płatności, subskrypcji, triali i odnowień,
• warunki zmiany pakietu lub wypowiedzenia usługi,
• ograniczenia korzystania z systemu,
• prawa do oprogramowania i treści,
• odpowiedzialność dostawcy i klienta,
• SLA, dostępność i przerwy techniczne,
• zasady wsparcia technicznego,
• przetwarzanie danych i bezpieczeństwo informacji,
• skutki naruszenia warunków przez użytkownika,
• zasady zakończenia współpracy i eksportu danych.

Największy błąd polega na tym, że wiele dokumentów SaaS opisuje usługę zbyt ogólnie. Wtedy przy sporze, reklamacji, awarii albo rozmowie z dużym klientem okazuje się, że umowa nie odpowiada na realne problemy operacyjne.

Regulamin SaaS najczęściej wystarcza wtedy, gdy produkt jest sprzedawany na powtarzalnych, standardowych warunkach, a użytkownik akceptuje zasady online. Dotyczy to szczególnie produktów samoobsługowych, prostych subskrypcji, aplikacji webowych, narzędzi dla mniejszych firm albo usług zautomatyzowanych.

Osobna umowa B2B jest potrzebna wtedy, gdy klient oczekuje indywidualnych warunków, negocjuje odpowiedzialność, wymaga SLA, potrzebuje wdrożenia, integracji, niestandardowych funkcji, większego pakietu użytkowników albo szczególnych zasad przetwarzania danych.

W praktyce im większy klient i większe znaczenie produktu dla jego działalności, tym większa potrzeba dodatkowej umowy. Regulamin porządkuje standardowy model, ale umowa B2B pozwala obsłużyć relacje strategiczne, większe wdrożenia i klientów enterprise.

Model płatności w SaaS powinien być opisany bardzo precyzyjnie. Dotyczy to nie tylko ceny, ale również okresów rozliczeniowych, automatycznego odnowienia, zmiany planu, okresu próbnego, opóźnień w płatności, podatków, waluty, fakturowania i skutków braku zapłaty.

W umowie warto określić między innymi, czy subskrypcja odnawia się automatycznie, kiedy klient może zrezygnować, co dzieje się po zakończeniu okresu próbnego, czy opłata jest zwracana przy wcześniejszym rozwiązaniu umowy oraz kiedy dostawca może ograniczyć dostęp do usługi.

Szczególnie ważne są sytuacje graniczne: brak płatności, chargeback, rezygnacja po rozpoczęciu okresu rozliczeniowego, zmiana pakietu w trakcie miesiąca, dezaktywacja konta i dostęp do danych po zakończeniu subskrypcji. To właśnie te sytuacje najczęściej powodują spory, jeżeli dokumentacja jest zbyt ogólna.

W SaaS dostawca powinien jasno określić, za co odpowiada, a za co nie. Produkt cyfrowy zwykle działa w określonym środowisku technicznym, korzysta z infrastruktury zewnętrznej, integracji, usług płatniczych, hostingu, API lub narzędzi podwykonawców. Umowa powinna uwzględniać te zależności.

W praktyce warto uregulować odpowiedzialność za dostępność usługi, błędy systemu, utratę danych, przerwy techniczne, integracje zewnętrzne, działania użytkowników, nieprawidłową konfigurację konta oraz korzystanie z produktu niezgodnie z jego przeznaczeniem.

Nie chodzi o to, aby całkowicie wyłączyć odpowiedzialność, bo takie podejście może być nieskuteczne lub nieakceptowalne biznesowo. Chodzi o to, aby odpowiedzialność była przewidywalna, proporcjonalna do wartości usługi i dopasowana do realnego wpływu dostawcy na działanie produktu.

SLA warto przygotować wtedy, gdy dostępność systemu, czas reakcji na zgłoszenia albo wsparcie techniczne mają znaczenie dla klienta. Dotyczy to szczególnie produktów B2B, systemów wykorzystywanych operacyjnie, narzędzi dla zespołów sprzedażowych, finansowych, HR, e-commerce, fintech albo klientów enterprise.

SLA powinno jasno określać, jaki poziom dostępności deklaruje dostawca, jak mierzy się dostępność, jakie przerwy są wyłączone z kalkulacji, jak zgłaszane są błędy, jakie są czasy reakcji i jakie konsekwencje przewidziano w przypadku niedotrzymania parametrów.

Dobrze przygotowane SLA nie powinno obiecywać więcej, niż firma jest w stanie faktycznie zapewnić. Zbyt ambitne SLA może wyglądać dobrze sprzedażowo, ale później tworzyć ryzyko roszczeń, kar, reklamacji albo utraty zaufania klientów.

Jeżeli produkt SaaS przetwarza dane osobowe użytkowników, klientów albo danych wprowadzanych przez klientów do systemu, dokumentacja powinna jasno określać role stron i zasady przetwarzania. W zależności od modelu produktowego dostawca może działać jako administrator, podmiot przetwarzający albo w różnych rolach dla różnych kategorii danych.

W praktyce często potrzebna jest umowa powierzenia przetwarzania danych, czyli DPA, a także polityka prywatności, informacje o podwykonawcach, transferach danych, lokalizacji infrastruktury, czasie przechowywania danych i zasadach ich usuwania po zakończeniu współpracy.

W SaaS szczególnie ważne jest odróżnienie danych konta użytkownika od danych wprowadzanych przez klienta do systemu. To dwa różne poziomy ryzyka i często dwa różne modele odpowiedzialności.

W modelu SaaS klient zwykle nie nabywa praw do oprogramowania. Otrzymuje dostęp do usługi na określonych warunkach. Umowa powinna to jasno wskazywać, aby nie powstało wrażenie, że klient uzyskuje prawo do kodu, kopii systemu, infrastruktury, dokumentacji technicznej albo elementów produktu.

Warto określić, że prawa do oprogramowania, interfejsu, technologii, baz danych, dokumentacji, znaków towarowych i know-how pozostają przy dostawcy lub właściwym właścicielu praw. Klient otrzymuje wyłącznie ograniczone prawo korzystania z usługi w czasie trwania subskrypcji.

To ma znaczenie zwłaszcza przy produktach B2B, integracjach, wdrożeniach i indywidualnych konfiguracjach. Bez jasnych postanowień może powstać spór o to, czy klient ma prawo żądać kodu, kopii systemu, dokumentacji albo dalszego korzystania po zakończeniu umowy.

Umowa SaaS powinna określać, czego użytkownik nie może robić w ramach korzystania z produktu. Dotyczy to między innymi prób obejścia zabezpieczeń, udostępniania konta osobom nieuprawnionym, kopiowania elementów systemu, reverse engineeringu, przeciążania infrastruktury, naruszania praw osób trzecich albo wykorzystywania produktu do działań niezgodnych z prawem.

Warto również określić, kiedy dostawca może zablokować konto, ograniczyć dostęp do usługi albo usunąć treści użytkownika. Te mechanizmy powinny być opisane jasno, bo w praktyce pozwalają reagować na nadużycia bez improwizowania decyzji w sytuacji kryzysowej.

Dobrze napisane postanowienia ochronne są szczególnie ważne przy produktach z funkcjami współdzielenia danych, generowania treści, automatyzacji, komunikacji, integracji z API albo zapraszania wielu użytkowników do jednego konta organizacji.

Koszt zależy od tego, czy potrzebny jest jeden dokument, czy cały zestaw dokumentacji dla produktu. Inaczej wycenia się prosty regulamin dla aplikacji, inaczej Terms of Service dla usługi B2B, a inaczej dokumentację obejmującą umowę SaaS, SLA, DPA, politykę prywatności, warunki subskrypcji i wsparcie przy wdrożeniu w procesie sprzedaży.

Na koszt wpływa między innymi model produktu, liczba typów klientów, sprzedaż B2B lub B2C, dane osobowe, integracje, płatności, rynek zagraniczny, poziom indywidualizacji dokumentów oraz to, czy dokumentacja ma być przygotowana od zera, czy uporządkowana na bazie istniejących materiałów.

Najrozsądniej zacząć od analizy modelu SaaS i ustalenia, które dokumenty są rzeczywiście potrzebne. Celem nie jest tworzenie nadmiarowej dokumentacji, tylko takiej, która zabezpiecza kluczowe ryzyka i wspiera sprzedaż produktu.