CRM dla firmy usługowej - od zapytania do realizacji

Czym CRM dla firmy usługowej różni się od CRM-u dla handlowców

Większość systemów CRM powstała dla zespołów, które sprzedają i na tym kończą. Szansa przechodzi przez etapy, trafia do kolumny „wygrana” i znika z widoku. W usługach to dopiero połowa historii. Po podpisie ktoś musi pojechać na miejsce, zamówić materiał, wykonać pracę i odebrać ją z klientem. CRM dla firmy usługowej ma prowadzić sprawę przez całą tę drogę, a przynajmniej nie gubić jej w połowie.

Różnicę widać w czterech miejscach. Po pierwsze, ta sama firma wraca. Serwis klimatyzacji, biuro rachunkowe albo zakład obróbki mają klientów, z którymi pracują latami. Karta klienta musi więc trzymać historię wielu spraw, a nie jednej transakcji. Po drugie, w sprawie bierze udział więcej osób niż handlowiec. Osoba z biura, kierownik ekipy, podwykonawca i księgowa potrzebują innych informacji z tej samej karty. Po trzecie, przedmiot sprawy ma adres, termin i zakres, który zmienia się po oględzinach. Po czwarte, sprzedaż nie kończy się na ofercie. Klient płaci za wykonanie i to wykonanie decyduje, czy zamówi ponownie.

Dlatego przy projektowaniu CRM-u dla usług zaczynamy od innego pytania niż w handlu. Zamiast liczyć oferty w lejku, pytamy, gdzie dziś giną ustalenia między sprzedażą a realizacją. Ten poradnik przechodzi tę drogę krok po kroku: od zapytania, przez ofertę i przekazanie, po odbiór i powrót klienta. Opis zakresu i sposobu pracy jest na stronie dedykowanych systemów CRM. Jeśli najpierw chcesz zdecydować, czy w ogóle budować własny system, zacznij od porównania gotowego CRM-u z dedykowanym.

Moment przekazania: co musi być przy sprawie, zanim ruszy realizacja

Handlowiec ustala zakres, klient akceptuje ofertę, a zespół wykonawczy zaczyna pracę. Jeśli uzgodnienia zostały w prywatnej skrzynce handlowca, wykonawca musi zebrać je od nowa. Dzwoni do klienta z pytaniami, na które klient już odpowiadał. Klient odbiera to jako bałagan, a handlowiec dowiaduje się o problemie dopiero przy reklamacji.

Dlatego najważniejszy punkt w projekcie CRM-u dla usług to warunek przekazania. Zapisz, co musi znaleźć się przy sprawie, zanim zmieni status na „do realizacji”. Zacznij od tej listy i skreśl, co u Ciebie nie ma znaczenia:

• Zaakceptowana wersja oferty, z datą akceptacji i formą, w jakiej klient ją potwierdził.
• Osoba kontaktowa po stronie klienta na etapie wykonania, bo często jest inna niż osoba, która zamawiała.
• Uzgodniony zakres w punktach, razem z tym, czego w zakresie nie ma.
• Adres wykonania i uwagi o dostępie: godziny, klucze, wjazd, ochrona, winda.
• Dokumenty: pomiary, zdjęcia z oględzin, rysunki, protokoły, zgody.
• Ustalenia niestandardowe, które padły w rozmowie i nie weszły do oferty.
• Termin, który klient usłyszał, i to, czy był to termin orientacyjny, czy zobowiązanie.

Rozdziel dane wymagane od tych, które można uzupełnić później. Jeśli wszystko będzie wymagane, handlowcy zaczną wpisywać „brak” w każde pole, żeby system puścił sprawę dalej. Jeśli nic nie będzie wymagane, wrócisz do punktu wyjścia. Zwykle wymagane są zakres, osoba kontaktowa i zaakceptowana oferta. Reszta ma być widoczna jako brak, który ktoś ma uzupełnić przed konkretną datą.

Sam status „wygrana” rzadko wystarcza, żeby zacząć zlecenie. Między akceptacją oferty a pierwszym dniem pracy jest zwykle kilka czynności: zaliczka, zamówienie materiału, potwierdzenie terminu z ekipą. W CRM-ie te czynności mogą być zadaniami przypiętymi do sprawy, z osobą i datą. Wtedy pytanie „czy możemy już jechać” ma odpowiedź w systemie, a nie w pamięci jednej osoby.

