Webhook CRM: come collegare il form del sito alle vendite

Un webhook CRM è una notifica automatica. Quando qualcuno compila il form del tuo sito, il webhook manda subito i dati della richiesta a un indirizzo stabilito, in modo che il CRM la registri e il team commerciale possa lavorarla. Il collegamento tecnico però copre solo una parte del lavoro. Una richiesta diventa un'opportunità gestita solo se poi viene validata, confrontata con i contatti già presenti, assegnata a una persona e seguita da un'attività di richiamo. In questa guida trovi le differenze tra webhook, API e importazione manuale spiegate in parole semplici, un flusso ipotetico completo, la gestione di errori e responsabilità e una checklist per provare tutto prima di andare in produzione.

In breve

• Notifica su evento o interrogazione. Un webhook notifica un evento al sistema ricevente. Un’API è un’interfaccia per leggere o modificare dati; qui la confrontiamo con il controllo periodico dei nuovi dati. L'importazione manuale carica un file quando decide una persona.
• Il valore commerciale sta dopo la ricezione. Senza validazione, controllo dei duplicati, assegnazione e richiamo, il webhook porta solo record nel database.
• Gli errori vanno previsti. Molti sistemi ripetono l'invio quando la consegna fallisce, quindi la stessa richiesta può arrivare due volte.
• Ogni passaggio ha un responsabile. Decidi chi controlla i registri, chi corregge la mappatura dei campi e chi richiama il cliente.
• Prova sempre con un invio controllato e verifica il risultato nel CRM prima di pubblicare il modulo.

Indice

• Cos'è un webhook, spiegato senza gergo
• Webhook, API e importazione manuale: le differenze
• Esempi di webhook nel lavoro commerciale
• Il flusso ipotetico: dalla richiesta al richiamo
• Quando qualcosa va storto: errori, tentativi ripetuti e registri
• Sicurezza della ricezione
• Checklist di test con invio controllato
• Come gestire le richieste in arrivo con Flusia
• Domande frequenti
• Fonti
• Raccomandati

Cos'è un webhook, spiegato senza gergo

Pensa a due applicazioni: il sito con il form di contatto e il CRM, cioè il software dove il team gestisce lead, clienti e opportunità. Il webhook è il meccanismo con cui la prima avvisa la seconda appena succede qualcosa.

Come spiega la scheda di Red Hat sui webhook, si tratta di una comunicazione leggera e guidata dagli eventi che trasferisce dati tra applicazioni tramite HTTP. In pratica:

1. si verifica un evento, per esempio l'invio di un modulo;
2. il sistema di origine prepara un payload, cioè il pacchetto di dati della richiesta, di solito in formato JSON (un formato di testo strutturato a coppie nome e valore);
3. il payload viene inviato con una chiamata HTTP POST a un endpoint, l'indirizzo web che il sistema ricevente ha messo a disposizione;
4. il ricevente elabora i dati e risponde con un codice che conferma o segnala un problema.

Per questo il webhook viene chiamato anche "API inversa": non è il CRM a chiedere se ci sono novità, è il sito a comunicarle.

Webhook, API e importazione manuale: le differenze

Webhook e API possono lavorare insieme: la notifica comunica un evento, mentre le chiamate API permettono di leggere o modificare i dati. Il confronto qui riguarda notifiche su evento, interrogazione periodica e importazione manuale, non tre tecnologie mutuamente esclusive.

Criterio	Webhook	API	Importazione manuale
Chi avvia lo scambio	Il sistema di origine, all'evento	Il sistema che chiede i dati	Una persona del team
Tempistica	Appena succede l'evento	Quando parte la richiesta, anche a intervalli (polling)	Quando qualcuno carica il file
Direzione tipica	Una direzione, notifica	Lettura e scrittura, anche in due direzioni	Una direzione, a lotti
Uso tipico nel commerciale	Nuova richiesta dal form, nuovo ordine	Aggiornare o leggere schede, sincronizzare dati	Liste da fiere, migrazioni, recupero di archivi
Cosa serve	Un endpoint sempre raggiungibile	Credenziali e logica di interrogazione	Un file pulito e una mappatura delle colonne
Rischio principale	Invii persi o doppi	Interrogazioni inutili, limiti di chiamate	Errori di formato, duplicati di massa

