Co łączy hulajnogi, rowery elektryczne, aplikację, regulamin i potencjalną karę dla osoby zarządzającej do 2 mln zł?
Zarzuty postawione przez Prezesa UOKiK spółce Bolt Operations OÜ.
Urząd zakwestionował 22 postanowienia regulaminów wynajmu hulajnóg i rowerów elektrycznych. Zastrzeżenia dotyczą między innymi jednostronnej zmiany warunków po rejestracji użytkownika, wyłączania odpowiedzialności za działanie aplikacji oraz przerzucania na konsumentów ryzyka związanego ze stanem udostępnianego sprzętu.
Na obecnym etapie są to zarzuty, a nie ostateczna decyzja stwierdzająca stosowanie niedozwolonych postanowień. Sprawa jest jednak dobrym powodem, żeby zajrzeć do własnego regulaminu.
I nie dotyczy to wyłącznie firm wynajmujących hulajnogi. Podobne ryzyka pojawiają się w aplikacjach B2C, platformach, marketplace’ach, e-commerce oraz produktach SaaS oferowanych konsumentom.
Szybki onboarding, jeszcze szybsza akceptacja regulaminu
Wiele produktów cyfrowych powstaje według podobnego schematu:
- użytkownik zakłada konto w kilkanaście sekund;
- regulamin akceptuje przy okazji rejestracji albo przez rozpoczęcie korzystania z usługi;
- produkt zmienia się w kolejnych sprintach;
- nowe funkcje i opłaty są dodawane już po uruchomieniu usługi;
- regulamin zawiera szerokie wyłączenia odpowiedzialności za awarie, błędy i przerwy techniczne.
Na etapie growth taki model może wydawać się bardzo wygodny. Onboarding nie ma zbędnych przeszkód, zespół produktowy może szybko wdrażać zmiany, a ryzyka zostają opisane w jednym obszernym disclaimerze.
Problemy zaczynają się wtedy, gdy aplikacja przestaje działać, opłata nalicza się dalej, integracja nie odpowiada albo klient składa reklamację.
Wtedy regulamin przestaje być dokumentem wiszącym gdzieś w stopce. Staje się mapą ryzyk całego produktu.
Aplikacja jest konieczna, ale firma za nią nie odpowiada?
W sprawie Bolt szczególną uwagę zwraca zarzut dotyczący wyłączania odpowiedzialności za problemy z aplikacją.
Aplikacja jest niezbędna do rozpoczęcia i zakończenia korzystania z usługi. Jeżeli nie działa prawidłowo, użytkownik może na przykład nie być w stanie zakończyć przejazdu, mimo że opłaty nadal są naliczane.
W takim modelu trudno jednocześnie twierdzić:
„Musisz korzystać z naszej aplikacji, żeby skorzystać z usługi, ale nie odpowiadamy za to, że aplikacja nie działa”.
Można to sprowadzić do zasady: app required, but app not our problem.
Z perspektywy biznesowej taki zapis jest bardzo wygodny. Z perspektywy konsumenta oznacza jednak, że przedsiębiorca kontroluje rozwiązanie niezbędne do wykonania usługi, ale próbuje przenieść konsekwencje jego błędów na użytkownika.
Podobny problem może pojawić się, gdy:
- użytkownik nie może anulować subskrypcji z powodu błędu aplikacji;
- system nalicza opłatę mimo zakończenia usługi;
- klient nie może złożyć reklamacji albo zgłosić awarii;
- aplikacja błędnie rejestruje zamówienie, rezerwację lub płatność;
- integracja z zewnętrznym dostawcą nie działa, ale koszt obciąża użytkownika;
- marketplace pobiera opłatę za usługę, której wykonanie nie zostało prawidłowo potwierdzone.
Nie oznacza to, że przedsiębiorca musi gwarantować stuprocentową dostępność aplikacji albo odpowiadać za każdą przerwę techniczną. Regulamin powinien jednak realistycznie opisywać odpowiedzialność, procedurę zgłoszenia problemu oraz sposób rozliczenia sytuacji, w której użytkownik nie mógł skorzystać z usługi z powodu błędu systemu.
Regulamin nie naprawi źle zaprojektowanego produktu
Sprawę można potraktować jako problem prawny dotyczący klauzul niedozwolonych. Warto jednak spojrzeć na nią również od strony architektury produktu.
Jeżeli aplikacja pobiera opłatę za czas korzystania z usługi, trzeba wcześniej odpowiedzieć na kilka pytań:
- co stanie się, gdy użytkownik nie może zakończyć usługi;
- czy opłata zostanie automatycznie zatrzymana;
- czy system pozwala zweryfikować moment wystąpienia awarii;
- jak użytkownik może szybko zgłosić problem;
- kto może ręcznie skorygować naliczenie;
- czy support ma dostęp do danych potrzebnych do rozpatrzenia reklamacji;
- czy regulamin odpowiada temu, jak proces rzeczywiście działa.
Jeżeli model biznesowy działa tylko wtedy, gdy prawie całe ryzyko błędu systemu ponosi użytkownik, problem nie znajduje się wyłącznie w regulaminie. Znajduje się również w założeniach produktu.
Prawnik może poprawić opis odpowiedzialności. Nie naprawi jednak przyciskiem w regulaminie procesu, który technicznie nie pozwala zatrzymać błędnie naliczanej opłaty.
Czy regulamin można zmienić „w miarę rozwoju usługi”?
Drugim obszarem zakwestionowanym przez UOKiK są postanowienia pozwalające przedsiębiorcy jednostronnie zmieniać warunki umowy już po rejestracji użytkownika.
To częsty temat w regulaminach aplikacji i produktów SaaS. Produkt jest rozwijany, pojawiają się nowe funkcje, integracje, plany cenowe i sposoby świadczenia usługi. Firma chce więc zostawić sobie szeroką możliwość aktualizowania zasad.
W regulaminie pojawiają się wtedy postanowienia takie jak:
„Możemy zmienić regulamin w dowolnym momencie”;
„Regulamin może ulec zmianie w związku z rozwojem usługi”;
„Dalsze korzystanie z aplikacji oznacza akceptację nowych warunków”.
Tak szerokie sformułowania mogą być problematyczne w relacjach z konsumentami.
Samo poinformowanie użytkownika o zmianie i umożliwienie mu zamknięcia konta nie zawsze wystarczy. Regulamin powinien wskazywać konkretne i ważne przyczyny, z powodu których może zostać zmieniony.
Takimi przyczynami mogą być przykładowo:
- zmiana przepisów wpływających na sposób świadczenia usługi;
- konieczność dostosowania produktu do decyzji organu lub orzeczenia sądu;
- wprowadzenie nowych funkcji wpływających na prawa i obowiązki użytkownika;
- zmiana sposobów płatności;
- konieczność przeciwdziałania nadużyciom albo poprawy bezpieczeństwa;
- zmiany techniczne wymagające aktualizacji zasad korzystania z usługi.
Katalog przyczyn powinien odpowiadać konkretnemu produktowi. Nie chodzi o stworzenie pozornie zamkniętej listy, w której ostatni punkt brzmi „oraz z innych przyczyn według naszej decyzji”.
Istotny jest również zakres zmiany. Przyczyna dodana do regulaminu nie powinna być pretekstem do dowolnego przebudowania całej umowy albo pogorszenia sytuacji użytkownika w obszarach niezwiązanych z tą przyczyną.
Akceptacja przez dalsze korzystanie nie zawsze wystarczy
W regulaminach często spotyka się mechanizm, zgodnie z którym dalsze korzystanie z aplikacji oznacza akceptację nowych warunków.
Taki mechanizm nie powinien być traktowany jako uniwersalna zgoda na każdą zmianę.
Trzeba uwzględnić między innymi:
- charakter zawartej umowy;
- rodzaj wprowadzanej zmiany;
- to, czy zmiana dotyczy istniejącej usługi, czy nowej funkcjonalności;
- czas, jaki użytkownik otrzymał na zapoznanie się z nowymi warunkami;
- sposób przekazania informacji;
- możliwość zakończenia umowy bez dodatkowych kosztów;
- skutki braku akceptacji.
Dodanie nowej, opcjonalnej funkcji nie musi być oceniane tak samo jak podwyższenie ceny istniejącej subskrypcji albo rozszerzenie odpowiedzialności użytkownika.
Dlatego procedura zmiany regulaminu powinna być projektowana razem z produktem, billingiem i komunikacją do klienta. Sam zapis przygotowany przez legal nie wystarczy, jeżeli system nie potrafi odnotować, którą wersję regulaminu zaakceptował użytkownik i kiedy go o zmianie poinformowano.
„As is”, czyli bierzesz usługę taką, jaka jest
Kolejnym ryzykownym rozwiązaniem są klauzule mówiące, że produkt, usługa albo sprzęt są udostępniane w takim stanie, w jakim się znajdują.
Takie postanowienia są często przejmowane z zagranicznych wzorów umów. Zwroty „as is” oraz „as available” trafiają do polskiego regulaminu, a razem z nimi szerokie wyłączenie odpowiedzialności za jakość, dostępność i przydatność usługi.
W relacjach B2B zakres dopuszczalnego ograniczenia odpowiedzialności może być szerszy. W relacji z konsumentem nie można jednak zakładać, że jedno zdanie przeniesie na użytkownika wszystkie ryzyka związane z produktem.
Szczególnie ostrożnie należy podchodzić do klauzul, które mogą sugerować, że przedsiębiorca nie odpowiada także za okoliczności znajdujące się pod jego kontrolą.
Regulamin powinien rozróżniać między innymi:
- planowane przerwy techniczne;
- nieprzewidziane awarie;
- problemy po stronie dostawcy zewnętrznego;
- błędy urządzenia lub aplikacji;
- nieprawidłowe korzystanie z produktu przez użytkownika;
- zdarzenia, na które przedsiębiorca rzeczywiście nie miał wpływu.
Wrzucenie wszystkich tych sytuacji do jednego wyłączenia odpowiedzialności może być wygodne redakcyjnie, ale nie musi być skuteczne prawnie.
Support, product i legal muszą mówić tym samym językiem
Dobry regulamin nie powstaje wyłącznie na podstawie opisu produktu z prezentacji sprzedażowej.
Przed jego przygotowaniem warto porozmawiać z osobami, które wiedzą:
- jak rzeczywiście przebiega onboarding;
- gdzie najczęściej występują błędy;
- jakie reklamacje składają użytkownicy;
- kiedy opłaty mogą zostać błędnie naliczone;
- które integracje są krytyczne dla działania usługi;
- jak wygląda ręczna obsługa sytuacji wyjątkowych;
- które funkcje zespół planuje zmienić w najbliższych miesiącach.
Regulamin powinien odpowiadać produktowi, a produkt regulaminowi.
Jeżeli support obiecuje użytkownikowi zwrot opłaty, aplikacja nie pozwala go wykonać, a regulamin twierdzi, że firma za nic nie odpowiada, powstają trzy różne wersje tej samej usługi.
To prosta droga do reklamacji, złych opinii i zainteresowania regulatora.
Co sprawdzić we własnym regulaminie?
Właściciel aplikacji, platformy albo SaaS-u oferowanego konsumentom powinien sprawdzić przede wszystkim:
- czy regulamin wskazuje konkretne przyczyny jego zmiany;
- czy sposób informowania o zmianach odpowiada rzeczywistemu procesowi;
- czy da się ustalić, którą wersję regulaminu zaakceptował użytkownik;
- czy odpowiedzialność za awarie aplikacji została opisana realistycznie;
- co dzieje się z opłatą, gdy użytkownik nie może zakończyć usługi;
- jak rozliczane są błędy systemu i integracji;
- czy użytkownik ma sprawny kanał zgłaszania reklamacji;
- czy klauzule „as is” albo „as available” nie przerzucają na konsumenta zbyt szerokiego ryzyka;
- czy regulamin zgadza się z komunikatami w aplikacji, FAQ i praktyką supportu;
- czy edge case’y zostały omówione przez product, support i legal.
Warto przy tym pamiętać, że kara za stosowanie niedozwolonych postanowień nie jest jedynym ryzykiem. Dochodzą do tego reklamacje, zwroty opłat, spory z użytkownikami, problemy reputacyjne oraz konieczność przebudowania działającego już procesu.
Dobra umowa nie psuje growthu
Regulamin nie powinien blokować rozwoju produktu. Nie powinien też być próbą przeniesienia na użytkownika każdego ryzyka, którego zespół produktowy nie zdążył rozwiązać.
Dobry regulamin pozwala rozwijać usługę, ale jednocześnie jasno opisuje zasady zmian, odpowiedzialność za awarie i sposób rozwiązania sytuacji, w której system nie zadziałał zgodnie z planem.
Dobra umowa nie psuje growthu. Chroni growth przed drogim zderzeniem z reklamacjami klientów i regulatorem.
Jeżeli natomiast aplikacja jest niezbędna do wykonania usługi, trudno bezpiecznie budować model: „app required, but app not our problem”.