Etapy nazwane po czynnościach, nie po nadziejach

Gotowe systemy proponują lejek: lead, kwalifikacja, oferta, negocjacje, wygrana. Te nazwy opisują emocje handlowca, a nie to, co się dzieje w firmie. W usługach lepiej działa nazwa etapu, która mówi, jaka czynność została wykonana i kto ma wykonać następną.

Przykładowa ścieżka dla firmy, która wycenia po oględzinach: nowe zapytanie, umówione oględziny, po oględzinach, oferta wysłana, oferta zaakceptowana, przekazane do realizacji, w realizacji, odebrane, rozliczone. Dziewięć etapów wygląda na dużo. Każdy z nich odpowiada jednak na pytanie klienta, który dzwoni z pytaniem „co z moją sprawą”. Jeśli dwa etapy nie różnią się czynnością, połącz je.

Dla każdego etapu zapisz trzy rzeczy: kto za niego odpowiada, co musi się wydarzyć, żeby sprawa przeszła dalej, i co się dzieje, gdy nic się nie dzieje. Ten trzeci punkt jest najczęściej pomijany. Sprawa w etapie „oferta wysłana” bez ruchu od dwóch tygodni powinna sama upomnieć się o kontakt. Bez tej reguły CRM zamienia się w cmentarz ofert, o które nikt nie dopytał.

Sprawdź też ścieżki boczne. Co się dzieje, gdy klient rezygnuje po oględzinach, gdy zmienia zakres po akceptacji oferty, gdy wraca po roku z nowym zleceniem. Każda z tych sytuacji powinna mieć miejsce w systemie. Rezygnacja z powodem. Zmiana zakresu jako nowa wersja oferty przypięta do tej samej sprawy. Powrót klienta jako nowa sprawa na starej karcie klienta, z widoczną historią.

Różne usługi, różne ścieżki

Jedna firma może prowadzić kilka typów spraw i każdy z nich ma inną drogę. Narzucanie wszystkim tego samego lejka kończy się etapami, które dla połowy spraw nic nie znaczą.

Karta klienta i karta sprawy to dwa różne obiekty

Najczęstszy błąd w arkuszach i prostych CRM-ach to jedna tabela na wszystko. Wiersz to klient, a przy nim kolumny z ostatnią ofertą, ostatnim terminem i ostatnią uwagą. Gdy ten sam klient zamawia drugi raz, ktoś nadpisuje poprzednie dane albo dodaje drugi wiersz z tą samą firmą. Po roku nikt nie wie, ile razy ta firma u Was zamawiała i co dokładnie.

Karta klienta

Trzyma to, co jest stałe albo zmienia się rzadko. Nazwa, dane rejestrowe, adresy, osoby kontaktowe z rolami, preferowany sposób rozmowy, warunki handlowe, uwagi o współpracy. Do tego lista wszystkich spraw, otwartych i zamkniętych, z datami. Firma z trzema oddziałami może mieć jedną kartę i trzy adresy wykonania albo trzy karty powiązane z centralą. Tę decyzję podejmij przed budową, bo zmiana po imporcie danych jest kosztowna.

Karta sprawy

Trzyma to, co dotyczy jednego zlecenia. Zakres, wersje oferty, etap, opiekun, najbliższe zadanie, adres wykonania, dokumenty, historia ustaleń, powiązania z innymi sprawami. Jeśli klient po montażu zamawia serwis, serwis jest nową sprawą z linkiem do montażu. Wtedy serwisant widzi, co i kiedy zostało zamontowane, bez przeszukiwania maili.

Historia ustaleń

Każda zmiana, która ma znaczenie dla wykonania, powinna zostawiać ślad: kto, kiedy, co zmienił. Ten ślad odpowiada na pytanie „kto obiecał klientowi sobotę”, zanim spór trafi do właściciela. Notatki z rozmów wpisuj przy sprawie, a nie przy kliencie, bo po kilku zleceniach notatki przy kliencie są nieczytelne.

Kto widzi, kto zmienia, kto eksportuje

