Analiza win loss: jak ją przeprowadzić w pięciu krokach, z darmowym szablonem i prawdziwymi powodami transakcji

Analiza win loss pyta kupujących, dlaczego wybrali ciebie, konkurenta albo nic. Potem zamienia odpowiedzi w liczby, na podstawie których można działać. Potrzebujesz trzech rzeczy: rejestru z jednym kodem przyczyny na każdą zamkniętą transakcję, krótkiego scenariusza wywiadu i comiesięcznego przeglądu, który coś zmienia. W tym wpisie znajdziesz wszystkie trzy.

Dziesięć kodów przyczyn pochodzi z własnego rejestru Spona obejmującego 137 zamkniętych transakcji, a osiem pytań z 29 wywiadów, które Spona przeprowadziła po decyzji kupującego. Darmowy arkusz Google Sheets jest w języku angielskim i zawiera każdą z tych transakcji jako przykładowy wiersz. Możesz zobaczyć, jak działają formuły, zanim usuniesz przykładowe wiersze. Zrób kopię arkusza i przejdź przez pięć kroków poniżej.

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Analiza win loss: na jakie pytania odpowiada

Analiza odpowiada na trzy pytania: dlaczego wygrywasz, dlaczego przegrywasz i dlaczego transakcje utykają bez decyzji. Większość zespołów pomija trzecie. Dixon i McKenna przeanalizowali na potrzeby The JOLT Effect miliony nagranych rozmów sprzedażowych. Odkryli, że od 40 do 60% przegranych transakcji kończyło się brakiem decyzji.

Jeśli twój rejestr zna tylko Wygraną i Przegraną, około połowy przegranych może trafiać do złej kolumny. Licz każdą zamkniętą transakcję jako Wygrana, Przegrana albo Brak decyzji i daj każdemu wynikowi własne kody. Kupujący, który wstrzymał projekt, wcale cię nie odrzucił. Kupujący, który podpisał umowę z dotychczasowym dostawcą, odrzucił cię, a te dwa przypadki wymagają różnych poprawek.

Druga rzecz, którą pokazuje analiza, to skala, w jakiej myli się twój CRM. Clozd prowadzi programy wywiadów dla dostawców. Według Clozd powody przegranych podawane przez kupującego i sprzedawcę pokrywają się tylko w 15% przypadków. Handlowiec wpisuje „cena”, a kupujący mówi, że zespół nie mógł zmienić swojego procesu.

Tylko wersja kupującego mówi, co trzeba zmienić. Dlatego opisana niżej metoda zapisuje dla każdego powodu dwa źródła: kod, który handlowiec wybiera przy zamknięciu, i odpowiedź, której kupujący udziela kilka tygodni później. Szablon zapisuje oba i pokazuje, jak często są zgodne.

Własny rejestr Spona pokazuje to na liczbach. Obejmuje 137 zamkniętych transakcji. Z tego 85 zakończyło się wygraną, a 25 przegraną. Pozostałe 27 zakończyło się brakiem decyzji.

Z tych liczb wynika, że Spona wygrała 62,0% wszystkich zamkniętych transakcji i 77,3% transakcji, w których zapadła decyzja. Różnicę między tymi dwoma wskaźnikami tworzą transakcje bez decyzji. Rejestr z samymi wygranymi i przegranymi nigdy jej nie pokaże. Szablon pokazuje ją na samym początku.

Jak przeprowadzić analizę win loss?

Pięć kroków, w kolejności, jakiej oczekuje szablon. Każdy krok kończy się wierszem, kodem albo liczbą, więc nic nie zależy od pamięci.

