Panel klienta B2B - co powinien zawierać, żeby był używany?

Zacznij od pytań, z którymi klienci wracają do zespołu

Panel klienta B2B jest używany wtedy, gdy załatwia sprawę szybciej niż telefon do opiekuna. To cała zasada. Jeśli klient po zalogowaniu widzi mniej niż dowie się z jednego maila, wróci do maila. Dlatego projekt panelu zaczynamy od listy spraw, z którymi odbiorcy regularnie wracają do Waszego zespołu, a nie od listy modułów.

Zbierz przez dwa tygodnie pytania, które przychodzą od klientów firmowych. Nie z pamięci, tylko z rzeczywistej skrzynki i z notatek osoby, która odbiera telefony. Zwykle wychodzi kilka powtarzalnych grup. „Na jakim etapie jest moje zamówienie”. „Proszę o aktualną dokumentację”. „Czy mogę prosić o fakturę jeszcze raz”. „Zamawiam to samo, co w zeszłym miesiącu”. „Akceptuję projekt, proszę o produkcję”. Każda z tych grup to kandydat na funkcję panelu.

Obok każdej grupy zapisz dwie rzeczy. Ile razy w tygodniu to pytanie pada i czy klient potrafi oraz chce załatwić je sam. Pytanie o status pada często i klient chętnie sprawdzi je sam, jeśli odpowiedź będzie aktualna. Uzgodnienie nietypowego zakresu pada rzadko i wymaga rozmowy. Do panelu trafia pierwsza grupa. Druga zostaje u opiekuna, a panel ma jasno pokazać, jak się z nim skontaktować.

Nie wszystkie kontakty opłaca się przenosić do aplikacji. Klient, który dzwoni raz na kwartał z dużym zamówieniem, nie potrzebuje panelu. Potrzebuje go klient, który pisze trzy razy w tygodniu o to samo. Jeśli nie masz jeszcze pewności, czy panel jest właściwym pierwszym krokiem, przeczytaj, jak określić zakres pierwszej wersji aplikacji. Tutaj zakładamy, że powtarzalne pytania od klientów są Waszym najdroższym procesem i że panel ma je przejąć.

Jedno zadanie, które klient załatwi po zalogowaniu

Pierwsza wersja panelu powstaje wokół jednego zadania. Dla firmy, która realizuje projekty, może to być sprawdzenie postępu i akceptacja materiałów. Dla stałych odbiorców produktów złożenie albo ponowienie zamówienia. Oba narzędzia są panelami B2B, ale potrzebują innych danych i innych ekranów. Próba zbudowania obu naraz kończy się panelem, w którym żadne zadanie nie dochodzi do końca.

Dla wybranego zadania odpowiedz na cztery pytania:

• Jaki wynik klient chce osiągnąć po zalogowaniu i po czym pozna, że go osiągnął.
• Jakie informacje są mu potrzebne, żeby wykonać zadanie, i skąd panel je weźmie.
• Co po stronie Waszej firmy wymaga akceptacji albo reakcji, zanim sprawa pójdzie dalej.
• Jaki komunikat potwierdza klientowi, że sprawa została przyjęta i kto się nią zajmie.

Te odpowiedzi określają zakres lepiej niż kopiowanie wszystkich modułów z systemu pracowników. System wewnętrzny ma dwadzieścia pól na karcie zlecenia, bo potrzebuje ich produkcja. Klient potrzebuje trzech: co zamówił, na jakim to jest etapie i kiedy będzie gotowe. Reszta jest szumem, który utrudnia znalezienie tych trzech.

Zapisz też, czego klient w panelu nie zrobi. Nie zmieni ceny, nie anuluje zamówienia w produkcji, nie zobaczy marży ani uwag wewnętrznych. Granica jest tak samo ważna jak lista funkcji, bo to ona decyduje, które dane wolno pokazać na zewnątrz. Na stronie paneli klienta i portali B2B opisujemy zakres, w którym tę granicę ustalamy razem z Tobą.

Co powinien zawierać panel klienta B2B: cztery obszary

W ofercie dzielimy możliwości panelu na cztery obszary. Nie każdy panel ma wszystkie cztery, ale każdy ma przynajmniej jeden rozbudowany i pozostałe w wersji minimalnej.

Zamówienia i zapytania

Klient przekazuje potrzebne informacje w uporządkowanym formularzu zamiast w mailu z załącznikiem w nieznanym formacie. Na starcie ustalamy, czy zamawia z katalogu, wysyła zapytanie z parametrami, czy ponawia wcześniejsze zlecenie. Każdy z tych trzech wariantów to inny formularz. Katalog wymaga aktualnej listy produktów i dostępności. Zapytanie wymaga pól, które handlowiec naprawdę potrzebuje, żeby wycenić. Ponowienie wymaga historii i możliwości zmiany ilości bez wpisywania wszystkiego od nowa.

