SaaS B2B przed pierwszym płatnym klientem. Co przygotować, żeby zacząć sprzedawać?

Masz działające demo i firmę, która chce za nie zapłacić. Potrzebujesz ustalić, co właściwie kupuje, od kiedy naliczasz opłatę i co stanie się z jej danymi po zakończeniu współpracy. Kilkudziesięciostronicowy pakiet pod wszystkie przyszłe warianty produktu może spokojnie poczekać. Warunki pierwszej sprzedaży już nie.

Przygotowanie prawne SaaS B2B zacznij od rzeczywistej ścieżki klienta: zamówienia, dostępu, płatności, danych i wyjścia z usługi. Dopiero do niej dobierz dokumenty i zmiany w aplikacji. Dzięki temu budżet idzie na uruchomienie sprzedaży, a kolejne funkcje dostają obsługę wtedy, gdy naprawdę wchodzą do produktu.

Czego dowiesz się z tego tekstu?

Najpierw przejdź zakup tak, jak przechodzi go klient

Załóżmy, że sprzedajesz aplikację firmom. Dziś jest jeden plan, miesięczna opłata i ręczny onboarding. Za pół roku chcesz dodać płatności roczne, rozliczenie za użycie i API. Na start trzeba opisać działający model, a przyszłe zmiany zapisać na liście kolejnych decyzji.

Przejdź od oferty do pierwszej faktury. Ustal, czy umowę zawiera osoba klikająca przycisk, firma podpisująca zamówienie, czy ktoś akceptujący ofertę e-mailem. Sprawdź, kiedy udostępniasz warunki i co zapisujesz jako dowód ich przyjęcia. Administrator konta nie zawsze jest osobą uprawnioną do zamawiania płatnej usługi w imieniu firmy.

W Polsce art. 8 ustawy o świadczeniu usług drogą elektroniczną wymaga m.in. udostępnienia regulaminu przed zawarciem umowy w sposób pozwalający go pozyskać, odtworzyć i utrwalić. Sam link w stopce nie rozwiązuje więc kwestii tego, co klient dostał przed zakupem.

Co powinno być ustalone przed naliczeniem pierwszej opłaty?

Najwięcej tarcia powodują zwykle drobiazgi rozrzucone między landingiem, cennikiem, panelem i umową. W jednym miejscu trial jest darmowy, w drugim wymaga karty, a nikt nie zdecydował, kiedy zaczyna się płatny okres.

Przed startem połącz te ustalenia:

• Zakres: funkcje, limity, użytkownicy i elementy dodatkowo płatne.
• Cena: waluta, podatki, okres rozliczeniowy i jednostka naliczania opłat.
• Start: moment zawarcia umowy i rozpoczęcia płatnego dostępu.
• Zmiany: przejście między planami, odnowienie oraz sposób wprowadzania nowej ceny.
• Brak płatności: ponowienie obciążenia, kontakt z klientem i ewentualne zawieszenie dostępu.
• Koniec: wypowiedzenie, eksport danych, okres przechowywania i usunięcie konta.

To lista decyzji do podjęcia, a nie jeden obowiązkowy model dla każdego SaaS. Jeśli pierwszą umowę zawierasz indywidualnie, część ustaleń trafi do zamówienia. Przy zakupie samoobsługowym większą rolę przejmą warunki dostępne w aplikacji i zapis akceptacji ich konkretnej wersji.

Pakiet na start powinien odpowiadać temu, co sprzedajesz

Przy prostym modelu potrzebujesz spójnych warunków usługi, informacji o danych i, jeśli występujesz jako procesor, ustaleń dotyczących powierzenia. Osobne zamówienie może określać plan, cenę i uzgodnione odstępstwa. Ustal, który dokument ma pierwszeństwo przy rozbieżności.

Nie musisz tworzyć pięciu załączników tylko dlatego, że konkurent tyle ma. Z drugiej strony jedna strona regulaminu nie zastąpi decyzji o odpowiedzialności, gdy obsługujesz proces krytyczny dla klienta. Zakres dobierasz do ryzyka i sposobu świadczenia usługi, nie do oczekiwanej liczby stron.

