Come abbiamo costruito Ricondizionato.it: un marketplace europeo da zero

Ricondizionato.it nasce da un'idea semplice: creare il punto di riferimento italiano per l'acquisto di prodotti tech rigenerati, aggregando vendor da tutta Europa in un'unica piattaforma. Semplice da dire, complessa da costruire.

Ci hanno coinvolto nella fase iniziale di progettazione. Quello che sembrava un marketplace ecommerce standard è diventato rapidamente uno dei progetti più articolati che abbiamo affrontato: doppio canale B2B e B2C sullo stesso catalogo, vendor da 8 paesi europei con lingue e sistemi diversi, 240.000 referenze da deduplicare con la logica del master product, split payment temporizzato via Stripe in stile Amazon, e un help desk integrato per gestire le dispute tra acquirenti italiani e vendor stranieri.

Questo articolo racconta come l'abbiamo costruito, le decisioni che abbiamo preso e — soprattutto — i problemi che non avevamo previsto.

Il progetto in numeri

• 100+ vendor europei da 8 paesi UE
• 240.000+ referenze attive con logica master product
• 7.500+ ordini/anno su canale B2C e B2B
• Doppio canale B2B + B2C sullo stesso catalogo

Il brief iniziale e quello che abbiamo trovato sotto

Il brief era chiaro: marketplace di prodotti tech rigenerati, multi-vendor, con gestione automatica dei pagamenti tra operatore e vendor. Quello che non era chiaro — e che emerge quasi sempre solo quando si inizia a fare le domande giuste — era la complessità che si nascondeva sotto ogni punto.

Il primo problema è emerso nella seconda settimana. Il catalogo iniziale aveva centinaia di migliaia di referenze, molte delle quali corrispondenti allo stesso prodotto fisico caricato da vendor diversi con codici articolo, titoli e descrizioni completamente diversi. Un iPhone 13 128GB nero poteva comparire con trenta varianti di nome, sei livelli di grading diversi e prezzi che variavano del 40% tra vendor. Senza una logica di master product, il marketplace sarebbe risultato un ammasso ingestibile.

La lezione numero uno di questo progetto: nei marketplace con catalogo ampio, la qualità del dato è più importante della piattaforma. Abbiamo passato più tempo a definire la struttura del master product e le regole di grading dei prodotti ricondizionati che a sviluppare qualsiasi funzionalità tecnica.

Il secondo problema è arrivato quando abbiamo iniziato a ragionare sulla gestione dei vendor. Cento vendor europei significa cento onboarding, cento verifiche KYC tramite Stripe, cento configurazioni di payout, e soprattutto cento soggetti con sistemi, processi e lingue diverse che devono gestire autonomamente il proprio pannello.

Le sfide principali e come le abbiamo risolte

240.000 referenze con duplicati — la logica del master product

Il master product è il cuore architetturale del marketplace. Ogni prodotto fisico esiste una volta sola nel catalogo come scheda madre. I vendor non caricano prodotti propri: associano le loro offerte al master product, specificando grading, prezzo, disponibilità e condizioni di consegna.

Questo risolve tre problemi in un colpo solo. Il cliente vede un prodotto con tutte le offerte disponibili dai vendor — esattamente come succede su Amazon — e può scegliere in base a prezzo, condizione e reputazione del vendor. Il SEO beneficia perché c'è una sola pagina per prodotto con contenuto consolidato invece di trenta pagine duplicate. E la gestione del catalogo diventa sostenibile.

La parte complessa è stata definire la tassonomia di grading. Nel mercato del ricondizionato non esiste uno standard universale — ogni vendor usa le proprie categorie. Abbiamo lavorato con il cliente per definire gradi standardizzati (Eccellente, Ottimo, Buono, Accettabile) con criteri oggettivi per ognuno.

Vendor da 8 paesi, lingue diverse — il connettore AI per le traduzioni

Vendor da Germania, Spagna, Francia, Polonia, Portogallo, Belgio, Olanda e Italia. Ognuno carica le proprie schede prodotto nella propria lingua. Il cliente italiano deve trovare tutto in italiano.

La traduzione manuale di 240.000 referenze è fuori discussione. Abbiamo costruito un connettore che intercetta ogni contenuto caricato dal vendor e lo passa attraverso un motore di traduzione AI verso l'italiano e verso le altre lingue del marketplace. La traduzione avviene in background al momento del caricamento: il vendor carica in tedesco, il cliente italiano vede italiano.

