Come progettare una richiesta di offerta online tra configurazione, preventivo e ordine

7 Settembre 2026 · Guide

Una richiesta di offerta online, spesso chiamata RFQ da Request for Quotation, è l’invio dei dati con cui chiedi a un fornitore una proposta. Non coincide con un ordine. Nel B2B può riguardare prodotti a catalogo o pezzi da realizzare e lasciare aperti alcuni dettagli che il tecnico commerciale dovrà chiarire prima del preventivo.

Il risultato da ottenere

Una richiesta di offerta online deve consegnare al commerciale dati sufficienti per valutare la domanda senza imporre al buyer dettagli che, in quella fase, non può ancora conoscere. Il risultato atteso è quindi un passaggio chiaro dalla selezione alla verifica, fino all’eventuale preventivo o ordine.

Definire i modelli commerciali

Preventivo semplice, carrello RFQ, configurazione tecnica, ordine con approvazione e modello ibrido hanno dati e responsabilità differenti. La piattaforma viene scelta dopo il processo.

Separare selezione e fattibilità

Il catalogo può aiutare a scegliere prodotti e varianti; materiali, tolleranze, integrazioni o quantità possono richiedere verifica. Il sistema deve dichiarare che cosa è confermato e che cosa resta da validare.

Progettare il data model della richiesta

Prodotto, variante, quantità, unità, progetto, consegna, allegato, account, valuta e note devono essere strutturati. Il testo libero non deve contenere tutta l’informazione.

Nella RFQ, il dato che serve a instradare la domanda va distinto da quello necessario per preparare la quotazione dettagliata.

Gestire identità, prezzi e permessi

Guest, cliente, distributore, listino, sconto e approvatore possono vedere condizioni diverse. Prezzi indicativi e finali devono essere distinguibili.

Collegare routing e sistemi

La richiesta deve generare identificativo, stato, owner e sincronizzazione con CRM o ERP. Modifiche e versioni dell’offerta devono restare tracciabili.

Progettare esperienza e misurazione

Salvataggio, modifica, duplicazione, riordino, conferma e tempi aiutano il buyer. Abbandono, errori, fattibilità, tempo di risposta e conversione in ordine misurano il processo.

Matrice decisionale

Sequenza operativa

1. Mappare processo commerciale e tipi di richiesta..

2. Definire dati obbligatori e informazioni differibili..

3. Progettare catalogo, configurazione e carrello RFQ..

4. Stabilire identità, listini e permessi..

5. Definire stati, owner, versioni e SLA..

6. Collegare CRM, ERP e documenti..

7. Testare scenari, errori e mobile..

8. Misurare fattibilità, tempi e ordini..

La sequenza è pronta per il rilascio quando i casi reali attraversano sito e sistemi collegati senza perdere varianti, allegati, stato o versione dell’offerta; i punti che richiedono intervento manuale devono essere visibili al buyer e al team commerciale.

Come misurare il lavoro

• RFQ avviate e completate
• Completezza dei dati e allegati
• Tasso di fattibilità
• Tempo di prima risposta e preventivo
• Revisioni e riaperture
• Conversione RFQ–ordine e valore

Le metriche vanno interpretate per tipo di richiesta e fase commerciale: meno invii può indicare un filtro più efficace, mentre tempi più brevi possono nascondere preventivi incompleti. Il confronto utile collega completezza iniziale, lavorazioni successive ed esito della trattativa.

Scenario applicativo

Un catalogo usa un pulsante «richiedi preventivo» che invia nome prodotto e messaggio libero. Il commerciale deve richiamare per quantità, applicazione e consegna.

Il nuovo carrello RFQ conserva varianti, quantità e allegati, permette campi «da definire» e instrada in base alla famiglia. Il buyer riceve identificativo e tempi.

Criteri di completamento

Errori da evitare

• Trasformare ogni RFQ in checkout.
• Chiedere tutte le specifiche come obbligatorie.
• Mescolare prezzo indicativo e offerta vincolante.
• Usare testo libero per ogni dato.
• Non versionare modifiche e preventivi.
• Integrare sistemi senza gestione errori.

Testare una RFQ con casi realistici

Un test efficace non segue soltanto il percorso ideale. Parte da richieste che il commerciale riceve davvero e verifica come il sistema tratta informazione certa, informazione mancante e dato contraddittorio. I casi vanno preparati con vendite, assistenza tecnica e amministrazione, perché ciascuna funzione incontra errori diversi durante la lavorazione.

• Il buyer seleziona opzioni incompatibili e chiede comunque di inviare la configurazione per una valutazione tecnica.
• Un distributore autenticato modifica quantità e destinazione, facendo cambiare valuta, condizioni visibili o soggetto incaricato della risposta.
• Un allegato viene sostituito dopo l’invio e occorre capire quale versione accompagna il preventivo già in preparazione.
• Una richiesta viene duplicata per un secondo progetto, ma deve conservare soltanto i dati riutilizzabili e non note o approvazioni precedenti.

