TL;DR
Vendere su più canali senza oversell richiede tre cose: una sola fonte di verità per le giacenze, sincronizzazione a livello di variante (EAN) e regole esplicite su chi vince quando le quantità divergono. BaseLinker fa da hub: il gestionale resta il padrone di catalogo e stock, l'hub distribuisce su marketplace e shop. L'oversell nasce quando manca uno dei tre pezzi.
La gestione multicanale tiene coerenti le giacenze mentre gli stessi pezzi sono in vendita in più posti contemporaneamente: il negozio, due marketplace, un portale B2B. Il fallimento è famoso. Due canali vendono entrambi l'ultimo pezzo della stessa taglia, un cliente riceve l'email di annullamento, e l'algoritmo del marketplace penalizza in silenzio l'account.
Nella moda il problema è più acuto che in quasi ogni altra categoria, perché l'unità vendibile è piccola e specifica. Nessuno oversella "la sovracamicia": si oversella la Cammello M, un EAN con tre pezzi a scaffale. Qualsiasi sincronizzazione che lavori sopra il livello della variante fa aritmetica sui numeri sbagliati.
Questa guida copre l'architettura che regge nel 2026, perché il modello a hub con BaseLinker scala meglio dei connettori punto-punto, e le regole di sincronizzazione che decidono chi vince quando i sistemi divergono.
Una Sola Verità di Stock, e Non È il Marketplace
La prima decisione è dove vive la quantità autorevole. I candidati sono il gestionale, la piattaforma dello shop o il backend di un marketplace. La risposta è il gestionale, per una ragione strutturale: è l'unico posto che vede la merce prima che sia in vendita da qualsiasi parte.
La merce arriva dai fornitori, viene verificata, e solo dopo diventa vendibile. Quel flusso di carico (documenti in ingresso, discrepanze risolte, stock registrato) avviene nel gestionale per definizione; il ciclo di vita è descritto in Gestione Magazzino Abbigliamento: Dal DDT allo Scaffale. Se la quantità madre vivesse in un canale, ogni consegna diventerebbe un aggiornamento manuale a quel canale, e tutti gli altri erediterebbero il ritardo.
La fonte di verità è dove lo stock cambia per primo. In un'azienda che riceve consegne fisiche, è il gestionale, sempre.
Sincronizza per EAN, Aggrega per gli Umani
L'unità di sincronizzazione è la variante: un EAN, una quantità. Un feed a livello di prodotto ("Sovracamicia: 13 disponibili") è inutile per un canale che deve smettere di vendere specificamente la Navy L.
Il record che viaggia tra i sistemi è minimo:
{ "ean": "8051234560011", "quantita": 3, "aggiornatoAl": "2026-07-02T09:14:00Z" }
Il timestamp non è decorazione. Quando due sistemi hanno quantità diverse per lo stesso EAN, la recenza è l'unico criterio difendibile: vince l'ultima scrittura, per variante, con il timestamp a decidere chi ha scritto per ultimo. Una sincronizzazione senza timestamp per variante finisce per sovrascrivere conteggi freschi di magazzino con dati stantii del canale, o il contrario, e nessuno riesce a ricostruire perché.
Tre direzioni hanno bisogno di regole esplicite:
| Situazione | Regola |
|---|---|
| Prima connessione (baseline) | Spingi le quantità del gestionale verso il canale, per EAN |
| Cambio locale (consegna, inventario) | Vince il locale, spingi verso l'esterno |
| Cambio remoto (vendita sul marketplace) | Vince il remoto, tira verso l'interno |
Il caso baseline merita rispetto. Collegare un catalogo esistente a un account esistente significa migliaia di EAN su cui entrambi i lati hanno un'opinione. Fallo come scelta di direzione esplicita e una tantum, non come "quello che sincronizza per primo".
Il Modello a Hub: Perché BaseLinker Scala
L'integrazione punto-punto (il gestionale si collega a ogni marketplace direttamente) cresce come N connettori, ognuno con le sue stranezze API, i suoi rate limit e le sue tassonomie di categoria. L'alternativa è l'hub: il gestionale sincronizza con un solo channel manager, e il channel manager si dirama verso marketplace, shop e logistica.
È l'architettura che Agilo usa con BaseLinker. Agilo resta la verità di stock e il padrone del catalogo; l'integrazione spinge i prodotti come record padre-varianti (il padre porta i dati del modello, ogni variante il suo EAN e la sua quantità) e riconcilia lo stock per EAN in entrambe le direzioni con la regola dell'ultima scrittura. BaseLinker gestisce poi la meccanica per marketplace: inserzioni, ordini, corrieri.
Cosa compra il modello a hub:
- Una sola integrazione da mantenere invece di una per canale.
- Espansione senza sviluppo. Aggiungere un marketplace diventa configurazione dell'hub.
- Aggregazione degli ordini lato hub, così il gestionale consuma un solo flusso di decrementi.
Cosa costa: il modello prodotto dell'hub diventa un vincolo. Gli hub modellano tipicamente prodotti padre con varianti piatte, quindi struttura il catalogo di conseguenza (variante = taglia × colore, EAN obbligatorio) e tieni le immagini agganciate al colore giusto, o le inserzioni ereditano le foto sbagliate. La disciplina di catalogo è coperta in Gestionale Abbigliamento: Guida alla Scelta.
Anche la Scheda Prodotto Viaggia, Non Solo lo Stock
Lo stock si prende l'attenzione, ma lo stesso tubo trasporta i dati prodotto, e lì si rompe in modi più silenziosi. Tre campi causano la maggior parte dei problemi di inserzione multicanale nella moda:
- Immagini. L'inserzione ha bisogno della foto del colore della propria variante. Se la sincronizzazione manda un set di immagini a livello di modello, ogni colore non di default va online con le foto sbagliate. Chiave sul colore alla fonte, invio per variante.
- Categorie. Ogni canale ha la sua tassonomia. Mappa una volta dalle tue categorie a quelle dell'hub, e lascia all'hub il mapping per marketplace; farlo per canale nel gestionale reintroduce il problema degli N connettori dalla porta di servizio.
- Identificativi. L'EAN è la chiave di join lungo tutta la catena. Una variante senza barcode non si traccia nell'hub, non si abbina alle inserzioni e non si riconcilia dopo una deriva. Tratta i barcode mancanti come errore bloccante a catalogo, non come avviso.
La regola pratica: le quantità si sincronizzano di continuo, la scheda prodotto al cambiamento, ed entrambe scorrono in una sola direzione, dal padrone del catalogo verso l'esterno.
E l'AI in questo quadro? Sta quasi tutta a monte della sincronizzazione: estrarre i documenti fornitore in varianti pulite, classificare i prodotti nella tua tassonomia, arricchire EAN nudi in schede pubblicabili. Il lato ingresso è coperto in Estrazione Dati da Fatture e DDT con OCR e AI.
Latenza, Buffer e i Limiti Onesti
Anche una sincronizzazione corretta ha una finestra: un pezzo può vendersi sul canale A nei secondi prima che il canale B lo sappia. Mitigazioni pratiche, in ordine di utilità:
- Sincronizza sugli eventi, non solo a orari. Una vendita o una modifica di stock devono spingere subito; le sincronizzazioni complete pianificate sono la rete di sicurezza, non il meccanismo.
- Buffer di sicurezza sullo stock sottile. Pubblicare quantità meno uno quando restano uno o due pezzi scambia un po' di disponibilità con zero oversell proprio sulle taglie che contano (gli ultimi pezzi di una taglia buona sono esattamente quelli che vendono ovunque).
- Riconciliazione completa ricorrente, che confronta ogni EAN sui due lati e registra cosa ha corretto. La deriva succede; la deriva non misurata si accumula.
Se l'oversell continua anche con sincronizzazione a eventi, timestamp per EAN e buffer sullo stock sottile, la causa è quasi sempre a monte: merce entrata nel sistema senza essere verificata. Sistema prima il carico; la disciplina del ciclo di vita in ERP Moda: Cosa Deve Fare Davvero nel 2026 esiste proprio per tenere le quantità non verificate fuori dal vendibile.
Anche il B2B È un Canale
Chi fa ingrosso tende a considerare i marketplace "il problema multicanale" mentre il canale più grande, i riordini B2B, gira ancora su un listino PDF e una telefonata. Dal punto di vista del registro giacenze, una boutique che riordina dodici pezzi è lo stesso evento di dodici vendite marketplace: decrementi per variante che ogni altro canale deve conoscere in fretta. Portare il B2B sulla stessa verità di stock, anche solo prendendo i riordini su disponibilità reale nel gestionale, elimina la fonte di doppia vendita più grande e meno visibile dell'ingrosso.
Prezzi Diversi per Canale: Modellali, Non Biforcarli
Il pricing multicanale fallisce quando l'unico modo di fare una promozione sul marketplace è modificare il prezzo del prodotto. A quel punto cambia anche il prezzo in boutique, e lo storico prezzi è perso. La struttura che funziona tiene un prezzo al pubblico base sul prodotto e i listini per canale accanto: un prezzo di listino specifico del canale quando serve, e una promozione come percentuale o sconto assoluto, calcolata in un prezzo promo finale. La sincronizzazione manda a ogni canale il suo prezzo effettivo insieme alla quantità per EAN. Il prezzo base non muta mai per una campagna, e togliere una promo significa cancellare il listino di canale, non ricordarsi quale fosse il numero di prima.
Checklist per il 2026
Per valutare una gestione multicanale, o per fare l'audit di quella che hai:
- Esiste esattamente un sistema dove lo stock cambia per primo, ed è quello che riceve le consegne?
- La sincronizzazione lavora per EAN con timestamp, e sai enunciare la regola di conflitto in una frase?
- La baseline della prima connessione è stata una scelta di direzione esplicita e documentata?
- Un canale può fare una promozione senza mutare il prezzo base?
- Quando le quantità sui due lati divergono, qualcosa se ne accorge, e dove è registrato?
Cinque sì e l'oversell smette di essere un incidente ricorrente e diventa un errore di arrotondamento. Qualcosa di meno, e i buchi sono da dove arrivano le email di annullamento.