TL;DR
- Kontekst: Lead UX w scaleupie e-commerce B2B z opakowaniami.
- Problem: Wycena customowego zamówienia wymagała ręcznego przepisywania danych do drugiego systemu i trwała dni.
- Co zrobiłem: Scaliłem przekazanie między systemami i poukładałem wyceny w 3 jasne ścieżki na jednym ekranie.
- Wynik: Czas wyceny → tego samego dnia; wolumen sprzedaży utrzymany przy ~20% mniejszym zespole.
Diagnoza
Wyceny customowego opakowania nie da się zrobić prosto. Jedno zamówienie może mieć wiele pozycji, każda w kilku wariantach (rozmiar, materiał, nadruk, ilość), każda wyceniana z jednego z trzech źródeł, z decyzją o marży na końcu. Celem nie było usunąć tę złożoność — nie da się. Celem było zabić tarcie wokół niej: sales przepisywał te same dane zamówienia do drugiego systemu i czekał dni na liczbę. Zostawiłem więc gęstość (to power-userzy) i zaatakowałem tarcie — scaliłem przekazanie między systemami i poukładałem wyceny w trzy jasne ścieżki na miejscu budowania oferty.
flowchart TD
subgraph Przed["Przed"]
A1["Sales wpisuje zamówienie<br/>do systemu wycen"] --> A2["Dostaje ceny"]
A2 --> A3["Ręcznie przepisuje wszystko<br/>do systemu ofert"]
A3 --> A4["Klient czeka dni"]
end
subgraph Po["Po"]
B1["Klient wpisuje pozycje<br/>i warianty"] --> B2["Sales wybiera 1 z 3 ścieżek wyceny<br/>na 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:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
style Po fill:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
linkStyle default stroke:#a8a8b3,stroke-width:1.5px
Co zrobiłem
- Poprowadziłem przebudowę flow wyceny jako Lead UX (dwie projektantki raportujące do mnie), a gdy PM-ka odeszła w trakcie — przejąłem cały proces samodzielnie.
- Zaprojektowałem zagnieżdżoną tabelę pozycji w legacy Ruby on Rails — pozycje i ich warianty widoczne naraz, każda komórka rozwijalna do detali wyceny (nawigacja po typie wyceny po lewej, detale po prawej).
- Zbudowałem 3-stopniowy model wyceny (instant z API / platforma dostawców / ręcznie), odpalany na miejscu tworzenia oferty, żeby sales wybierał najszybsze źródło, które pasuje.
- Usunąłem ręczne przepisywanie między systemem wycen a systemem ofert — pozycje i warianty wpisane przez klienta stawały się punktem startowym salesu, nie zadaniem przepisywania.
Wyniki
- Czas wyceny z rzędu dni → tego samego dnia (~dniem szybciej).
- Wolumen sprzedaży high-touch utrzymany przy ~20% mniejszym zespole sales managerów, w dołku rynku, gdzie naturalnie się kurczało.
- 3 ścieżki wyceny na jednym ekranie (instant / platforma dostawców / ręcznie) zamiast osobnego systemu wycen plus ręcznego przepisywania.
- Pozycje i warianty wpisane przez klienta wpadały prosto do oferty — bez podwójnego wprowadzania danych.
Problem
Co było zepsute w wycenianiu customowych opakowań?
Zamówienia customowe (high-touch) — wszystko, co nie z półki — wymagały wyceny przez człowieka. Sales manager wpisywał zamówienie do systemu wycen, dostawał ceny, a potem ręcznie przepisywał wszystko do osobnego systemu ofert, żeby zbudować wycenę dla klienta. Customowa wycena trwała dni; sales siedział zablokowany w środku, a klient mógł odejść. Dwa systemy, jedno ręczne przepisywanie, dni czekania.
Dlaczego po prostu nie uprościć ekranu?
Bo złożoność jest realna i należy do użytkownika. Customowe zamówienie faktycznie ma pozycje, każda z wariantami, każda wyceniana z innego źródła, z decyzją o marży na końcu. „Uprość i dodaj pustą przestrzeń” ukryłoby rzeczy, które sales manager musi widzieć, żeby zdecydować szybko. Wygrana była gdzie indziej — w tarciu wokół wyceny, nie w samej wycenie.
Moja rola / zakres
- Lead UX obszaru back office i high-touch sales. Dwie projektantki raportujące do mnie (po fali zwolnień została jedna).
- Zmapowałem journey obecnego stanu razem z PM-ką, a potem przejąłem cały proces samodzielnie, gdy PM odeszła.
- Przebudowa sięgała więcej niż jednego systemu — system wycen, system ofert, platforma dla dostawców i portal klienta.
Proces
- Journey mapping z sales — zmapowałem obecny flow wyceny end-to-end z ludźmi, którzy w nim żyli, zanim cokolwiek zaprojektowałem.
- Prototypowanie zagnieżdżonej tabeli, potem testy z 2–3 sales managerami. Balans między gęstością a skanowalnością wyszedł z tych sesji.
- Przejąłem realizację samodzielnie w trakcie projektu; koordynowałem między zespołami backendu i platformą dla dostawców.
Kluczowe decyzje i trade-offy
- Wycena w ofercie, nie w osobnym systemie. Ręczne przepisywanie między systemem wycen a systemem ofert było prawdziwym wąskim gardłem. Scalenie wrzuciło więcej na jeden ekran — ale zabiło podwójną pracę. Tarcie było problemem, nie złożonością.
- Trzy ścieżki wyceny, nie jedna. Instant z API dla lekko niestandardowych customizacji (liczba w sekundy); zlecenie 1-klik na platformę dostawców dla średniego przypadku (1–2 dni, ze statusem na żywo); wpis ręcznie dla naprawdę customowych transakcji, często po rozmowie, gdzie dostawca zgodził się na niższą stawkę. Jedna ścieżka nie obsłuży tego zakresu — trzy, każda dobrana gdy pasuje, tak.
| Ścieżka | Czas | Kiedy stosowana |
|---|---|---|
| Instant z API | sekundy | lekko niestandardowe customizacje |
| Platforma dostawców (1 klik) | 1–2 dni, status na żywo | średni przypadek |
| Ręcznie | dni, po negocjacji | naprawdę customowe transakcje |
- Zostaw gęstość — to power-userzy. Zagnieżdżona tabela ze statusami wycen widocznymi naraz, rozwijalna per komórka. Gęstość to tutaj szybkość. „Uprość” spowolniłoby właśnie tych ludzi, którzy domykają transakcje.
- Szczerze: przeoczona zależność cross-system. Portal klienta osadzał element z platformy dostawców — zależność, którą złapaliśmy późno, co oznaczało dodatkową pracę dev. Częściowo przeoczenie; częściowo wyciek wiedzy po fali zwolnień. Wydłużyło to projekt.
flowchart LR
A["System wycen"] --> B["System ofert"]
D["Platforma dostawców"] --> B
C["Portal klienta"] -->|"osadzony element, zależność złapana 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
Jak to się skończyło
Czas wyceny spadł z rzędu dni do tego samego dnia. A wolumen sprzedaży high-touch został utrzymany przy ~20% mniejszym zespole sales managerów, w dołku, gdzie naturalnie się kurczało. Najtrudniejsza część projektu nie była ekranem — to była koordynacja cross-system za nim (platforma dostawców, portal klienta, kilka zespołów backendu). To wydłużyło oś czasu; sam design był prostą częścią, gdy już tarcie było jasne.
Co z tego wyniosłem
- Atakuj tarcie wokół złożoności, nie złożoność samą. Wycena była realnie złożona i należała do użytkownika. Wygrana to zabicie ręcznego przekazania i czekania.
- Zmapuj każdą zależność backendową, zanim zaprojektujesz. Zależność portalu, którą złapaliśmy późno, kosztowała realny czas. Praca cross-system psuje się na szwach, nie w środku.
- Wlicz wyciek wiedzy. W dołku człowiek, który znał zależność, może już nie być. Zakładaj dziury w tym, co dziedziczysz.
- Gęstość to feature dla power-userów. Ta sama lekcja, inny system — ekran, który outsiderowi wydaje się „zagracony”, może być dokładnie tym, czego potrzebuje ekspert, który w nim żyje codziennie.