Lunedì mattina, nel backoffice, arriva un ordine ricevuto durante il fine settimana. Il codice prodotto è nuovo per il gestionale, quindi qualcuno lo ricopia a mano, verifica la disponibilità in magazzino e manda un messaggio al corriere. Nel frattempo, il cliente chiede aggiornamenti perché lo stato dell'ordine non è visibile.
Quando mi chiedono come creare un sito di vendita, parto da qui. Il risultato non è una vetrina online pubblicata, ma un sistema in cui shop, gestionale, magazzino, contabilità e assistenza lavorano sullo stesso dato. Dopo oltre 14 anni di sviluppo, so che la piattaforma conta, ma conta meno delle regole che fanno muovere un ordine senza richiedere ogni volta l'intervento di una persona.
Indice
- Il punto di arrivo che guida le scelte tecniche
- Scegliere la piattaforma partendo dai vincoli operativi
- Progettare l'integrazione tra shop gestionale e magazzino
- Pagamenti catalogo e ciclo dell'ordine end to end
- Quando serve un portale B2B affianco allo shop
- Automazioni di backoffice e presidio operativo
- Rilascio progressivo e passi successivi
Il punto di arrivo che guida le scelte tecniche
Il punto di arrivo è semplice da descrivere: un dato inserito una volta, letto da tutti e aggiornato in modo affidabile. L'articolo ha un codice coerente nello shop e nell'ERP, il prezzo arriva dal listino corretto, la disponibilità riflette il magazzino e lo stato dell'ordine è visibile a chi deve lavorarci.
Questo cambia completamente il modo di progettare un eCommerce. Non scelgo prima il tema grafico per poi chiedermi come collegare il gestionale. Definisco prima il percorso dell'ordine, le responsabilità dei sistemi e le condizioni che devono restare vere anche quando un servizio esterno non risponde.
Regola pratica: il sito è il punto in cui il cliente compra. Il backoffice è il punto in cui l'azienda mantiene la promessa.
Un ordine arrivato dallo shop deve entrare nel gestionale senza essere ricopiato, passare al magazzino con le informazioni necessarie e restituire un aggiornamento leggibile al cliente. Se il collegamento si interrompe, l'ordine deve restare in coda, riprovare da solo e segnalare il problema a chi può intervenire. Il sistema deve quindi avere una sola fonte dei dati, non tante copie che ogni reparto interpreta a modo proprio.
Questa impostazione è utile anche quando il progetto parte da un negozio già attivo. Nel mio metodo osservo chi modifica cataloghi, listini, ordini, resi e disponibilità, poi disegno il flusso che porta al punto di arrivo. La progettazione di un software di sistema aiuta a inquadrare proprio questa differenza, un sito può essere una pagina di vendita oppure una parte di un'infrastruttura aziendale più ampia.
Prima del go-live verifico scenari concreti: un nuovo SKU, un prezzo riservato, una giacenza esaurita, un pagamento confermato ma non registrato nel gestionale, un reso ricevuto dal magazzino. Se il processo funziona solo quando tutto va bene, non è pronto. Un sito di vendita affidabile si riconosce da come gestisce l'eccezione senza perdere l'ordine.
Scegliere la piattaforma partendo dai vincoli operativi
SaaS e open source non sono scelte ideologiche. Sono due modi diversi di sostenere il lavoro quotidiano, e la decisione va presa guardando catalogo, ERP, listini, logistica e autonomia interna.
Un SaaS può accelerare l'avvio perché hosting, aggiornamenti e parte della gestione infrastrutturale sono già organizzati. Il costo, però, può crescere con app, plugin e funzioni aggiuntive. Le integrazioni personalizzate con gestionali italiani possono richiedere adattamenti specifici, soprattutto quando entrano in gioco regole commerciali non standard.
Con un open source non c'è necessariamente un canone di licenza per il software, ma servono competenze, hosting gestito, manutenzione e qualcuno che segua sicurezza e aggiornamenti. La libertà di intervenire sul codice è utile quando il flusso di vendita deve seguire regole proprie, ma comporta una responsabilità tecnica reale.
| Criterio | SaaS | Open source |
|---|---|---|
| Avvio | Rapido, con componenti già predisposti | Richiede configurazione e gestione dell'ambiente |
| Costi ricorrenti | Abbonamento e possibili estensioni | Hosting, manutenzione e competenze |
| Integrazioni custom | Possibili, entro i limiti della piattaforma | Più libertà sul codice e sui flussi |
| Gestionale italiano | Va verificata la compatibilità del connettore | Va progettato e mantenuto il collegamento |
| Listini B2B | Da controllare in base a cliente, fascia e regole | Personalizzabili con maggiore intervento |
| Gestione interna | Dipende dalle funzioni disponibili | Richiede un presidio tecnico più consapevole |
I vincoli che verifico prima della scelta
Nel contesto italiano, controllo subito la possibilità di collegare lo shop a sistemi come AS400, SAP, Zucchetti, TeamSystem e Mexal, senza dare per scontato che un connettore generico basti. Verifico anche listini differenziati, sconti per cliente, fatturazione elettronica e split payment.
La piattaforma deve adattarsi ai processi che generano ricavi, non il contrario. Se il backoffice gestisce pochi prodotti, un solo listino e una logistica lineare, una soluzione pronta può essere adeguata. Se esistono varianti, condizioni commerciali articolate, ordini ricorrenti o più depositi, la parte decisiva sarà l'integrazione.
Non scelgo Shopify, WooCommerce o una piattaforma proprietaria perché una soluzione è di moda. Le valuto in base a ciò che devono fare ogni giorno, a chi ne manterrà i collegamenti e a quanto controllo serve sui dati.
Progettare l'integrazione tra shop gestionale e magazzino
Il collegamento tra shop, gestionale e magazzino va disegnato prima di pubblicare il catalogo. Se le regole restano implicite, ogni eccezione finisce in una telefonata o in una correzione manuale.
Le decisioni da fissare
Parto da una domanda: qual è il sistema proprietario di ogni informazione? Il gestionale può essere il master per anagrafiche e listini, mentre il magazzino può essere il riferimento per la disponibilità fisica. Lo shop espone i dati, raccoglie l'ordine e restituisce al cliente ciò che gli altri sistemi hanno confermato.
Definisco poi le regole per:
- Anagrafiche: codice articolo, descrizione, varianti, unità di misura e aliquota IVA devono avere corrispondenze chiare.
- Prezzi: ogni cliente o gruppo deve ricevere il listino corretto, senza sovrascritture casuali.
- Giacenze: stabilisco quando aggiornare la disponibilità e cosa mostrare quando un articolo raggiunge lo stock zero.
- Ordini: decido quali dati sono obbligatori e quale documento deve nascere nel gestionale.
- Resi: assegno un percorso preciso per rientro, controllo, rimborso e aggiornamento della disponibilità.
Prima del lancio preparo l'ERP. Cataloghi puliti, codici coerenti, listini attivi e unità di misura allineate non sono attività secondarie. Se un prodotto esiste nello shop ma non ha una corrispondenza utilizzabile nel gestionale, l'integrazione non può creare una base affidabile.
Il flusso minimo da provare
Il percorso operativo parte dall'importazione delle anagrafiche. Il sistema aggiorna prezzi e disponibilità, riceve l'ordine e crea il documento necessario, poi trasmette le informazioni al magazzino o al WMS. Quando il picking procede, lo stato torna allo shop e diventa consultabile dal cliente.
Provo anche l'errore. Un codice mancante, una risposta lenta, un articolo esaurito o una modifica contemporanea non devono generare un ordine duplicato o una giacenza inventata. Nel lavoro su Shopify e Danea, il valore non sta nel semplice collegamento, ma nelle regole che impediscono ai due sistemi di interpretare diversamente lo stesso ordine.
Pagamenti catalogo e ciclo dell'ordine end to end
Un sito di vendita mostra la propria solidità nel passaggio tra il clic su “paga” e la ricezione della fattura. Il percorso deve essere leggibile anche quando il pagamento viene autorizzato, ma il gestionale risponde in ritardo.
Il pagamento non chiude l'ordine
Scelgo il gateway considerando rimborsi, chargeback, controlli antifrode e riconciliazione contabile. Il commercialista deve poter collegare pagamento, ordine, documento e rimborso senza ricostruire la storia da email sparse.
Nel catalogo verifico varianti, prezzi per canale, disponibilità e comportamento durante la sessione. Se un articolo diventa non disponibile mentre il cliente sta acquistando, il sito deve informarlo prima dell'addebito e mantenere il carrello in uno stato coerente.
Il percorso completo
Il flusso deve seguire questa sequenza:
- Il cliente conferma il pagamento e il gateway restituisce un esito verificabile.
- Lo shop registra l'ordine e lo trasmette al gestionale.
- Il gestionale applica anagrafica, listino, IVA e condizioni commerciali.
- Il magazzino riceve le righe per il picking e aggiorna la disponibilità.
- La spedizione restituisce tracking e stato dell'evasione.
- La fattura elettronica viene emessa e il documento torna disponibile al cliente.
Ogni passaggio deve lasciare una registrazione utile. Se il pagamento è confermato ma l'ordine non arriva al gestionale, il sistema lo conserva in una coda e lo riprova senza creare un secondo ordine. Un'architettura con coda, retry automatico e alert può usare tentativi a 1, 5, 30 secondi e 5 minuti, con avviso dopo 3 retry, come descritto nella documentazione tecnica sull'integrazione tra ERP, eCommerce e CRM (approfondimento sui flussi di integrazione).
Provo anche timeout, evento fuori ordine, doppio invio e modifica concorrente. L'obiettivo è concreto: nessun ordine doppio, nessun pagamento scollegato e una procedura chiara per recuperare ciò che si è fermato.
Quando serve un portale B2B affianco allo shop
Un portale B2B serve quando il cliente business deve fare più di un acquisto occasionale. Deve poter entrare, vedere il proprio listino, ripetere un ordine e controllare una spedizione senza chiamare il commerciale per ogni informazione.
La stessa offerta non vale per tutti
Nel B2B il catalogo può cambiare in base al cliente, alla zona o al canale. Un rivenditore vede articoli dedicati, prezzi concordati e sconti a volume; un altro può avere condizioni diverse. Il portale deve applicare queste regole leggendo l'anagrafica corretta dal gestionale.
Nella pratica, il rivenditore usa soprattutto funzioni operative:
- Riordino: ripete un acquisto precedente senza ricostruire ogni riga.
- Ordini ricorrenti: programma forniture che si ripresentano secondo le condizioni concordate.
- Tracking: consulta lo stato della spedizione direttamente dal proprio accesso.
- Documenti: ritrova storico ordini e fatture senza chiedere un invio manuale.
- Catalogo filtrato: visualizza solo ciò che può acquistare o ciò che gli è stato assegnato.
Ho visto che questa impostazione funziona quando il portale diventa una parte del lavoro quotidiano, non una seconda vetrina scollegata. Il cliente trova prezzi, riordini e spedizioni nello stesso punto, mentre il backoffice conserva una fonte condivisa per condizioni e stato dell'ordine. Ne parlo anche nella guida al portale clienti B2B.
B2B e B2C hanno regole diverse
Nel B2C il cliente può pagare con strumenti immediati e ricevere una conferma standard. Nel B2B possono servire bonifico, RID o credito concordato, oltre a fatturazione e autorizzazioni legate all'azienda.
Se vendi sia al consumatore sia ai rivenditori, non duplico automaticamente tutto il progetto. Mantengo una base dati comune e costruisco un'esperienza differente dove cambiano login, listini, pagamenti, documenti e permessi.
Automazioni di backoffice e presidio operativo
Un eCommerce maturo deve lavorare anche quando nessuno è seduto davanti al computer. Le automazioni utili non servono a impressionare, servono a evitare che una routine notturna diventi un problema del mattino.
Cosa lascio lavorare al sistema
Parto dai compiti ripetitivi e dalle verifiche che qualcuno esegue sempre nello stesso modo:
- Listini: importazione degli aggiornamenti dal gestionale, con controllo delle righe non riconosciute.
- Giacenze: sincronizzazione periodica dello stock e segnalazione delle anomalie.
- Riordino: generazione di ordini fornitore quando una scorta raggiunge la soglia definita.
- Fatturazione: invio dei documenti allo SDI e registrazione degli esiti.
- Chiusura giornaliera: confronto tra incassi, ordini, rimborsi e documenti.
Il sistema deve anche avvisare quando qualcosa richiede attenzione. Un pagamento non riuscito, un ordine fermo in attesa, una spedizione bloccata o un'integrazione silenziosa da troppo tempo sono eventi da intercettare prima che il cliente li segnali.
Il presidio deve avere un responsabile
Scrivo nei contratti con i fornitori tecnologici i tempi di presa in carico. Non basta sapere chi riceve l'alert, serve sapere entro quando verifica il problema e quale procedura applica. Un disguido resta gestibile quando qualcuno lo prende in carico rapidamente; un fermo vendite nasce quando l'avviso resta senza proprietario.
Preparo anche un manuale operativo per il team interno. Deve spiegare come controllare una coda, riattivare un collegamento dopo un aggiornamento del gestionale, gestire un ordine sospeso e capire quando coinvolgere il fornitore.
Una procedura utile non descrive il software. Descrive cosa deve fare una persona alle nove del mattino quando un flusso si è fermato durante la notte.
Rilascio progressivo e passi successivi
Non apro subito ogni catalogo, ogni pagamento e ogni integrazione. Pubblico una base controllabile, verifico ordini reali e aggiungo complessità solo quando il flusso precedente è stabile.
Una sequenza che protegge l'operatività
Parto da un MVP B2C con catalogo ridotto e metodi di pagamento essenziali. Dopo aver osservato il comportamento del ciclo ordine, posso aggiungere il portale B2B per i clienti con listini dedicati, poi collegare funzioni logistiche più avanzate e infine introdurre automazioni sul riordino.
Prima di ogni rilascio stabilisco criteri verificabili:
- Ordini: il percorso completo deve arrivare al gestionale senza duplicazioni.
- Contabilità: i cicli contabili devono chiudersi con ordini, pagamenti e documenti riconciliati.
- Magazzino: la disponibilità esposta deve restare coerente con quella gestita internamente.
- Presidio: gli alert devono arrivare alla persona incaricata e seguire i tempi scritti.
- Rollback: il team deve sapere come tornare alla versione precedente senza lasciare ordini sospesi.
Documento ogni modifica con changelog, runbook e checklist di rollback. La documentazione non è un allegato da consegnare alla fine, è parte del rilascio. Se un nuovo fornitore deve intervenire, deve poter capire flussi, credenziali, responsabilità e procedure senza dipendere dalla memoria di chi ha seguito il progetto.
L'analisi operativa che uso per questi progetti non supera mai le due settimane. Prima di sviluppare raccolgo il funzionamento reale del backoffice attraverso una checklist di 28 domande, distribuite su sette aree operative, così il punto di partenza non è una preferenza grafica ma la capacità del sistema di sostenere il lavoro.
Quando hai appena letto una guida su come creare un sito di vendita, il passo utile è verificare dove si trova oggi il tuo eCommerce: rispondi alle 28 domande, impiega circa cinque minuti e ricevi un punteggio con il dettaglio per area. Non è una diagnosi automatica del progetto, ma una base concreta per decidere quale flusso analizzare prima.
PHABDEV sviluppa integrazioni tra eCommerce, ERP e magazzino, automazioni di backoffice e portali B2B su misura, con analisi, rilascio e documentazione dei flussi. Se vuoi valutare il tuo sito di vendita partendo dal lavoro reale dei reparti, visita PHABDEV e porta in analisi ordini, catalogo, disponibilità e procedure che vuoi rendere affidabili.