Il punto critico non è la traduzione in sé — per le schede tecniche standardizzate l'AI funziona bene. Il problema emerge nelle descrizioni più narrative. Abbiamo gestito questo con un layer di revisione: le traduzioni vanno online automaticamente, ma vengono flaggate per revisione umana quando il sistema rileva bassa confidenza o termini ambigui.

Dispute cross-border — l'help desk integrato

Un cliente italiano compra uno smartphone da un vendor polacco. Il prodotto arriva con un difetto. Il cliente apre una contestazione. Il vendor risponde in polacco. Senza un sistema strutturato, questa situazione diventa un'escalation immediata verso l'operatore.

Abbiamo integrato un help desk con tre livelli. Il primo è la comunicazione diretta tra cliente e vendor, con traduzione automatica dei messaggi in entrambe le direzioni. Il secondo livello è l'escalation verso l'operatore del marketplace quando la disputa non si risolve entro 48 ore. Il terzo è la gestione del rimborso o della sostituzione tramite il flusso RMA, con tracciamento della spedizione di ritorno e sblocco del payout al vendor solo dopo la conferma del reso.

Split payment temporizzato — il modello Amazon via Stripe

Il cliente paga l'intero importo al checkout. I fondi vengono trattenuti su un conto tecnico Stripe. Dopo la conferma della consegna e il periodo di holding configurato dall'operatore, Stripe esegue automaticamente il payout al vendor, trattenendo la commissione dell'operatore.

Il 'temporizzato' è la parola chiave. Non è semplicemente split payment — è split payment con holding period variabile. Sugli ordini di basso valore con vendor affidabili, il periodo è breve. Sugli ordini di alto valore o con vendor nuovi sulla piattaforma, il periodo è più lungo.

Abbiamo usato Stripe Connect come infrastruttura. Ogni vendor ha il proprio account Stripe collegato alla piattaforma, con onboarding KYC gestito direttamente da Stripe. Questo è importante: raccogliere fondi per conto di terzi senza la struttura giusta espone a rischi regolatori significativi.

La configurazione dello split payment non è un problema tecnico. È un problema di regole di business. Quanto tempo trattenere i fondi? Come gestire i rimborsi parziali? Cosa succede se il vendor chiude l'account prima del payout? Queste decisioni vanno prese prima dello sviluppo, non durante.

B2B e B2C sullo stesso catalogo

Ricondizionato.it serve sia consumatori privati sia aziende che acquistano in volume — scuole, aziende IT, pubbliche amministrazioni che rinnovano il parco hardware con ricondizionato certificato. Il catalogo è lo stesso, ma tutto il resto è diverso: prezzi, condizioni di pagamento, workflow di approvazione, fatturazione.

La soluzione che abbiamo adottato prevede account separati per il profilo privato e quello aziendale, collegati alla stessa email con switch rapido tra i due contesti. Il cliente non deve ricordarsi due credenziali diverse, ma i due profili hanno storico ordini, prezzi e condizioni completamente separati.

Quello che abbiamo imparato e faremmo diversamente

Iniziare dalla struttura del catalogo, non dalla piattaforma

Se tornavamo indietro, dedicheremmo le prime quattro settimane esclusivamente alla definizione del master product, delle categorie di grading e delle regole di catalogazione — prima di scrivere una riga di codice. La struttura del dato è la fondamenta. Tutto il resto si costruisce sopra.

Progettare l'onboarding vendor come un prodotto a sé

Il pannello vendor non è un'area di backoffice. È il prodotto che il vendor usa ogni giorno. Se è complicato, i vendor caricano male i prodotti, gestiscono male gli ordini e generano problemi che ricadono sull'operatore. Avremmo investito di più nel design del flusso di onboarding e nel tutorial in-app fin dall'inizio.

Coinvolgere prima il commercialista sull'aspetto IVA cross-border

Vendere prodotti da vendor europei a clienti italiani ha implicazioni IVA non banali — soglie OSS, gestione dell'IVA per vendor extra-UE, documentazione fiscale per le aziende acquirenti. Abbiamo risolto tutto, ma alcune decisioni architetturali sarebbero state diverse se avessimo avuto la consulenza fiscale nella fase di design e non durante lo sviluppo.

Se stai valutando un progetto simile

Se stai valutando un progetto marketplace — sia che si tratti di un'idea simile o di un contesto completamente diverso — la prima cosa che facciamo è capire i numeri reali: quanti vendor, quanti prodotti, quali integrazioni esistenti, quale complessità commerciale. Da lì emergono le scelte tecniche. Non il contrario.