Przyjrzyj się poniższemu fragmentowi rozmowy.
Klient | Programista |
Czy moglibyście dodać do tego ekranu jeszcze jeden przycisk do generowania częściowego raportu? | - |
- | Jakie konkretnie mają to być dane? Co pokazać, gdy nie ma danych do zaprezentowania? Czy pomyślałeś o konsekwencjach agregowania częściowych danych? To może wymagać poważniejszej refaktoryzacji? |
Ok…może jeszcze się zastanowię… | - |
Zadawanie dużej ilości szczegółowych pytań osobie nietechnicznej, jest przez nią postrzegane jako zachowanie agresywne. Właśnie tak! Pomyśl o swojej ostatniej wizycie u mechanika samochodowego, elektryka - albo bardziej dramatycznie – lekarza. O czym myślisz, gdy ów specjalista przedstawia Ci diagnozę z użyciem dużej ilości niezrozumiałych słów, która brzmi miej więcej tak: bla bla bla bla bla trzy tysiące złotych?Przerwij na chwilę czytanie i pokontempluj to niepokojące uczucie całkowitej bezsilności wobec specjalisty, od którego jesteś w jakimś stopniu uzależniony.
Czasami, że zadawanie dużej ilości pytań jest używane jako taktyka służąca do powiedzenia „nie” lub przesunięcia terminów. Pierwsza technika w tym artykule brzmi: Jeśli chcesz powiedzieć „nie”, powiedz „nie”. Jeśli chcesz powiedzieć „później” powiedz „później”. Mówienie „nie” jest asertywne. Może się to klientowi nie podobać, może wywołać zażartą dyskusję albo twarde negocjacje. Plus mówienia „nie” jest taki, że wiadomo, gdzie leży punkt sporny i można zacząć poszukiwać rozwiązania. Mówienie „nie” w sposób nie wprost, poprzez zadawanie dużej ilości pytań jest działaniem agresywnym, kieruje uwagę w stronę zupełnie nieistotnych szczegółów i z pewnością nie dodaje wartości biznesowej.
Poznaj potrzebę
W artykułach Czym jest potrzeba biznesowa? oraz Pytać, słuchać precyzować znajdziesz instrukcję, w jaki sposób odnaleźć oraz sprecyzować potrzeby Twojego klienta. Będę odnosił się, do opisanych tam technik w dalszej części artykułu.
Najpierw odkryj nazwij potrzebę klienta, potem przejdź proponowania mu alternatywnych rozwiązań– to główna zasada postępowania podczas konwersacji z klientem. Poniższy przedstawia polecany przez nas schemat postępowania.
Pierwszy krok to określenie stanowiska klienta, czyli co klient deklaruje, że chce? Drugim krokiem jest odkrywanie potrzeb klienta, stojących za jego stanowiskiem. Mogą to być korzyści do osiągnięcia lub problemy do rozwiązania. Następnie nazwij główną potrzebę, która będzie: konkretna, związana z biznesem tego klienta oraz motywująca.
Obserwacje wskazują, że zwyczajowo mamy tendencję do proponowania alternatywnych rozwiązań zaraz po poznaniu stanowiska klienta. Najczęściej prowadzi to do konfliktu. Nie w sensie kłótni, lecz spolaryzowania się stanowisk i wzajemnego „obrzucania się” argumentami.
Trzeci krok dostarcza nieco trudności. Jest to moment, w który trzeba określić kryteria zaspokojenia potrzeby, a więc kryteria rozwiązania problemu albo osiągnięcia korzyści. Kryteria są niczym innym jak testami akceptacyjnymi dla potrzeby, innymi słowy: po czym klient pozna, że jego potrzeba została zaspokojona. Dopiero po nazwaniu potrzeby oraz określeniu dla niej kryteriów akceptacyjnych, następuje odpowiedni moment na zaproponowanie klientowi alternatywnego rozwiązania, które uważasz za właściwsze.
Bywa, że w nawet po nazwaniu potrzeby oraz określeniu kryteriów akceptacji, klient nie zgadza się na zaproponowanie przez Ciebie rozwiązanie. Oznacza to jedynie tyle, że istnieją jakieś kryteria, które nie zostały jeszcze przez Ciebie rozpoznane. Zapytaj po prostu: Co jeszcze oprócz <<ZNANE KRYTERIA>>musi się stać, abyś osiągnął/uniknął <<POTRZEBA>>?
W tabeli poniżej znajduje się przytoczona na wstępnie rozmowa na temat „dodatkowego przycisku” poprowadzona według opisanego wyżej schematu proponowania alternatywnych.
Klient | Programista | Komentarz |
Czy moglibyście dodać do tego ekranu jeszcze jeden przycisk do generowania częściowego raportu? | - | Klient deklaruje swoje początkowe stanowisko. Programista chciałby mu zaproponować lepsze, jego zdaniem rozwiązanie, ale… |
- | Do czego potrzeby jest Ci ten raport? Co chciałbyś za jego pomocą osiągnąć w swojej pracy? | …skupia się najpierw na odkryciu potrzeby, która skłoniła Klienta to żądania tej funkcjonalności. Programista zadaje pytanie o oczekiwaną korzyści, natomiast klient… |
Nie chcę czekać na wykresy sprzedaży, aż do końca miesiąca. | - | …odpowiada problemem, którego stara się uniknąć. Tak bywa. Ludzie zazwyczaj nie odpowiadają na zadane pytania, tylko mówią o tym, co wiedzą. Jeśli zadałeś pytanie o korzyść, a klient opowiada o problemach, podążaj za klientem. |
- | Czyli to długi czas oczekiwania na wykresy jest tu kłopotliwy? | Programista nazywa potrzebę – „długi czas oczekiwania na wykresy sprzedaży”. |
Tak. | - | - |
- | Jakie wykresy sprzedaży są Ci najbardziej potrzebne? | Programista chce sformułować kryteria akceptacji dla odkrytej potrzeby, czyli skąd klient będzie wiedział, że problem zostanie rozwiązany. |
Chodzi mi o sprzedaż do kluczowych klientów. | - | - |
- | Czyli jeśli dostaniesz od nas maila z tymi wykresami będzie OK? Możemy sobie odpuścić ten dodatkowy przycisk? | Mając kryterium w postaci „wykresy sprzedaży do kluczowych klientów”, Programista sugeruje alternatywne do „nowego przycisku”, rozwiązanie problemu klienta, ale.. |
No, nie. Bo z tym przyciskiem mogę mieć wykresy kiedy chcę, a mail uzależnia mnie od was. | - | …okazuje się, że klient go nie akceptuje. Oznacza to, że istnieją jeszcze jakieś niezdefiniowane kryteria akceptacyjne, które należy… |
- | Powiedz, jak często potrzebujesz oglądać wykresy sprzedaży do kluczowych klientów, skoro koniec miesiąca to za rzadko. | …doprecyzować. |
Co najmniej co dwa tygodnie. | - | Rzeczywiście. Drugim kryterium jest częstotliwość oglądania raportów. |
- | Ok, a więc jeśli dostaniesz maila z tymi wykresami co 2 tygodnie, to Ci wystarczy? | Programista jeszcze raz proponuje alternatywne rozwiązanie z uwzględnieniem wszystkich zdefiniowanych do tej porty kryteriów akceptacji. |
Myślę, że tak. Przynajmniej na teraz. | - | Bingo! Prewencyjnie klient dodaje, że jest to rozwiązanie „na teraz”. Cóż, biznes się zmienia J |
Jak sądzisz czy w tym artykule jest mowa o przekonywaniu? Technicznie rzecz biorąc Analityk spowodował zmianę zdania Klienta, a zatem go „przekonał”. Zwróć jednak uwagę, że jest to przekonywanie związane z poznaniem i zrozumieniem potrzeb, a nie z dostarczeniem odpowiedniej ilości argumentów. Argumenty bywają pomocne, aby przekonanych utwierdzić w już powziętej decyzji. Natomiast odkrycie potrzeb i zdefiniowanie kryteriów jest niezbędne do wypracowania rozwiązania korzystnego zarówno dla klienta jak i dla Ciebie.