TL;DR
- Kontekst: Lead UX w scaleupie e-commerce B2B z opakowaniami.
- Problem: Przy wycenie opakowania na zamówienie handlowiec ręcznie przepisywał dane do drugiego systemu. Wycena trwała kilka dni.
- Co zrobiłem: Połączyłem wycenę z budowaniem oferty i ułożyłem ją w 3 ścieżki na jednym ekranie.
- Wynik: Wycena jest gotowa tego samego dnia. Zespół mniejszy o ~20% utrzymał poziom sprzedaży.
Diagnoza
Wyceny opakowania na zamówienie nie da się zrobić prosto. Jedno zamówienie może mieć wiele pozycji, a każda z nich kilka wariantów (rozmiar, materiał, nadruk, ilość). Każdy wariant wycenia się z jednego z trzech źródeł, a na końcu trzeba zdecydować o marży. Tej złożoności nie dało się usunąć. Dało się za to usunąć niepotrzebną pracę wokół niej. Handlowiec przepisywał te same dane zamówienia do drugiego systemu i czekał kilka dni na cenę. Zostawiłem więc gęsty ekran, bo korzystają z niego doświadczeni ludzie, a zająłem się przepisywaniem. Połączyłem oba systemy i ułożyłem wycenę w trzy ścieżki w miejscu, w którym handlowiec buduje ofertę.
flowchart TD
subgraph Przed["Przed"]
A1["Handlowiec wpisuje zamówienie<br/>do systemu wycen"] --> A2["Dostaje ceny"]
A2 --> A3["Ręcznie przepisuje wszystko<br/>do systemu ofert"]
A3 --> A4["Klient czeka kilka dni"]
end
subgraph Po["Po"]
B1["Klient wpisuje pozycje<br/>i warianty"] --> B2["Handlowiec wybiera 1 z 3 ścieżek wyceny<br/>w miejscu budowania oferty"]
B2 --> B3["Oferta gotowa<br/>tego samego dnia"]
end
classDef good fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
classDef bad fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
classDef accent fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
class A1,A2,A3,A4 bad
class B1,B2 good
class B3 accent
style Przed fill:#fdf5f5,stroke:#e0c3c3,stroke-width:1px,color:#5f2626,rx:14,ry:14
style Po fill:#f2f8f3,stroke:#c2dcc8,stroke-width:1px,color:#1f4d33,rx:14,ry:14
linkStyle default stroke:#a8a8b3,stroke-width:1.5px
Co zrobiłem
- Prowadziłem przebudowę wycen jako Lead UX, z dwiema projektantkami w zespole. Kiedy w trakcie projektu odeszła PM-ka, przejąłem cały proces.
- W starej aplikacji Ruby on Rails zaprojektowałem tabelę, w której pozycje i ich warianty widać naraz. Każdą komórkę można rozwinąć i zobaczyć szczegóły wyceny: rodzaj wyceny po lewej, szczegóły po prawej.
- Zaprojektowałem 3 ścieżki wyceny: natychmiastową z API, przez platformę dostawców i ręczną. Handlowiec uruchamia je w miejscu tworzenia oferty i wybiera najszybszą, która pasuje.
- Usunąłem ręczne przepisywanie między systemem wycen a systemem ofert. Pozycje i warianty wpisane przez klienta są od razu punktem startowym dla handlowca.
Odtworzony szkic. Każdy wiersz ma status wyceny (⚡ to wycena natychmiastowa, w innym przypadku idzie zapytanie i wraca od 1 do n wycen). Nic nie trzeba przepisywać do drugiego systemu.
Wyniki
- Wycena trwa jeden dzień zamiast kilku (co najmniej dzień szybciej).
- Zespół handlowców obsługujących zamówienia na miarę był mniejszy o ~20%, a mimo to utrzymał poziom sprzedaży w czasie dołka na rynku.
- 3 ścieżki wyceny na jednym ekranie (natychmiastowa, platforma dostawców, ręczna) zamiast osobnego systemu wycen i przepisywania.
- Pozycje i warianty wpisane przez klienta trafiają prosto do oferty. Nikt nie wpisuje danych dwa razy.
Problem
Co nie działało w wycenach opakowań na zamówienie?
Wszystko, czego nie było w standardowej ofercie, musiał wycenić człowiek. Handlowiec wpisywał zamówienie do systemu wycen, dostawał ceny, a potem ręcznie przepisywał wszystko do osobnego systemu ofert, żeby przygotować ofertę dla klienta. Taka wycena trwała kilka dni. Handlowiec nie mógł nic zrobić, a klient w tym czasie mógł zrezygnować.
Dlaczego nie uprościć po prostu ekranu?
Bo ta złożoność jest prawdziwa i potrzebna handlowcowi. Zamówienie na miarę naprawdę ma wiele pozycji z wariantami, każdy wyceniany z innego źródła, a na końcu trzeba zdecydować o marży. Gdybym „uprościł” ekran i dodał wolnej przestrzeni, schowałbym rzeczy, które handlowiec musi widzieć, żeby szybko podjąć decyzję. Najwięcej dało się zyskać na pracy wokół wyceny.
Moja rola / zakres
- Byłem Lead UX obszaru back office i sprzedaży zamówień na miarę. W zespole miałem dwie projektantki, a po fali zwolnień jedną.
- Obecny proces rozpisałem razem z PM-ką. Kiedy odeszła, przejąłem go w całości.
- Przebudowa obejmowała kilka systemów: system wycen, system ofert, platformę dla dostawców i portal klienta.
Proces
- Mapa procesu z handlowcami. Zanim cokolwiek zaprojektowałem, rozpisałem cały obecny proces wyceny z ludźmi, którzy pracowali w nim na co dzień.
- Prototyp tabeli i testy z 2–3 handlowcami. W tych sesjach ustaliliśmy, ile informacji zmieścić na ekranie, żeby dało się go nadal szybko przejrzeć.
- W trakcie projektu przejąłem całe wdrożenie i koordynowałem pracę zespołów backendu i platformy dla dostawców.
Kluczowe decyzje i trade-offy
- Wycena w ofercie, bez osobnego systemu. Najbardziej spowalniało przepisywanie danych między systemem wycen a systemem ofert. Po połączeniu na jednym ekranie jest więcej informacji, ale zniknęła podwójna praca.
- Trzy ścieżki wyceny. Natychmiastowa wycena z API działa przy małych zmianach w standardowym produkcie i daje cenę w kilka sekund. Zlecenie jednym kliknięciem przez platformę dostawców pasuje do średnio skomplikowanych zamówień, trwa 1–2 dni i ma status na żywo. Ręczny wpis zostaje dla naprawdę nietypowych zamówień, często po rozmowie, w której dostawca zgodził się na niższą stawkę. Jedna ścieżka nie obsłużyłaby tak różnych przypadków.
| Ścieżka | Czas | Kiedy |
|---|---|---|
| Natychmiastowa z API | sekundy | małe zmiany w standardowym produkcie |
| Platforma dostawców (1 klik) | 1–2 dni, status na żywo | średnio skomplikowane zamówienia |
| Ręczna | kilka dni, po negocjacjach | naprawdę nietypowe zamówienia |
- Gęsty ekran dla doświadczonych handlowców. W tabeli widać naraz wszystkie statusy wycen, a każdą komórkę można rozwinąć. Tutaj gęstość pozwala pracować szybko. Uproszczenie spowolniłoby właśnie tych ludzi, którzy domykają sprzedaż.
- Przeoczona zależność między systemami. Muszę przyznać, że tu popełniliśmy błąd. Portal klienta wyświetlał element z platformy dla dostawców, a my zauważyliśmy to za późno. Developerzy musieli wykonać dodatkową pracę, a projekt się wydłużył. Częściowo to było nasze przeoczenie, a częściowo skutek tego, że po fali zwolnień z firmy odeszła wiedza o takich powiązaniach.
flowchart LR
A["System wycen"] --> B["System ofert"]
D["Platforma dostawców"] --> B
C["Portal klienta"] -->|"wyświetlany element, zależność zauważona późno"| D
classDef info fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
classDef bad fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
class A,B,D info
class C bad
linkStyle default stroke:#a8a8b3,stroke-width:1.5px
Odtworzony szkic. Trzy źródła wyceny na jednym ekranie, wybór po lewej i szczegóły po prawej. Nic nie trzeba przepisywać do osobnego systemu ofert.
Jak to się skończyło
Wycena skróciła się z kilku dni do jednego. Zespół handlowców był mniejszy o ~20%, a mimo to utrzymał poziom sprzedaży w czasie dołka, w którym sprzedaż zwykle spadała. Najtrudniejszy okazał się nie sam ekran, tylko koordynacja kilku systemów za nim: platformy dostawców, portalu klienta i kilku zespołów backendu. To ona wydłużyła projekt. Kiedy już było jasne, gdzie ginie czas, sam projekt ekranu był prostą częścią.
Co z tego wyniosłem
- Zamiast walczyć ze złożonością, warto usunąć pracę wokół niej. Wycena była naprawdę skomplikowana i handlowcy tego potrzebowali. Najwięcej dało usunięcie przepisywania i czekania.
- Najpierw rozpisuję zależności między systemami, potem projektuję. Zależność portalu, którą zauważyliśmy późno, kosztowała nas sporo czasu. Według mnie projekty obejmujące kilka systemów najczęściej psują się na styku między nimi.
- W czasie zwolnień wiedza znika razem z ludźmi. Osoba, która znała zależność, mogła już nie pracować w firmie. Przejmując coś po innych, zakładam, że czegoś nie wiem.
- Gęsty ekran może być zaletą. Ekran, który komuś z zewnątrz wydaje się zagracony, bywa dokładnie tym, czego potrzebuje ekspert pracujący na nim codziennie.