Najczęstszy błąd w tym obszarze to formularz zaprojektowany z perspektywy działu, który go odbiera. Ma dwanaście pól obowiązkowych, bo każde komuś się kiedyś przydało. Klient wypełnia cztery i dzwoni. Formularz w panelu ma pytać o to, bez czego nie da się przyjąć sprawy, a o resztę dopytuje opiekun.

Status i historia współpracy

Klient widzi uzgodnione etapy realizacji i historię swoich spraw. Zespół określa, które informacje są dostępne na zewnątrz. Słowo „uzgodnione” jest tu najważniejsze. Statusy w panelu to nie statusy z systemu produkcyjnego. „Oczekuje na komponenty od dostawcy B” jest informacją wewnętrzną. „W przygotowaniu, planowana wysyłka w przyszłym tygodniu” jest informacją dla klienta. Tłumaczenie jednego na drugie jest decyzją firmy, podejmowaną przed budową.

Historia współpracy odpowiada na pytanie „co zamawialiśmy rok temu i za ile”. Dla stałego odbiorcy to najczęściej otwierany widok, bo z niego ponawia zamówienie i z niego sprawdza, czy faktura się zgadza.

Pliki i akceptacje

Dokumenty i materiały są przypisane do właściwego projektu albo zamówienia, nie do ogólnej skrzynki. Rysunek techniczny leży przy zamówieniu, którego dotyczy. Projekt graficzny do akceptacji leży przy zleceniu, a klient klika „akceptuję” przy konkretnej wersji. Możemy zaplanować wersje, komentarze oraz potwierdzenie akceptacji konkretnego materiału, z datą i osobą, która zaakceptowała.

Ten obszar przejmuje najwięcej maili w firmach projektowych: agencjach, biurach projektowych, drukarniach, producentach na zamówienie. Zdanie „przecież akceptowaliśmy wcześniejszą wersję” przestaje być przedmiotem sporu, gdy akceptacja ma datę i przypisaną wersję pliku.

Konta firmowe i uprawnienia

Jedną firmę może reprezentować kilka osób z różnymi rolami. Zamawia magazynier, akceptuje kierownik, faktury pobiera księgowa. Ustalamy zasady zaproszeń, dostępu do dokumentów i zarządzania kontami. Ten obszar jest niewidoczny dla klienta, dopóki działa, i jest pierwszym powodem porzucenia panelu, gdy nie działa. Dlatego ma własną sekcję niżej.

Panel w zależności od tego, co sprzedajesz

Zadanie, od którego zaczyna się panel, zależy od branży. Poniżej te, które wracają w rozmowach z firmami z regionu, z pierwszym zakresem i z tym, co odkładamy na kolejny etap.

Produkcja B2B

Pierwsze zadanie: klient wysyła zapytanie z parametrami i widzi, na jakim etapie jest jego zlecenie. Do pierwszej wersji wchodzi formularz zapytania dopasowany do tego, czego technolog potrzebuje do wyceny. Do tego status zlecenia w kilku uzgodnionych etapach oraz dokumenty przypisane do zlecenia: rysunki, oferty, świadectwa jakości. Odkładamy: katalog z cenami, planowanie dostaw, reklamacje. Jeśli zapytania wpływają dziś przez stronę, panel może je przejąć, a formularz publiczny zostaje dla nowych klientów. Jak zaprojektować tę część publiczną, opisujemy w poradniku o stronie firmy produkcyjnej.

Handel i dystrybucja

Pierwsze zadanie: stały odbiorca ponawia zamówienie i pobiera fakturę bez pisania do handlowca. Do pierwszej wersji wchodzi historia zamówień, ponowienie ze zmianą ilości, status realizacji i faktury do pobrania. Odkładamy: cenniki indywidualne, limity kredytowe, stany magazynowe na żywo, bo każdy z nich wymaga połączenia z zapleczem i ustalenia, kto odpowiada za aktualność. Panel B2B dla odbiorców hurtowych nie jest sklepem internetowym, choć wygląda podobnie. Jeśli sprzedajesz też klientom indywidualnym, sklep jest osobnym projektem, o którym piszemy w tekście jak zacząć sklep internetowy.

Serwis i instalacje