Consiglio pratico: per il form del sito il webhook è spesso la scelta più naturale, perché la richiesta deve arrivare al commerciale quando il contatto è ancora interessato. L'API serve quando devi anche leggere o aggiornare dati già presenti. L'importazione manuale va bene per dati occasionali, non per un flusso quotidiano.

Esempi di webhook nel lavoro commerciale

Gli esempi che seguono sono ipotetici e descrivono scenari comuni, non integrazioni specifiche:

• Richiesta di preventivo dal sito: l'invio del form crea un lead con nome, azienda, servizio richiesto e messaggio.
• Iscrizione a un evento o a un webinar: la registrazione aggiunge il contatto a una lista e crea un'attività per il responsabile dell'evento.
• Ordine su un e-commerce: il nuovo ordine aggiorna la scheda del cliente e avvisa chi segue il rapporto commerciale.
• Lead da una campagna pubblicitaria: il modulo compilato sulla piattaforma pubblicitaria entra nel CRM con l'origine della campagna.
• Cambio di stato in un gestionale: una fattura segnata come pagata viene notificata al CRM, così il commerciale lo sa prima di richiamare.

In tutti i casi lo schema è lo stesso: un evento, un pacchetto di dati, un destinatario e un'azione da compiere. Se il tuo problema riguarda soprattutto lo scambio di dati tra CRM e software amministrativo, trovi un approfondimento nella guida su come far lavorare insieme CRM e gestionale.

Il flusso ipotetico: dalla richiesta al richiamo

Prendi un'azienda ipotetica che riceve dal sito richieste di consulenza. L'obiettivo: ogni richiesta valida deve diventare un lead assegnato con un'attività di richiamo, senza doppioni. Ecco i cinque passaggi.

1. Richiesta ricevuta

Il visitatore compila il modulo e il sito invia il payload all'endpoint. Il sistema ricevente deve fare due cose: validare autenticità e formato, registrare durevolmente la richiesta e solo allora confermare la ricezione, demandando le elaborazioni lente a una coda quando prevista. Se l'elaborazione è lenta e la risposta arriva in ritardo, il sistema di origine può considerare fallito l'invio e riprovare.

2. Validazione

Prima di creare il record, controlla che i dati abbiano senso:

• i campi obbligatori sono presenti (almeno un recapito e il motivo della richiesta);
• l'email ha un formato valido e il telefono contiene cifre;
• i valori a scelta (servizio, provincia, dimensione aziendale) corrispondono alle opzioni previste nel CRM;
• il messaggio non è vuoto o palesemente spam.

Decidi cosa succede a una richiesta non valida. Scartarla in silenzio è la scelta peggiore: meglio metterla in una coda da rivedere, con il motivo dello scarto.

3. Riconoscimento dei duplicati

Un duplicato può nascere in due modi diversi:

• duplicato tecnico: lo stesso invio arriva due volte per un tentativo ripetuto;
• duplicato commerciale: una persona già presente nel CRM compila di nuovo il form, magari con un'email diversa.

Per il primo caso serve un identificativo univoco dell'invio, se lo strumento di origine lo fornisce: se quell'identificativo è già stato elaborato, la seconda copia si ignora. Per il secondo caso stabilisci una regola di confronto, per esempio email uguale, oppure telefono uguale più stesso nome azienda. Se c'è corrispondenza, la nuova richiesta si aggiunge come attività alla scheda esistente invece di creare un nuovo contatto.

4. Assegnazione

Una richiesta senza proprietario non la richiama nessuno. Definisci criteri semplici e scritti:

Criterio ipotetico	Esempio di regola
Zona	Nord a Marco, Centro-Sud a Giulia
Servizio richiesto	Consulenza a un commerciale, assistenza a un tecnico
Cliente già esistente	Al commerciale che segue già l'account
Nessun criterio applicabile	Al responsabile commerciale, che riassegna