1. Zbierz każdą zamkniętą transakcję, także bez decyzji. Wyeksportuj każdą zamkniętą szansę z lejka sprzedaży razem z historią etapów. Zachowaj transakcje, które ucichły po wysłaniu oferty. Należą do rejestru jako Brak decyzji (No decision), a nie do otwartego lejka. Według przewodnika Klue potrzebujesz co najmniej 10 podobnych transakcji, zanim wzorzec zacznie coś znaczyć. Rejestr Spona rósł przez cztery miesiące o 32 do 40 zamkniętych transakcji miesięcznie. Mimo to cztery z dziesięciu kodów pozostały poniżej 10 transakcji. Mniejszy zespół powinien zebrać transakcje z co najmniej kwartału. Zespół, który zamyka kilka transakcji miesięcznie, powinien zebrać je z całego roku.
2. Zakoduj w CRM jeden główny powód. HubSpot ma do tego dwie domyślne właściwości transakcji: Closed won reason i Closed lost reason. Ogranicz obie do stałej listy twoich kodów i dodaj zestaw kodów dla braku decyzji. Jeden kod na transakcję, wybrany przy zamknięciu przez handlowca, który ją prowadził. Transakcja z dwoma powodami dostaje ten, który kupujący wymienił jako pierwszy. Zapisz też, skąd pochodzi kod: z pola CRM, z omówienia z handlowcem czy z wywiadu z kupującym. Jeśli twoim CRM jest arkusz, nasz szablon CRM ma pole na powód przegranej, które możesz podpiąć pod tę samą listę.
3. Rozmawiaj z kupującymi po decyzji. Kod handlowca to hipoteza, a odpowiedź kupującego to dane. Clozd radzi przeprowadzać wywiady w ciągu 30 do 90 dni od decyzji, po równo z wygranymi i przegranymi. User Intuition opowiada się za terminem od dwóch do czterech tygodni, póki pamięć jest świeża. Klue zaleca 30-minutowe rozmowy z godziną zarezerwowaną w kalendarzu. Licz się z tym, że na wywiad zgodzi się od 15 do 30% kupujących. Ankiety osiągają 3 do 5%. Pytać powinien ktoś inny niż handlowiec. Pragmatic Institute zaprasza do rozmowy ludzi od produktu, bo kupujący mogą zatajać złe wieści, żeby chronić relację z handlowcem. Według wyjaśnień UODO rejestr czynności przetwarzania prowadzi każdy administrator, w miarę możliwości z planowanymi terminami usunięcia poszczególnych kategorii danych. Zwolnienie dla firm zatrudniających mniej niż 250 osób nie ma zastosowania, gdy przetwarzanie nie ma charakteru sporadycznego. Dlatego radzimy ująć w rejestrze nagrania wywiadów i cytaty kupujących, a słowa kupującego zapisywać tylko wtedy, gdy pozwala na to kolumna Zgoda na cytat (Quote permission) w zakładce Scenariusz wywiadu (Interview guide).
4. Zapisz i policz. Jeden wiersz na zamkniętą transakcję: wynik, kod, źródło kodu i słowa kupującego. Następnie policz transakcje stojące za każdym kodem. Kod z trzema transakcjami to anegdota. Kod z jedenastoma transakcjami to wzorzec. Zapisuj słowa kupującego krótko i dosłownie, bo parafraza gubi słowo, które miało znaczenie. Ustal minimum, zanim zaczniesz odczytywać jakikolwiek kod, a wszystko poniżej traktuj jako „jeszcze nie”. Szablon liczy za ciebie i oznacza każdy kod poniżej ustawionego minimum.
5. Daj każdemu czołowemu kodowi właściciela i zmianę. Zasada Liminal mówi, że wnioski powinny co miesiąc aktualizować trzy rzeczy: battlecardy, pytania discovery i obsługę obiekcji. Przypisz czołowy kod każdego wyniku do jednego zespołu. Zapisz zmianę i w następnym miesiącu sprawdź, czy liczba się przesunęła. Badanie Clozd wykazało, że tylko 39% firm prowadzi win loss jako stały program obejmujący kilka działów. 72% programów należy do zespołów go-to-market, po równo do sprzedaży i marketingu. Wybierz jednego właściciela teraz i ustal datę przeglądu, zanim wyjdziecie z sali.

Pytania do wywiadu win loss: osiem, które zadajemy

Klue proponuje napisać od 20 do 30 pytań i liczyć się z tym, że użyjesz mniej więcej połowy. Scenariusz Spona ma osiem. Obejmują impuls, alternatywy, dowody, ranking kryteriów, ludzi, moment, w którym transakcja prawie przepadła, brakującą zmianę i to, co działo się potem. Sześć trafia do każdego kupującego; jedno tylko do tych, którzy wybrali Spona, i jedno tylko do tych, którzy jej nie wybrali.

Tabela pokazuje pytania słowo w słowo, z liczbą wywiadów, w których padło każde z nich. W pytaniach 6 i 7 zamień „Spona” na nazwę swojej firmy. Zakładka Interview guide w szablonie ma obok naszych sformułowań kolumnę na twoje. Zadawaj pytania po kolei: ranking z pytania 4 ma sens dopiero wtedy, gdy alternatywy z pytania 2 leżą już na stole.

Liczby pochodzą z 29 zaplanowanych rozmów po decyzji, oddzielnych od samych rozmów sprzedażowych. 17 odbyło się po wygranych transakcjach, a 12 po przegranych. W tej grupie nie ma kupującego, którego transakcja zakończyła się wynikiem No decision. Tę lukę zamknęlibyśmy w pierwszej kolejności.