Pierwsze zadanie: klient firmowy zgłasza usterkę do konkretnego urządzenia albo obiektu i widzi, kto i kiedy przyjedzie. Do pierwszej wersji wchodzi lista obiektów albo urządzeń klienta, zgłoszenie z opisem i zdjęciem oraz status zgłoszenia. Odkładamy: historię przeglądów, protokoły z podpisem, umowy serwisowe z terminami. Ten panel jest zwykle zewnętrzną stroną aplikacji do obsługi zleceń, w której pracuje Wasz zespół. Zakres widoczności, dokumenty oraz sposób logowania projektujemy oddzielnie od widoku pracowników, o czym piszemy na stronie aplikacji do obsługi zleceń.

Usługi dla firm: agencje, biura projektowe, biura rachunkowe

Pierwsze zadanie: klient akceptuje materiał albo dokument i wie, co jest po jego stronie do zrobienia. Do pierwszej wersji wchodzi lista spraw z terminami, pliki z wersjami i przycisk akceptacji. Odkładamy: rozliczenia godzin, komentowanie na pliku, harmonogram całego projektu. W biurze rachunkowym zadaniem może być przesłanie dokumentów za miesiąc i sprawdzenie, czego brakuje. To samo narzędzie, inne pola i inne terminy.

Firma budowlana i deweloper

Pierwsze zadanie: inwestor widzi postęp prac i akceptuje zmiany zakresu. Do pierwszej wersji wchodzi karta inwestycji, zdjęcia z placu z datą i opisem, lista zmian do akceptacji. Odkładamy: rozliczenia etapów, protokoły odbioru z podpisem, dostęp dla podwykonawców. Dane o postępie muszą powstawać w narzędziu zespołu w formie, którą da się pokazać na zewnątrz. Zdjęcie wysłane kierownikowi przez komunikator do panelu nie trafi.

Firma z kilkoma oddziałami

Pierwsze zadanie: klient obsługiwany przez różne oddziały widzi wszystkie swoje sprawy w jednym miejscu. Tutaj pierwsza wersja ma dodatkowy warunek: struktura oddziałów i przypisanie klienta do opiekuna w każdym z nich od pierwszego dnia. Odkładamy: porównania między oddziałami, przenoszenie spraw, lokalne wyjątki od procesu. Jeśli oddziały prowadzą statusy inaczej, przed panelem trzeba ustalić jeden słownik. Klient nie powinien widzieć, że w Lesznie „w realizacji” znaczy co innego niż w Poznaniu.

Kto reprezentuje firmę klienta i co może zrobić

Konto w panelu B2B należy do firmy, nie do osoby. To pierwsza decyzja projektowa i pierwsza różnica względem sklepu dla klientów indywidualnych. Osoba, która zamawia, nie zawsze powinna zarządzać kontami albo widzieć wszystkie dokumenty. Osoba, która odchodzi z firmy klienta, nie może zabrać ze sobą dostępu do jego historii.

Role po stronie klienta

Typowy zestaw to trzy role. Administrator konta firmowego, który zaprasza i usuwa osoby. Osoba zamawiająca, która składa zamówienia i widzi ich status. Osoba przeglądająca, która widzi dokumenty i faktury, ale nie zamawia. Nazwy i zakres dobieramy do Waszych klientów. Hurtownia z odbiorcami, u których zamawia jedna osoba, nie potrzebuje trzech ról. Producent z odbiorcami korporacyjnymi potrzebuje ich czasem więcej.

Zaproszenia, zmiana opiekuna, odebranie dostępu

Zaplanuj trzy przepływy, zanim pierwszy klient dostanie login. Jak nowa osoba po stronie klienta dostaje dostęp: zaprasza ją administrator klienta czy Wasz opiekun. Co się dzieje, gdy zmienia się opiekun po Waszej stronie: klient widzi nowe nazwisko i kontakt bez pytania. Jak odbiera się dostęp po zakończeniu współpracy albo po odejściu osoby z firmy klienta: kto to robi i czy historia zostaje. Bez tych trzech przepływów panel po roku ma konta osób, które nie pracują już u klienta, i nikt nie wie, kto ma do niego dostęp.

Uprawnienia do spraw i plików

Uprawnienia dotyczą ekranów, ale też konkretnych spraw i plików. Klient A nie może zobaczyć zamówienia klienta B, nawet jeśli zgadnie jego numer w adresie. Osoba przeglądająca nie może pobrać oferty, do której ma dostęp tylko osoba zamawiająca. Ukrycie przycisku nie zastępuje kontroli po stronie aplikacji. Każde żądanie ma być sprawdzone na serwerze, niezależnie od tego, co widać w przeglądarce. Wadliwa kontrola dostępu otwiera zestawienie najczęstszych błędów bezpieczeństwa OWASP Top Ten, a w panelach, do których logują się obce firmy, jest szczególnie kosztowna.

Dane osób kontaktowych

