Case study · 02
Cumuj
Jeden system dla trzech ról — żeglarza, bosmana, managera. 16 portów mazurskich na żywo.
Wejdź na Cumuj →- Branża
- Marina operations · B2B2C
- Zespół klienta
- 3 role: żeglarz, bosman, manager
- Timeline
- 16 tygodni od briefu do live
- Porty
- 16 mazurskich (live)
- Scope
- Web + mobile app + manager dashboard
Kontekst
Wielkie Jeziora Mazurskie mają 16 portów jachtowych — od Ekomariny Giżycko (42 stanowiska) po mniejsze przystanie w Sztynorcie, Rucianem-Nidzie, Piszu. Przez dekady każdy port prowadził oddzielną rezerwację — telefon, SMS, papier. Żeglarz płynący latem przez jeziora nigdy nie wiedział czy w Ekomarinie będzie miejsce gdy wieczorem tam dobije. Bosman marnował dzień odbierając telefony. Manager portu nie miał overview'u sezonu — dowiadywał się o pełnej obłożoności z Excela po tygodniu.
Problem
Okazało się że problem nie jest techniczny, jest koordynacyjny. Trzy role (żeglarz, bosman, manager) mają trzy różne konteksty i trzy różne metryki sukcesu, ale muszą współdzielić ten sam state — dostępność stanowisk w czasie rzeczywistym. Żeglarz myśli „za 3 godziny będę w Giżycku, czy jest miejsce?". Bosman myśli „ta łódź wpłynie o 18, które stanowisko mu wyznaczyć?". Manager myśli „obłożenie sezonu wzrosło czy spadło rok-do-roku?". Trzy UI, jeden data model.
Trzy role, jeden system
Zaprojektowaliśmy trzy różne UI pod wspólny backend. Żeglarz: mapa portów na telefonie z live availability (zielony/żółty/czerwony marker), 3-tap rezerwacja, check-in QR bez kolejki. Bosman: web-app na biurkowym ekranie, kolejka przypłynięć na dziś (sortowana po ETA), manual override dla walk-ins, sygnalizacja konfliktów (np. długość jednostki > stanowisko). Manager: dashboard z obłożeniem sezonu, pricing per dzień (dynamic na peak), revenue, rok-do-roku porównania od pierwszego dnia.
Rozpoznanie (3 dni)
Poszliśmy w teren. Wizyty w trzech portach (Ekomarina Giżycko, Sztynort, Mikołajki), godzina z każdą rolą. Z żeglarzami siedzieliśmy na pokładzie, z bosmanami za burtą, z managerami w biurze. Jedna z najważniejszych obserwacji pierwszego dnia: bosmanom nie wolno dać telefonu w ręce — pracują z rękami w wodzie, liny, cumy, bosak. Manager dashboard MUSI być web-only na dużym ekranie, bosman ZAWSZE na tablecie zamontowanym w oknie bosmanówki.
Decyzje projektowe
Real-time bez kompromisów — WebSockets dla live availability, każda rezerwacja lub check-in propaguje się do wszystkich ról w <200ms. Płatności online z SCA-compliant checkout, bez tymczasowych „hold" blokad na kartach. QR check-in zamiast ręcznego wpisywania — bosman skanuje kod, state się aktualizuje, stanowisko przestaje być dostępne. Trzy UI pod jeden design system w OKLCH, ale każda rola ma własny color accent (żeglarz — teal, bosman — amber, manager — navy).
Wdrożenie port-by-port (10 tygodni)
Rollout szedł portami, nie featurami. Pierwsze 2 tygodnie — Ekomarina Giżycko (największy port, 42 stanowiska). Bosman Jacek dostał dedykowany onboarding na miejscu, 3 dni obserwacji. Następnie Sztynort i Mikołajki (mid-size), potem mniejsze porty po 2-3 dziennie. Check-in QR przetestowany w lipcu (peak season) — zero kolejek, zero przekroczeń capacity, zero przypadków że manager dowiedział się o pełnym porcie z opóźnieniem.
Outcome
Brief → live w 16 tygodni. 16 portów mazurskich obsługiwanych przez jeden system. Aplikacja mobilna (iOS + Android) + web dla bosmanów i managerów. Rezerwacja w real-time z płatnością online. Check-in QR w <10 sekund. Managerowie mają rok-do-roku porównania od pierwszego dnia (nie dopiero w kolejnym sezonie).
Czego nauczyliśmy się
Peer review manager-dashboardu poszedł zbyt późno — tydzień przed launchem usłyszeliśmy że managerowie chcieli widzieć rok-do-roku porównanie od dnia zero, a nie po pełnym sezonie. To nie feature, to kluczowa metryka biznesowa. W przyszłym razie: analytics-first na dashboardzie, nie jako phase 2. Bonus: bosmani jako UX audytorzy to złoto — ludzie którzy całe życie robili to ręcznie, widzą każdą friction którą my jako tech przegapiamy.