Uprawnienia ustal na starcie, bo wpływają na budowę systemu. Czy handlowiec widzi sprawy kolegów. Czy kierownik ekipy może zmienić zakres, czy tylko dopisać uwagę. Czy księgowa widzi notatki z negocjacji. Kto może wyeksportować całą bazę i czy taki eksport zostawia ślad. Na stronie oferty opisujemy to jako dostęp do własnych spraw, zespołu albo całej bazy, a zakres eksportu i administracji ustalamy osobno.

Widoki dla każdej roli

Jedna baza, kilka widoków. Handlowiec otwiera listę swoich spraw z najbliższym zadaniem. Biuro widzi zapytania bez opiekuna i oferty bez odpowiedzi. Kierownik ekipy widzi sprawy gotowe do przekazania i te, w których brakuje danych. Właściciel ogląda wszystkie otwarte sprawy według etapu. Jeśli każdy po zalogowaniu widzi to samo, ludzie zaczynają omijać system. Widoki dobieramy do decyzji, które każda z tych osób podejmuje w ciągu dnia.

Gdzie kończy się CRM, a zaczyna obsługa zleceń i panel klienta

CRM porządkuje kontakt i proces handlowy. Realizacja ma własne potrzeby: planowanie ekip, listy materiałów, zadania cząstkowe, protokoły, zdjęcia z miejsca. Nie każda z tych informacji musi trafiać do widoku handlowca. Nie każda notatka handlowca interesuje ekipę.

Są trzy sposoby na tę granicę. Pierwszy: jeden system z dwoma widokami, w którym sprawa po przekazaniu zmienia zestaw pól i osób. Drugi: CRM i osobny moduł zleceń, które wymieniają się statusami i dokumentami. Trzeci: CRM i gotowy program do planowania pracy, połączone integracją. Który jest właściwy, zależy od tego, ile osób pracuje w realizacji i jak bardzo jej potrzeby różnią się od sprzedaży.

Niezależnie od wariantu ustal, które statusy i dokumenty są potrzebne obu zespołom. Handlowiec chce wiedzieć, czy zlecenie jest w toku, odebrane, czy wstrzymane, bo klient do niego dzwoni. Ekipa chce widzieć zakres, adres, kontakt i dokumenty. Obie strony chcą wiedzieć, kiedy coś się zmieniło. Reszta może zostać w swoim module. Jak zaplanować stronę realizacyjną, opisujemy w poradniku o aplikacji do obsługi zleceń, a zakres takiego modułu na stronie usługi obsługi zleceń.

Trzeci element pojawia się, gdy klienci regularnie pytają o postęp. Panel klienta pokazuje im wybrane informacje ze sprawy: etap, dokumenty do akceptacji, faktury, termin. Zakres tego, co klient widzi, projektuje się osobno od widoku pracowników. Klient nie powinien oglądać notatek wewnętrznych ani marż. Co taki panel powinien zawierać, żeby klienci z niego korzystali, opisujemy w poradniku o panelu klienta B2B, a zakres na stronie paneli klienta i portali B2B.

Jak ta sama zasada wygląda w różnych firmach usługowych

Przekazanie, etapy i karta sprawy są wspólne. Różni się to, co w sprawie jest najważniejsze i kto bierze w niej udział. Poniżej sześć typów firm, z którymi rozmawiamy najczęściej, i to, co w każdej z nich decyduje o kształcie CRM-u.

Serwis i instalacje

Sprawa ma adres i urządzenie. Karta klienta powinna trzymać listę zamontowanych urządzeń z datami, bo zgłoszenie serwisowe za trzy lata zaczyna się od pytania „co u Was stoi”. Etap oględzin jest osobny, z własnym terminem i osobą. Najwięcej problemów robi różnica między tym, co handlowiec obiecał, a tym, co ekipa zastała. Dlatego zdjęcia z oględzin i uwagi o dostępie muszą być przy sprawie przed przekazaniem. Przy zgłoszeniach serwisowych przydaje się osobny typ sprawy z krótszą ścieżką: zgłoszenie, przyjęte, umówione, wykonane.

Produkcja na zlecenie i usługi dla przemysłu