Panel przechowuje imiona, adresy e-mail i telefony pracowników Waszych klientów. To dane osobowe, a Wasza firma jest ich administratorem. Obowiązki administratora opisuje rozporządzenie dostępne na EUR-Lex, a wyjaśnienia Urzędu Ochrony Danych Osobowych na uodo.gov.pl. Po naszej stronie jest technika: szyfrowane połączenie, właściwe przechowywanie haseł, dziennik logowań, usuwanie kont na żądanie. Po Waszej stronie treść informacji dla użytkowników i decyzja, jak długo przechowujecie dane po zakończeniu współpracy.

Statusy i informacje, którym klient może zaufać

Panel traci zaufanie w jeden sposób: klient sprawdza status, widzi „w realizacji”, dzwoni, a opiekun mówi, że towar wyjechał wczoraj. Od tego momentu klient dzwoni zawsze, a panel staje się dodatkową pracą dla zespołu. Dlatego każda informacja w panelu ma mieć ustalone źródło, znaczenie oraz świeżość.

Źródło

Status musi pochodzić z jednego ustalonego miejsca. Jeśli zespół prowadzi zlecenia w aplikacji, status w panelu jest odczytem z tej aplikacji. Jeśli prowadzi je w systemie magazynowym, panel czyta z systemu magazynowego. Jeśli prowadzi je w głowach i w arkuszu, panel nie ma skąd czytać i trzeba zacząć od narzędzia dla zespołu. Status wpisywany do panelu ręcznie, osobno od systemu wewnętrznego, przestaje być aktualizowany po dwóch tygodniach.

Znaczenie

Każdy status widoczny dla klienta ma mieć jedno zdanie wyjaśnienia i informację, czy klient ma coś zrobić. „Oczekuje na akceptację” bez dopisku „Twojej akceptacji projektu z 12 października” jest zagadką. Poniżej przykład tłumaczenia statusów wewnętrznych na komunikaty dla klienta.

Świeżość

Jeśli dane aktualizują się okresowo, na przykład raz na godzinę z systemu magazynowego, panel ma to pokazać: „stan na 14:00”. Klient nie powinien podejmować decyzji na podstawie wartości, której nikt nie aktualizuje od tygodnia. Przy stanach magazynowych i cenach ta zasada jest ważniejsza niż przy statusach, bo na ich podstawie klient składa zamówienie.

Co się dzieje, gdy źródło nie odpowiada

Przy połączeniu z zapleczem firmy planujemy obsługę przerwy w wymianie danych. Panel ma wtedy pokazać ostatnią znaną wartość z informacją o czasie, a nie pustą tabelę albo błąd. Ustalamy, kto reaguje na błędy połączenia i jak klient ma zgłosić niezgodność między panelem a rzeczywistością. Przycisk „zgłoś problem z tą sprawą” przy każdym zamówieniu załatwia więcej niż ogólny formularz kontaktowy.

Skąd panel bierze dane: połączenie z zapleczem

Panel bez połączenia z zapleczem jest tablicą, którą ktoś musi ręcznie aktualizować. Dlatego przy wycenie sprawdzamy możliwość wymiany danych między panelem a używanym u Was systemem: aplikacją do zleceń, CRM-em, programem magazynowym, systemem księgowym. Potrzebujemy nazw systemów, ich wersji i informacji o dostępnej dokumentacji. Przed wyceną ustalamy ograniczenia dostawców i dodatkowe koszty dostępu, bo część programów każe płacić za interfejs osobno.

Dla każdego rodzaju danych ustalamy trzy rzeczy. Skąd pochodzi status, cena, dostępność, dokument. Jaki identyfikator łączy zamówienie w panelu z zamówieniem w zapleczu, bo bez wspólnego numeru dwa systemy opisują dwie różne rzeczy. I w którą stronę płyną aktualizacje: panel tylko czyta, czy też zapisuje do zaplecza, na przykład nowe zamówienie. Zapis w obie strony jest możliwy, ale wymaga ustalenia, który system ma rację przy konflikcie.

Częstotliwość wymiany dobieramy do procesu. Status zamówienia może zmieniać się przy zdarzeniu, natychmiast po zmianie w zapleczu. Cennik może aktualizować się raz dziennie. Stan magazynowy zależy od tego, jak często zmienia się naprawdę i co system udostępnia. Nie każda informacja musi być „na żywo”, a każde „na żywo” kosztuje więcej w budowie i utrzymaniu. Zakres takich prac opisujemy na stronie integracji systemów.

