Model SaaS upraszcza dystrybucję oprogramowania, ale komplikuje relację prawną. Klient nie kupuje programu raz na zawsze. Otrzymuje dostęp do stale rozwijanej usługi, zależnej od infrastruktury, integracji, podwykonawców i danych. Dokumentacja musi odzwierciedlać tę dynamikę.
Największy błąd to adaptowanie klasycznej licencji na oprogramowanie bez sprawdzenia, jak produkt faktycznie działa. Umowa SaaS powinna powstać razem z zespołem produktu, sprzedaży i security.
Self-service, mid-market i enterprise to różne modele umowne
Przy sprzedaży samoobsługowej dokumentem bazowym jest zwykle regulamin lub Terms of Service akceptowany online. Klient enterprise częściej oczekuje indywidualnej umowy, SLA, DPA, załącznika bezpieczeństwa i czasem własnych standardów zakupowych.
Warto zdecydować, które elementy są wspólne dla wszystkich klientów, a które podlegają negocjacjom. Bez takiego podziału sprzedaż może zgadzać się na wyjątki, których produkt i support nie są w stanie później obsłużyć.
Zakres usługi, plany i funkcjonalności
Umowa powinna określać, z jakiego produktu klient korzysta, ilu ma użytkowników, jakie limity obowiązują i które funkcje należą do danego planu. Nie chodzi o przenoszenie całej dokumentacji produktu do umowy, lecz o wyznaczenie granicy między gwarantowaną usługą a roadmapą.
Jeżeli dostawca regularnie zmienia funkcjonalności, warto uregulować zasady takich zmian i sposób komunikacji. Dla klienta enterprise istotne może być, czy krytyczna funkcja może zostać wyłączona bez okresu przejściowego.
SLA, support i dostępność
SLA powinno odpowiadać temu, co zespół techniczny rzeczywiście mierzy. Warto zdefiniować sposób liczenia dostępności, wyłączenia, planowane prace serwisowe, klasy incydentów i czas reakcji supportu.
Jeżeli strony uzgadniają service credits lub inne konsekwencje niedotrzymania poziomu usługi, trzeba określić sposób ich naliczenia i relację do pozostałej odpowiedzialności. SLA nie powinno powstawać wyłącznie w negocjacjach prawników — musi być wykonalne operacyjnie.
Najlepsze SLA jest zbudowane na rzeczywistym monitoringu i procedurach incident response.
Abonament, odnowienie i zmiana cen
Model rozliczeń powinien opisywać okres abonamentowy, sposób fakturowania, podatki, opłaty za przekroczenie limitów, zawieszenie usługi przy braku płatności oraz zasady zmiany planu. Przy umowach wieloletnich ważna jest waloryzacja i mechanizm zmiany ceny.
Automatyczne odnowienie powinno być jednoznaczne: kiedy następuje, na jaki okres i do kiedy klient może złożyć wypowiedzenie. W przeciwnym razie z pozornie prostego mechanizmu powstaje spór handlowy.
Dane klienta, DPA i bezpieczeństwo
Produkt SaaS często przetwarza dane w imieniu klienta. Trzeba ustalić role stron, zakres powierzonych danych, podwykonawców, lokalizację, zasady reagowania na incydenty i zwrot lub usunięcie danych po zakończeniu usługi.
Duzi klienci mogą oczekiwać szczegółowego security addendum. Dostawca powinien wcześniej ustalić, które zobowiązania odpowiadają realnemu poziomowi bezpieczeństwa i jakie informacje może udostępniać bez narażania własnej infrastruktury.
IP: kod dostawcy, integracje i treści klienta
Klient SaaS zazwyczaj nie nabywa praw do kodu platformy. Otrzymuje prawo korzystania z usługi w określonym zakresie. Trzeba jednak oddzielić IP dostawcy od treści i danych klienta, materiałów tworzonych podczas wdrożenia oraz integracji.
Warto uregulować również feedback produktowy, materiały demonstracyjne, wykorzystanie logo klienta w referencjach oraz ograniczenia dotyczące reverse engineeringu czy współdzielenia kont.
Odpowiedzialność i ryzyko biznesowe
Limit odpowiedzialności powinien odpowiadać skali ryzyka. SaaS będący narzędziem marketingowym ma inny profil niż system wspierający proces finansowy, medyczny czy logistyczny. W negocjacjach enterprise często pojawiają się carve-outy dla poufności, danych i IP.
Dostawca powinien również określić odpowiedzialność klienta za konfigurację, uprawnienia użytkowników, legalność wprowadzanych danych i korzystanie z integracji zewnętrznych.
Offboarding i przenoszalność danych
Największy konflikt może pojawić się dopiero przy końcu współpracy. Umowa powinna określać okres dostępu po rozwiązaniu, format eksportu, pomoc migracyjną, termin usunięcia danych i to, które informacje dostawca zachowuje z przyczyn prawnych lub technicznych.
Przy krytycznych systemach warto ustalić exit assistance jeszcze przed podpisaniem umowy. Wtedy klient zna koszt migracji, a dostawca nie jest zaskoczony oczekiwaniem wielotygodniowego wsparcia bez dodatkowego wynagrodzenia.
Architektura dokumentacji SaaS: jeden regulamin rzadko wystarcza
Przy dojrzałym produkcie dokumentacja jest modułowa. Główne warunki opisują relację biznesową, order form lub zamówienie parametry konkretnego klienta, DPA porządkuje przetwarzanie danych, SLA poziomy usługi, a załącznik bezpieczeństwa odpowiada na wymagania organizacji enterprise. Dzięki temu negocjacja jednego elementu nie wymusza przepisywania całej umowy.
Ważna jest też kolejność pierwszeństwa dokumentów. Klient może mieć zamówienie, master agreement, politykę wsparcia, specyfikację i kilka załączników. Jeżeli nie wiadomo, który dokument wygrywa przy sprzeczności, ryzyko ujawnia się dopiero przy awarii albo sporze o funkcjonalność.
Nowa integracja, model billingowy, funkcja wykorzystująca dane klienta albo zmiana sposobu przechowywania danych może wymagać sprawdzenia dokumentacji. Legal nie powinien dowiadywać się o takich zmianach po wdrożeniu.
Negocjacje enterprise warto standaryzować
Duzi klienci wracają zwykle do podobnych obszarów: dostępność, odpowiedzialność, bezpieczeństwo, podwykonawcy, audyt, prawa do danych, exit i ciągłość działania. Zamiast za każdym razem ustalać stanowisko od zera, warto przygotować macierz fallbacków i osoby uprawnione do akceptacji odstępstw.
Osobnego dopracowania wymaga offboarding. Produkt powinien wiedzieć, jak długo klient ma dostęp do eksportu danych, w jakim formacie może je pobrać, kiedy konto zostanie zamknięte i co dzieje się z kopiami zapasowymi. Te zasady muszą być zgodne z realnymi możliwościami technicznymi. Klauzula obiecująca proces, którego zespół nie potrafi wykonać, jest gorsza niż uczciwie opisany standard.
Checklista dokumentacji SaaS przed pierwszym klientem enterprise
Negocjacja z większą organizacją szybko pokaże luki w dokumentach. Warto przygotować je wcześniej, zanim każda odpowiedź będzie powstawała pod presją procesu sprzedażowego.
- główne warunki usługi i jednoznaczny opis modelu subskrypcji;
- order form lub wzór zamówienia z planem, ceną, okresem i liczbą użytkowników;
- SLA zgodne z rzeczywistym monitoringiem i sposobem obsługi incydentów;
- DPA oraz lista kategorii danych, podwykonawców i kluczowych przepływów;
- opis bezpieczeństwa, który można przekazać klientowi bez nadmiernych obietnic;
- zasady odpowiedzialności i procedura zatwierdzania wyjątków negocjacyjnych;
- proces zakończenia usługi: eksport danych, dostęp po rozwiązaniu i usunięcie danych.
Warto też ustalić właściciela każdego dokumentu po stronie produktu, security i legal. Dokumentacja SaaS starzeje się szybko, jeżeli nikt nie odpowiada za jej aktualizację.
Możemy przygotować ToS lub kontrakt B2B, SLA, DPA, zasady bezpieczeństwa i playbook negocjacyjny dla sprzedaży.
Obsługa prawna firm technologicznych ↗