Zapytanie przychodzi z rysunkiem, parametrami i ilością. Oferta ma wersje, bo klient zmienia ilość albo materiał. CRM musi trzymać te wersje osobno, z informacją, którą klient zaakceptował. Osoba techniczna bierze udział w wycenie, więc sprawa ma etap „do wyceny technicznej” z przypisaną osobą. Po akceptacji sprawa przechodzi do planowania produkcji, które zwykle żyje w innym systemie. Wtedy granica z poprzedniej sekcji staje się integracją. Przy projekcie Nomatec zakres objął stronę, która przedstawia ofertę inżynieryjną, oraz CRM wspierający obsługę zapytań i kontakt handlowy.

Handel i dystrybucja z usługą

Hurtownia, która sprzedaje z montażem, albo dystrybutor, który serwisuje sprzedany sprzęt, mają dwa rodzaje spraw na jednej karcie klienta. Zamówienia towaru i zlecenia usługowe. Zamówienia zwykle obsługuje program handlowo-magazynowy, a CRM ma widzieć, że klient zamówił, i prowadzić część usługową. Tu najważniejsza jest decyzja, który system jest źródłem danych o kliencie. Jeśli oba, po roku będziecie mieć dwie różne listy adresów. Jak planować takie połączenie, opisujemy na stronie integracji systemów.

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

Tu sprawa trwa miesiącami albo latami, a jej przedmiotem są dokumenty i terminy. Karta klienta jest ważniejsza niż karta sprawy, bo relacja jest ciągła. CRM ma pilnować terminów cyklicznych i listy dokumentów, które klient ma dostarczyć. Przekazanie wygląda inaczej: od osoby, która podpisała umowę, do osoby, która prowadzi klienta na co dzień. Ta druga osoba musi dostać komplet ustaleń z rozmów handlowych, łącznie z tym, co klientowi obiecano w zakresie obsługi.

Firma budowlana i remontowa

Sprawa jest projektem z etapami, odbiorami częściowymi i zmianami zakresu w trakcie. CRM prowadzi ją od zapytania do umowy, a potem śledzi zmiany i ustalenia z narad. Najwięcej sporów bierze się z ustnych uzgodnień na budowie, które nie trafiły do żadnego dokumentu. Dlatego w CRM-ie przydaje się prosty mechanizm: notatka ze zmianą zakresu, datą i osobą, która ją zaakceptowała po stronie inwestora. Sam harmonogram i rozliczenia podwykonawców zwykle zostają w innych narzędziach.

Firmy z oddziałami

Kilka lokalizacji oznacza pytanie, kto widzi czyje sprawy i kto przydziela zapytania. Zapytanie ze strony WWW może trafiać do oddziału według kodu pocztowego klienta albo do centrali, która je rozdziela. Raporty mają pokazywać oddziały osobno i razem. Uprawnienia rosną, bo kierownik oddziału widzi swoje sprawy, a właściciel wszystkie. Przy takim układzie przydaje się też wspólna karta klienta, który kupuje w dwóch oddziałach. Inaczej dwóch handlowców złoży mu dwie różne oferty.

Skąd wchodzą zapytania i jak mają trafiać do CRM-u

Firma usługowa dostaje zapytania z kilku źródeł naraz. Formularz na stronie, telefon, e-mail, Profil Firmy w Google, polecenie, czasem komunikator. Każde źródło ma inną jakość danych. Formularz daje ustrukturyzowane pola, telefon daje notatkę z pamięci, e-mail daje wątek z pięcioma załącznikami.

CRM ma te źródła sprowadzić do jednej karty sprawy. Formularz może tworzyć sprawę automatycznie, z przypisaniem opiekuna według typu usługi albo lokalizacji. Telefon i e-mail wymagają, żeby ktoś założył sprawę ręcznie, dlatego formularz zakładania ma być krótki. Jeśli założenie sprawy po telefonie zajmuje pięć minut, pracownicy będą zapisywać na kartce. Jakie pola formularz na stronie powinien zbierać, żeby pierwsza odpowiedź była możliwa bez dopytywania, opisujemy w poradniku o formularzu kontaktowym.

Przy połączeniu strony z CRM-em trzeba ustalić kilka rzeczy, które w rozmowach o „integracji” często umykają. Co się dzieje, gdy ten sam klient wyśle formularz dwa razy. Co się dzieje, gdy CRM nie odpowiada, a formularz został wysłany. Kto dostaje informację o nowej sprawie i w jakiej formie. Czy zapytanie spoza obszaru działania ma w ogóle tworzyć sprawę. Te pytania rozpisujemy w poradniku o integracji strony z CRM-em. W zakresie integracji określamy rejestrowanie błędów, ponowienia i sposób informowania osoby odpowiedzialnej.