Zdarza się, że system, w którym firma pracuje od lat, nie ma żadnej dokumentacji wymiany danych. Wtedy omawiamy alternatywy: eksport plików według harmonogramu, ręczne potwierdzanie wybranych statusów przez opiekuna, albo przeniesienie tej części procesu do aplikacji, którą budujemy. Ostatni wariant bywa początkiem rozmowy o dedykowanym CRM-ie albo aplikacji do zleceń, z panelem jako ich zewnętrzną częścią. Jak taki przepływ wygląda od strony zapytania ze strony WWW, opisujemy w poradniku o integracji strony z CRM-em.

Ceny, katalogi i dokumenty handlowe

Partnerzy mogą mieć różne ceny i katalogi. Można to uwzględnić w zakresie, jeśli firma ma określone reguły handlowe. Słowo „określone” znowu robi różnicę. Jeśli rabat zależy od tego, co handlowiec uzgodnił przy ostatniej rozmowie, panel nie ma czego pokazać. Jeśli jest tabela grup cenowych i każdy klient należy do jednej, panel pokaże właściwą cenę.

Przed budową ustalamy źródło cen, rabaty, dostępność produktów i odpowiedzialność za aktualizacje. Kto zmienia cennik i gdzie. Czy cena w panelu jest wiążąca, czy orientacyjna. Co z produktami na zamówienie, które nie mają ceny katalogowej. Czy klient widzi dostępność jako liczbę, jako „dostępne / na zamówienie”, czy wcale. Każda z tych decyzji zmienia zakres i każda należy do firmy, nie do wykonawcy.

Dokumenty handlowe to obszar, w którym panel szybko zdobywa zaufanie. Faktury do pobrania, potwierdzenia zamówień, oferty z datą ważności, certyfikaty, karty produktów. Klient, który pobrał fakturę sam zamiast pisać do księgowości, wraca do panelu następnym razem. Warunek: dokument w panelu ma być tym samym dokumentem, który poszedł mailem, z tym samym numerem i tą samą datą.

Czego w panelu nie pokazywać: marży, uwag wewnętrznych, nazwisk pracowników produkcji, innych klientów na liście dostaw, dokładnej przyczyny opóźnienia, jeśli dotyczy dostawcy. Lista wykluczeń jest częścią zakresu i spisujemy ją przed projektem ekranów, bo łatwiej nie pokazać pola niż usunąć je po tym, jak klient je zobaczył.

Przykład z biurka: panel dla odbiorców firmy dystrybucyjnej

Firma dystrybuująca materiały dla warsztatów opisała problem jednym zdaniem. „Handlowcy przepisują zamówienia z maili, a klienci dzwonią, czy już wyjechało”. Odbiorcy stali, kilkudziesięciu, zamawiający podobne rzeczy co tydzień albo co dwa. Zamówienia przychodziły mailem, w arkuszu, na zdjęciu kartki, czasem telefonicznie w drodze.

Krok pierwszy: lista pytań. Przez dwa tygodnie biuro zapisywało, o co klienci pytają. Trzy grupy pokryły prawie wszystko: czy zamówienie wyjechało, proszę o fakturę jeszcze raz, i „to samo co ostatnio, tylko więcej”. Nietypowe zapytania o produkty spoza katalogu zostały przy handlowcach.

Krok drugi: jedno zadanie. Wybraliśmy ponowienie zamówienia, bo to ono generowało przepisywanie. Status i faktury weszły jako informacje przy zamówieniu, nie jako osobne moduły. Cenniki indywidualne poszły do kolejnego etapu, bo rabaty były ustalane „z głowy” i firma najpierw musiała je spisać. Panel pokazywał ceny bazowe z dopiskiem, że rabat klienta zostanie naliczony na fakturze jak dotychczas.

Krok trzeci: źródło danych. Zamówienia były prowadzone w programie magazynowym, który miał dokumentację wymiany danych, ale płatną osobno. Sprawdziliśmy przed wyceną, co udostępnia: listę zamówień klienta ze statusem, pozycje oraz faktury w PDF. Nie udostępniał stanów magazynowych w czasie rzeczywistym, więc dostępność zostawiliśmy na kolejny etap. Nowe zamówienie z panelu trafiało do programu magazynowego jako zamówienie do potwierdzenia przez handlowca, nie od razu do realizacji. Ta decyzja uspokoiła handlowców, którzy bali się, że panel zrobi coś za nich bez ich wiedzy.

Krok czwarty: konta i uprawnienia. U większości odbiorców zamawiała jedna osoba, ale u kilku większych zamawiał magazyn, a faktury pobierała księgowość. Weszły dwie role: zamawiająca i przeglądająca, plus administrator po stronie klienta u tych, którzy mieli więcej niż jedną osobę. Zaproszenia wysyłał opiekun, bo znał ludzi po stronie klienta.

