Budowa SaaS dla wielu firm: konta, uprawnienia i osobne dane

Wyobraź sobie aplikację do obsługi przeglądów technicznych sprzedawaną firmom usługowym. Każda firma ma własne zlecenia, klientów i pracowników. Właściciel zakłada organizację, zaprasza zespół i wybiera plan. To przykładowy SaaS B2B: produkt wspólny dla wielu odbiorców, z osobnymi obszarami pracy.

Ustal, czy jedna osoba może należeć do kilku organizacji. Zewnętrzny specjalista może współpracować z dwiema firmami, a księgowość obsługiwać kilka podmiotów. Wtedy uprawnienia wynikają z członkostwa w danej organizacji. Sam adres e-mail nie wystarczy do określenia, jakie dane użytkownik powinien widzieć.

Nazwy „admin” i „pracownik” są zbyt ogólne do wyceny. Zapisz, kto zaprasza osoby, zmienia plan, pobiera dokumenty, zatwierdza pracę i usuwa rekordy. Odróżnij administratora firmy klienta od operatora całego produktu. Ten drugi może potrzebować dostępu do obsługi abonamentów, lecz niekoniecznie do wszystkich dokumentów.

Dla każdej roli wskaż jeden scenariusz dozwolony i jeden zabroniony. Pracownik odczytuje przydzielone zlecenie, ale nie zmienia planu organizacji. Administrator firmy dodaje członka swojego zespołu, ale nie zaprasza go do innej firmy. To konkretniejsze kryteria odbioru niż samo istnienie ekranu ustawień.

Microsoft opisuje izolację klientów jako spektrum, od współdzielonych zasobów po osobną infrastrukturę. Większe rozdzielenie może oznaczać wyższy koszt i dodatkową pracę przy wdrożeniach. Wspólna baza z prawidłową kontrolą dostępu oraz osobne bazy to różne modele, które trzeba odnieść do wymagań odbiorców.

Dla właściciela produktu ważne są praktyczne pytania: czy firma potrzebuje indywidualnego odtwarzania danych, własnego regionu hostingu lub odmiennego cyklu aktualizacji? Jeśli tak, wpisz to do założeń przed wyborem rozwiązania. Sama duża liczba firm nie przesądza jeszcze, że każda musi otrzymać oddzielny serwer.

Lista w panelu może poprawnie pokazywać tylko własne zlecenia, a plik PDF nadal otwierać się po podaniu cudzego adresu. Podobny problem może wystąpić przy wyszukiwarce, wiadomościach e-mail czy zadaniach generujących raporty. Każdy z tych przepływów powinien znać organizację oraz sprawdzać właściwe uprawnienia.

Przygotuj dwie firmy testowe z podobnymi nazwami rekordów. Sprawdź odczyt, zmianę, pobranie załącznika i eksport między nimi. Uwzględnij osobę, której odebrano członkostwo. Taki test dotyczy podstawowej obietnicy produktu: klient korzysta ze wspólnej aplikacji, ale pracuje na swoich danych.

Plan może zależeć od liczby użytkowników, organizacji, obsłużonych zleceń albo udostępnionych funkcji. Wybierz jednostkę, którą klient rozumie i potrafi przewidzieć. Jeżeli rozliczasz aktywnych pracowników, zdefiniuj, kiedy osoba staje się aktywna i jak traktujesz konta sezonowe.

Następnie opisz zmianę planu, przekroczenie limitu i brak płatności. Czy firma może dokończyć rozpoczęte sprawy? Czy zachowuje odczyt i eksport dokumentów? Jak informujesz administratora? To zachowania aplikacji, które wymagają implementacji poza samym ekranem wyboru pakietu.

Przed startem warto przejść cały cykl na kontach testowych: utworzenie organizacji, zaproszenie pracownika, korzystanie z produktu, zmianę planu i zakończenie abonamentu. Nie trzeba budować wielu pakietów, by sprawdzić, czy ktoś chce płacić za rozwiązanie konkretnego problemu.

Możesz zacząć od jednego procesu branżowego, prostego planu i ręcznej pomocy przy wdrażaniu pierwszych klientów. Indywidualne motywy graficzne i kilkanaście wariantów raportów nie muszą być dostępne od razu. Organizacje, podstawowe role i rozdzielenie danych są jednak potrzebne już wtedy, gdy wpuszczasz pierwsze niezależne firmy.

Do rozmowy z wykonawcą przygotuj opis przyszłego klienta, listę ról, przykład dokumentu oraz pomysł na jednostkę rozliczeniową. Dopisz wymagania znane z rozmów z odbiorcami. Wycena powinna pokazać zarówno funkcje użytkowe, jak i obsługę organizacji oraz utrzymanie produktu.