Telefon zasługuje na osobne zdanie, bo w usługach to wciąż najczęstsze źródło. Osoba odbierająca powinna mieć przed sobą formularz z pięcioma polami: kto, skąd, czego dotyczy, kiedy oddzwonić, kto ma oddzwonić. Wszystko inne można dopisać później. Jeśli numer telefonu jest już w bazie, system ma pokazać kartę klienta, zanim ktokolwiek zacznie pytać o nazwę firmy.

Zgody i dane osobowe wchodzą do systemu razem z zapytaniem. Formularz zbiera zgodę i informację o administratorze, a CRM przechowuje dane w zakresie potrzebnym do obsługi. Zasady, na jakich wolno te dane przetwarzać i jak długo je trzymać, wynikają z RODO, a wyjaśnienia publikuje Urząd Ochrony Danych Osobowych. Treść obowiązków po stronie firmy ustal z osobą, która zajmuje się u Was ochroną danych. Po naszej stronie jest to, gdzie dane są przechowywane, kto ma do nich dostęp i jak wygląda usunięcie na żądanie.

Przykład z biurka: trzy sprawy testowe, zanim powstał system

Firma instalacyjna z trzema ekipami poprosiła o CRM. Powód brzmiał: „handlowcy i ekipy nie wiedzą, co obiecano klientowi”. Zamiast od listy funkcji, zaczęliśmy od trzech spraw, które mieli przejść razem przez obecny sposób pracy. Zwykłe zapytanie, zmiana oferty po oględzinach i powracający klient.

Krok pierwszy: zwykłe zapytanie z formularza. Trafiało na skrzynkę biura, biuro przepisywało je do arkusza i wysyłało mailem do handlowca według rejonu. Handlowiec dzwonił, umawiał oględziny i zapisywał termin w swoim kalendarzu. Po oględzinach robił ofertę w edytorze tekstu i wysyłał z prywatnej skrzynki. Arkusz w biurze nadal pokazywał status „przekazane”. Pierwsza luka: biuro nie wiedziało, czy oferta w ogóle wyszła.

Krok drugi: zmiana oferty. Klient po oględzinach dołożył drugie urządzenie. Handlowiec poprawił ofertę i wysłał nową wersję. Ekipa dostała zlecenie na podstawie pierwszej, bo kierownik wydrukował ją tydzień wcześniej. Druga luka: wersje oferty żyły w skrzynce handlowca, a nie przy sprawie.

Krok trzeci: powracający klient. Dzwonił po dwóch latach w sprawie serwisu. Nikt nie pamiętał, co u niego zamontowano, bo handlowiec, który go obsługiwał, już nie pracował. Trzecia luka: historia była w prywatnej skrzynce, która została zamknięta razem z kontem.

Z tych trzech spraw powstała lista wymagań na pierwszą wersję. Sprawa zakładana automatycznie z formularza, z przypisaniem według rejonu. Wersje oferty przypięte do sprawy, z oznaczeniem zaakceptowanej. Warunek przekazania: zaakceptowana wersja, zdjęcia z oględzin, kontakt na miejsce. Karta klienta z listą zamontowanych urządzeń. Reszta, w tym planowanie ekip i magazyn, została na później. Jak wybierać zakres pierwszej wersji, żeby nie budować wszystkiego naraz, opisujemy w poradniku o pierwszej wersji aplikacji dla firmy.

Taki przegląd możesz zrobić sam, przed rozmową z jakimkolwiek wykonawcą. Wybierz trzy sprawy i poproś osobę ze sprzedaży i osobę z realizacji o przejście ich krok po kroku. Zapisuj, gdzie potrzebna jest dodatkowa wiadomość albo telefon. Ta lista jest lepszym briefem niż lista funkcji z internetu. Co jeszcze przygotować po stronie firmy, zanim ruszy wdrożenie, opisujemy w poradniku o tym, jak przygotować firmę do wdrożenia CRM.

Gotowy CRM czy dedykowany: jak to rozstrzygnąć w usługach

