Kwalifikacja zapytań i przygotowanie ofert bez ręcznej roboty

Zapytanie trafia do handlowca jako gotowy, opisany rekord w CRM, a nie surowa wiadomość do przepisania. Najpierw sprowadzamy zapytania z formularza, maila i komunikatora do jednego miejsca i rozpoznajemy treść: czego dotyczy, jaki jest zakres, czy klient podał budżet i termin. Na tej podstawie powstaje wpis w CRM z kategorią, priorytetem i przypisaniem do handlowca według ustalonych reguł. Automat sprawdza też, czy taki kontakt już istnieje, żeby nie mnożyć duplikatów, i uzupełnia dane firmy ze wskazanych źródeł.

Większość wdrożeń nazywanych automatyzacją sprzedaży kończy się na podpięciu formularza do CRM. Naszym zdaniem to jeszcze nie automatyzacja, tylko szybszy transport surowca: handlowiec dostaje ten sam tekst co wcześniej, tylko w innym oknie, i nadal musi go przeczytać, zrozumieć i opisać. Wartość zaczyna się dopiero tam, gdzie rekord przychodzi z kategorią, właścicielem i informacją, czego w zapytaniu brakuje. Dlatego pierwszą rzeczą, którą ustalamy, nie jest narzędzie ani model, tylko to, jak ma wyglądać rekord, którego handlowiec nie musi poprawiać.

Każde pole uzupełnione automatycznie oznaczamy jako uzupełnione automatycznie — uważamy to za jedną z ważniejszych decyzji w całym projekcie, choć wygląda na kosmetykę. Handlowiec, który nie odróżnia danych podanych przez klienta od danych dopasowanych przez automat, po pierwszej pomyłce przestaje ufać obu. Wolimy zostawić pole puste, niż wypełnić je najlepszym przypuszczeniem: puste pole jest zadaniem do wykonania, a błędnie wypełnione — pułapką, która zadziała dopiero w ofercie.

• Kategoria sprawy i priorytet nadane według reguł, a nie według odczucia
• Właściciel przypisany od razu, żeby zapytanie nie leżało w kolejce bez adresata
• Rozpoznany zakres, budżet i termin, jeśli klient je podał
• Oznaczenie, które pola pochodzą od klienta, a które z automatycznego uzupełnienia
• Informacja o istniejącym kontakcie zamiast kolejnego duplikatu
• Wskazanie, czego w zapytaniu brakuje i o co trzeba dopytać

Zawodzi nie dlatego, że przepływ nie działa, tylko dlatego, że handlowcy przestają go używać. Mechanizm jest zwykle ten sam: automat raz dopasuje zapytanie do niewłaściwej firmy albo podstawi nieaktualną pozycję cennika, ktoś zauważy to przy kliencie, historia obiega zespół w jeden dzień i od tego momentu wszyscy na wszelki wypadek sprawdzają wszystko ręcznie. Wdrożenie formalnie działa, statystyki się zgadzają, a praca wróciła do arkusza i notatnika. Uważamy, że to najczęstszy sposób, w jaki takie projekty umierają — nie w awarii, tylko w cichym omijaniu.

Powszechne wyjaśnienie brzmi: to opór przed zmianą, trzeba przeszkolić zespół. Naszym zdaniem to zwykle nie opór, tylko racjonalna reakcja na narzędzie, które raz podało błędną informację przed klientem — handlowiec odpowiada za relację i nie ma powodu ryzykować jej dla cudzej wygody. Szkolenie nie odbuduje zaufania, którego podstawą jest dokładność danych. Odbudowuje je coś znacznie nudniejszego: widoczne źródło każdego pola, twarda reguła, że ceny pochodzą z cennika, i możliwość poprawienia wszystkiego przed wysłaniem.

Dlatego odradzamy wdrożenia, w których żaden handlowiec nie brał udziału w ustalaniu reguł. Technicznie zrobimy je tak samo dobrze, ale wiemy, jak się kończą: proces zaprojektowany wyłącznie przez zarząd i dział IT opisuje sprzedaż taką, jaka powinna być, a nie taką, jaka jest — a automat trafia dokładnie w tę różnicę. Prosimy więc o jedną osobę ze sprzedaży, która ma prawo powiedzieć „u nas to tak nie wygląda", i o zgodę, żeby jej zdanie coś znaczyło. To wymaganie stawiamy przed wyceną, nie po niej.

1. 01Pokazujemy pochodzenie każdego polaPrzy rekordzie widać, co podał klient, co przyszło z CRM, a co dopasował automat. Handlowiec nie musi zgadywać, czemu ufać, a to jest warunek, żeby w ogóle zaczął korzystać.
2. 02Zostawiamy puste, gdy nie wiemyAutomat nie zgaduje. Pole bez pewnego źródła zostaje puste i staje się zadaniem, zamiast cichą pomyłką, która wypłynie w dokumencie u klienta.
3. 03Pracujemy równolegle przed przełączeniemPrzez ustalony okres nowy proces działa obok dotychczasowego, a zespół porównuje wyniki na własnych sprawach, nie na przykładach z prezentacji.
4. 04Zbieramy pomyłki jako materiał, nie jako zarzutKażdy przypadek, w którym automat się pomylił, wraca do reguł i poprawia je. Bez tej pętli wdrożenie zatrzymuje się na dniu uruchomienia.

