Scenario · Configuratore B2B · Manifattura su misura
Dall’offerta via email
al configuratore in tempo reale.
Un’azienda che produce componenti su misura e prepara ogni offerta a mano, tra listini, fogli di calcolo e richieste all’ufficio tecnico. Un configuratore web che calcola prezzo e codice articolo mentre il cliente sceglie.
Scenario web app — configuratore di prodotti B2B
300 varianti di prodotto.
Ogni preventivo fatto a mano.
Lo scenario: un produttore di valvole e componenti idraulici industriali su misura, che rifornisce impianti di processo, cantieri navali e industria alimentare in tutta Europa. I prodotti sono molto configurabili: diametro, pressione nominale, materiale del corpo, tipo di attacco, rivestimento interno, certificazioni. Combinando le variabili si arriva a centinaia di configurazioni possibili, ognuna con un prezzo diverso.
Senza un configuratore, ogni richiesta d'offerta segue lo stesso giro: il commerciale raccoglie le specifiche, le manda per email all'ufficio tecnico, che verifica la fattibilità e passa i dati all'ufficio prezzi, che prepara il preventivo in Excel e lo rimanda al commerciale. Tempo tipico: 3–5 giorni lavorativi.
In un mercato dove i concorrenti esteri rispondono in meno di 24 ore, questo processo diventa uno svantaggio concreto: una parte delle trattative si perde solo per i tempi di risposta.
«Sappiamo già che il prodotto lo facciamo. Il problema è che il cliente non lo sa — perché ci vogliono quattro giorni per dirglielo. Nel frattempo ha già chiamato qualcun altro.»
— Quello che sento spesso nelle aziende manifatturiereRequisiti configuratore industriale B2B
Da giorni a minuti.
Senza errori di configurazione.
Configuratore guidato step-by-step con validazione in tempo reale
Il sistema deve guidare l'utente attraverso i parametri del prodotto mostrando solo le combinazioni tecnicamente valide. Se selezioni DN 150 con pressione 40 bar, il materiale "bronzo" deve sparire dalla lista — perché quella combinazione non è omologata. Le regole di compatibilità sono gestite lato server, non lato client.
Pricing real-time con listini differenziati per cliente
Il prezzo deve aggiornarsi a ogni modifica di parametro, senza click su "calcola". Ogni cliente B2B ha un listino personalizzato (sconti, maggiorazioni per certificazioni, prezzi bloccati su alcune famiglie). Il motore di pricing deve applicare le regole corrette in base all'utente loggato, senza mai esporre il listino base al frontend.
Generazione PDF offerta brandizzato in un click
Il PDF dell'offerta deve includere: intestazione aziendale, dati cliente, descrizione tecnica completa del prodotto configurato, prezzo netto con breakdown, condizioni di fornitura, validità offerta e firma digitale del commerciale. Generazione in meno di 5 secondi, inviato via email al cliente automaticamente.
Sincronizzazione automatica con CRM HubSpot
Ogni offerta generata deve creare automaticamente un deal in HubSpot con tutti i dettagli della configurazione, il valore dell'offerta e il commerciale assegnato. Se il cliente esiste già nel CRM, il deal viene collegato al contatto esistente. Se è nuovo, viene creato il contatto. Nessun doppio inserimento manuale.
Accesso self-service per clienti diretti con area riservata
I clienti più grandi devono poter accedere al configuratore direttamente, senza passare da un commerciale. Vedono solo il proprio listino, lo storico delle offerte precedenti e possono ripartire da una configurazione salvata. L'ufficio commerciale riceve una notifica per ogni nuova offerta generata da un cliente in autonomia.
Sfide tecniche pricing engine real-time
Un motore di pricing
che non mente mai.
Un configuratore sbagliato è peggio di nessun configuratore: se genera un prezzo errato o accetta una combinazione impossibile, l'azienda deve rinegoziare un'offerta già accettata. La sfida principale non è tecnica — è la correttezza assoluta.
Processo sviluppo configuratore B2B
9–10 settimane per trasformare
la conoscenza tacita in software.
Due settimane con il responsabile tecnico e il commerciale più esperto per mappare ogni regola di compatibilità. Di solito non sono documentate: vivono nella testa delle persone e in qualche file Excel interno. Il risultato è un documento strutturato con tutte le regole nella forma "SE [parametro A] = X E [parametro B] = Y → ALLORA [parametro C] non può essere Z", che diventa il modello di dati del motore.
Il cuore del sistema: il motore di regole in Node.js legge le regole da PostgreSQL, le valuta per priorità e restituisce le opzioni di ogni passo. Il motore prezzi applica il listino dell'utente collegato — prezzo base × coefficiente materiale × coefficiente pressione + optional, poi lo sconto contrattuale. Redis tiene in cache i listini per 15 minuti. Test di carico per verificare che regga centinaia di richieste al secondo.
Interfaccia React a passi progressivi: ogni scelta chiede al backend le opzioni valide del passo successivo. Il prezzo si aggiorna in tempo reale con un debounce di 300 ms sulla chiamata. Lo stato si salva su PostgreSQL ogni 30 secondi — chiudendo e riaprendo il browser si ritrova tutto com'era. In più, lo "storico offerte" per l'accesso diretto dei clienti.
Il modello PDF è costruito in HTML/CSS e replica fedelmente quello cartaceo esistente. Puppeteer lo trasforma in PDF in pochi secondi in un processo dedicato. Il file va su S3 e parte via email al cliente e al commerciale. In parallelo la stessa offerta arriva nel CRM via API: contatto creato o aggiornato, trattativa con tutti i campi della configurazione, associazione al commerciale.
Due settimane di test con alcuni commerciali e agenti esterni. È normale che emergano un paio di regole mancanti (casi rarissimi mai citati nelle interviste) o uno sconto applicato male su una famiglia di prodotti: con il motore a regole configurabile si correggono senza un nuovo rilascio. Messa online graduale: prima la rete commerciale interna, poi gli agenti, infine i clienti in autonomia dopo qualche settimana di stabilità.
Soluzione: motore regole e pricing Node.js
Il motore di regole:
centinaia di vincoli, nessuno nel codice.
La scelta di architettura più importante è separare le regole di business dal codice. Ogni volta che l'ufficio tecnico aggiunge una variante o cambia una compatibilità, modifica una riga nel database — senza nuovi rilasci.
Rule engine configurabile — modificabile senza codice
Ogni regola è una riga PostgreSQL con quattro campi: param_key,
param_value, excluded_key, excluded_values
e una priority per la gestione dei conflitti. Il motore Node.js carica
le regole rilevanti per la configurazione corrente, le valuta in ordine e restituisce
un array di opzioni valide per il passo successivo. L'ufficio tecnico
gestisce le regole da un pannello admin costruito con React Table — nessun
intervento del developer per aggiungere o modificare vincoli.
PDF in pochi secondi — identico al modello cartaceo
Puppeteer trasforma un modello HTML/CSS con i dati dell'offerta inseriti sul server. Il modello replica il formato cartaceo dell'azienda: intestazione con logo vettoriale, tabella dei parametri tecnici con unità di misura, dettaglio del prezzo, condizioni di fornitura, validità e firma del commerciale. Il processo Puppeteer è separato dal server principale, con timeout di 10 secondi e nuovo tentativo automatico. Obiettivo: offerta pronta in meno di 5 secondi.
CRM sempre aggiornato — senza toccare HubSpot
Ogni offerta avvia una sequenza in background: prima il PDF va su S3, poi parte la sincronizzazione con il CRM. Il contatto si cerca per email — se esiste si aggiorna, altrimenti si crea. Poi si crea o aggiorna la trattativa con un campo offerta_id come chiave di idempotenza: se il job gira due volte, non crea un doppione. I commerciali trovano ogni offerta nel CRM già associata al contatto giusto, con il PDF allegato, il valore e la fase "Offerta inviata". Obiettivo: zero inserimenti manuali.
Perché conta: il responsabile commerciale smette di fare il "giro serale" per aggiornare il CRM a mano, e i dati restano puliti, senza doppioni.
Stack tecnologico Node.js React PostgreSQL
Node.js al centro.
Ogni strumento al suo posto.
Perché Node.js e non PHP/Laravel?
Il motore prezzi valuta decine di regole in sequenza per ogni richiesta: un'operazione veloce ma molto frequente. Node.js gestisce bene la concorrenza tipica di un'API che fa molte query Redis e PostgreSQL in parallelo. Usare TypeScript sia nel frontend che nel backend riduce i cambi di contesto e gli errori di interfaccia tra i due livelli.
Perché Puppeteer e non una libreria PDF?
Librerie come PDFKit o jsPDF richiedono di costruire il layout programmaticamente — ogni riga, ogni tabella, ogni margine definito in codice. Il template HTML/CSS è infinitamente più manutenibile: un grafico può modificare l'aspetto dell'offerta cambiando CSS, senza toccare JavaScript. Il prezzo è un processo leggermente più pesante, risolto con il worker isolato e il pre-warm di Puppeteer all'avvio del server.
Obiettivi di esempio — configuratore B2B
Da giorni a minuti.
Ogni offerta tracciata.
Numeri di esempio, non risultati di un cliente: obiettivi realistici per uno scenario come questo, da misurare nei primi mesi dopo il lancio rispetto allo stesso periodo precedente.
«Un cliente manda un ordine dall'accesso diretto alle 22:30 di un venerdì. Prima avrebbe aspettato il lunedì.» È lo scenario a cui puntare: l'azienda che risponde anche quando l'ufficio è chiuso.
— L'obiettivo concreto dell'accesso self-serviceLearnings sviluppo configuratore prodotti
Cosa porto
in ogni progetto così.
Separare le regole di business dal codice si ripaga subito. Dopo il lancio arrivano sempre nuove varianti e compatibilità: con il motore a regole le gestisce l'ufficio tecnico dal pannello, senza interventi di sviluppo.
Il prezzo si calcola sempre e solo sul server. Calcolarlo nel browser ridurrebbe le chiamate, ma esporrebbe i coefficienti del listino a chiunque apra gli strumenti per sviluppatori — cioè regalerebbe la struttura dei prezzi alla concorrenza. Con un debounce di 300 ms l'esperienza resta comunque in tempo reale.
Il salvataggio automatico vale sempre il costo. Basta un aggiornamento accidentale della pagina per perdere dieci minuti di configurazione: per qualsiasi web app con moduli complessi è un requisito non negoziabile.
L'idempotenza dei job di sincronizzazione non è un dettaglio. In produzione capita che un job giri due volte (timeout + nuovo tentativo). Senza un controllo su un ID unico, il CRM si riempie di doppioni proprio nei primi giorni dopo il lancio, quando la qualità dei dati conta di più.
L'accesso diretto per i clienti B2B cambia il rapporto più di qualsiasi funzione. Una parte delle offerte arriva fuori dall'orario d'ufficio, e un processo trasparente e veloce crea un tipo di fiducia diverso rispetto alla telefonata con il commerciale.
Hai un processo di vendita che merita di essere automatizzato?
Configuratori, preventivi, cataloghi complessi — se la logica esiste già, si può codificare.
Hai un progetto simile in mente?
Raccontamelo: partiamo da obiettivi e priorità, la prima call è gratuita.