Sprawdź też, komu naprawdę sprzedajesz. W Polsce samo podanie NIP przez osobę prowadzącą działalność nie wyłącza wszystkich regulacji ochronnych. Przy umowie niemającej dla niej charakteru zawodowego mogą znaleźć zastosowanie m.in. przepisy o niedozwolonych postanowieniach, art. 385⁵ Kodeksu cywilnego. Otwarcie rejestracji dla takich odbiorców wymaga osobnej oceny, a nie tylko etykiety „B2B”.

Dane: ustal role przed wysłaniem klientowi DPA

Przy danych wprowadzanych przez klienta możesz działać jako procesor, a przy własnych rozliczeniach jako administrator. Trzeba sprawdzić konkretne cele i przepływy. DPA nie zastępuje informacji o przetwarzaniu danych we własnych celach.

Jeżeli przetwarzasz dane osobowe na rzecz klienta objęte RODO, art. 28 RODO określa wymagania umowy powierzenia. Przygotuj również listę podprocesorów, opis zabezpieczeń, zasady dostępu supportu i postępowania po zakończeniu usługi. O zmianach dostawców przeczytasz w tekście o sprzeciwie wobec nowego podprocesora.

Wróćmy do aplikacji z ręcznym onboardingiem. Jeżeli support dostaje dostęp do konta klienta przez wspólne hasło, nowy załącznik nie naprawi tego procesu. Potrzebujesz ustalić dostęp techniczny i dopiero potem rzetelnie opisać go w dokumentach.

Pierwszy enterprise może potrzebować osobnej ścieżki

Duży klient może przesłać własną umowę, DPA i ankietę bezpieczeństwa. Zanim potwierdzisz wszystkie odpowiedzi, sprawdź je z osobami odpowiedzialnymi za produkt i infrastrukturę. Deklaracja w ankiecie może stać się zobowiązaniem umownym, zwłaszcza gdy ankieta jest załącznikiem do kontraktu.

Przygotuj granice negocjacji: jaki poziom dostępności zapewniasz, jak działa support, jakie audyty możesz obsłużyć i jaką odpowiedzialność przyjmujesz. SLA określa uzgodnione poziomy usługi. Deklaracja dostępności 99,9% ma sens dopiero razem z metodą pomiaru, wyłączeniami i skutkami niedotrzymania tego poziomu. Zweryfikuj też prawa do produktu, jeżeli masz je zapewnić klientowi w umowie.

Nie każda negocjacja powinna zmieniać warunki wszystkich użytkowników. Indywidualne zamówienie z jasno określonymi wyjątkami pozwala utrzymać standardowy model sprzedaży i obsłużyć większy kontrakt.

Co może poczekać na kolejną iterację?

Przyszły program partnerski, nieistniejący jeszcze marketplace i plan z API nie muszą mieć gotowych warunków w dniu sprzedaży pierwszego abonamentu. Powinny mieć za to wyraźny moment ponownego sprawdzenia.

Wpisz przegląd prawny do procesu wprowadzania nowych płatności, kategorii klientów, integracji i sposobów użycia danych. Ustal, kto zgłasza zmianę, kto zatwierdza warunki i jak zachowujesz wcześniejsze wersje. Przy wyjściu z usługi oceń także zastosowanie Data Act i zasad zmiany dostawcy.

W skrócie

• Na start przygotuj zakup, płatności, dane i zakończenie usługi dla faktycznie oferowanego planu.
• Sprawdź działanie aplikacji i dowody akceptacji, nie tylko treść plików.
• DPA dobierz do rzeczywistych ról i dostawców, a obietnice enterprise do możliwości zespołu.
• Rozwój dokumentacji powiąż z kolejnymi zmianami produktu, żeby nie finansować przyszłych wariantów przed ich uruchomieniem.

Tak dobieramy zakres wsparcia prawnego SaaS. Przykład pracy nad uruchomieniem platformy i kolejnymi iteracjami płatności znajdziesz w doświadczeniu.