Gotowe systemy obsługują sprzedaż dobrze i można je uruchomić szybko. Jeśli Wasz proces to zapytanie, oferta, akceptacja i faktura, a realizacja żyje w innym narzędziu, konfiguracja gotowego CRM-u może wystarczyć. Własny system ma sens wtedy, gdy przekazanie, uprawnienia albo integracje trudno odtworzyć w gotowym narzędziu. Albo gdy obejścia zaczynają kosztować więcej niż budowa. Szersze porównanie, z migracją i utrzymaniem, jest w poradniku gotowy CRM czy dedykowany.

W usługach trzy sygnały przemawiają za dedykowanym systemem. Pierwszy: sprawa po przekazaniu zmienia właściciela, zestaw pól i widok, a gotowy CRM zna tylko „wygraną”. Drugi: dane o kliencie muszą płynąć do programu magazynowego, księgowego albo systemu planowania, a gotowe narzędzie nie ma do nich wtyczki. Trzeci: role w firmie są nietypowe, na przykład podwykonawca ma widzieć tylko adres i zakres, a nie nazwę klienta.

Demonstracja CRM-u na naszej stronie oferty działa na przykładowych danych i pokazuje układ ekranów, nie konkretne wdrożenie. Służy do rozmowy o tym, które elementy pasują do Waszej pracy, a które są zbędne. Realizacje z CRM-em opisujemy osobno na stronach projektów.

Pytania do wykonawcy przed wyceną

Te pytania pokażą, czy wykonawca rozumie usługi, czy tylko sprzedaż. Zadaj je nam i każdej innej firmie.

• Jak system obsłuży przekazanie sprawy do realizacji i co się stanie, gdy brakuje wymaganych danych.
• Jak wyglądają wersje oferty przy jednej sprawie i skąd wiadomo, która została zaakceptowana.
• Czy powracający klient dostaje nową sprawę na starej karcie, czy nowy wiersz w bazie.
• Jakie role użytkowników przewidziano i czy podwykonawca może mieć ograniczony widok.
• Z jakimi systemami było już łączone i jak obsługiwane są błędy połączenia.
• Gdzie będą przechowywane dane, kto robi kopie i jak wygląda eksport całej bazy.
• Kto jest właścicielem kodu i danych po zakończeniu współpracy.
• Co obejmuje utrzymanie, a co jest rozwojem wycenianym osobno.
• Jak wygląda migracja z arkusza albo obecnego systemu i jak sprawdzicie jej wynik.

Co wpływa na wycenę takiego systemu i jak porównać oferty różnych wykonawców, rozpisujemy w poradniku o tym, ile kosztuje aplikacja dla firmy.

Najczęstsze błędy przy planowaniu CRM-u w usługach

Każdy z tych błędów widzieliśmy u firm, które przychodziły z gotowym, ale niedziałającym systemem. Żaden nie wynika z braku staranności. Wynikają z tego, że CRM projektował ktoś, kto patrzył tylko na sprzedaż.

• Lejek skopiowany z szablonu. Etapy „kwalifikacja” i „negocjacje” nic nie znaczą dla firmy, która wycenia po oględzinach. Handlowcy przestają zmieniać etapy, bo żaden nie pasuje.
• Wszystkie pola wymagane. System nie puszcza sprawy dalej bez numeru NIP, więc handlowiec wpisuje same jedynki. Po pół roku baza jest pełna fikcyjnych danych.
• Brak warunku przekazania. Status „wygrana” uruchamia realizację, a ekipa i tak dzwoni po zakres. CRM istnieje, a problem, dla którego powstał, zostaje.
• Jedna tabela na klienta i sprawę. Drugie zlecenie tego samego klienta nadpisuje pierwsze albo tworzy duplikat firmy.
• CRM kupiony dla właściciela, nie dla zespołu. Raporty są ładne, ale handlowcy wpisują dane raz w tygodniu, z pamięci, więc raporty pokazują nieprawdę.
• Integracja „na później”. Dane klienta wpisuje się do CRM-u i osobno do programu do faktur. Po roku to dwie różne bazy.
• Brak ścieżek bocznych. Rezygnacja, zmiana zakresu i reklamacja nie mają miejsca w systemie, więc lądują w mailach, czyli tam, skąd miały zniknąć.
• Uprawnienia ustawione po wdrożeniu. Okazuje się, że każdy widzi marże i może wyeksportować całą bazę, a zmiana wymaga przebudowy.
• Brak osoby, która odpowiada za dane. Nikt nie czyści duplikatów ani nie zamyka martwych spraw, więc system po roku wygląda jak arkusz, który miał zastąpić.