Bardzo często okazuje się, że lejek w CRM i lejek, według którego naprawdę pracuje zespół, to dwie różne rzeczy. W systemie są etapy wpisane kiedyś przy wdrożeniu, a prawdziwy stan sprawy siedzi w notatniku, w wątku na komunikatorze i w pamięci jednej osoby. Automat nie ma wtedy czego automatyzować — może co najwyżej sumiennie przesuwać puste etykiety. Naszym zdaniem to moment, w którym trzeba zatrzymać projekt techniczny i wrócić do rozmowy, bo żadne narzędzie nie odtworzy procesu, którego nikt nigdy nie zapisał.

Spisujemy więc etapy od handlowca, a nie z podręcznika sprzedaży, i stawiamy im jeden warunek: każdy etap musi dać się rozpoznać po zdarzeniu widocznym z zewnątrz. Wysłana oferta, umówione spotkanie, potwierdzony zakres, otrzymane zamówienie — to są etapy. „Klient jest ciepły" i „to się dopina" nie są etapami, tylko nastrojem, i nie da się na nich zbudować ani automatyzacji, ani prognozy sprzedaży, o którą ktoś i tak zapyta na koniec roku. To jedyne miejsce, w którym bywamy uparci wobec klienta, bo cała reszta wdrożenia stoi na tej jednej definicji.

Między rozbudowanym lejkiem, który opisuje każdy niuans, a krótkim, który zespół faktycznie uzupełni, wybieramy krótki. Rozbudowany wygląda lepiej na warsztacie i pustoszeje po miesiącu, bo każdy dodatkowy etap to kolejne kliknięcie odbierane jako biurokracja. A jeśli firma nie ma dziś żadnego zapisu szans sprzedażowych — ani CRM, ani nawet arkusza — odradzamy zaczynanie od agenta AI. Najpierw prosty rejestr, w którym w ogóle powstają dane; automatyzacja bez danych nie ma na czym pracować i zrobi jedynie szybszy bałagan.

Ofertę zatwierdza handlowiec — automat przygotowuje dokument, człowiek decyduje o wysyłce. Kiedy zapytanie ma komplet danych, przepływ składa ofertę z Waszego szablonu: pozycje, warianty, warunki, terminy, dane kontrahenta. Ceny pochodzą z jednego, wskazanego cennika — nie z modelu i nie z historii korespondencji — bo to jedyny sposób, żeby dokument był wiarygodny. Gotowy plik trafia do akceptacji: handlowiec sprawdza, poprawia, dopisuje to, czego automat nie mógł wiedzieć, i dopiero wysyła. Kroku akceptacji nie proponujemy przesuwać bez wyraźnej decyzji po Waszej stronie.

Krąży przekonanie, że skoro model językowy potrafi napisać ofertę, to potrafi ją także wycenić. Nie potrafi i nie jest to kwestia lepszego promptu. Model jest dobry w formułowaniu zdań i układaniu dokumentu, a zły w pilnowaniu, że rabat nie zjadł marży, że wariant B nie zawiera pozycji z cennika sprzed dwóch aktualizacji i że obiecany termin ma pokrycie w produkcji. Dlatego ceny i warunki pochodzą u nas z jednego wskazanego źródła, a model odpowiada najwyżej za sposób opisania tego, co cennik już rozstrzygnął.

Automatyczną wysyłkę ofert bez człowieka odradzamy niemal zawsze, choć technicznie jest to najprostszy element całego przepływu. Jedna oferta z błędną ceną wysłana do klienta kosztuje więcej niż wszystkie minuty, które ten skrót miałby zaoszczędzić — i kosztuje w miejscu, w którym płaci się reputacją, a nie budżetem. Wyjątek robimy dla przypadków naprawdę powtarzalnych, o wąskim zakresie i niskiej wartości, i traktujemy to jako Waszą świadomą decyzję zapisaną w projekcie, nie jako domyślne ustawienie, które ktoś kiedyś włączył.

1. 01SzablonWasz dokument, Wasz układ i Wasze warunki. Nie proponujemy przebudowy szablonu przy okazji wdrożenia — to osobna decyzja i osobna rozmowa.
2. 02CennikJedno wskazane źródło pozycji i stawek. Jeśli cennik ma wyjątki, opisujemy je regułami, zamiast liczyć na wyczucie automatu.
3. 03Dane kontrahentaZ rekordu w CRM, z widocznym oznaczeniem pól uzupełnionych automatycznie, żeby handlowiec wiedział, co sprawdzić w pierwszej kolejności.
4. 04AkceptacjaHandlowiec sprawdza, poprawia i dopisuje to, czego automat nie mógł wiedzieć. Ten krok zostaje, dopóki nie zdecydujecie inaczej na piśmie.

