Listini per cliente, sconti a scaglioni, giacenze, agenti: un portale ordini B2B si rompe quasi sempre sui dati, non sul codice. Dove guardare prima.
Un portale ordini B2B somiglia a un ecommerce solo visto da fuori. Catalogo, carrello, un bottone che conferma. Sotto, le regole sono un'altra cosa: il prezzo dipende da chi sta guardando, la disponibilità è una promessa che deve mantenere qualcun altro, e l'ordine non finisce quando il cliente clicca, ma quando entra nel gestionale con il numero giusto.
Gli errori che si ripetono in questi progetti non sono quasi mai errori di codice. Sono decisioni rimandate sui dati e sulle regole commerciali. Vengono a galla a sviluppo avviato, quando cambiarle costa molto più che prenderle prima. Questi sono quelli che tornano più spesso.
La differenza non è il login davanti al listino. È il comportamento di chi ordina.
Il tuo cliente B2B non scopre il catalogo: lo conosce già. Arriva con una lista, spesso scritta a mano o esportata dal suo gestionale, e vuole trasformarla in un ordine nel minor tempo possibile. Non gli interessa la gallery a tutta pagina. Gli interessa cercare per codice articolo, vedere cosa ha comprato l'ultima volta, capire in quanti giorni arriva.
Da qui discende quasi tutto il resto. Una ricerca che funzioni anche sui codici interni e su quelli del fornitore, non solo sulle descrizioni. Una griglia che accetti quantità multiple in una schermata sola, invece di costringere a entrare e uscire da trenta schede prodotto. Se l'interfaccia è quella di un negozio online pensato per il consumatore finale, l'ufficio acquisti continuerà a mandare email, e il portale resterà una vetrina costosa.
È uno degli errori strutturali più frequenti, e tra i più cari da correggere dopo. Nel B2B il prezzo è il risultato di un calcolo, e il calcolo ha parecchi ingredienti: il listino assegnato al cliente, gli sconti di categoria o di marca, gli scaglioni sulla quantità, gli sconti in cascata (la notazione 10+5, cioè un primo sconto e poi un secondo calcolato sul residuo), le condizioni riservate a un singolo cliente su un singolo articolo, le promozioni con una data di inizio e una di fine.
Prima di scrivere una riga servono risposte nette. In che ordine si applicano questi livelli. Quale vince quando due si sovrappongono. Quante cifre decimali si tengono e dove si arrotonda, sulla riga o sul totale. Se i prezzi esposti sono netti o ivati. Cosa succede al prezzo di un ordine già inserito quando il listino cambia il giorno dopo.
L'ultima domanda è la più insidiosa. Un ordine è una fotografia: deve conservare i prezzi con cui è stato confermato, non ricalcolarli ogni volta che qualcuno apre la pagina. Se il portale ricalcola, prima o poi un cliente vedrà un totale diverso da quello che aveva accettato. Quella discussione la perdi sempre, anche quando hai ragione.
Mostrare la giacenza sembra banale. Non lo è, perché disponibile nel gestionale può voler dire cose diverse: la quantità fisica in magazzino, la quantità meno quello che è già impegnato da altri ordini, oppure la quantità comprese le merci in arrivo con una data prevista. Sono tre numeri diversi, e il cliente ne vedrà uno solo.
Poi ci sono i vincoli che il B2C non ha: lotti minimi, multipli di confezione, magazzini diversi con tempi di partenza diversi, articoli gestiti a lotto o a taglia e colore. E c'è la frequenza: se le giacenze si allineano solo di notte, quello che il cliente legge alle cinque del pomeriggio è vecchio di quasi un giorno.
Non esiste una risposta giusta universale, esiste una scelta da fare in modo consapevole: sincronizzare più spesso, mostrare fasce invece di numeri esatti (disponibile, in esaurimento, su ordinazione), oppure accettare l'ordine in attesa di riassortimento dichiarandolo in conferma. La cosa da non fare è esporre un numero preciso che nessuno ti garantisce.
È la domanda che decide l'architettura: per ogni tipo di dato, chi comanda?
Nella maggior parte dei casi anagrafiche, articoli, listini e giacenze nascono nel gestionale, e il portale è un lettore: li riceve, li mostra, non li modifica. L'ordine invece nasce nel portale, e il portale ne è proprietario finché non viene trasmesso. Da quel momento lo stato dell'ordine — confermato, evaso, spedito, fatturato — è responsabilità del gestionale.
Il guaio comincia quando un dato ha due padroni. Se la descrizione di un articolo si può cambiare sia sul portale sia sul gestionale, la prossima sincronizzazione cancellerà uno dei due lavori, e spesso non saprai nemmeno quale. La regola pratica è una sola: un proprietario per ogni campo, deciso e scritto prima di partire. Se davvero un dato deve essere modificabile da entrambe le parti, quella è una decisione di progetto, con regole di precedenza esplicite.
Servono anche le risposte alle domande noiose. Cosa succede se il gestionale è spento nel momento in cui un cliente conferma un ordine. Come si evita che un invio ripetuto diventi due ordini uguali. Come si riconoscono le stesse entità dalle due parti quando i codici cambiano nel tempo. Una coda con tentativi ripetuti, identificativi stabili e un invio che si può rieseguire senza duplicare sono il minimo sindacale: è la parte di lavoro che non si vede in nessuna schermata e che tiene in piedi tutto il resto.
Aggiungere la rete agenti a progetto avviato è uno dei modi più affidabili per sfondare tempi e budget. Un agente non è un utente con qualche permesso extra: è un ramo intero di funzionalità.
Deve poter ordinare per conto di un cliente, e in quel caso l'ordine appartiene al cliente ma porta la firma dell'agente. Deve vedere solo il proprio portafoglio, che però cambia nel tempo: quando un cliente passa a un altro agente, bisogna sapere chi prende la provvigione sugli ordini già inseriti. Bisogna decidere se la provvigione matura alla conferma, alla fattura o all'incasso, e cosa succede in caso di reso, nota di credito o insoluto. Bisogna decidere se l'agente vede il margine, se può forzare uno sconto, fino a quale soglia, e se sopra quella soglia serve l'approvazione di qualcuno.
Sono tutte domande commerciali, non tecniche. Rispondere prima costa una riunione. Rispondere dopo costa una riscrittura.
In un negozio al pubblico si paga e basta. Qui no: il cliente ha un fido, un esposto, uno scaduto, un metodo concordato, un pagamento a trenta o sessanta giorni fine mese. Il portale deve sapere cosa fare quando quel cliente ha superato il fido o ha fatture scadute. Bloccare l'ordine, accettarlo mettendolo in attesa di approvazione, oppure lasciarlo passare e avvisare l'amministrazione.
Qualunque sia la scelta, il messaggio che vede il cliente va scritto con cura. Un ordine rifiutato senza spiegazione fa perdere l'ordine e la fiducia nello strumento: la volta dopo quel buyer riprende il telefono.
Dove l'assortimento è stabile e il riordino è frequente, un ordine assomiglia molto al precedente. È spesso la parte con il rapporto migliore fra sforzo di sviluppo e tempo tolto a chi ordina, ed è quasi sempre la più trascurata: riordino a partire dallo storico, liste personali che il cliente si salva, bozze che si compilano in più momenti e si confermano dopo, caricamento di un elenco di codici e quantità esportato dal gestionale del cliente. Sono le funzioni che tolgono minuti a ogni ordine di chi ordina tutte le settimane, ed è su quei minuti che si gioca la scelta fra il portale e il telefono.
Questa è la parte scomoda. Il software si scrive; i dati vanno bonificati, e non ha voglia di farlo nessuno.
Le schede del gestionale sono nate per la contabilità, non per essere lette da un cliente. Le descrizioni sono abbreviate e in maiuscolo, le unità di misura non sono coerenti, i codici hanno duplicati e varianti create negli anni per aggirare qualche limite del vecchio sistema, le foto mancano o stanno in una cartella condivisa con nomi che non corrispondono a niente. Non c'è Laravel o Next.js che tenga: questo non lo sistema il software.
Quindi, prima ancora di stimare lo sviluppo, servono tre risposte. Chi è responsabile dei dati di prodotto, con nome e cognome, dentro l'azienda. Con che frequenza vengono aggiornati e da quale sistema. Quali campi devono esistere perché una scheda sia pubblicabile, e cosa fa il portale quando mancano: nasconde l'articolo, lo mostra incompleto, o lo segnala a qualcuno perché lo completi.
La bonifica è una fase del progetto, con un tempo suo e un costo suo. Metterla nel piano è quello che separa un portale che va online da uno perennemente fermo a un passo dal lancio. È anche una delle voci che spostano di più il perimetro, insieme alle integrazioni: se vuoi farti un'idea di come si muove un preventivo, le cose che spostano il costo sono più o meno queste.
Laravel per il dominio e le integrazioni, Next.js per l'interfaccia: è una combinazione che regge bene questo tipo di lavoro, perché la logica commerciale resta in un posto solo e il front-end rimane veloce anche con cataloghi grandi. Ma qualunque stack serio funziona se le regole sono chiare, e nessuno stack salva un progetto in cui non si sa chi decide il prezzo.
Le scelte tecniche che contano davvero sono meno appariscenti. Dove tieni il risultato dei prezzi calcolati e come lo butti via quando cambia un listino. Come processi le sincronizzazioni in coda, invece che dentro la richiesta web di un cliente che aspetta. Come mantieni un ambiente di prova con dati realistici, per collaudare le regole di sconto senza sperimentare sugli ordini veri.
Se ti accorgi che a più di una di queste domande in azienda non esiste una risposta condivisa, non hai un problema tecnico: hai il primo capitolo del progetto. Portare a casa quelle risposte prima di scrivere codice è esattamente il lavoro di analisi che sta all'inizio di uno sviluppo software su misura. Se vuoi una lettura esterna prima di impegnarti, la prima call di analisi è gratuita.
Un portale B2B non si giudica dalle schermate. Si giudica da quante email il tuo ufficio commerciale smette di ricevere. E quel numero dipende quasi tutto da decisioni prese prima della prima riga di codice.
Parliamone. Una prima call di misurazione è sempre gratuita.
Prenota una call