Nomad X Collective

Ancora a metà 2025 nomadxcollective.com girava su un software di shop standard. È costruito per un solo rivenditore: un magazzino, un account di spedizione, una persona che aggiorna i prezzi. L'attività dietro era da tempo un'altra. Nomad X Collective cura marchi indipendenti che vendono anche la propria origine, ognuno con un magazzino proprio, un account di spedizione proprio e una propria idea di ciò che va detto su un capo. Se si costringono questi marchi in un sistema che conosce un solo rivenditore, alla fine qualcuno ricopia tutto a mano e ogni modifica diventa un'e-mail.

L'incarico era quindi: tre sistemi collegati che diano la sensazione di un unico marchio e che servano tre gruppi di utenti con compiti molto diversi.

• Gestione della piattaforma: ordini, fatturato e nuove registrazioni a colpo d'occhio, senza che qualcuno debba costruire un foglio di calcolo.
• Marchi partner: catalogo proprio, pagina di marca propria, fasi di fulfillment proprie, senza uno sviluppatore a chiamata.
• Clienti: un acquisto che risulta curato e non un modello da marketplace.

A questo si aggiungeva il momento. La piattaforma doveva partire insieme a un rebranding completo, quindi l'interfaccia rivolta ai clienti doveva portare una nuova identità visiva mentre sotto girava per la prima volta un marketplace.

Abbiamo costruito la piattaforma come tre sistemi collegati sopra una base dati comune e abbiamo distribuito in modo disuguale l'impegno di progettazione. Lo storefront porta il rebranding completo, il pannello admin e quello vendor girano su una UI di base più sobria e funzionale. È un ordine di priorità, non un risparmio: prima devono funzionare i processi sottostanti, perché un bel pannello vendor con uno stato d'ordine sbagliato non vale nulla.

1. Dati condivisi, titolarità separata

• Prodotti, varianti, giacenze, ordini e dati dei clienti risiedono in un'unica base dati, che tutti e tre i sistemi interrogano attraverso la stessa interfaccia REST.
• La titolarità dei contenuti resta separata. Le credenziali di accesso per i marchi nascono centralmente, così l'onboarding rimane in un unico punto; i dati di marca e di prodotto di un marchio appartengono poi al marchio stesso.
• Tutte le immagini risiedono in un bucket S3 in eu-central-1. I loghi dei marchi e le immagini delle pagine di marca sono archiviati separatamente per rivenditore, le immagini dei prodotti risiedono in uno spazio dei nomi comune, perché dipendono dal prodotto e non dal marchio.

2. L'import è il vero lavoro di traduzione

I marchi portano spesso con sé uno shop esistente, per esempio su Shopify o WordPress. Nel pannello vendor c'è un pulsante che collega lo shop esterno. L'import evita di ricopiare tutto a mano, ma il problema più difficile non lo risolve da solo. Due shop descrivono lo stesso capo in modo diverso: le taglie hanno nomi differenti, i nomi dei colori sono denominazioni interne, e ciò che uno shop tratta come due prodotti nell'altro è una variante dello stesso prodotto. Su un marketplace con filtri condivisi tutto questo deve diventare un vocabolario, altrimenti il filtro per colore si disgrega in sinonimi e non trova nulla. Fino a che punto arrivi un allineamento dipende inoltre da ciò che la rispettiva piattaforma esterna rende disponibile tramite la sua API. Lo abbiamo detto così al cliente, invece di promettere una sincronizzazione completa.

3. La redazione come record di dati

Home page, Chi siamo, Contatti, footer, programma partner e workshop sono ciascuno una configurazione che lo storefront carica a runtime; le pagine di marca sono un record strutturato a sé. Immagini, testi e la visibilità di intere sezioni si possono così modificare senza che nessuno faccia un deployment.