Nomi e regole sono di fantasia: adattali alla tua organizzazione. Quello che conta è che ogni richiesta finisca sempre a qualcuno, anche quando nessuna regola corrisponde.

5. Attività di richiamo

L'ultimo passaggio trasforma il dato in lavoro commerciale. Insieme al lead crea un'attività con scadenza, assegnata alla stessa persona, con il messaggio del cliente in evidenza. Stabilisci con il team entro quanto tempo si richiama una nuova richiesta e cosa si fa se l'attività resta aperta oltre la scadenza, per esempio una segnalazione al responsabile.

Se nel modulo chiedi anche il consenso a ricevere comunicazioni, il testo dell'informativa, i consensi da raccogliere e le regole per gli invii successivi vanno verificati con il referente privacy della tua azienda. Un contatto che chiede un preventivo non ha per questo accettato di ricevere messaggi promozionali.

Quando qualcosa va storto: errori, tentativi ripetuti e registri

Un'integrazione affidabile non è quella che non sbaglia mai, ma quella in cui ogni errore si vede e ha qualcuno che lo risolve.

Errori di consegna e tentativi ripetuti

Molti sistemi garantiscono una consegna "almeno una volta" (at-least-once). La documentazione di Google Cloud sui tentativi di consegna spiega che, se il destinatario non conferma la ricezione di un evento, il sistema prova automaticamente a consegnarlo di nuovo. Due conseguenze pratiche:

1. un invio può arrivare più di una volta, quindi l'elaborazione deve essere idempotente: elaborare due volte la stessa richiesta deve dare lo stesso risultato che elaborarla una volta sola, cioè un solo lead;
2. un invio può non arrivare mai se i tentativi si esauriscono, quindi ti serve un modo per accorgertene.

La stessa documentazione descrive l'uso di una coda per i messaggi non consegnati (dead-letter), dove finiscono gli eventi che non è stato possibile elaborare. Che lo strumento che scegli la offra o no, il principio vale: nessuna richiesta deve sparire senza lasciare traccia.

Non tutti gli strumenti si comportano allo stesso modo: numero di tentativi, intervalli e codici di risposta attesi cambiano da piattaforma a piattaforma. Per questi dettagli, come per autenticazione e struttura del payload, segui la documentazione ufficiale dello strumento che invia il webhook.

Registri

Il registro (o log) è l'elenco cronologico degli invii con il loro esito. Per ogni richiesta dovresti poter sapere:

• quando è arrivata;
• se è stata accettata, scartata o messa in coda;
• il motivo di un eventuale errore;
• quale record del CRM è stato creato o aggiornato.

Nei registri non devono comparire chiavi di accesso, token o dati personali oltre lo stretto necessario. Chi può consultarli e per quanto tempo si conservano è una decisione da prendere con il referente privacy.

Chi è responsabile di cosa

Attività	Responsabile ipotetico
Configurare il form e l'invio	Chi gestisce il sito
Mappatura dei campi e regole di validazione	Responsabile commerciale con chi gestisce il CRM
Controllo settimanale di registri e coda errori	Amministratore del CRM
Correzione dei dati scartati	Amministratore del CRM o segreteria commerciale
Richiamo del contatto	Commerciale assegnato
Verifica di informative e consensi	Referente privacy

Condividi questa tabella con tutte le persone coinvolte. Il problema più frequente non è tecnico: è un errore che tutti vedono e nessuno considera proprio.

Sicurezza della ricezione

Se l’endpoint webhook è esposto su Internet, chiunque ne conosca l’indirizzo può tentare di inviargli dati. Alcune regole di base:

• non affidarti solo a un URL difficile da indovinare: verifica che la richiesta provenga davvero dal sistema atteso, con i metodi previsti dallo strumento, per esempio una firma digitale nell'intestazione della richiesta;
• usa solo connessioni cifrate (HTTPS);
• conserva le chiavi in un luogo protetto, mai in documenti condivisi, email o chat;
• limita ciò che l'integrazione può fare nel CRM: creare lead e attività, non cancellare clienti.

Checklist di test con invio controllato

