Własne narzędzie do onboardingu klientów B2B

Lista użytkowników już jest. Na import trzeba poczekać

Załóżmy, że klient rozpoczyna korzystanie z usługi raportowania danych. Przesłał listę osób, które mają z niej korzystać. Dostęp do źródła danych nadal czeka jednak na osobę z jego działu IT. Zespół wdrożeniowy otrzymał listę użytkowników, ale nie może jeszcze spróbować importu.

Klient powinien móc zobaczyć, że jego plik dotarł, oraz znaleźć otwartą prośbę o dostęp do źródła. Przy tej prośbie potrzebuje informacji, kto ma się nią zająć i dlaczego jest potrzebna. Wtedy osoba prowadząca wdrożenie po stronie klienta może zwrócić się do własnego IT bez kolejnego maila do wykonawcy z pytaniem o postęp.

Zespół wdrożeniowy potrzebuje widzieć przy próbie importu, że czeka na dostęp od IT klienta. To zależność między zadaniami: wykonanie jednego pozwala rozpocząć drugie. Gdy osoba z IT odpowie, wdrożeniowiec sprawdzi dostęp i będzie mógł podjąć próbę importu. Koordynator znajdzie odpowiedź przy tej samej sprawie, bez odpytywania obu stron.

Taki widok nie wymaga rozbudowanego panelu. Przy każdym kroku może wystarczyć zrozumiały opis, osoba odpowiedzialna i informacja, na co czekamy. Największa zmiana dotyczy pracy koordynatora: zamiast odtwarzać stan z korespondencji, wraca do tej samej sprawy, którą widzi klient.

Być może wystarczy obecne narzędzie

Zależności między zadaniami są dostępne w gotowym oprogramowaniu projektowym. Asana opisuje oznaczanie zadań jako blokujących inne zadanie lub oczekujących na jego wykonanie. Gdy wszystkie zadania blokujące zostaną ukończone, osoba przypisana do kolejnego zadania otrzymuje powiadomienie. Dostępność tej funkcji zależy od planu (dokumentacja zależności w Asanie).

Przed zakupem aplikacji warto więc przejść opisany przykład w używanym systemie. Czy klient zobaczy, że lista dotarła, a sprawa dostępu pozostaje otwarta? Czy wdrożeniowiec odnajdzie przy imporcie powód oczekiwania? Jeżeli tak, praca może polegać głównie na uporządkowaniu zadań i uzgodnieniu, kto potwierdza ich zakończenie. Samo posiadanie funkcji zależności nie zapewni tego porządku, jeśli zespół zapisuje wszystkie przygotowania jako jedno zadanie „materiały od klienta”.

Warto też zobaczyć projekt z konta klienta. Asana pozwala współpracować z gośćmi, którzy widzą udostępnione im treści. Udostępnienie pojedynczego zadania daje dostęp do niego, natomiast udostępnienie projektu obejmuje wszystkie zadania tego projektu (uprawnienia gości w Asanie). Jeżeli zespół zapisuje tam również wewnętrzne uwagi, trzeba dobrać sposób współpracy do tego, co klient ma rzeczywiście zobaczyć. Warto obejrzeć ten widok z konta gościa.

Gdy po stronie klienta zmienia się kontakt

Wróćmy do prośby o dostęp. Jeżeli osoba z IT przekazuje sprawę koledze, nowy kontakt potrzebuje zobaczyć, o co proszono i co już ustalono. Koordynator powinien móc przekazać mu otwarte zadanie wraz z rozmową, zachowując informację o wcześniejszych odpowiedziach. Zespół nadal czeka na dostęp do tego samego źródła danych; zmiana osoby nie powinna wymuszać rozpoczynania sprawy od początku.

Trzeba przy tym ustalić z klientem, komu przekazać zadanie i czy poprzedni kontakt nadal uczestniczy we wdrożeniu. Jeśli odchodzi z firmy, jego dostęp wymaga odebrania. Historia pracy powinna pozostać przy wdrożeniu, żeby następca mógł je kontynuować. Warto uwzględnić tę zwykłą sytuację podczas wyboru narzędzia, szczególnie gdy dziś cała rozmowa trafia do jednej skrzynki pocztowej.

Rozszerzenie czy osobna aplikacja

Jeśli zespół dobrze pracuje w swoim systemie projektowym, a klient gubi się w jego interfejsie, można rozważyć wąski widok dla klienta. Pokazywałby jego otwarte prośby i pozwalał odpowiadać przy właściwym zadaniu. Wewnętrzne planowanie mogłoby pozostać w dotychczasowym narzędziu. Przed wyborem takiego rozszerzenia trzeba sprawdzić, czy dostępne połączenie przeniesie odpowiedzi oraz zmiany zadań. Ręczne przepisywanie ich przez koordynatora pozostawiłoby część obecnej pracy.

Osobna aplikacja staje się sensownym kandydatem, gdy uruchomienie usługi wymaga łączenia działań klienta z informacjami z kilku systemów i obecne narzędzia nie obsługują tego wygodnie. Zakres może ograniczać się do czasu od rozpoczęcia wdrożenia do gotowości usługi. Sprzedaż i późniejsza obsługa zgłoszeń mogą nadal działać w używanych produktach. Szerszą decyzję o portalu klienta połączonym z CRM opisujemy osobno.

W porównaniu ofert uwzględnij także pracę po uruchomieniu narzędzia. Ktoś po waszej stronie będzie aktualizował przebieg wdrożeń, gdy zmieni się usługa. Wykonawca aplikacji potrzebuje uzgodnionego zakresu opieki nad połączeniami z innymi systemami i sposobu obsługi błędów. Pomoc klientom z dostępem także pozostanie częścią obsługi. Te obowiązki wpływają na koszt własnego narzędzia, więc powinny znaleźć się w porównaniu z gotowym produktem.

Przy przejściu do nowego narzędzia najwięcej uwagi wymagają trwające wdrożenia. Otwarte prośby powinny zachować odpowiedzi klientów i zależności, aby zespół wiedział, od czego kontynuować. Ustal również możliwość późniejszego eksportu historii oraz warunki dostępu do kodu i przekazania utrzymania innemu wykonawcy.

Rozmowa o wdrożeniu, które utknęło

Syntalith tworzy aplikacje na zamówienie. Możliwy pierwszy zakres to widok otwartych próśb do klienta, połączony z zadaniami, które czekają na jego odpowiedź. Na takim przykładzie można ocenić, czy wystarczy konfiguracja obecnego produktu, czy potrzebny jest prostszy interfejs i dodatkowe połączenie.

Do pierwszej rozmowy wystarczy opisać ostatnie wdrożenie, przy którym klient uważał, że wszystko już przesłał, a zespół nadal czekał. Powiedz, czego brakowało i gdzie koordynator zapisywał kolejne ustalenia. Informacje o rozliczeniu prac znajdziesz w cenniku Syntalith.