Koszyk zapytań ofertowych (RFQ) w hurtowni B2B - kiedy zastępuje cenę

Jest taki moment w projekcie portalu B2B, w którym pada zdanie: „u nas nie da się pokazać ceny". Czasem to wymówka, częściej fakt.

Cena zależy od ilości, od tego, czy towar jest na stanie, od transportu, od tego, czy klient bierze paletę czy dwie sztuki, a bywa, że po prostu od negocjacji. Wtedy koszyk z przyciskiem „kup teraz" jest wprowadzaniem w błąd, a katalog bez żadnej ścieżki dalej jest ślepym zaułkiem.

Rozwiązaniem pośrednim jest koszyk zapytań ofertowych, w skrócie RFQ. Klient składa listę pozycji tak samo jak w zwykłym koszyku, tylko na końcu nie płaci, tylko wysyła zapytanie. Ten tekst jest o tym, kiedy to ma sens, co musi się w takim zapytaniu znaleźć i gdzie ten mechanizm potrafi zaszkodzić sprzedaży.

Kiedy cena naprawdę nie może stać przy produkcie

Cztery sytuacje, w których RFQ jest właściwym rozwiązaniem, a nie unikiem.

Cena zależy od wolumenu w sposób nieliniowy. Nie chodzi o prosty próg ilościowy, który da się zapisać regułą, tylko o sytuację, w której przy większym zamówieniu zmienia się sposób produkcji, transportu albo pakowania.

Towar jest konfigurowalny lub robiony na wymiar. Dopóki klient nie poda wymiaru, materiału i wykończenia, nie ma czego wyceniać. Tu RFQ często idzie w parze z konfiguratorem.

Transport jest istotną częścią ceny. Przy towarze ciężkim albo wielkogabarytowym koszt dostawy potrafi przesądzić o opłacalności całego zamówienia i nie da się go policzyć bez adresu i terminu.

Warunki są wynikiem negocjacji. Część hurtowni po prostu nie chce pokazywać cen publicznie, bo cennik jest elementem przewagi konkurencyjnej.

Jeśli żadna z tych sytuacji nie zachodzi, a cena jest ukrywana „bo tak zawsze było", to RFQ nie naprawi problemu. Doda tylko krok, który kosztuje klienta czas.

RFQ kontra zwykły koszyk: co się naprawdę zmienia

Różnica nie polega na zamianie napisu na przycisku.

Najważniejsza konsekwencja jest organizacyjna, nie techniczna. Koszyk z ceną sprzedaje sam. Koszyk zapytań przenosi robotę na człowieka. Jeśli nikt nie odpowiada na zapytania w ciągu kilku godzin, mechanizm działa gorzej niż numer telefonu na stronie.

Dlatego pierwsze pytanie przy wdrożeniu nie brzmi „jak to zbudować", tylko „kto i w jakim czasie odpowiada".

Co musi znaleźć się w zapytaniu, żeby było coś warte

Puste zapytanie o treści „proszę o wycenę" jest gorsze niż brak zapytania, bo generuje rundę pytań zwrotnych i opóźnia wszystko o dobę.

Zapytanie użyteczne dla handlowca zawiera:

1. Pozycje z indeksami i ilościami, dokładnie tak jak w koszyku
2. Dane kontrahenta, najlepiej pobrane z konta, a nie wpisywane ręcznie
3. Termin oczekiwany, bo to często decyduje, czy w ogóle da się zrealizować
4. Miejsce dostawy, bez którego nie policzy się transportu
5. Uwagi kupującego w wolnym polu, bo tam ląduje kontekst, którego żaden formularz nie przewidzi
6. Załączniki, jeśli branża tego wymaga: rysunek, specyfikacja, poprzednia oferta

Dwie rzeczy, które warto dołożyć, a które rzadko są od razu: możliwość podania własnego numeru zapytania po stronie klienta oraz zapis, z jakiej konfiguracji albo z jakiego wcześniejszego zamówienia to zapytanie powstało. Jedno i drugie oszczędza korespondencji.

Ścieżka od zapytania do zamówienia

Sam koszyk to jedna piąta pracy. Reszta to obieg.

Zapytanie wpada i dostaje numer oraz status. Klient widzi, że dotarło, i to jedna z rzeczy, na których najczęściej się oszczędza, a potem generuje telefony „czy państwo dostali".

Handlowiec wycenia. Tu jest rozwidlenie: albo przygotowuje ofertę ręcznie, albo system podpowiada ceny z cennika kontrahenta, a handlowiec je koryguje. Drugie podejście jest szybsze, ale wymaga, żeby warstwa cenowa w ogóle istniała.

Oferta wraca do klienta z terminem ważności. Bez daty ważności oferta żyje wiecznie i wraca po pół roku przy innych kosztach.

Klient akceptuje albo negocjuje. Jeśli akceptuje, zapytanie zamienia się w zamówienie i dopiero wtedy trafia do ERP. Jeśli negocjuje, powstaje kolejna wersja oferty i to jest moment, w którym większość wdrożeń traci historię. Warto od początku zakładać wersjonowanie.

Zamknięcie ze statusem. Także przy odmowie, z powodem. Bez tego nie da się później powiedzieć, dlaczego połowa zapytań nie kończy się sprzedażą.

Jak to wygląda w działającym portalu

W portalu B2B, który zbudowałem dla Ustawnik.pl, koszyk zapytań ofertowych działa obok zwykłego koszyka, a nie zamiast niego. Kontrahent z przyznanymi warunkami kupuje normalnie, a zapytanie składa tam, gdzie cena wymaga ustalenia.

