Rozdziały przewodnika
Panel operatora: od jednej osoby do zespołu
Problem#
Narzędzia operacyjne rosną szybciej niż potrzeba, bo każde z nich wygląda na oczywiste. Filtry, kolejki, przypisania, uprawnienia, pulpity. Dla jednej osoby, która i tak wie, co ma zrobić, większość z nich jest kosztem bez zwrotu.
Właściwym pytaniem nie jest „czego potrzebuje panel administracyjny", tylko „ile osób podejmuje decyzje i czy muszą się rozliczać przed sobą nawzajem".
Trzy etapy#
| Etap | Co wystarcza | Czego jeszcze nie budować |
|---|---|---|
| Jedna osoba | ekrany kontekstowe: sprzedawca, zamówienie, zgłoszenie, wypłata | kolejki, przypisania, uprawnienia |
| Kilka osób | autor decyzji, notatki wewnętrzne, filtry, prosty stan sprawy | role szczegółowe, terminy, pulpity |
| Zespół operacyjny | kolejki z przypisaniem, rejestr działań, role | automatyzacja decyzji |
Minimalna wersja#
- Ekran sprzedawcy z jego produktami, zamówieniami, wypłatami i historią decyzji.
- Ekran zamówienia z pozycjami, płatnością, zwrotami i wysyłką.
- Lista rzeczy wymagających reakcji, choćby jako proste zestawienie.
- Wyszukiwanie po numerze zamówienia, e-mailu i nazwie sprzedawcy.
Czego nie budować teraz#
- Konfigurowalnych uprawnień per zasób.
- Pulpitu z wykresami, zanim ktoś zada pytanie, na które wykres odpowiada.
- Powiadomień wewnętrznych i systemu zadań.
- Eksportów do arkusza dla każdego widoku.
Zaplanuj z góry#
Kontekst zamiast agregatu#
Praca operatora polega na odpowiadaniu na pytania o konkretny obiekt: tego sprzedawcę, to zamówienie, ten zwrot. Ekran, który to gromadzi w jednym miejscu, jest wart więcej niż dziesięć list z filtrami.
Izolacja danych sprzedawcy jako reguła, nie jako widok#
Sprzedawca ma widzieć wyłącznie swoje dane, i to musi wynikać z warstwy dostępu do danych, a nie z tego, co pokazuje interfejs. Filtr w widoku jest łatwy do ominięcia przy pierwszym nowym ekranie.
Pole autora wszędzie tam, gdzie zapada decyzja#
To ten sam punkt co w rozdziale o moderacji i wraca tu, bo dotyczy każdego działania operatora: zmiany stanu zamówienia, ręcznej wypłaty, korekty stanu magazynowego.
Wyzwalacze#
- druga osoba dostaje dostęp do panelu;
- ktoś pyta, kto zmienił dany rekord;
- powtarzalne zadanie zajmuje więcej niż kilkanaście minut dziennie;
- pojawia się osoba, która ma widzieć tylko część danych;
- to samo pytanie od sprzedawców wraca co tydzień.
Następny etap#
Po pierwszym i drugim wyzwalaczu naraz: autor decyzji i notatki wewnętrzne. Po trzecim: akcja zbiorcza dla tego jednego zadania, nie dla wszystkich. Po czwartym: role, ale najprostsze możliwe. Po piątym: udostępnienie odpowiedzi sprzedawcy, żeby pytanie przestało wracać.
Częste błędy#
| Założenie | Dlaczego kosztuje |
|---|---|
| "Panel potrzebuje pulpitu." | Wykresy dla jednej osoby, która zna stan z pamięci. |
| "Filtr w widoku wystarczy do izolacji danych." | Nowy ekran omija filtr i wystawia cudze dane. |
| "Uprawnienia dodamy przy zespole." | Dodanie ich później oznacza przegląd wszystkich ścieżek. |
| "Każdy widok potrzebuje eksportu." | Praca nad funkcją, z której nikt nie korzysta. |
| "Automatyzujmy powtarzalne zadania." | Automatyzacja procesu, który wykonuje się trzy razy w tygodniu. |
Co się sprawdza w praktyce#
W panelu najbardziej użyteczne okazały się ekrany kontekstowe, a nie listy. Odpowiedź na pytanie sprzedawcy prawie zawsze wymaga zestawienia jego zamówień, wypłat i decyzji w jednym miejscu, a nie przeszukiwania osobnych widoków.
Izolacja danych sprzedawcy jest w tym obszarze jedyną rzeczą, której nie da się dołożyć bezboleśnie później. Każdy ekran dopisany zanim reguła stała się domyślna trzeba potem przejrzeć osobno.
Checklista#
- Istnieją ekrany kontekstowe dla sprzedawcy i zamówienia.
- Izolacja danych sprzedawcy wynika z warstwy dostępu, nie z widoku.
- Każda decyzja operatora ma miejsce na autora.
- Nie ma kolejek ani ról, dopóki nie ma drugiej osoby.
- Wyszukiwanie obejmuje numer zamówienia, e-mail i sprzedawcę.
Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.
Zobacz usługę budowy marketplace