Limit kredytowy to miejsce, gdzie e-commerce spotyka windykację

Jedyne „nie" w całym systemie

Katalog zachęca. Wyszukiwarka pomaga. Koszyk podpowiada. Cały interfejs jest zbudowany wokół tego, żeby klient kupił.

I nagle, przy zatwierdzeniu zamówienia, system informuje kontrahenta, z którym firma współpracuje od ośmiu lat, że nie może kupić. Bo ma 4 tys. zł przeterminowanych należności sprzed dwóch tygodni.

To jest moment, w którym oprogramowanie e-commerce wchodzi w rolę windykacji - i robi to bez taktu, bez kontekstu i bez możliwości negocjacji. Handlowiec w tej samej sytuacji zadzwoniłby i zapytał, co się dzieje.

Dlaczego to nie jest twoja decyzja

Bo konsekwencje blokady nie są techniczne, tylko handlowe - i ponosi je ktoś inny niż zespół, który ją wdraża.

Zablokujesz za ostro: tracisz zamówienie, klient dzwoni do handlowca wściekły, handlowiec dzwoni do ciebie, a firma traci obrót od klienta, który miał pieniądze i po prostu zapomniał zapłacić jednej faktury.

Zablokujesz za miękko: sprzedajesz na kredyt komuś, kto nie zapłaci, a windykacja pyta, dlaczego system to przepuścił.

Żadna z tych dwóch pomyłek nie jest pomyłką e-commerce. Obie są decyzjami o apetycie firmy na ryzyko kredytowe - i podejmuje je dyrektor finansowy, nie zespół projektowy. Rolą e-commerce jest wyegzekwować regułę, którą ktoś inny ustalił, a nie ją wymyślić.

Problem w tym, że na warsztatach o wdrożeniu nie ma dyrektora finansowego. Więc reguła powstaje domyślnie, w kodzie, na podstawie tego, co wydawało się rozsądne deweloperowi.

Trzy scenariusze blokady

Warto je nazwać, bo różnią się bardziej, niż wygląda.

Twarda blokada. Nie da się złożyć zamówienia. Uczciwa, przewidywalna i najbardziej brutalna. Sensowna przy klientach z realnym problemem płatniczym.

Miękka blokada. Zamówienie się składa, ale trafia do kolejki akceptacji po twojej stronie - handlowiec albo finanse decydują. Klient nie dostaje ściany, dostaje „przyjęte, potwierdzimy". To jest wariant, który w większości przypadków wygrywa, bo zachowuje relację i kontrolę jednocześnie. Wymaga jednak działającego workflow akceptacji.

Ostrzeżenie. Klient widzi, ile mu zostało do limitu, zanim dojdzie do checkoutu. Nie blokuje niczego, a rozwiązuje sporą część problemu - bo większość przekroczeń to nie jest zła wola, tylko brak informacji.

Te trzy da się łączyć: ostrzeżenie od 80% limitu, miękka blokada powyżej 100%, twarda przy przeterminowanych powyżej progu ustalonego przez finanse.

Co ustalić przed wdrożeniem

Cztery pytania i wszystkie są do finansów, nie do IT.

• Co dokładnie liczy się do limitu? Same faktury czy też zamówienia w realizacji i towar zarezerwowany? Odpowiedź zmienia wynik o dziesiątki procent.
• Ile dni po terminie to jeszcze nie problem? Zwykle jest jakaś tolerancja i zwykle nikt jej nie zapisał.
• Kto może odblokować i w ile minut? Jeśli odpowiedź brzmi „pani z księgowości, jak wróci z urlopu", to miękka blokada właśnie zamieniła się w twardą.
• Czy limit jest na spółce, czy na grupie? Przy kliencie z oddziałami to pytanie potrafi zatrzymać projekt na tydzień.

Mechanikę samych limitów i to, jak je czytać z ERP-a, rozbieram w tekście o limitach kredytowych. Ten wpis jest o czymś prostszym: to jest jedyna funkcja w twoim sklepie, która mówi klientowi „nie" - więc nie może powstać przypadkiem.

Co dalej

• Mechanika limitów i czytanie ich z ERP: Limity kredytowe
• Miękka blokada wymaga tego procesu: Workflow akceptacji zamówień
• Jak klient za to zapłaci: Płatności B2B z terminem