Prima di collegare il form definitivo, fai una serie di invii controllati con dati di prova inventati, mai con dati di clienti reali. Per ogni punto verifica il risultato direttamente nel CRM.

• Invio completo: compila tutti i campi e controlla che il lead compaia con ogni valore nel campo giusto.
• Campi facoltativi vuoti: il record si crea lo stesso e i campi restano vuoti, senza testi strani.
• Campo obbligatorio mancante: la richiesta finisce nella coda da rivedere con il motivo indicato.
• Email non valida: la validazione la blocca o la segnala.
• Caratteri speciali: accenti, apostrofi e nomi come "D'Angelo" arrivano senza errori.
• Stesso invio ripetuto: nel CRM esiste un solo lead.
• Contatto già presente: la richiesta si aggiunge alla scheda esistente invece di crearne una nuova.
• Assegnazione: ogni regola porta alla persona prevista, compreso il caso senza corrispondenza.
• Attività di richiamo: viene creata con scadenza e proprietario corretti.
• Errore simulato: con il ricevente non raggiungibile, l'invio fallito risulta nel registro.
• Registro: ogni prova è tracciata con data, esito e record collegato.
• Pulizia finale: elimina i record di prova prima del lancio.

Ripeti la checklist ogni volta che modifichi il form: un campo rinominato sul sito basta a interrompere la mappatura.

Come gestire le richieste in arrivo con Flusia

In Flusia il percorso di questa guida, dalla richiesta al richiamo, si svolge nello stesso ambiente in cui il team gestisce lead, clienti, opportunità e attività. La pagina sull'acquisizione lead automatica nel CRM descrive come le richieste entrano nella piattaforma, che include anche form web drag & drop e automazioni dei flussi di lavoro. Se i contatti arrivano da canali specifici, trovi le pagine sulle integrazioni con WooCommerce e Meta Ads.

Funzioni e integrazioni dipendono dal piano e dagli eventuali add-on. Per piani, fasce di utenti e condizioni aggiornate fai riferimento alla pagina prezzi ufficiale.

Hai un form da collegare e non sai quale integrazione ti serve? Richiedi una demo di Flusia: partendo dai tuoi moduli e dal tuo processo commerciale, valutiamo insieme quali integrazioni sono necessarie.

Domande frequenti

Qual è la differenza tra webhook e API?

Un’API espone operazioni per leggere o modificare dati. Un webhook notifica un evento a un destinatario; può essere usato insieme alle API e ridurre la necessità di interrogare periodicamente il sistema. Spesso si usano insieme: il webhook avvisa che è arrivata una richiesta, l'API serve poi a leggere o aggiornare altri dati.

Posso creare un webhook da solo?

Molti form builder e piattaforme permettono di indicare un indirizzo a cui inviare i dati senza scrivere codice. Serve però un sistema capace di ricevere, validare ed elaborare la richiesta. Per autenticazione e formato dei dati segui la documentazione ufficiale dello strumento.

Perché nel CRM vedo lo stesso lead due volte?

Le cause più comuni sono due: un invio ripetuto dopo un errore di consegna o un contatto che ha compilato di nuovo il form. Il primo caso si risolve riconoscendo l'identificativo dell'invio, il secondo con una regola di confronto su email o telefono.

L'importazione manuale è ancora utile?

Sì, per dati occasionali come liste raccolte a una fiera o la migrazione da un altro sistema. Per le richieste quotidiane dal sito è meno adatta, perché il contatto arriva al commerciale solo quando qualcuno carica il file.

Fonti

• Red Hat: Webhook, cos'è?
• TechTarget: Webhook vs. API, which mechanism is better?
• Google Cloud Documentation: Retry events, Eventarc Standard

Raccomandati

• Come creare un form contatti per il sito
• Come portare i lead di Facebook e Instagram nel CRM
• CRM per e-commerce: ordini e magazzino integrati
• WhatsApp come canale di vendita: la guida

Le procedure e le tabelle della guida sono modelli da adattare al proprio processo. Prima di attivare un automatismo, verifica con il team quali passaggi sono disponibili nel piano e quali richiedono configurazioni o integrazioni.