Każdy z tych błędów da się naprawić, ale po wdrożeniu kosztuje to więcej niż przed. Dlatego etap ustalania zakresu kończy się decyzją o etapach, polach, rolach i warunku przekazania, zanim powstanie pierwszy ekran.

Jak przebiega wdrożenie CRM-u z nami

Nie musisz przynosić specyfikacji. Wystarczy opowiedzieć, jak dziś pracujecie i co chcecie usprawnić. Zakres i wycenę ustalamy indywidualnie po rozpoznaniu procesu. Cztery etapy z naszej oferty wyglądają tak:

Na wycenę wpływa przebieg zadań, role użytkowników, dane i połączenia z innymi systemami. Utrzymanie, licencje zewnętrzne i późniejszą rozbudowę ujmujemy osobno. W ofercie określamy też dokumentację, dostępy, licencje i prawa do kodu, żeby po wdrożeniu nie było wątpliwości, co należy do Was. Jeśli wolisz opisać proces na formularzu, możesz zacząć od briefu aplikacji.

Testy z zespołem na trzech sprawach

Scenariusze testowe to te same trzy sprawy, od których zaczęliśmy: zwykłe zapytanie, zmiana oferty i powracający klient. Osoba ze sprzedaży i osoba z realizacji przechodzą je w aplikacji, a my zapisujemy, gdzie się zatrzymały. Jeśli w teście ekipa nadal musi zadzwonić do handlowca, warunek przekazania jest źle ustawiony. Poprawiamy go przed uruchomieniem, nie po.

Co po wdrożeniu: dostępy, dane, utrzymanie i rozwój

Dzień uruchomienia jest początkiem, nie końcem. Kilka spraw trzeba zaplanować wcześniej, bo w pierwszym tygodniu pracy w nowym systemie nikt nie ma na nie czasu.

Dzień przełączenia

Ustal datę, od której sprawy zakłada się tylko w CRM-ie, i powiedz to całemu zespołowi. Równoległe prowadzenie arkusza i systemu „na wszelki wypadek” kończy się tym, że po miesiącu oba są niepełne. Sprawy otwarte w dniu przełączenia przenieś z arkusza ręcznie albo importem. W obu wypadkach ktoś ma sprawdzić, czy każda ma opiekuna i etap.

Dostępy i odejścia pracowników

Każdy użytkownik ma własne konto, bez wspólnych loginów. Gdy ktoś odchodzi, konto blokujesz tego samego dnia, a jego sprawy przepinasz na inną osobę. To jeden z powodów, dla których historia ma być przy sprawie, a nie w skrzynce. Lista najczęstszych zagrożeń dla aplikacji webowych, którą publikuje OWASP, jest punktem odniesienia przy projektowaniu logowania i uprawnień. Ty decydujesz, kto w firmie zarządza kontami.

Dane, kopie i obowiązki administratora

W ofercie ustalamy miejsce utrzymania, kopie zapasowe i sposób ich odtworzenia. Po wdrożeniu wyznacz osobę, która co jakiś czas sprawdza, czy kopia da się odtworzyć. Zaplanuj też, co dzieje się z danymi klientów, którzy od lat nie zamawiają, i jak obsłużycie prośbę o usunięcie danych. Te decyzje należą do firmy jako administratora danych, a system ma je umożliwiać.

Utrzymanie i rozwój

Utrzymanie to aktualizacje, monitoring, kopie i poprawki błędów. Rozwój to nowe moduły, pola i integracje, które wynikają z użycia. W ofercie określamy sposób zgłaszania problemów, czas reakcji i zakres utrzymania, a nowe moduły dodajemy na podstawie potrzeb zgłaszanych przez użytkowników. Po pierwszych tygodniach zbierz od zespołu listę rzeczy, które robią obok systemu. Każda z nich jest kandydatem na kolejną wersję albo sygnałem, że coś zaprojektowaliśmy źle.

Jak ocenić, czy CRM robi swoje

