Nomad X Collective

Jeszcze w połowie 2025 roku nomadxcollective.com działał na standardowym oprogramowaniu sklepowym. Jest ono zbudowane dla jednego sprzedawcy: jeden magazyn, jedno konto wysyłkowe, jedna osoba pilnująca cen. Biznes stojący za nim od dawna wyglądał inaczej. Nomad X Collective kuratoruje niezależne marki, które sprzedają razem z produktem swoje pochodzenie, każda z własnym magazynem, własnym kontem wysyłkowym i własnym wyobrażeniem o tym, co trzeba powiedzieć o danej sztuce odzieży. Jeśli wtłoczyć te marki w system, który zna tylko jednego sprzedawcę, ktoś ostatecznie przepisuje wszystko ręcznie, a każda zmiana zamienia się w e-mail.

Zlecenie brzmiało więc: trzy połączone systemy, które sprawiają wrażenie jednej marki i obsługują trzy grupy użytkowników o bardzo różnych zadaniach.

• Obsługa platformy: zamówienia, obrót i nowe rejestracje na jednym ekranie, bez budowania w tym celu arkusza.
• Marki partnerskie: własny katalog, własna strona marki, własne kroki fulfillmentu, bez programisty na zawołanie.
• Klientki i klienci: zakupy, które sprawiają wrażenie kuratorowanych, a nie szablonu marketplace'u.

Do tego doszło wyczucie czasu. Platforma miała wystartować razem z pełnym rebrandingiem, więc interfejs po stronie klienta musiał nieść nową identyfikację wizualną, podczas gdy pod spodem po raz pierwszy działał marketplace.

Zbudowaliśmy platformę jako trzy połączone systemy nad wspólną bazą danych i nierówno rozłożyliśmy nakład na projekt wizualny. Sklep niesie pełny rebranding, panel administracyjny i panel marki działają na oszczędniejszym, funkcjonalnym interfejsie bazowym. To kolejność, a nie oszczędność: najpierw muszą się zgadzać procesy pod spodem, bo ładny panel marki z błędnym statusem zamówienia jest bezwartościowy.

1. Wspólne dane, rozdzielona władza nad treścią

• Produkty, warianty, stany magazynowe, zamówienia i dane klientów leżą w jednej bazie danych, z którą wszystkie trzy systemy rozmawiają przez ten sam interfejs REST.
• Władza nad treściami pozostaje rozdzielona. Dane dostępowe dla marek powstają centralnie, żeby onboarding pozostał w jednym miejscu; dane marki i produktów należą potem do niej.
• Wszystkie obrazy leżą w jednym buckecie S3 w eu-central-1. Logotypy marek i zdjęcia stron marek są przechowywane osobno dla każdego sprzedawcy, a zdjęcia produktów leżą we wspólnej przestrzeni nazw, ponieważ są związane z produktem, a nie z marką.

2. Import to właściwa praca tłumaczeniowa

Marki często przychodzą z istniejącym sklepem, na przykład na Shopify albo WordPressie. W panelu marki jest do tego przycisk, który podłącza zewnętrzny sklep. Import oszczędza przepisywanie, ale trudniejszego problemu sam nie rozwiązuje. Dwa sklepy opisują tę samą sztukę odzieży inaczej: rozmiary nazywają się inaczej, nazwy kolorów są określeniami firmowymi, a to, co jeden sklep prowadzi jako dwa produkty, u drugiego jest wariantem tego samego produktu. Na marketplace ze wspólnymi filtrami musi z tego powstać jeden słownik, inaczej filtrowanie po kolorze rozpada się na synonimy i nic nie znajduje. Jak daleko sięga takie ujednolicenie, zależy dodatkowo od tego, co dana zewnętrzna platforma udostępnia przez swoje API. Powiedzieliśmy to klientowi wprost, zamiast obiecywać pełną synchronizację.

3. Redakcja jako zbiór danych

Strona główna, o nas, kontakt, stopka, program partnerski i warsztaty to każde z osobna konfiguracja, którą sklep wczytuje w czasie działania; strony marek są osobnym, ustrukturyzowanym zbiorem danych. Obrazy, teksty i widoczność całych sekcji można dzięki temu zmieniać bez tego, by ktoś wdrażał.

