Od tego warto zacząć
Czy dokument ma obsługiwać stałą usługę, wdrożenie klienta czy indywidualnie negocjowaną umowę SaaS?
Opisz model usługi, użytkowników, dane przetwarzane w systemie, wsparcie i punkt, który wymaga uzgodnienia.
W czym pomagamy
Pomagamy ułożyć umowę SaaS wokół rzeczywistego modelu usługi, odpowiedzialności stron i planu na zmianę lub zakończenie współpracy.
Zanim się skontaktujesz
W pierwszej wiadomości wskaż, czy działasz jako dostawca czy klient oraz który element współpracy wymaga analizy.
Od tego warto zacząć
Opisz model usługi, użytkowników, dane przetwarzane w systemie, wsparcie i punkt, który wymaga uzgodnienia.
W czym możemy pomóc
Informacje na początek
Nie załączaj jeszcze dokumentów ani danych poufnych. Sposób ich bezpiecznego przekazania ustalimy osobno.
Umowa SaaS ma opisywać działanie konkretnej usługi, a nie tylko nadawać nazwę dostępowi do platformy. Inaczej układa się dokument dla standardowej usługi wielu klientów, inaczej dla systemu z indywidualnym wdrożeniem, integracjami albo wymaganiami bezpieczeństwa.
Pracujemy nad zakresem usługi, zasadami dostępu, wsparciem, aktualizacjami, rozliczeniami, zmianami planu, ograniczeniami odpowiedzialności i zakończeniem współpracy. Gdy usługa przetwarza dane osobowe, analizujemy role stron oraz potrzebę umowy powierzenia w świetle rzeczywistego przepływu danych. Rezultatem może być projekt dokumentów, uwagi do dokumentów drugiej strony lub lista decyzji biznesowych wymagających podjęcia.
Nie oceniamy technicznej jakości systemu, nie certyfikujemy jego bezpieczeństwa i nie zapewniamy zgodności każdego użycia usługi z przepisami. Ustalenia prawne muszą odpowiadać temu, co produkt faktycznie robi.
Warto odróżnić dostęp do usługi od wdrożenia, migracji danych czy rozwoju funkcji. Należy ustalić, kto jest użytkownikiem, jak zgłasza problemy, co oznacza niedostępność, od czego zależą integracje i co klient otrzymuje przy zakończeniu współpracy. Jasny plan przekazania lub usunięcia danych oraz zamknięcia dostępów jest potrzebny zanim relacja stanie się sporna.
Najpierw określamy rolę klienta i zakres dokumentów, sprawdzamy konflikt interesów, a następnie uzgadniamy sposób przekazania materiałów. Formularz służy do krótkiego opisu problemu, nie do wysyłania danych klientów ani całej dokumentacji technicznej.
Najpierw kwalifikujemy rolę klienta, model usługi, etap rozmów i konflikt interesów. Potem uzgadniamy rezultat: projekt dokumentów, uwagi do kontraktu lub lista decyzji produktowych. Wycena zależy od liczby dokumentów i wariantów usługi, negocjowanego zakresu, integracji, danych osobowych, modelu wsparcia oraz terminu. Nie obejmuje testów technicznych ani certyfikacji bezpieczeństwa.
Nie zawsze. Zależy to od tego, czy poza dostępem do usługi strony uzgadniają konfigurację, migrację lub indywidualne prace.
To zależy od modelu sprzedaży i uzgodnień. Przy negocjowanej współpracy potrzebny może być dodatkowy kontrakt.
Nie. SLA powinno opisywać uzgodnione zasady wsparcia i skutki, a nie obiecywać zdarzenia poza realną kontrolą dostawcy.
Zależy od rzeczywistych ról stron i przetwarzania danych osobowych; nie wynika z samej nazwy produktu.
Nie. Na początek opisz model usługi; kanał dla dokumentacji ustalimy po kwalifikacji.
Przed rozpoczęciem redakcji warto przygotować prostą mapę usługi: co klient kupuje, co dostawca utrzymuje, jakie elementy pochodzą od innych dostawców i jakie działania są konieczne po stronie klienta. Dzięki temu regulamin nie przypisuje dostawcy odpowiedzialności za decyzje użytkownika, a umowa nie obiecuje funkcji, których produkt nie zapewnia. Szczególnego ustalenia wymagają integracje, migracja danych, konto administratora i zmiana planu.
Przy wsparciu pomocne jest oddzielenie kanału zgłoszenia od klasyfikacji problemu, czasu reakcji i czasu usunięcia przyczyny. Te pojęcia mogą mieć inne znaczenie i nie powinny być wymieniane zamiennie. Przy zakończeniu współpracy opisujemy zakres eksportu, termin, format, zamknięcie dostępów i warunki dalszego przechowywania danych.
Dostawca sprzedaje standardową usługę, ale dla jednego klienta ma wykonać migrację i integrację. Dokumenty powinny odróżnić dostęp abonamentowy od jednorazowych prac projektowych. To przykład projektowy, nie gotowy model dla każdej usługi SaaS.
Nie potwierdzamy zgodności technicznej, bezpieczeństwa infrastruktury ani zgodności zastosowania produktu u każdego klienta. Dokumenty prawne przygotowujemy na podstawie opisu rzeczywistej usługi i decyzji biznesowych przekazanych przez klienta.
Przed publikacją regulaminu lub wysłaniem projektu warto sprawdzić, czy nazwy planów, funkcji, kanałów wsparcia i zasad rozliczeń odpowiadają materiałom produktowym. Niespójność między stroną sprzedażową a umową może tworzyć problem niezależnie od poprawności pojedynczego zapisu.
Sprawdź także
Sprawdź usługi i artykuły związane z tym tematem.
Pomoc w podobnych sprawach
Przeczytaj przed rozmową
Zespół kancelarii
Sprawdź profil zawodowy i obszary praktyki wskazane przez kancelarię.
Pierwszy kontakt
Napisz, czego dotyczy projekt, co jest obecnie negocjowane lub realizowane i gdzie pojawił się problem.