Wróć do pytania z początku: gdzie ginęły ustalenia. Jeśli ekipa przestała dzwonić do handlowca po zakres, a biuro wie, które oferty wyszły, system robi to, po co powstał. Liczby z raportów przyjdą później. Raport, którego nikt nie czyta, nie jest potrzebny, więc ustal, kto i po co zagląda do widoku otwartych spraw.

AI w CRM-ie dla usług

Podsumowanie długiego wątku mailowego przy sprawie, szkic odpowiedzi na zapytanie albo odczytanie danych z przesłanego dokumentu to zadania, w których AI może pomóc. Dobieramy takie funkcje do konkretnego zadania i ustalamy, co wymaga akceptacji człowieka. CRM działa bez nich. Gdzie AI pomaga, a gdzie wymaga kontroli, opisujemy w poradniku o AI w aplikacji firmowej.

Słownik pojęć i lista kontrolna przed rozmową

Kilka słów, które pojawią się w ofercie i w rozmowie o CRM-ie. Krótkie wyjaśnienia, żebyś wiedział, o co pytasz i na co się zgadzasz.

• Lead, zapytanie. Pierwszy kontakt od potencjalnego klienta, zanim wiadomo, czy będzie z tego sprawa.
• Sprawa, szansa. Jedno konkretne zlecenie albo projekt prowadzony dla klienta, z własnym etapem, opiekunem i dokumentami.
• Karta klienta. Zbiór stałych informacji o firmie albo osobie oraz lista wszystkich jej spraw.
• Lejek, pipeline. Ciąg etapów, przez które przechodzi sprawa. W usługach ciągnie się za akceptację oferty, do odbioru.
• Warunek przejścia. Zestaw danych albo czynności, które muszą być gotowe, żeby sprawa zmieniła etap.
• Przekazanie. Moment, w którym sprawa przechodzi ze sprzedaży do realizacji i zmienia właściciela.
• Opiekun. Osoba odpowiedzialna za sprawę na danym etapie. Może zmieniać się po przekazaniu.
• Rola, uprawnienie. Zestaw tego, co użytkownik widzi i może zmienić. Handlowiec, kierownik ekipy i księgowa mają inne role.
• Historia zmian. Zapis, kto, kiedy i co zmienił przy sprawie.
• Integracja, API. Połączenie CRM-u z innym systemem, w którym dane przepływają bez przepisywania. API to interfejs, który taki system udostępnia.
• Migracja. Przeniesienie danych z arkusza albo poprzedniego systemu, z ustaleniem identyfikatorów i duplikatów.
• Panel klienta. Osobny widok dla klienta, w którym po zalogowaniu widzi wybrane informacje ze swojej sprawy.

Lista kontrolna przed pierwszą rozmową

1. Trzy sprawy, które przejdziesz z zespołem: zwykła, ze zmianą oferty, z powracającym klientem.
2. Lista miejsc, w których dziś giną ustalenia między sprzedażą a realizacją.
3. Typy usług i ścieżka każdego z nich, choćby w punktach.
4. Co musi być przy sprawie przed przekazaniem do realizacji.
5. Kto bierze udział w sprawie i co każda z tych osób musi widzieć.
6. Skąd przychodzą zapytania i które z nich mają trafiać do systemu automatycznie.
7. Systemy, z którymi CRM ma się łączyć, i to, co ma między nimi przepływać.
8. Gdzie dziś są dane klientów i w jakim stanie.
9. Osoba, która będzie odpowiadać za dane i decyzje po wdrożeniu.

TL;DR

• CRM dla usług ma prowadzić sprawę za akceptację oferty, do odbioru i powrotu klienta.
• Najważniejszy punkt to warunek przekazania: co musi być przy sprawie, zanim ruszy realizacja.
• Etapy nazwij po czynnościach i zapisz, co się dzieje przy rezygnacji, zmianie zakresu i powrocie klienta.
• Karta klienta i karta sprawy to dwa różne obiekty. Historia zmian zostaje przy sprawie.
• Ustal granicę między CRM-em, modułem zleceń i panelem klienta oraz to, co przepływa między nimi.
• Przed rozmową z wykonawcą przejdź trzy sprawy testowe z osobami ze sprzedaży i realizacji.
• Uprawnienia, miejsce danych, kopie i prawa do kodu ustal przed budową, nie po.

FAQ