Każda marka partnerska wysyła z własnej lokalizacji przez własne konto wysyłkowe. Nie ma więc wspólnego strumienia przesyłek, który platforma mogłaby odczytać, ani sposobu, by zapytać o status doręczenia po stronie serwera.

Dotyczy to czegoś więcej niż samego wskazania statusu. Jeśli wysyłka leży po stronie marki, zamówienie obejmujące dwie marki nieuchronnie staje się dwiema wysyłkami: dwie paczki, dwa czasy realizacji, dwa linki do śledzenia. Dlatego koszyk pokazuje koszty wysyłki osobno dla każdego sprzedawcy i dopiero potem je sumuje. Z tego samego powodu zamodelowaliśmy zwrot towaru i zwrot pieniędzy jako osobny workflow. Zwrot pieniędzy dotyka jednocześnie stanu magazynowego, wypłaty dla sprzedawcy i komunikacji z klientem, a z reguły obejmuje część zamówienia, a nie całość.

Przebieg jest więc zbudowany wokół rzeczywistej relacji wysyłkowej:

1. Marka ustawia swoją część zamówienia na „wysłane” i podaje przy tym link do śledzenia wygenerowany przez jej własne konto.
2. Dokładnie ten link wychodzi automatycznie jako e-mail.
3. „Doręczone” marka potwierdza ręcznie, gdy tylko zobaczy to po swojej stronie.

Automatyczny status doręczenia byłby w tym miejscu tylko zgadywaniem, a zgadnięta obietnica jest gorsza niż uczciwa informacja. Dlatego sklep mówi dokładnie to, co system wie, i mówi to tam, gdzie pojawia się pytanie. W sekcji wysyłki na stronie produktu widnieje „Each shipment is managed directly by our brand partners; therefore, costs and delivery times vary based on your location.”, a niżej w tej samej sekcji „Once your order has been dispatched, you will receive a tracking link via email.”

Sklep to powierzchnia, na której z historii marki powstaje zakup. Strona główna ma stałą strukturę złożoną z wideo-hero, „Latest Arrivals” i „Meet Our Brands”, których treści ustala redakcja. Stała struktura, swobodne treści: układ bez samowoli, redakcja bez wdrożenia.

1. Katalog

• Filtrowanie według kategorii, marki i koloru, sortowanie według nowości i ceny, nawigacja stronami po 16 artykułów na stronę.
• Rozmiary i warianty kolorystyczne są już na kafelku, tak samo jak schowek i koszyk. Kto już wie, jaki ma być rozmiar i kolor, w ogóle nie musi otwierać strony produktu.
• Koszyk i schowek działają bez konta dzięki identyfikatorowi gościa po stronie serwera. Zalogować można się hasłem, kodem jednorazowym lub przez Google.

2. Strona produktu

Strona produktu jest warstwowa. Pod zdjęciem, rozmiarem i ceną leżą rozwijane sekcje, a o tym, które to są, decyduje marka przez własne treści. Mongolskie spodnie z jaka mają własną sekcję transparentności z miejscem produkcji; dzianina wykonana we Włoszech łączy skład, pochodzenie i pielęgnację w jednej sekcji i podaje tam swój certyfikat. Poniżej stoi marka z nazwą, historią i linkiem do własnej strony.

3. Strony marek

Każda marka partnerska dostaje własną stronę o tej samej budowie: historia marki, bloki Material Traceability, Production Process, Origins & Resources oraz Maintenance & Repair, a na dole własne produkty. Pochodzenie staje się dzięki temu strukturą w systemie, którą każda marka wypełnia sama. Marki partnerskie wypełniają ją bardzo różnymi treściami, od założonego w 1991 roku mongolskiego producenta po kolekcję dzianin wykonaną we Włoszech.

Panel marki daje każdej marce partnerskiej własną przestrzeń roboczą z pięcioma obszarami: Dashboard, strona marki, zarządzanie produktami, zarządzanie zamówieniami i ustawienia. Marka ma móc zmienić opis albo oznaczyć zamówienie jako wysłane bez angażowania do tego kogokolwiek z zespołu platformy.

1. Produkt to skorupa, wariant to towar

Produkt niesie tytuł, opis i wariant bazowy; sprzedawany jest zawsze wariant z własnym SKU, własnymi atrybutami rozmiaru i koloru oraz własną ceną. Dlatego marka może wycenić jeden kolor drożej niż inny i pozwolić pojedynczym wariantom przejść w stan „niedostępne”, podczas gdy produkt pozostaje aktywny.