Ogni marchio partner spedisce dalla propria sede attraverso il proprio account di spedizione. Non esiste quindi un flusso di spedizioni comune che la piattaforma potrebbe leggere, né un modo per richiedere lato server lo stato di consegna.

Questo riguarda più della sola indicazione di stato. Se la spedizione è in capo al marchio, un ordine su due marchi diventa inevitabilmente due spedizioni: due pacchi, due tempi di consegna, due link di tracking. Per questo il carrello espone le spese di spedizione per rivenditore e le somma solo dopo. Per lo stesso motivo abbiamo modellato reso e rimborso come un workflow a sé. Un rimborso tocca contemporaneamente giacenza, pagamento al rivenditore e comunicazione al cliente, e riguarda di norma una parte dell'ordine, non l'intero.

Il flusso è costruito di conseguenza attorno alla reale relazione di spedizione:

1. Il marchio porta la sua parte dell'ordine su "spedito" e registra il link di tracking generato dal suo stesso account.
2. Esattamente quel link parte automaticamente via e-mail.
3. "Consegnato" lo conferma il marchio manualmente, non appena lo vede dalla sua parte.

Uno stato di consegna automatico sarebbe qui solo una supposizione, e una promessa supposta è peggio di un'informazione onesta. Lo storefront dice quindi esattamente ciò che il sistema sa, e lo dice dove nasce la domanda. Nella sezione spedizioni della pagina prodotto si legge "Each shipment is managed directly by our brand partners; therefore, costs and delivery times vary based on your location.", e più in basso nella stessa sezione "Once your order has been dispatched, you will receive a tracking link via email."

Lo storefront è la superficie su cui la storia del marchio diventa un acquisto. La home page ha una struttura fissa fatta di hero video, "Latest Arrivals" e "Meet Our Brands", i cui contenuti vengono impostati redazionalmente. Struttura fissa, contenuti liberi: layout senza proliferazione, redazione senza deployment.

1. Catalogo

• Filtri per categoria, marchio e colore, ordinamento per novità e prezzo, navigazione per pagine con 16 articoli per pagina.
• Taglie e varianti di colore si trovano già nella scheda in griglia, così come lista dei desideri e carrello. Chi sa già quale taglia e quale colore vuole non deve nemmeno aprire la pagina prodotto.
• Carrello e lista dei desideri funzionano senza account tramite un ID ospite lato server. Ci si può registrare con password, codice monouso o Google.

2. Pagina prodotto

La pagina prodotto è stratificata. Sotto immagine, taglia e prezzo si trovano sezioni espandibili, e quali siano lo decide il marchio attraverso i propri contenuti. Un pantalone mongolo in yak porta una propria sezione di trasparenza con il luogo di produzione; un capo in maglia realizzato in Italia riunisce composizione, origine e cura in un'unica sezione e vi indica la propria certificazione. Sotto compare il marchio con nome, storia e un link alla propria pagina.

3. Pagine di marca

Ogni marchio partner riceve una pagina propria con la stessa struttura: storia del marchio, i blocchi Material Traceability, Production Process, Origins & Resources e Maintenance & Repair nonché i propri prodotti in fondo. L'origine diventa così una struttura nel sistema che ogni marchio riempie da sé. I marchi partner la riempiono con contenuti molto diversi, da un produttore mongolo fondato nel 1991 a una collezione in maglia realizzata in Italia.

Il pannello vendor dà a ogni marchio partner un'area di lavoro propria con cinque sezioni: dashboard, pagina di marca, gestione dei prodotti, gestione degli ordini e impostazioni. Un marchio deve poter modificare una descrizione o contrassegnare un ordine come spedito senza dover impegnare qualcuno del team di piattaforma.

1. Il prodotto è un involucro, la variante è la merce

Un prodotto porta titolo, descrizione e una variante base; ciò che si vende è sempre una variante con SKU propria, attributi propri per taglia e colore e prezzo proprio. Per questo un marchio può mettere un colore a un prezzo più alto dell'altro e lasciare singole varianti su "non disponibile" mentre il prodotto resta attivo.