Krok piąty: test z osobą spoza projektu. Poprosiliśmy pracownika jednego z odbiorców, żeby ponowił ostatnie zamówienie bez podpowiedzi. Utknął na nazwie przycisku, który brzmiał jak w systemie wewnętrznym. Zmieniliśmy nazwę. Nie zauważył, gdzie jest faktura, bo była na osobnej zakładce. Przenieśliśmy ją na kartę zamówienia. Dwie poprawki przed uruchomieniem, obie tańsze niż tłumaczenie tego kilkudziesięciu klientom po uruchomieniu.

Po uruchomieniu zbieraliśmy pytania od klientów przez opiekunów. Większość dotyczyła pierwszego logowania. Jedna uwaga wróciła od kilku odbiorców: chcieli widzieć, kto po ich stronie złożył zamówienie, bo zamawiało kilka osób. Weszło do drugiego etapu razem ze spisanymi w międzyczasie rabatami. Pytania o status spadły do tych, w których status w panelu nie zgadzał się z rzeczywistością, co zdarzało się przy opóźnieniu dostawcy. Dla tych przypadków doszło pole „komentarz opiekuna” przy zamówieniu.

Jak sprawić, żeby klienci zaczęli używać panelu

Zbudowany panel to połowa pracy. Druga połowa dzieje się u klientów, którzy mają swoje przyzwyczajenia i swojego handlowca, do którego lubią dzwonić. Nikt nie zacznie używać panelu dlatego, że go dostał. Zacznie, gdy pierwsza sprawa załatwi się w nim szybciej niż mailem.

Pierwsze logowanie

Zaproszenie wysyłane masowo do wszystkich klientów naraz ląduje w spamie albo w folderze „kiedyś”. Lepiej działa zaproszenie od opiekuna, z jednym zdaniem o tym, co klient załatwi w panelu, i linkiem do konkretnej sprawy, która właśnie go dotyczy. „Twoje zamówienie z wtorku jest gotowe do wysyłki, szczegóły tutaj” otwiera więcej paneli niż „zapraszamy do nowego portalu”.

Panel odpowiada na maila

Przez pierwsze tygodnie opiekun odpowiada na pytanie o status linkiem do sprawy w panelu, obok normalnej odpowiedzi. Klient dostaje to, o co prosił, i przy okazji widzi, że mógł sprawdzić sam. Bez nacisku. Po kilku takich odpowiedziach większość klientów zaczyna sprawdzać sama, a ci, którzy wolą dzwonić, nadal mogą. Panel ma uprościć powtarzalne czynności, a w sprawach wymagających rozmowy kontakt z opiekunem ma zostać widoczny.

Uruchomienie partiami

Pierwszych klientów wybierz spośród tych, którzy pytają najczęściej i mają z Wami dobre relacje. Oni wybaczą niedociągnięcie i powiedzą o nim wprost. Po ich uwagach poprawiasz to, co blokuje, i zapraszasz kolejnych. Uruchomienie dla wszystkich naraz oznacza, że ten sam problem zgłasza pięćdziesiąt firm w jednym tygodniu.

Co mierzyć

Sama liczba logowań nie mówi, czy panel pomaga. Ludzie logują się też po to, żeby sprawdzić, czy działa. Licz ukończone zadania: złożone zamówienia, pobrane faktury, akceptacje. I licz pytania, które panel miał przejąć: ile maili o status przychodzi teraz w porównaniu z listą z pierwszej sekcji. Jeśli pytania o status nie spadają, panel nie pokazuje tego, o co klienci pytają, albo pokazuje nieaktualnie. Obie przyczyny da się sprawdzić w tydzień.

Kto odpowiada za panel po stronie firmy

Wyznacz osobę, która zbiera pytania od klientów i opiekunów, odsiewa je i przekazuje nam jedną listę. Ta sama osoba decyduje o statusach, wykluczeniach oraz rolach, gdy pojawia się przypadek, którego nie przewidzieliśmy. Bez niej uwagi rozchodzą się po mailach, a wykonawca dostaje sprzeczne polecenia od trzech handlowców.

Etapy współpracy przy panelu klienta

Na stronie oferty opisujemy cztery etapy pracy nad aplikacją. Przy panelu klienta mają one swoją specyfikę, bo użytkownikami są obce firmy, a dane pochodzą z zaplecza. Poniżej, co w każdym etapie przychodzi od Ciebie i co dostajesz.

Na etapie projektowania pokazujemy układ ekranów i przebieg najważniejszych zadań. Przy panelu klienta prosimy, żeby ekrany obejrzała też osoba, która rozmawia z klientami na co dzień. Handlowiec zauważy, że klienci nie nazywają produktu tak, jak nazywa go system. Księgowa zauważy, że klient pyta o fakturę korygującą, której w projekcie nie ma. Te uwagi są tańsze przed budową niż po niej.