Kody dla transakcji bez decyzji (wstrzymany projekt, przesuwająca się data startu, przegląd w dziale zakupów) trudno nadać na podstawie samego pola w CRM. Handlowiec widzi, że transakcja ucichła, i musi zgadywać. Tylko kupujący wie, czy projekt umarł, czy tylko się przesunął. Dopisz tych kupujących do listy wywiadów od pierwszego miesiąca.

Pytanie 1 zasługuje na swoje miejsce, bo oddziela prawdziwy impuls od mglistego życzenia. Pytanie 2 mówi, z kim naprawdę przyszło ci konkurować, a to nie zawsze dostawca wpisany w CRM. Pytanie 3 prosi o dowody, nie o opinie, więc odpowiedź wskazuje próbkę, test albo plik konkurenta. Pytanie 4 wymusza ranking i tak dowiadujesz się, czy „cena” oznaczała cenę, czy brak możliwości kupienia czegoś na małą skalę.

Pytania 6 i 7 to para, która zmienia playbook sprzedaży. To, co prawie zatrzymało wygranego kupującego, jest jutrzejszym powodem przegranej. Brakująca zmiana wskazana przez przegranego kupującego to albo luka w produkcie, albo dowód, którego nie udało się pokazać. Pytanie 8 wyłapuje, co stało się po podpisie lub po rezygnacji, a właśnie tam kryją się referencje i ryzyko odejścia klienta.

Pytanie 5 ma największe znaczenie przy większych kontach. Gartner szacuje typową grupę zakupową przy złożonym zakupie B2B na od sześciu do 10 decydentów. Ci kupujący spędzają tylko 17% czasu zakupowego na spotkaniach z potencjalnymi dostawcami. Handlowiec mógł poznać dwie albo trzy z tych osób.

Wywiad to jedyna szansa, by usłyszeć, na czym zależało pozostałym. Zapisz rolę każdej osoby, a nie jej nazwisko. Potem przenieś role do swojego szablonu buyer persony, żeby następna rozmowa discovery pytała o te osoby po stanowisku.

Powody wygranych i przegranych: 137 transakcji Spona według kodu

Większość opublikowanych list kodów jest ogólna. AskElephant proponuje pięć powodów przegranej: cenę, timing, dopasowanie, konkurenta i błąd procesu. Szablon Unkover dzieli powody na pięć koszyków: ceny, produkt, ludzi, proces i pozycjonowanie. Żadna z tych list nie podaje prawdziwych liczb transakcji i żadna nie daje transakcjom bez decyzji osobnych kodów przyczyn.

CRM Spona używa dziesięciu kodów dla trzech wyników: czterech dla wygranych, trzech dla przegranych i trzech dla braku decyzji. Każda zamknięta transakcja ma dokładnie jeden. Kody są specyficzne dla dostawcy danych, więc zmień ich nazwy pod swój produkt. Zachowaj strukturę: kod nazywa powód, który kupujący by rozpoznał, a nie etap sprzedaży czy odczucie.

Tabela podaje każdy kod, regułę jego użycia i słowa kupującego zapisane przy nim w rejestrze Spona. Każdy kod ma jedno zapisane sformułowanie. Traktuj cytat jako typowe ujęcie, a nie coś, co powiedział każdy kupujący.

Verified coverage to kod 31 ze 137 transakcji, co daje największy pojedynczy udział. Z liczb wynika, że to 36,5% wygranych. Po stronie przegranych Existing contract to kod 11 z 25 przegranych. Zapisane przy nim słowa mówią o okresie budżetowym, a nie o produkcie.

Procurement delay to kod 11 z 27 transakcji bez decyzji. Trzy największe powody braku wygranej leżą po stronie firmy kupującego: umowa, przegląd i brak właściciela. Dlatego scenariusz wywiadu pyta, co działo się po decyzji, i dlatego krok 1 zostawia transakcje bez decyzji w rejestrze.

Flexible purchase, drugi kod wygranych z 23 transakcjami, można sprawdzić na podstawie publicznych cen. Plan Pro w Spona kosztuje 99 USD miesięcznie i obejmuje 10 500 kredytów. Nowa sesja wyszukiwania zużywa 1000 kredytów, więc zostaje 9500. Standard Search z samym adresem e-mail kosztuje od 3 do 7 kredytów za lead.

Według naszych obliczeń pierwszy miesiąc daje mniej więcej od 1357 do 3166 zweryfikowanych leadów. Każde wyszukiwanie zaczyna się od darmowej próbki. Opłata podlega zwrotowi przez 14 dni, o ile nie wykorzystasz żadnych kredytów. Właśnie taki rodzaj zakupu opisują zapisane słowa kupującego przy tym kodzie.