La giacenza non è quindi un numero, ma tre: quantità, di cui riservata, e da queste derivata la disponibile. Questa distinzione è la differenza tra un marketplace che vende due volte lo stesso ultimo pezzo e uno che non lo fa.

2. Due decisioni segnano il progetto

• L'onboarding è uno stato, non un modulo. L'avanzamento viene salvato passo per passo, quindi un marchio può interrompere la configurazione e riprenderla più tardi. Il prezzo da pagare è che possono esistere marchi a metà: devono comparire nel sistema senza apparire nel catalogo.
• Il passaggio di spedizione richiede un'immissione. Il link di tracking è l'unica informazione del ciclo dell'ordine che la piattaforma non possiede, e per questo l'unico punto in cui il pannello chiede qualcosa prima di procedere.

Per produttori piccoli e molto consapevoli questo decide se la crescita sia possibile senza gestire nel frattempo un'azienda di logistica.

Un marketplace resta curato solo se qualcuno rilegge. Allo stesso tempo questa rilettura non deve significare che un marchio scriva un'e-mail per ogni didascalia. Abbiamo separato le due cose: il marchio scrive da sé, ma non pubblica da sé.

La pagina di marca nasce a questo scopo nel pannello come una configurazione di sei sezioni, ciascuna modificabile singolarmente: hero, descrizione, griglia informativa, galleria, cura e identità di marca. L'hero accetta a scelta un'immagine o un video, e il testo alternativo sta accanto come campo a sé invece che come ripensamento, perché altrimenti non nascerebbe mai.

Alla fine non c'è un "Salva", ma Submit For Approval. Esistono così due versioni una accanto all'altra: quella a cui il marchio sta lavorando e l'ultima approvata, che lo storefront pubblica. Il pannello dice entrambe le cose nello stesso punto, cioè che la pagina è live e quale versione lo è. I prodotti passano per lo stesso meccanismo, perciò nell'elenco dei prodotti accanto a titolo e varianti compare sempre anche uno stato di approvazione.

L'effetto è che un refuso su una pagina di marca non costa nulla e che una presentazione non concordata comunque non va live. Il prezzo è una coda che qualcuno deve smaltire, ed è esattamente per questo che l'approvazione è limitata alla pagina di marca e al catalogo dei prodotti e non estesa a ogni modifica di giacenza.

Entrambi i pannelli sono costruiti attorno agli stessi indicatori: ordini, fatturato, ordini recenti e ordini aperti. Abbiamo iniziato dalla dashboard, perché prima la domanda su ordini e fatturato costava un export e una tabella pivot.

Sotto si trova l'oggetto vero e proprio, il ciclo dell'ordine. Conosce sei stati, e la distribuzione tra questi è il primo grafico che un marchio vede dopo l'accesso:

• Pending, Packed, Shipped, Delivered come percorso normale. "Packed" sta volutamente tra ricezione e spedizione, perché tra le due, con merce fatta a mano, possono passare giorni e altrimenti una cliente non verrebbe a sapere che sta succedendo qualcosa.
• Cancelled e Refunded come le due uscite. Non sono casi di errore, ma stati finali con conseguenze proprie per giacenza e pagamento.

Accanto ci sono i compiti che appartengono solo alla piattaforma: gestione di utenti e rivenditori con blocco e sblocco, storico degli ordini ed export CSV per la contabilità, il ciclo completo compresi resi e rimborsi nonché il rilascio delle credenziali di accesso per i nuovi marchi partner.

Le e-mail transazionali passano da Brevo, così che conferma di spedizione, reso e creazione dell'account seguano la stessa via di consegna e restino tracciabili in caso di dubbio. In un marketplace le cui spedizioni arrivano da più direzioni, l'e-mail è l'unico canale che la piattaforma controlla completamente.