System zgłoszeń, który od pierwszego ekranu buduje zaufanie.

BearlyCare startowało jako nowa usługa dla firm. Nie było starego systemu do naprawienia ani strony, którą trzeba było odświeżyć. Był pomysł, rynek do sprawdzenia i potrzeba zbudowania narzędzia, które pozwoli ruszyć z pracą.

Sama strona informacyjna nie wystarczyłaby w takim projekcie. Mogłaby opisać ofertę, ale nie obsłuży procesu: weryfikacji firmy, zgłoszenia i dalszej pracy nad sprawą. Z drugiej strony budowanie od razu rozbudowanej aplikacji byłoby ryzykowne, bo przy nowej usłudze nie wiadomo jeszcze, które funkcje będą naprawdę potrzebne.

Dlatego BearlyCare potraktowaliśmy jako system dla firm. Mniejszy niż korporacyjna platforma, ale znacznie bardziej konkretny niż landing. Pierwsza wersja miała działać, przyjmować zgłoszenia i zostawiać miejsce na dalszy rozwój.

W BearlyCare formularz nie jest zwykłym formularzem kontaktowym. To pierwszy moment, w którym osoba zgłaszająca ocenia, czy może zaufać całemu procesowi.

Jeśli pracownik ma opisać trudną sytuację w firmie, nie może poczuć, że trafia prosto do tej samej struktury, której sprawa może dotyczyć. Dlatego publiczna strona od razu stawia na zewnętrzność kanału: sprawa trafia do procesu prowadzonego spoza firmy, bez HR-u i bez przełożonego po drugiej stronie pierwszego kontaktu.

Ścieżka zgłoszenia została zaprojektowana tak, żeby była spokojna i możliwie prosta. Najpierw firma, potem opis sytuacji, bez zakładania konta i bez nadmiaru ekranów. W takim systemie mniej pytań na starcie nie jest uproszczeniem dla wygody. To warunek, żeby ktoś w ogóle zdecydował się opisać problem.

Przy nowych narzędziach B2B łatwo zbudować za dużo. Można dopisywać role, raporty, scenariusze, ustawienia i moduły, zanim ktokolwiek sprawdzi, czy będą potrzebne w codziennej pracy.

W BearlyCare ważniejsza była pierwsza wersja gotowa do pracy. Taka, która obsługuje kluczowy proces i pozwala klientowi wejść na rynek z usługą, zamiast czekać na idealną platformę.

To było MVP w praktycznym sensie: nie makieta do pokazania na spotkaniu, tylko działający system, na którym można zacząć przyjmować zgłoszenia i prowadzić sprawy. Rozbudowa ma sens dopiero wtedy, gdy pojawią się realne potrzeby, a nie tylko wyobrażenia z pierwszej rozmowy.

Najważniejszą decyzją było ograniczenie systemu do tego, co pozwala zacząć pracę. Nie dlatego, że większa aplikacja byłaby niemożliwa. Dlatego, że przy nowej usłudze lepiej sprawdzić pierwszy proces w praktyce niż budować moduły na podstawie domysłów.

• Nie robiliśmy z tego zwykłej strony, bo publiczny opis usługi nie obsłuży procesu zgłoszenia i pracy na sprawie.
• Zaczęliśmy od pierwszej wersji gotowej do pracy, zamiast miesiącami projektować platformę na podstawie założeń.
• Ograniczyliśmy zakres do rzeczy potrzebnych na start, bez funkcji na wszelki wypadek.
• Formularz potraktowaliśmy jako element zaufania, bo osoba zgłaszająca musi czuć, że trafia do zewnętrznego procesu.

Pierwsza wersja BearlyCare nie miała zamykać projektu. Miała dać fundament. To ważne, bo przy nowej usłudze nie wszystko da się przewidzieć na starcie.

Rynek, klienci i sposób pracy pokazują dopiero po czasie, które funkcje są warte rozwijania. Czasem okazuje się, że coś zaplanowane na początku nie jest potrzebne. Czasem odwrotnie: dopiero realne użycie pokazuje brak, o którym nikt nie pomyślał w briefie.

Przy systemach szytych pod firmę moja rola nie polega tylko na spisaniu listy funkcji i zbudowaniu ich po kolei.

Czasem trzeba klienta zatrzymać i zapytać: czy to jest potrzebne już teraz? Czy ta funkcja pomoże w pierwszej wersji, czy tylko zwiększy koszt, utrzymanie i liczbę decyzji? A czasem odwrotnie: trzeba pokazać coś, o czym klient jeszcze nie pomyślał, ale co będzie ważne w codziennej pracy z systemem.

Dobre narzędzie dla firmy nie musi być duże. Musi być trafione. Ma robić konkretne rzeczy, pasować do sposobu pracy klienta i zostawiać przestrzeń na dalszy rozwój.