Przypomnienia opieramy na zdarzeniach i zatrzymujemy je w momencie odpowiedzi klienta. Wyzwalaczem jest brak odpowiedzi po ustalonym czasie, otwarcie dokumentu albo prośba o zmianę zakresu, a przy każdym kroku decydujemy, czy ma być mailem, czy zadaniem dla handlowca do wykonania telefonicznie. Automat, który pisze mimo reakcji klienta, kosztuje więcej, niż daje, dlatego sekwencje projektujemy oszczędnie. Podstawa prawna kontaktu handlowego i zgody pozostają Waszą decyzją — my dostarczamy mechanizm i miejsce, w którym zgoda jest odnotowana.

Granica między przypomnieniem a spamem nie leży naszym zdaniem w liczbie wiadomości, tylko w tym, czy każda kolejna cokolwiek wnosi. Przypomnienie dotyczy sprawy, którą klient sam otworzył, i niesie nową informację albo konkretne pytanie: oferta jest ważna do piątku, czy przedłużyć; czy zakres w wariancie B odpowiada. Spam to ta sama treść w nowym opakowaniu, wysłana dlatego, że tak wypadło w harmonogramie. Test jest prosty i warto zrobić go na sobie: gdyby ta wiadomość przyszła do Was w sprawie, o którą naprawdę pytaliście, byłaby pomocą czy hałasem?

Uważamy też, że każda sekwencja musi mieć wyraźny koniec, a ostatnia wiadomość powinna go nazwać wprost: zamykamy temat, wracamy, gdy dacie znać. Sekwencja bez końca przestaje być kontaktem handlowym i staje się przypomnieniem z kalendarza, które nie wie, że rozmowa dawno się skończyła. Odradzamy natomiast budowanie przypomnień na zdarzeniach, których klient nie kontroluje i o których nie wie — „otworzył dokument trzeci raz" to szum, a reakcja na ten szum wygląda z drugiej strony jak podglądanie. Zysk jest wątpliwy, a wrażenie zostaje dłużej niż jedna transakcja.

• Odpowiedź klienta w dowolnym kanale, także telefonicznie
• Zmiana etapu sprawy w CRM przez handlowca
• Prośba o wstrzymanie kontaktu lub wycofanie zgody
• Wyczerpanie ustalonej liczby kroków, bez cichego przedłużania sekwencji
• Ręczne przejęcie sprawy: od tego momentu decyduje człowiek, a nie harmonogram

Agent AI nie zastąpi handlowca. Zastąpi kilkanaście minut jego dnia, powtarzanych codziennie: przepisywanie danych z maila do CRM, składanie dokumentu z gotowych klocków, pilnowanie, żeby sprawa nie utknęła bez kontaktu. To dokładnie ta część dnia, w której handlowiec nie sprzedaje — i cała różnica między sensownym wdrożeniem a pokazem na konferencji polega na tym, którą część dnia bierze się na cel.

Reszta zostaje po stronie człowieka i naszym zdaniem powinna zostać. Automat nie usłyszy, że „za drogo" znaczy czasem „nie widzę wartości", a czasem „nie mam teraz budżetu, wróćmy w nowym roku" — a to dwie zupełnie różne sprzedaże. Nie rozpozna, kto w organizacji klienta naprawdę podejmuje decyzję, choć na papierze podejmuje ją ktoś inny. Nie weźmie odpowiedzialności za obietnicę terminu, którą ktoś musi dowieźć produkcją, i nie zdecyduje o odstępstwie od warunków, bo to decyzja o pieniądzach firmy. Nie zadzwoni też w trudnej sprawie, a w sprzedaży telefon w niewygodnym momencie bywa całą przewagą.

Powiemy również rzecz, która nam w sprzedaży nie pomaga: opublikowanego wdrożenia AI w sprzedaży jeszcze nie mamy — nasze portfolio to strony, sklepy i aplikacje. Wataha Media jest jednoosobową działalnością, więc dla Waszego działu sprzedaży oznacza to zaletę i ryzyko naraz: kontakt bez warstwy pośredników i bez przekazywania sprawy między konsultantami, ale też jeden zasób, który trzeba uwzględnić w harmonogramie. Mówimy o tym przed umową, nie po niej, i z tego samego powodu proponujemy zaczynać od jednego kanału zapytań zamiast od całego procesu sprzedaży. Mniejszy pierwszy krok jest tu ostrożnością wobec Was, nie wobec nas.

• Rozmowa, w której trzeba usłyszeć, co klient mówi między zdaniami
• Decyzja o rabacie i odstępstwie od standardowych warunków
• Zobowiązanie do terminu, które ktoś w firmie musi realnie dowieźć
• Rozpoznanie, kto po stronie klienta faktycznie podejmuje decyzję
• Telefon wtedy, gdy kolejny mail już niczego nie zmieni