Portale klienta w praktyce: co naprawdę zmienia się w pracy z klientami

Większość oprogramowania na miarę, które buduję dla klientów, jest nieefektowna. Najbardziej niezawodnie użyteczna rzecz — w bardzo różnych firmach — okazała się tą najnudniejszą: danie ich klientom loginu.

Nie platformy. Loginu i czterech ekranów za nim.

Oto, czego się nauczyłem o tym, co naprawdę się wtedy zmienia — łącznie z tym, co mnie zaskoczyło, i z tym, co zrobiłem źle.

To, co się zmienia, to nie ilość pracy

Kiedyś sprzedawałem to argumentem oszczędności czasu. Ta rama jest błędna, a klienci, którzy kupują na tej podstawie, często bywają rozczarowani.

Pytania, które portal pochłania, są pojedynczo malutkie. „Gdzie jest moje zamówienie". „Możecie wysłać fakturę jeszcze raz". „Co ustaliliśmy co do terminu dostawy". Każde to dziewięćdziesiąt sekund. Jeśli je policzysz i pomnożysz, wyjdzie liczba, która przy koszcie wdrożenia wygląda nieimponująco.

Tym, co naprawdę się zmienia, jest kiedy ta praca się dzieje.

Przed: dwanaście przerwań rozsianych po dniu, każde lądujące w środku czegoś innego, każde kosztujące powrót do rytmu po obu stronach. Po: tę samą informację klient konsumuje o 22:40 w niedzielę i nikomu nie rozbija to wtorkowego przedpołudnia.

To jest realny zysk produktywności i nie widać go w arkuszu z zaoszczędzonymi minutami. Widać go w tym, że osoba, która cały dzień była reaktywna, może zaplanować sobie poranek.

Efekt drugiego rzędu, którego nikt nie przewiduje

Oto ten, którego się nie spodziewałem: portal zmienia to, co wie zespół samego klienta.

Żeby pokazać klientowi rzetelny status, ktoś musi zdefiniować, jakie te statusy są. Brzmi banalnie. Nie jest. W większości małych firm na pytanie „gdzie jest to zamówienie" odpowiada człowiek, który rekonstruuje odpowiedź z pamięci, trzech systemów i przeczucia. Nie ma kanonicznego statusu, bo nikt nigdy nie musiał go zapisać.

Budowa portalu wymusza tę definicję. A gdy statusy już istnieją i są aktualizowane, firma dostaje niemal przy okazji tę przejrzystość operacyjną, o której mówiła od lat. Nie jeden klient wyciągnął więcej wartości z własnego, wewnętrznego widoku danych statusowych niż z części dla klienta.

Jeśli rozważasz taki projekt: to jest argument, od którego dziś bym zaczynał. Nie „klienci obsłużą się sami", tylko „nareszcie będziesz wiedział, gdzie co jest".

Cztery ekrany

Każdy portal, który zbudowałem i który zadziałał, zawierał te ekrany — a te, które miały pod górkę, zawierały ich więcej:

Status. Gdzie jest sprawa, językiem zrozumiałym dla klienta. Nie „WIP" — co się wydarzyło, kiedy i co będzie dalej.
Dokumenty. Faktury, umowy, listy przewozowe, raporty. Czyste pobieranie, zero oceny — i po cichu zabija całą kategorię maili.
Historia. Co było wcześniej zamówione, ustalone albo dostarczone. Używana rzadziej niż pozostałe, ale to ona usuwa najgorsze zadanie — przekopywanie roku korespondencji, żeby odpowiedzieć na jedno pytanie.
Jedna akcja. Ponowne zamówienie, akceptacja, wgranie pliku. Dokładnie jedna, wybrana dlatego, że to najczęściej ta rzecz, którą klient chce zrobić jako następną.

Wszystko poza tym w wersji pierwszej to zakład, którego nie umiesz ocenić, bo nie masz jeszcze danych o użyciu. Wypuść cztery ekrany, obserwuj przez miesiąc, potem dodaj to, po co ludzie naprawdę sięgają.

Trzy rzeczy, które zrobiłem źle

Hasła. Mój pierwszy portal miał zwykłe logowanie e-mailem i hasłem z procedurą resetu. Użycie było fatalne. Klienci B2B logują się najwyżej co kilka tygodni, więc hasło nigdy nie wchodzi w pamięć mięśniową ani w pamięć przeglądarki — co znaczy, że każda wizyta zaczyna się od maila z resetem. Magic linki naprawiły to bardziej niż jakakolwiek inna zmiana. Jeśli klient loguje się rzadko, nie każ mu niczego pamiętać.

Statusy uczciwe, ale bezużyteczne. Raz zmapowałem statusy portalu wprost na wewnętrzne stany produkcji, bo to było rzetelne. Klienci widzieli „Etap 3" i dzwonili spytać, co to znaczy. Rzetelne i bezużyteczne. Status dla klienta potrzebuje własnego słownika, napisanego dla kogoś, kto tam nie pracuje — i musi mówić, co będzie dalej, bo to jest prawdziwe pytanie kryjące się za „gdzie jest moje zamówienie".

Założenie, że ogłoszenie równa się adopcja. Jeden portal uruchomiliśmy mailem. Dwa tygodnie później prawie nikt się nie zalogował i wniosek w pokoju był taki, że klienci tego nie chcą. Chcieli — tylko zapomnieli, że to istnieje. Zadziałało coś przyziemnego: link trafił do każdego maila transakcyjnego i każdej stopki, a przez dwa miesiące zespół odpowiadał na rutynowe pytania zdaniem „właśnie zaktualizowałem to w portalu, oto link". Adopcja to nawyk, który się trenuje, a nie funkcja, którą się wypuszcza.

Kiedy odradzam budowę portalu

Trzy sytuacje, w których powiedziałem „nie" — albo powinienem był:

Dane jeszcze nie istnieją. Jeśli status zamówienia żyje w czyjejś głowie, portal nie ma czego pokazać. To najpierw projekt systemowy, a udawanie inaczej daje portal pokazujący nieaktualne informacje, który w miesiąc niszczy zaufanie.
Klienci kupują raz w roku. Portale kumulują wartość przez powtarzalność. Klient raz do roku i tak napisze maila, bo dla niego to naprawdę łatwiejsze — i ma rację.
Nikt nie odpowiada za aktualność. Tryb awarii po osiemnastu miesiącach nie polega na tym, że portal się psuje. Polega na tym, że po cichu przestaje być aktualny, klienci działają na błędnych informacjach i staje się gorszy niż nic.

Co bym powiedział właścicielowi firmy

Zrób najpierw ćwiczenie z liczeniem. Przez tydzień zapisuj każde przychodzące pytanie, na które mógłbyś odpowiedzieć, wskazując ekran. Jeśli wychodzi mniej niż dziesięć tygodniowo, nie buduj portalu — napisz lepsze szablony maili i zajmij się czymś innym. Jeśli wychodzi trzydzieści, masz uzasadnienie, i jest ono mocniejsze, niż sugerują minuty, bo kosztem, który usuwasz, jest rozdrobnienie uwagi, a nie czas.

I ogranicz zakres do czterech ekranów. Każdy portal, który widziałem upadać, w tym mój, upadał przez to, że był wcześnie ambitny zamiast wcześnie użyteczny.