Sprzedawca: model danych i onboarding

Problem#

Onboarding sprzedawcy wygląda na formularz, a jest rozstrzygnięciem trzech osobnych pytań: kogo w ogóle dopuszczasz do sprzedaży, które dane trzymasz u siebie, a które zostają u dostawcy płatności, oraz w którym momencie sprzedawca staje się operacyjnie gotowy.

Pomieszanie tych pytań kończy się zwykle tak samo: konto istnieje, produkty są wystawione, a przy pierwszej sprzedaży okazuje się, że nie da się wypłacić pieniędzy albo nie wiadomo, kto jest stroną umowy z kupującym.

Minimalna wersja#

Sprzedawca potrzebuje jawnego stanu, a nie zestawu rozproszonych flag. Najmniejszy sensowny zestaw to pięć stanów i jedno rozróżnienie.

Gotowość operacyjna to pochodna kilku warunków, a nie pole ustawiane ręcznie przez operatora. Zwykle wystarczą cztery: dane firmy, weryfikacja u dostawcy płatności, ustawiona wysyłka i przynajmniej jeden produkt. Można ją liczyć przy odczycie albo przeliczać po każdej zmianie i zapisywać. Ważne jest to, żeby nikt nie ustawiał jej ręcznie, bo wtedy przestaje opisywać rzeczywistość.

Czego nie budować teraz#

• Własnej weryfikacji tożsamości. Dostawca płatności marketplace już ją prowadzi i ponosi za nią odpowiedzialność.
• Systemu odwołań od decyzji z wieloma instancjami. Na start wystarczy powód odrzucenia i kontakt.
• Migracji formy prawnej sprzedawcy. To rzadki przypadek, obsłuż go ręcznie, gdy wystąpi po raz pierwszy.
• Rozbudowanej macierzy uprawnień. Właściciel konta i członek zespołu wystarczą, dopóki nikt nie zgłosi realnej potrzeby.

Zaplanuj z góry#

Referencja do konta u dostawcy, nie kopia danych#

Platforma trzyma identyfikator konta u dostawcy płatności i własną interpretację jego statusu. Nie kopiuje dokumentów tożsamości ani danych rachunku. Dublowanie tych danych zwiększa zakres odpowiedzialności, a nie zmniejsza liczby problemów.

Dane, o które dopytasz później#

Zawsze pojawia się wymóg, o którym nie pomyślałeś na starcie. Model danych sprzedawcy ma znieść dołożenie pola bez migracji istniejących kont, a proces ma umieć poprosić o uzupełnienie i wstrzymać część funkcji do czasu odpowiedzi.

Dane historyczne oddzielnie od profilu#

Profil sprzedawcy się zmienia. Nazwa firmy widoczna przy zamówieniu sprzed roku ma zostać taka, jaka była wtedy. To ten sam wzorzec co snapshot ceny, tylko dotyczy tożsamości.

Wyzwalacze#

• pierwszy sprzedawca prosi o dodanie drugiej osoby do konta;
• pierwsze zgłoszenie żądania usunięcia danych;
• pierwsza zmiana formy prawnej albo nazwy firmy po sprzedaży;
• akceptacja zgłoszeń zaczyna zajmować więcej czasu niż inne zadania operacyjne;
• pojawia się druga osoba akceptująca sprzedawców.

Następny etap#

Po pierwszym wyzwalaczu: role w koncie i zaproszenia. Po czwartym: kolejka zgłoszeń z filtrami i informacja, kto podjął decyzję. Centralny rejestr działań personelu dopiero wtedy, gdy trzeba odtworzyć, kto co zrobił między kilkoma osobami.

Częste błędy#

Co się sprawdza w praktyce#

Na produkcji gotowość sprzedawcy jest u mnie wyprowadzana z kilku niezależnych warunków i przeliczana po każdej zmianie profilu, produktów, wysyłki albo statusu u dostawcy płatności. Sprzedawca widzi wtedy dokładnie, czego brakuje, a operator nie odklikuje niczego ręcznie.

Drugą rzeczą, która okazała się ważniejsza, niż wyglądała na początku, było rozdzielenie anonimizacji od usunięcia. Żądanie usunięcia danych przychodzi prędzej czy później i bez tego rozdzielenia zderza się z obowiązkiem przechowywania dokumentów.

Checklista#

• Stan sprzedawcy jest jawny i ma skończoną listę wartości.
• Dopuszczenie przez operatora i zdolność przyjmowania pieniędzy to dwa niezależne warunki.
• Gotowość operacyjna jest wyprowadzana z warunków, a nie ustawiana ręcznie.
• Platforma trzyma referencję do konta u dostawcy, nie kopię jego danych.
• Dane sprzedawcy widoczne przy zamówieniu są zapisane w momencie sprzedaży.
• Anonimizacja jest oddzielona od usunięcia rekordów rozliczeniowych.