Integrazione sito e CRM: verifica che le richieste arrivino
Neaptide · 7 settembre 2026 · 6 min di lettura · Aggiornato: 3 ottobre 2026
Collega i moduli al CRM, conserva la provenienza e gestisci i tentativi senza duplicati. Con uno scenario di errore e una checklist di collaudo.
In questo articolo
Un messaggio di ringraziamento non dimostra che la richiesta sia arrivata nel CRM. Prima di approvare il sito, fatti mostrare l’invio salvato, la scheda corrispondente e il commerciale incaricato. E se il processo si interrompe a metà, il team deve poter individuare il passaggio in cui si è fermato.
L’integrazione trasmette i dati del modulo al sistema commerciale e applica le regole concordate per richieste, contatti e assegnazioni. A seconda di come vanno gestite le tue richieste, può bastare un modulo nativo del CRM o un connettore già pronto, oppure serve codice dedicato sulle API.
Definisci quando una richiesta è ricevuta
I passaggi sono tre: il sito salva la richiesta, il CRM conferma la scheda e il commerciale riceve l’incarico. Un’email o una notifica Telegram non dimostrano da sole che siano riusciti tutti e tre.
Quando il CRM è indisponibile, il sito può conservare la richiesta in modo affidabile per trasmetterla dopo, e a quel punto può confermarne la ricezione. Se fallisce anche il salvataggio, non deve dichiarare un successo. Deve offrire un nuovo tentativo o un altro contatto.
Parti dalla soluzione adatta più semplice
Guarda prima se un modulo nativo o un connettore esistente trasmette i campi che ti servono, assegna le richieste alle persone giuste e riprende l’invio dopo un errore. Fattelo mostrare su richieste di prova. Lo sviluppo su misura non è più affidabile solo perché è su misura.
Una coda separa ricezione ed elaborazione, ma qualcuno deve tenere d’occhio i messaggi in attesa o falliti. Con un flusso ridotto e stabile, un servizio di code separato è spesso superfluo. Nel decidere, metti nel conto anche la manutenzione.
Conserva il contesto della richiesta
Prepara una tabella che associ ogni campo del modulo a quello corrispondente nel CRM. Aggiungi i dati che il sito fornisce da sé, come la pagina, l’identificativo del modulo, l’ora di ricezione e la fonte conosciuta della visita. Poi controlla quali campi sono obbligatori e quali valori ammettono le liste di scelta.
Decidi se conservare la prima fonte conosciuta, quella della richiesta attuale o entrambe. L’assenza di UTM non dimostra una visita diretta. Può darsi semplicemente che la fonte sia sconosciuta.
Le credenziali del CRM restano sul server. Quanto ai log, limita l’accesso ed evita di copiarvi senza motivo i messaggi completi dei clienti.
Un nuovo tentativo non è una nuova richiesta
Prendiamo uno scenario ipotetico. Il sito salva l’invio S-104 e il CRM crea la scheda C-208, ma la conferma si perde. Il sito vede soltanto un timeout. Se ripete la creazione senza verificare l’esito, può generare un duplicato.
Usa lo stesso identificativo quando ritenti l’invio. Se l’API supporta l’idempotenza, può trattare i tentativi ripetuti come una sola operazione. Altrimenti serve un meccanismo adatto per associare e verificare le registrazioni. Cercare una scheda prima di crearla non basta, perché due richieste possono arrivare insieme. E un timeout non dimostra che il primo salvataggio sia fallito.
Se il giorno dopo la stessa persona chiede un altro servizio, quella è una nuova richiesta, S-105. Puoi collegarla al contatto esistente conservandone il contenuto. Eliminando tutti gli invii con lo stesso numero di telefono faresti sparire richieste vere.
Verifica il comportamento in caso di guasto
La tabella descrive i risultati attesi in un ambiente di prova. Non riporta misure fatte su un CRM specifico. Usala per tutti i moduli e tutte le lingue, e registra gli identificativi, così potrai confrontare la stessa richiesta nei diversi sistemi.
| Caso | Verifica attesa |
|---|---|
| Richiesta normale | Campi, provenienza, record e referente corretti. |
| CRM indisponibile | Richiesta salvata, attesa visibile, consegna ripresa. |
| Timeout dopo la creazione | Il reinvio non crea un’altra richiesta; l’esito si verifica tramite l’identificativo. |
| Campo obbligatorio non valido | Errore visibile, senza tentativi infiniti. |
| Nuova richiesta, stesso telefono | Contenuto conservato secondo le regole concordate. |
| Nessun parametro UTM | Nessuna campagna inventata al posto della fonte sconosciuta. |
Prepara la gestione dopo il lancio
Alla consegna, richiedi la tabella dei campi, le regole per le nuove richieste di contatti già presenti e le istruzioni per consultare gli errori. Serve anche un responsabile, e i tempi di trasmissione vanno concordati. Fatti mostrare infine come riprendere il lavoro dopo un errore senza creare duplicati.
Il numero di nuove opportunità non basta per verificare le consegne, perché alcune richieste si collegano a contatti o opportunità esistenti. Conviene confrontare identificativi e stati, distinguendo test, spam e richieste in attesa.
Per un progetto web con Neaptide, invia l’indirizzo del sito, il CRM, l’elenco dei moduli e un esempio del record desiderato senza dati personali. Specifica come trattare i clienti che tornano e chi approva il lavoro per il reparto commerciale.