Per ciascun caso bisogna osservare ciò che vede il buyer, il record ricevuto dal commerciale e il dato trasferito ai sistemi collegati. Una conferma corretta sul sito non basta se nel CRM manca una variante; allo stesso modo, un’integrazione tecnicamente riuscita non è sufficiente se il cliente non comprende se la richiesta sia stata presa in carico oppure già approvata.

Ridurre l’ambiguità senza allungare il modulo

Non tutte le lacune richiedono un nuovo campo obbligatorio. Prima di aggiungerlo, chiedersi chi conosce il dato, in quale momento diventa disponibile e quale decisione impedisce di prendere. Le informazioni indispensabili per instradare la richiesta possono essere raccolte subito; quelle necessarie soltanto alla quotazione dettagliata possono essere richieste dopo, mantenendo il collegamento con la configurazione iniziale.

Un campo «applicazione» generico, per esempio, può produrre descrizioni difficili da confrontare. Domande condizionali su ambiente d’uso, compatibilità o scadenza possono essere più utili, purché compaiano solo per le famiglie interessate. Se il buyer non conosce ancora la risposta, un’opzione esplicita come «da verificare» è preferibile a un valore inventato pur di completare il modulo. Il commerciale distingue così un’incertezza dichiarata da una dimenticanza e può preparare la domanda successiva senza ricostruire l’intera richiesta.

Il cliente deve capire a che punto è la richiesta

Dopo aver inviato un disegno, il buyer può aspettare una conferma di ricezione oppure credere che il fornitore abbia già accettato la lavorazione. Il sito deve rendere visibile la differenza. Il messaggio di conferma riporta il riferimento della richiesta e spiega quale sarà il prossimo contatto, senza dichiarare approvata una configurazione ancora da esaminare.

Gli stati nell’infografica descrivono una richiesta che ha bisogno di un chiarimento tecnico prima dell’offerta.

«Ricevuta» significa che i dati sono arrivati. «In attesa di un chiarimento» indica che manca una risposta del cliente. «In valutazione tecnica» segnala che il fornitore sta esaminando il lavoro. Con «Offerta inviata», la proposta ha una sua versione da richiamare nelle comunicazioni. L’eventuale ordine segue le modalità concordate nell’offerta.

Un disegno nuovo non deve cancellare la storia

Un ufficio acquisti invia una richiesta per una flangia a disegno. Durante il confronto emerge una tolleranza da correggere e il buyer carica una nuova revisione. Il commerciale deve poter associare la nuova revisione alla stessa richiesta, mantenendo leggibile quale file era stato usato per la prima valutazione.

Nel messaggio al cliente, indica il nome del file su cui è stato preparato il preventivo. Un allegato chiamato «definitivo.pdf» può essere sostituito più volte mantenendo lo stesso nome; servono quindi una revisione o un riferimento che distingua le copie ricevute. La quotazione già inviata resta collegata ai dati usati in quel momento.

Se la modifica cambia il prezzo o la consegna proposta, il commerciale prepara una nuova versione dell’offerta e chiarisce quale sostituisce. Il sito non deve presentare entrambe come proposte correnti senza spiegazioni. Il cliente deve poter ritrovare il documento cui si riferisce la conversazione.

Le attese da misurare separatamente

Una richiesta può restare ferma perché manca una quota del disegno oppure perché il tecnico non l’ha ancora aperta. Sono ritardi su cui intervenire in modo diverso. Nel primo caso il commerciale manda una domanda precisa al buyer; nel secondo il responsabile assegna il lavoro a un collega disponibile.

Per leggere i tempi, usa le date dei passaggi effettivi. L’arrivo del modulo e l’inizio della valutazione non sono lo stesso momento. Nel riepilogo delle richieste aperte deve comparire chi deve fare la prossima mossa, così una pratica non resta genericamente «in lavorazione» mentre tutti aspettano una risposta altrui.

Quando il collegamento con il gestionale si interrompe

Una conferma sul sito deve corrispondere a una richiesta recuperabile, anche durante un errore di trasferimento al gestionale. Chi segue l’integrazione prepara un elenco degli invii non completati e una procedura per ritentarli. Il riferimento originale permette di riconoscere la stessa richiesta quando il trasferimento riparte.

Nel collaudo, prova a ritrasmettere una richiesta già acquisita. Il commerciale deve ritrovare una sola pratica oppure un avviso esplicito del duplicato. Un doppio preventivo prodotto da due colleghi può confondere il cliente e lasciare condizioni diverse per lo stesso pezzo.

Domande frequenti

WooCommerce può gestire una RFQ?

Può sostenere catalogo, carrello e workflow tramite progettazione ed estensioni, ma la complessità dipende dal modello.

Quando mostrare il prezzo?

Quando è sufficientemente stabile e autorizzato; altrimenti si distinguono indicazione, fascia e preventivo.

Serve obbligare il login?

Solo se account, prezzi, cronologia o permessi lo richiedono; il login anticipato può creare attrito.

Approfondisci il servizio: E-commerce WooCommerce.