Do zapytania dołączone jest pole uwag kupującego, bo w praktyce to ono najczęściej przesądza o tym, czy handlowiec odpowie trafnie za pierwszym razem. Osobną rzeczą, która okazała się ważniejsza, niż zakładałem, jest ponowienie wcześniejszego zamówienia jednym kliknięciem. Duża część ruchu w hurtowni to powtórka, więc skrócenie tej ścieżki daje więcej niż kolejny filtr w katalogu.

Kiedy RFQ szkodzi sprzedaży

Trzy sytuacje, w których lepiej go nie wdrażać.

Gdy nikt nie odpowiada szybko. Jeśli zapytania leżą po dwa dni, klient w tym czasie kupuje gdzie indziej. Koszyk zapytań bez zobowiązania czasowego to sposób na utratę klienta z zachowaniem pozorów procesu.

Gdy cena mogłaby być pokazana. Każdy dodatkowy krok kosztuje konwersję. Jeśli 80 procent asortymentu da się wycenić regułą, to te 80 procent powinno mieć cenę, a RFQ zostaje dla reszty.

Gdy zastępuje konfigurator. Przy produktach na wymiar wysyłanie zapytania bez podania parametrów przerzuca całą pracę na handlowca. Wtedy właściwym rozwiązaniem jest konfigurator, który zbierze wymiary, a zapytanie wyśle już z gotową specyfikacją.

Ile to kosztuje

Sam koszyk zapytań w istniejącym portalu, razem z formularzem, numeracją i powiadomieniami, to zwykle kilkanaście tysięcy złotych. Pełny obieg z wersjonowaniem ofert, statusami, terminami ważności i eksportem do systemu, w którym pracuje firma, mieści się raczej w przedziale dwudziestu kilku do czterdziestu kilku tysięcy, zależnie od tego, ile ról obsługujemy i jak głęboko wchodzimy w integracje.

Jeśli portalu jeszcze nie ma, to RFQ jest jednym z modułów całego wdrożenia, a nie osobnym projektem. Widełki całości rozkładam w tekście o koszcie platformy B2B.

Często zadawane pytania

Czy RFQ i koszyk z ceną mogą działać jednocześnie?

Tak i zwykle tak właśnie powinno być. Część asortymentu ma cenę wyliczaną regułą i ta część sprzedaje się sama. Reszta, czyli towar na wymiar, nietypowe ilości albo pozycje sprowadzane na zamówienie, idzie ścieżką zapytania. Dzielenie tego sztywno na cały sklep w jednym trybie zwykle oznacza, że traci się albo konwersję, albo wiarygodność ceny.

Czy klient musi być zalogowany, żeby wysłać zapytanie?

Nie musi, ale warto, żeby mógł. Zapytanie od zalogowanego kontrahenta przychodzi z kompletem danych i historią, więc handlowiec odpowiada od razu. Zapytanie od gościa wymaga weryfikacji, kim jest pytający, co kosztuje czas. Rozsądny kompromis: gość może wysłać zapytanie, ale formularz prosi o NIP, a system podpowiada założenie konta.

Co zrobić z zapytaniami, które nigdy nie kończą się zamówieniem?

Zamykać je ze statusem i powodem. To najbardziej niedoceniana część całego mechanizmu. Po kwartale widać, czy przegrywacie ceną, terminem, brakiem towaru, czy po prostu czasem odpowiedzi. Bez tego zapisu każda rozmowa o poprawie procesu opiera się na przeczuciach.

Czy oferta wysłana z portalu jest wiążąca?

To zależy od tego, jak ją sformułujecie, i warto rozstrzygnąć to na etapie projektu, nie po pierwszym sporze. W praktyce stosuje się termin ważności oraz zastrzeżenie o dostępności towaru. Treść tych zapisów powinien zatwierdzić ktoś po Waszej stronie, kto odpowiada za warunki handlowe, bo to jest decyzja prawna, nie techniczna.

Czy zapytania mają trafiać do ERP?

Zwykle nie na etapie zapytania. Do ERP trafia dopiero zaakceptowane zamówienie, bo wcześniej nie ma czego księgować, a zaśmiecanie systemu dokumentami, z których większość nie dojdzie do skutku, utrudnia pracę. Wyjątek to firmy, w których ofertowanie jest już prowadzone w ERP i wtedy portal powinien się w to wpiąć, a nie budować drugi obieg obok.

Ile trwa wdrożenie samego koszyka zapytań?

Jeśli portal już działa i ma konta kontrahentów, to zwykle kilka tygodni. Najwięcej czasu zajmuje nie formularz, tylko ustalenie obiegu: kto odpowiada, w jakim czasie, co się dzieje przy negocjacji i jak wygląda zamknięcie. Te decyzje warto podjąć przed pisaniem kodu, bo później każda zmiana dotyka kilku ekranów naraz.

Podobne teksty z bloga

• Portal B2B dla dystrybutora - 12 pytań - decyzje przed startem projektu
• Ustawnik.pl - portal B2B na WooCommerce - jak to wygląda we wdrożeniu
• Cenniki indywidualne w hurtowni online - kiedy cenę jednak da się pokazać
• Platforma B2B dla hurtowni - ile kosztuje - budżet całego wdrożenia
• B2B vs B2C e-commerce - dlaczego w detalu tego problemu nie ma