Szablon analizy win loss: na co odpowiada każda zakładka

Szablon to anglojęzyczny arkusz Google Sheets z pięcioma zakładkami. Zrób kopię, a otworzy się ze 137 transakcjami Spona już wpisanymi do zakładki Rejestr szans (Deal log). Każda liczba i każde oznaczenie w pozostałych zakładkach działa, zanim cokolwiek wpiszesz. Wyczyść przykładowe wiersze, gdy przyjdzie pora, albo zostaw je na miesiąc, żeby poznać formuły.

Trzy elementy arkusza chronią rejestr przed rozjechaniem się. Po pierwsze kolumna Kontrola kodu (Code check) w zakładce Deal log sprawdza kod w każdym wierszu względem wyniku za pomocą COUNTIFS. Wyświetla „Kod nie pasuje do wyniku” („Code does not fit outcome”), gdy handlowiec wpisze powód wygranej przy przegranej transakcji. Po drugie kolumny Outcome, Przedział wielkości (Size band) i Reason code to listy rozwijane z zakresu, które odrzucają wszystko spoza listy.

Kolumna Wskazany konkurent (Competitor named) tylko ostrzega, więc „ZoomInfo + Sales Navigator” nadal przejdzie. Po trzecie zakładka Reason codes oznacza każdy kod z mniejszą liczbą transakcji niż minimum ustawione w zakładce Instructions. Oznaczenie brzmi „Za mało transakcji do odczytu” („Too few deals to read”), a minimum na start wynosi 10. Przy przykładowych wierszach to oznaczenie mają cztery kody.

Zakładka Reason codes trzyma też liczby Spona w dwóch stałych kolumnach do porównania. Twoje bieżące liczby stoją obok, więc widzisz, czy twoje przegrane skupiają się tam, gdzie nasze. Każdy kod ma sugerowany zespół-właściciela z listy rozwijanej: Sprzedaż (Sales), Marketing, Produkt (Product), Cennik (Pricing) albo Zarząd (Leadership). Zmień nazwy kodów pod swój produkt, a właściciel zostanie przy wierszu.

W zakładce Interview guide widać problem 15% zgodności. Każdy wiersz wywiadu pobiera wynik transakcji i kod z CRM z zakładki Deal log. Bierze główny powód kupującego z listy rozwijanej z tymi samymi kodami i wyświetla Zgodne (Match) albo Niezgodne (Mismatch). Zakładka Summary zamienia to we wskaźnik zgodności.

Jeśli twój wskaźnik jest niski, handlowcy nie kłamią. Zgadują, a rozwiązaniem jest krok 3, nie reprymenda. Zakładka Summary rozbija też wyniki według przedziału wielkości firmy i według wskazanego konkurenta. Gdy dodasz daty zamknięcia, policzy zamknięte transakcje w każdym miesiącu.

Dwie kolejne kolumny w zakładce Deal log pilnują uczciwości rejestru. Source of reason zapisuje, czy kod pochodzi z pola CRM (CRM field), z omówienia z handlowcem (Rep debrief) czy z wywiadu z kupującym (Buyer interview), więc widzisz, jaka część rejestru opiera się na domysłach. Kolumna Interviewed oznacza transakcje z przeprowadzonym wywiadem, a zakładka Summary je liczy. Przefiltruj zakładkę Deal log według wyniku, żeby porównać wywiady przy wygranych i przegranych z równym podziałem, który zaleca Clozd.

Inne darmowe szablony na ten temat są uboższe. Szablon Mural to tablica dostępna po rejestracji, arkusz Klue jest ukryty za formularzem, a plik XLSX od Unkover ma osiem pól i żadnych przykładowych danych. Użytkownicy Excela mogą pobrać nasz plik przez Plik, Pobierz, Microsoft Excel (.xlsx). Formuły używają COUNTIFS, INDEX, MATCH i SUMPRODUCT, więc Excel i LibreOffice przeliczają je bez poprawek.

Od powodów do zmian

Liczba to jeszcze nie zmiana. Zakładka Reason codes przypisuje każdemu kodowi sugerowany zespół-właściciela. Zakładka Deal log zapisuje pytanie, które handlowiec zadał, gdy kod był już jasny. Te pytania to początek poprawki, bo sprawdzają, czy powód był prawdziwy, czy był grzecznym wyjściem z rozmowy.

Sześć kodów, które kosztowały Spona transakcje, z sugerowanym przez nas właścicielem i pytaniem, które zadał handlowiec:

Trzy z sześciu pytań dotyczą terminów: daty odnowienia, daty powrotu do tematu i wydarzenia, które uruchomi projekt. To wskazuje na poprawkę w kwalifikacji, a nie w produkcie. Pytaj o datę odnowienia umowy z obecnym dostawcą i o właściciela projektu już na pierwszej rozmowie. Te dwa pytania należą do naszej checklisty kwalifikacji leadów.

Workflow change wskazuje na produkt i onboarding. Przegrany kupujący nie mógł zmienić procesu w środku migracji, więc zmianą jest pilotaż, który działa obok obecnego workflow, zamiast go zastępować. Budget constraint wskazuje na cennik. Jego pytanie dotyczy tego, jaki obecny koszt zastąpiłby pilotaż, co zamienia „brak budżetu” w porównanie.

Kody wygranych zasługują na to samo podejście. Kod Verified coverage wygrał najwięcej transakcji. Dowód, który za nim stoi, czyli test na kontach docelowych samego kupującego, należy do pierwszej rozmowy, nie do trzeciej. Kod Flexible purchase wygrał 23 transakcje, co przemawia za tym, by zaczynać od małego pilotażu zamiast od rocznej umowy.

Przeglądaj liczby według stałego harmonogramu. Clozd zaleca stały przegląd miesięczny lub kwartalny. Rytm miesięczny pasuje do zespołu, który zamyka 30 lub więcej transakcji miesięcznie, a kwartalny do mniejszego. Praktyczny opis od Cotera przedstawia jednostronicowe podsumowanie miesiąca w trzech akapitach: liczby, wzorzec i działania.

Zakładka Summary daje ci pierwszy akapit. Drugi akapit to kod, którego liczba zmieniła się najbardziej. Trzeci mówi, kto co zmienił, i podaje datę, kiedy sprawdzisz to ponownie.

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Najczęstsze pytania (FAQ)

Kto powinien prowadzić wywiady win loss?

Nie handlowiec, który prowadził transakcję. Klue zaleca bezstronną osobę prowadzącą wywiad, a sprzedaż zapewnia ciepłe wprowadzenie. Pragmatic Institute chce, żeby rozmowy prowadzili ludzie od produktu, bo kupujący mogą zatajać krytykę, która mogłaby zaszkodzić handlowcowi.

Badanie Clozd wykazało, że zespoły korzystające z firmy zewnętrznej ponad dwa razy częściej mówią, że ich feedback jest wystarczająco pogłębiony. Dla małego zespołu praktycznym rozwiązaniem pośrednim jest szef sprzedaży, który nie uczestniczył w transakcji.

Ile transakcji potrzeba do analizy?

Klue ustala próg na poziomie 10 podobnych transakcji na wzorzec. W przypadku wywiadów Clozd stwierdza, że odpowiedzi osiągają nasycenie przy 25 do 30 wywiadach na segment. User Intuition podaje minimum dla wzorców kierunkowych na poziomie od 20 do 30 wywiadów.

Liminal zauważa, że większość programów przeprowadza wywiady z 8 do 12 kupującymi na kwartał, czyli za mało, żeby dostrzec zmianę. 29 wywiadów Spona w ciągu czterech miesięcy mieści się w zakresach Clozd i User Intuition, jeśli traktować je jako jeden segment.

Jak liczy się win loss?

Wskaźnik wygranych to liczba wygranych transakcji podzielona przez liczbę zamkniętych transakcji. Przykład Klue dzieli 40 wygranych przez 100 zamkniętych transakcji. Te same 40 wygranych przy 60 przegranych daje stosunek wygranych do przegranych dwa do trzech. Zdecyduj, czy „zamknięte” obejmują transakcje bez decyzji, i napisz to w raporcie.

Rejestr Spona liczy dwa wskaźniki z tych samych liczb: 62,0% wszystkich zamkniętych transakcji i 77,3% transakcji rozstrzygniętych. Szablon pokazuje oba, bo różnica między nimi wynika z twoich transakcji bez decyzji.

Czy powody z CRM mogą zastąpić wywiady?

Nie, ale zachowaj jedno i drugie. Kod w CRM jest tani, dostępny od razu i obejmuje każdą transakcję, więc stanowi właściwy mianownik do liczenia. W HubSpot pierwszą poprawką jest ograniczenie domyślnych właściwości powodów do stałej listy twoich kodów.

Wywiad jest powolny i obejmuje tylko próbkę, ale to jedyne źródło, nad którym kontrolę ma kupujący. Wskaźnik 15% zgodności od Clozd to powód, dla którego szablon ma kolumnę Match. Pokazuje ona, jak często oba źródła zgadzają się w twoich własnych transakcjach.