Stan magazynowy nie jest przy tym jedną liczbą, lecz trzema: ilość, z tego zarezerwowane i wyprowadzone z nich dostępne. To rozdzielenie jest różnicą między marketplace'em, który dwa razy sprzeda tę samą ostatnią sztukę, a takim, który tego nie robi.

2. Dwie decyzje kształtują projekt

• Onboarding to stan, a nie formularz. Postęp zapisywany jest po każdym kroku, więc marka może przerwać konfigurację i wrócić do niej później. Ceną za to jest, że mogą istnieć marki niedokończone: muszą występować w systemie, nie pojawiając się w katalogu.
• Krok wysyłki wymaga wprowadzenia danych. Link do śledzenia to jedyna informacja w cyklu zamówienia, której platforma sama nie ma, i dlatego jedyny punkt w nim, w którym panel czegoś żąda, zanim pozwoli iść dalej.

Dla małych, bardzo świadomie pracujących producentów to właśnie decyduje o tym, czy wzrost jest możliwy bez prowadzenia przy okazji firmy logistycznej.

Marketplace pozostaje kuratorowany tylko wtedy, gdy ktoś czyta treści przed publikacją. Jednocześnie to sprawdzanie nie może oznaczać, że marka pisze e-mail o każdym podpisie pod zdjęciem. Rozdzieliliśmy to: marka pisze sama, ale sama nie publikuje.

Strona marki powstaje w tym celu w panelu jako konfiguracja z sześciu sekcji, każda edytowalna osobno: hero, opis, siatka informacyjna, galeria, pielęgnacja i identyfikacja marki. Hero przyjmuje do wyboru obraz albo wideo, a tekst alternatywny stoi obok jako osobne pole, a nie jako myśl po fakcie, bo inaczej nigdy by nie powstał.

Na końcu nie stoi „Zapisz”, lecz Submit For Approval. Dzięki temu obok siebie istnieją dwie wersje: ta, nad którą marka właśnie pracuje, i ostatnio zatwierdzona, która trafia do sklepu. Panel mówi obie rzeczy w tym samym miejscu, czyli że strona jest live i która to wersja. Produkty przechodzą przez ten sam mechanizm, dlatego na liście produktów obok tytułu i wariantów zawsze stoi też status zatwierdzenia.

Efekt jest taki, że literówka na stronie marki nic nie kosztuje, a nieuzgodniona prezentacja i tak nie trafia na żywo. Ceną jest kolejka, którą ktoś musi obsłużyć, i właśnie dlatego zatwierdzanie ogranicza się do strony marki i katalogu produktów, a nie rozciąga na każdą zmianę stanu magazynowego.

Oba panele są zbudowane wokół tych samych wskaźników: zamówienia, obrót, bieżące i otwarte zamówienia. Zaczęliśmy od Dashboardu, bo wcześniej pytanie o zamówienia i obrót kosztowało eksport i tabelę przestawną.

Pod spodem leży właściwy przedmiot, czyli cykl zamówienia. Zna sześć stanów, a rozkład na nie to pierwszy wykres, jaki marka widzi po zalogowaniu:

• Pending, Packed, Shipped, Delivered jako normalna droga. „Packed” stoi świadomie między przyjęciem a wysyłką, bo przy towarze robionym ręcznie między jednym a drugim mogą minąć dni, a klientka inaczej w ogóle nie dowie się, że cokolwiek się dzieje.
• Cancelled i Refunded jako dwa wyjścia. To nie są przypadki błędu, lecz stany końcowe z własnymi skutkami dla stanu magazynowego i wypłaty.

Obok stoją zadania należące wyłącznie do platformy: zarządzanie użytkownikami i sprzedawcami z blokowaniem i odblokowywaniem, historia zamówień i eksport CSV dla księgowości, pełny cykl łącznie ze zwrotami towaru i zwrotami pieniędzy oraz wydawanie danych dostępowych nowym markom partnerskim.

E-maile transakcyjne idą przez Brevo, żeby potwierdzenie wysyłki, zwrot i założenie konta szły tą samą drogą doręczenia i w razie wątpliwości pozostały możliwe do prześledzenia. W marketplace, którego przesyłki nadchodzą z wielu kierunków, e-mail jest jedynym kanałem, który platforma kontroluje w całości.