Zakres zapisany w ofercie jest tym, co wyceniamy. Pomysły, które pojawią się w trakcie, trafiają do listy na kolejny etap, chyba że bez nich zadania klienta nie da się dokończyć. Co składa się na koszt i jak przygotować porównywalne zapytanie, opisujemy w poradniku ile kosztuje aplikacja dla firmy.

Najczęstsze błędy przy panelach klienta

Każdy z tych błędów widzieliśmy w rozmowach o panelach więcej niż raz. Większość wynika z patrzenia na panel oczami firmy, a nie oczami klienta.

• Kopiowanie ekranów systemu wewnętrznego. Klient dostaje kartę zlecenia z dwudziestoma polami, z których rozumie trzy. Panel ma własne ekrany, zaprojektowane wokół zadania klienta.
• Statusy wpisywane ręcznie, osobno od zaplecza. Przez dwa tygodnie ktoś je aktualizuje, potem przestaje. Klient widzi nieaktualne dane i wraca do telefonu.
• Konto przypisane do osoby, nie do firmy. Pracownik odchodzi, historia zamówień odchodzi z nim, a nowa osoba zaczyna od pustego konta.
• Brak ról po stronie klienta „bo i tak zamawia jedna osoba”. U pierwszego większego odbiorcy okazuje się, że zamawia magazyn, akceptuje kierownik, a faktury pobiera księgowość.
• Uruchomienie dla wszystkich klientów naraz. Ten sam problem zgłasza kilkadziesiąt firm w tym samym tygodniu, a zespół nie nadąża z odpowiedziami.
• Panel zamiast kontaktu. Firma chowa numer telefonu opiekuna, żeby „zmusić” klientów do panelu. Klienci, którzy mają nietypową sprawę, czują się odcięci i część odchodzi.
• Pokazanie danych, których nie wolno było pokazać. Uwagi wewnętrzne o kliencie, nazwa dostawcy, lista innych odbiorców na trasie. Lista wykluczeń spisana przed projektem ekranów zapobiega temu w całości.
• Powiadomienia o wszystkim. Klient dostaje mail przy każdej zmianie statusu i po tygodniu ustawia filtr. Powiadomienie ma iść wtedy, gdy klient ma coś zrobić albo gdy zmienia się termin.
• Brak widoku na telefon. Właściciel warsztatu sprawdza status z telefonu w hali, nie z komputera w biurze. Jeśli tabela nie mieści się na ekranie, panel jest dla niego nieużywalny.
• Brak osoby po stronie firmy, która odpowiada za panel. Pytania od klientów nie mają adresata, a decyzje o statusach podejmuje ten, kto akurat odbierze telefon.

Wspólnym mianownikiem tych błędów jest założenie, że klient będzie używał panelu, bo go dostał. Klient będzie go używał, bo załatwi w nim sprawę szybciej niż dotychczas i zobaczy w nim dane, którym ufa.

Lista kontrolna i pytania do wykonawcy

Zaznacz, co masz, co masz do ustalenia, a czego świadomie nie będzie w pierwszej wersji panelu. Z taką listą pierwsza rozmowa kończy się propozycją zakresu.

1. Lista pytań, z którymi klienci wracają do zespołu, z liczbą powtórzeń w tygodniu.
2. Jedno zadanie, które klient załatwi w panelu od początku do końca.
3. Grupa klientów, od której zaczniecie, i osoba u jednego z nich, która przetestuje panel.
4. Systemy, w których dziś powstają statusy, dokumenty oraz ceny, z informacją o dokumentacji wymiany danych.
5. Słownik statusów: nazwa wewnętrzna, nazwa dla klienta, co klient może zrobić.
6. Lista wykluczeń: dane, których klient nie może zobaczyć.
7. Role po stronie klienta i zasady zaproszeń, zmiany opiekuna, odebrania dostępu.
8. Decyzje o cenach: źródło, rabaty, czy cena jest wiążąca, co z produktami bez ceny katalogowej.
9. Dokumenty, które klient pobiera sam, i miejsce, z którego panel je bierze.
10. Sposób, w jaki klient zgłasza niezgodność, i osoba, która na to reaguje.
11. Osoba po stronie firmy, która zbiera uwagi i podejmuje decyzje o panelu.
12. Miernik: ukończone zadania w panelu i liczba pytań, które panel miał przejąć.

Pytania, które możesz zadać każdemu wykonawcy, także nam:

• Skąd panel będzie brał statusy i co się stanie, gdy to źródło nie odpowie.
• Czy uprawnienia do spraw i plików są sprawdzane na serwerze przy każdym żądaniu, czy tylko ukrywane w interfejsie.
• Jak wygląda odebranie dostępu osobie, która odeszła z firmy klienta, i co dzieje się z jej historią.
• Czy panel działa w przeglądarce na telefonie i które widoki zostały pod to zaprojektowane.
• Co obejmuje utrzymanie, jak zgłasza się problemy i co jest rozliczane osobno: licencje, dostęp do interfejsów systemów zaplecza, rozbudowa.
• Kto ma prawa do kodu i danych po zakończeniu, co obejmuje dokumentacja i jakie dostępy dostaje firma.

W naszej ofercie odpowiedzi na dwa ostatnie pytania są zapisane. Określamy dokumentację, dostępy, licencje oraz prawa do kodu. Utrzymanie, licencje zewnętrzne i późniejszą rozbudowę ujmujemy osobno. Jeśli wygodniej Ci wpisać listę w formularz, brief aplikacji przyjmuje opis i pliki.

Słownik pojęć z rozmów o panelu

Kilka słów, które pojawią się w ofercie i w rozmowie o zakresie.

• Panel klienta. Część aplikacji dostępna po zalogowaniu dla klientów firmy, z danymi i czynnościami przypisanymi do konkretnego klienta. Może działać obok istniejącej strony WWW.
• Portal B2B. Panel klienta rozbudowany o zamówienia z katalogu, ceny oraz dokumenty handlowe dla odbiorców firmowych. Granica między panelem a portalem jest umowna.
• Konto firmowe. Konto należące do firmy klienta, do którego przypisane są osoby z rolami. Historia zostaje przy firmie, gdy osoby się zmieniają.
• Rola. Zestaw uprawnień przypisany do typu użytkownika po stronie klienta: administrator konta, osoba zamawiająca, osoba przeglądająca.
• Zaplecze. Systemy, w których Wasz zespół prowadzi zlecenia, magazyn, sprzedaż oraz księgowość. Panel czyta z nich dane i czasem do nich zapisuje.
• Źródło prawdy. System, który jako jedyny może zmieniać daną informację, na przykład status zamówienia. Ustalane dla każdego rodzaju danych osobno.
• Integracja. Połączenie panelu z systemem zaplecza. Wymaga sprawdzenia, co ten system udostępnia i na jakich warunkach, przed wyceną.
• API. Interfejs, przez który jeden system udostępnia dane drugiemu. Jego brak nie wyklucza integracji, ale ogranicza ją do wymiany plików według harmonogramu.
• Akceptacja. Potwierdzenie przez klienta konkretnej wersji materiału albo oferty, z datą i osobą. Zastępuje zdanie „przecież akceptowaliśmy” w mailach.
• Wersja dokumentu. Kolejne wydanie tego samego pliku przy tej samej sprawie. Panel pokazuje, która wersja jest aktualna i która została zaakceptowana.
• Lista wykluczeń. Spis danych z zaplecza, których panel nie pokazuje klientowi. Część zakresu, ustalana przed projektem ekranów.
• Dziennik zdarzeń. Zapis tego, kto i kiedy zalogował się, złożył zamówienie, zaakceptował plik albo zmienił uprawnienia. Przydaje się przy sporach i przy odbieraniu dostępu.
• Utrzymanie. Opieka nad działającym panelem: poprawki, kopie, aktualizacje, reakcja na zgłoszenia, nadzór nad połączeniem z zapleczem. Ustalane w ofercie osobno od budowy.

TL;DR

• Zacznij od listy pytań, z którymi klienci wracają do zespołu. Do panelu trafiają te, które powtarzają się często i które klient załatwi sam.
• Pierwsza wersja obsługuje jedno zadanie klienta od początku do końca. Nie kopiuj ekranów systemu wewnętrznego.
• Cztery obszary z oferty: zamówienia i zapytania, status i historia, pliki i akceptacje, konta i uprawnienia. Jeden rozbudowany, reszta minimalna.
• Konto należy do firmy klienta, nie do osoby. Zaplanuj role, zaproszenia, zmianę opiekuna i odebranie dostępu, zanim ktokolwiek dostanie login.
• Każdy status ma ustalone źródło, znaczenie dla klienta i świeżość. Status wpisywany ręcznie osobno od zaplecza umiera po dwóch tygodniach.
• Sprawdź, co udostępnia zaplecze, przed wyceną. Bez dokumentacji wymiany danych integracja jest obietnicą, nie zakresem.
• Uruchamiaj partiami, od klientów, którzy pytają najczęściej. Licz ukończone zadania i pytania, które panel miał przejąć, nie logowania.

FAQ