Rozdziały przewodnika
Prowizje
Problem#
Prowizja to najlepszy przykład decyzji, która wygląda na jedno pole, a jest pytaniem o historię. Stawka zmieni się prędzej czy później, a każde zamówienie sprzed zmiany musi zostać rozliczone tak, jak było wtedy.
Ten rozdział jest w przewodniku po to, żeby pokazać wzorzec, który wraca w kilku innych miejscach: wartość używana do liczenia pieniędzy nie może być odczytywana z bieżącej konfiguracji.
Minimalna wersja#
- Jedna stawka na platformę, zapisana w konfiguracji.
- Naliczona kwota prowizji zapisana przy pozycji zamówienia w chwili zakupu.
- Kwota zapisana wraz z podstawą, od której liczono, żeby dało się ją zweryfikować.
- Zwrot zmniejsza prowizję proporcjonalnie do zwróconej wartości.
Czego nie budować teraz#
- Hierarchii reguł per kategoria, typ produktu i sprzedawca, dopóki masz jedną stawkę.
- Interfejsu do negocjowania stawek indywidualnych.
- Prowizji zmiennej w czasie, na przykład malejącej wraz z obrotem.
- Symulatora pokazującego, ile sprzedawca zarobi przy różnych stawkach.
Zaplanuj z góry#
Wynik, nie reguła#
Przy zamówieniu ma leżeć naliczona kwota, a nie odwołanie do reguły, według której ją policzono. Odwołanie do reguły oznacza, że zmiana reguły zmienia przeszłość. Kwota zapisana wprost jest odporna na wszystko, co stanie się później z konfiguracją.
Miejsce na drugi wymiar#
Dziś stawka jest jedna. Jutro pojawi się inna dla jednej kategorii albo dla jednego sprzedawcy. Jeżeli naliczona prowizja jest zapisana przy pozycji, dołożenie drugiego wymiaru nie dotyka niczego historycznego. Jeżeli jest liczona przy odczycie, dotyka wszystkiego.
Kto finansuje rabat#
Rabat udzielony przez platformę zmniejsza wpływy platformy, a nie sprzedawcy. Rabat sprzedawcy zmniejsza jego przychód. Jeżeli model tego nie rozróżnia, każda promocja staje się sporem o to, kto za nią zapłacił.
Wyzwalacze#
- pierwsza zmiana stawki;
- pierwszy sprzedawca z wynegocjowaną inną stawką;
- pierwsza kategoria, dla której stawka ma być inna;
- pierwsza promocja finansowana przez platformę;
- sprzedawca kwestionuje wysokość potrącenia.
Następny etap#
Po pierwszym wyzwalaczu: nic, jeśli kwoty są utrwalone. To jest cała pointa tego rozdziału. Po drugim i trzecim: reguły z określonym pierwszeństwem, od najbardziej szczegółowej do ogólnej. Po piątym: pokazanie sprzedawcy rozbicia kwoty, co jest tanie, jeśli podstawa naliczenia była zapisana.
Częste błędy#
| Założenie | Dlaczego kosztuje |
|---|---|
| "Prowizja to liczba w ustawieniach." | Pierwsza zmiana stawki przelicza wstecz rozliczone zamówienia. |
| "Policzymy ją przy wypłacie." | Wypłata zależy wtedy od bieżącej konfiguracji, nie od stanu z chwili zakupu. |
| "Zwrot całkowity zeruje prowizję, częściowy pominiemy." | Zwroty częściowe zawyżają potrącenie i wracają jako reklamacja. |
| "Rabat to sprawa marketingu." | Bez wskazania, kto go finansuje, nie da się rozliczyć sprzedawcy. |
| "Zapiszemy odwołanie do reguły." | Zmiana reguły zmienia przeszłość. |
Co się sprawdza w praktyce#
Prowizja jest u mnie naliczana przy pozycji zamówienia i tam zostaje, razem z podstawą naliczenia. Dzięki temu zmiany stawek, dodanie reguł szczegółowych i wprowadzenie rabatów finansowanych przez platformę nie wymagały ani razu ruszania danych historycznych.
Rozbicie na to, kto finansuje obniżkę, okazało się potrzebne szybciej, niż zakładałem. Program lojalnościowy i rabaty powitalne to z perspektywy sprzedawcy pytanie, dlaczego dostał mniej, i bez jawnego zapisu odpowiedź wymaga rekonstrukcji.
Checklista#
- Naliczona kwota prowizji jest zapisana przy pozycji zamówienia.
- Razem z kwotą zapisana jest podstawa naliczenia.
- Zapisane jest, czy liczono od wartości przed rabatem, czy po.
- Zwrot częściowy zmniejsza prowizję proporcjonalnie.
- Wiadomo, kto finansuje każdy rabat.
- Zmiana stawki nie dotyka żadnego zamówienia sprzed zmiany.
Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.
Zobacz usługę budowy marketplace