---
title: "Come aggiunge al suo sito un modulo di contatto che scrive direttamente nel suo CRM?"
blueprint: 013
slug: website-contact-form-into-crm
category: Acquisizione lead
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/it/blueprints/website-contact-form-into-crm/
language: it
translation_of: https://blueprints.coevera.com/blueprints/website-contact-form-into-crm/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---
# Come aggiunge al suo sito un modulo di contatto che scrive direttamente nel suo CRM?
**Risposta breve.** **Un modulo di contatto è un online form che il CRM ospita e il sito web
incorpora.** Ogni definizione di modulo ha un `linkId`, e il modulo pubblico si trova a un URL
costruito a partire da quell'id. La pagina contiene quell'URL e un titolo accessibile: **niente
markup del modulo, niente elenco dei campi, niente endpoint, niente chiave API**. Così le domande
cambiano nel CRM senza un deploy del sito web.
Poi faccia dell'invio un **upsert**: attivi insieme `createRecordEnabled`, `updateRecordEnabled`
*e* `autolinkEnabled`. L'autolink confronta l'email inviata con il campo email del contatto, così
chi presenta di nuovo la domanda aggiorna il proprio record invece di diventare un secondo record.
Su un modulo attivo: **49 invii, 41 persone, nessuno senza corrispondenza.**
Il problema è la misurazione. Un modulo incorporato non ha destinatari, quindi non ha **né un
tasso di risposta né un elenco di solleciti**: entrambi vanno ricostruiti come reportistica sui
record che ha creato.
## 01 · Il problema di business
Ogni sito web ne ha uno: il modulo dietro *Contact us*, *Apply now*, *Request a call*, *Register
here*. Il requisito è ogni volta lo stesso, qualunque cosa dica il pulsante: uno sconosciuto
digita i propri dati su una pagina pubblica, e l'invio deve diventare subito un vero record. Non
una notifica che qualcuno trascrive nel CRM, e non una riga di un foglio di calcolo.
In pratica significa tutto questo insieme:
- la persona diventa un record che ha un **proprietario**, un **tipo** e la marcatura della sua
provenienza;
- chi invia due volte **non** diventa due persone;
- il candidato riceve subito una conferma;
- viene avvisata la persona interna giusta;
- chi ha iniziato senza mai finire viene sollecitato;
- e il marketing può ridisegnare la pagina, e un amministratore può aggiungere una domanda,
**senza che nessuno dei due debba aspettare l'altro**.
È quest'ultimo vincolo a far fallire la maggior parte delle implementazioni. Un modulo il cui
elenco dei campi risiede nel codice del sito web fa di ogni domanda un deploy, quindi l'insieme
delle domande si congela a com'era il giorno del lancio.
## 02 · Perché l'approccio ovvio non funziona
### Costruire il modulo con lo stack del sito web
Il riflesso è costruire a mano il modulo con il framework usato dal sito e inviarlo via POST
all'API del CRM. Funziona il primo giorno e da lì in poi si deteriora. L'elenco dei campi esiste
ora in due posti e va tenuto allineato a mano; aggiungere una domanda è una modifica al codice,
una revisione e un rilascio; e il sito web è diventato responsabile della validazione, dello spam
e della custodia di una credenziale che può scrivere nel CRM. Ognuno di questi è un problema che
il modulo ospitato ha già risolto.
### Un prodotto per moduli più un ponte di automazione
Uno strumento di moduli di terze parti collegato tramite una piattaforma di integrazione aggiunge
un passaggio che può fallire senza avvisare, e consegna un record senza sottotipo, senza
proprietario e senza provenienza, perché il ponte non conosce il suo modello dati. Serve poi un
processo di riconciliazione per finire il lavoro che il modulo avrebbe dovuto fare.
### Copiare il markup del modulo nella pagina
Non c'è markup da copiare. Il modulo ospitato è un'applicazione JavaScript servita da una CDN
statica e risolta tramite il suo link id in fase di esecuzione; l'HTML a quell'URL è un guscio di
circa 1,7 KB che contiene un unico elemento personalizzato. Qualsiasi cosa si aspetti di estrarre
o di ripubblicare i campi del modulo non vi troverà nulla.
### Creare un record per ogni invio
L'errore più costoso è il più semplice: attivare la creazione dei record e nient'altro. Le persone
inviano di nuovo i moduli pubblici come cosa normale: perdono la conferma, non sono sicure che
abbia funzionato, cambiano una risposta. Su un modulo di candidatura attivo, **49 invii
provenivano da 41 persone**. La sola creazione avrebbe prodotto otto contatti duplicati su un
modulo così piccolo, ciascuno con la propria email a valle, e il conto della deduplicazione arriva
più tardi con gli interessi.
### Dare per scontato che il candidato sia un lead
Modulo pubblico, persona sconosciuta: quindi un lead, di sicuro. Non necessariamente. Chi aderisce
a un programma sta entrando in una relazione, non in una pipeline di vendita: non ha una
trattativa, né un valore, né una data di chiusura, e inserirlo in una pipeline altera ogni metrica
della pipeline. Leghi il modulo all'entità che corrisponde a ciò che la persona è davvero. La
questione della collocazione è il [Blueprint
003](https://blueprints.coevera.com/it/blueprints/where-should-this-data-live/).
## 03 · Modello dati
Le tre entità coinvolte, la definizione del modulo, la risposta e la relazione di collegamento,
sono trattate nel [Blueprint
012](https://blueprints.coevera.com/it/blueprints/customer-survey-answers-onto-the-record/). Ciò
che è specifico qui è il confine tra il sito web e il CRM.
**Fonti.** Centro assistenza Coevera, [Working with online
forms](https://help.coevera.com/en/articles/8039971-working-with-online-forms) per il modulo in sé
e per l'incorporamento tramite iframe usato qui, che descrive come l'opzione più semplice ma con
dei limiti; e [Working with online forms in
JavaScript](https://help.coevera.com/en/articles/8287702-working-with-online-forms-in-javascript-developers-tutorial)
per l'altro percorso, un modulo incorporato tramite script che fa parte della pagina.
### L'accoppiamento è una sola stringa opaca
Una definizione di modulo espone `linkId`, e il modulo pubblico viene servito da un URL della
forma:
```
https://forms.{vendor-host}/{link-id}/viewform
```
Il sito web memorizza quell'URL e un titolo leggibile, e nient'altro. In un'implementazione
attiva, il modello dei contenuti della pagina contiene esattamente due chiavi per il modulo, l'URL
e il titolo, e il pulsante lo apre in un frame modale al momento del clic. Il titolo non è
decorazione: diventa il nome accessibile del frame, che è l'unica cosa che un lettore di schermo
può annunciare prima che il contenuto del frame si carichi.
> **Perché è questo il punto.** Poiché il sito web non contiene nomi di campi, aggiungere,
> rimuovere o riordinare una domanda è una modifica nel CRM senza alcun rilascio del sito. E
> poiché non contiene credenziali, nessuno che ne legga il sorgente può trasformare la pagina in
> un percorso di scrittura verso il suo CRM.
### Quanto costa davvero l'incorporamento
La risposta del modulo ospitato non porta alcun `X-Frame-Options` né alcuna restrizione
`frame-ancestors`, ed è proprio per questo che si incorpora ovunque. Incorporato come iframe, come
qui, ne derivano tre conseguenze, e tutte e tre di solito si scoprono tardi:
- **Non è indicizzabile.** Dentro l'iframe le domande sono generate da script, quindi motori di
ricerca e modelli vedono il guscio. Qualsiasi contenuto che debba essere indicizzato deve stare
sulla pagina attorno al frame, non al suo interno.
- **Senza JavaScript il modulo non c'è.** Non un modulo degradato: niente.
- **La pagina ospitante non può vedere dentro il frame.** Con il modulo in un iframe, i suoi
strumenti di analytics e di consenso osservano il clic che lo ha aperto e nulla dopo, quindi
l'abbandono a livello di campo è invisibile dall'esterno.
E poiché nulla limita chi può incorporarlo in un frame, lo stesso modulo può essere incorporato in
un sito che non è il suo. Il link id è l'unico segreto, e si trova nel sorgente della sua pagina.
### I campi dei moduli sono condivisi tra i moduli
Le definizioni dei campi dei moduli risiedono in un pool esteso a tutto lo spazio anziché dentro
un singolo modulo. Quattro identificativi di campo su questo modulo di candidatura, nome, cognome,
email, azienda, sono identici a quelli di un sondaggio clienti non correlato nello stesso spazio.
Quindi «aggiungere una domanda sull'email» riutilizza una definizione esistente invece di crearne
una nuova. Se la modifica di una definizione condivisa si propaghi a ogni modulo che la usa non è
stato testato; lo verifichi prima di rinominarne una.
### Ciò di cui il record ha bisogno e il visitatore non può dare
Un record creato deve comunque soddisfare i requisiti ordinari della piattaforma, e un invio
anonimo non ne soddisfa nessuno:
| Obbligatorio | Da dove proviene |
|---|---|
| Proprietario | Un id fisso nel modello di creazione. Non c'è nessuno da cui dedurlo |
| Unità di vendita | Anch'essa fissa. Un record con un proprietario e senza unità dovrebbe essere rifiutato; nessun invio lo ha verificato |
| Sottotipo | Un id di tipo fisso, così i candidati sono distinguibili a livello di record da chiunque altro sulla stessa entità: il pattern del discriminatore del [Blueprint 001](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/) |
| Provenienza | Marcata dal modello: si veda il §4 |
## 04 · Configurazione a livello di campo
### L'insieme delle domande, e che cosa dovrebbe significare «obbligatorio»
Il modulo attivo pone undici domande, nove delle quali obbligatorie:
| Domanda | Tipo di campo del modulo | Obbligatoria |
|---|---|---|
| First name, Last name | input a riga singola | sì |
| E-mail | email | sì, ed è la chiave dell'autolink |
| Phone | input a riga singola | sì |
| Company name | input a riga singola | **no** |
| Street | **area di testo** | sì |
| City, Zip, Country | input a riga singola | sì |
| State | input a riga singola | no |
| Privacy & data protection | casella di controllo | sì |
Da questa tabella vale la pena copiare due cose. Primo, **il tipo di campo del modulo segue il
tipo di campo del CRM, non la domanda**: la domanda sulla via è un'area di testo perché il campo
indirizzo del contatto sottostante è multiriga, e nessuna configurazione del modulo lo cambia.
Secondo, l'insieme degli obbligatori non è la lista dei desideri del marketing: un indirizzo
postale completo è obbligatorio perché il programma paga le persone e non può procedere senza,
mentre il nome dell'azienda, il campo su cui un addetto al marketing insisterebbe, è facoltativo.
**Renda obbligatorio ciò senza cui il passo successivo non può davvero funzionare**, e
nient'altro.
Si noti anche che ogni campo ha il precompilamento disattivato. Non c'è alcun record da cui
precompilare; la combinazione di precompilamento e autolink che identifica un cliente noto nel
[Blueprint
012](https://blueprints.coevera.com/it/blueprints/customer-survey-answers-onto-the-record/) non si
applica quando chi risponde è uno sconosciuto.
### Le tre impostazioni che ne fanno un upsert
| Impostazione | Valore | Effetto |
|---|---|---|
| `createRecordEnabled` | `true` | Un invio senza corrispondenza diventa un nuovo record |
| `updateRecordEnabled` | `true` | Un invio con corrispondenza aggiorna quello esistente |
| `autolinkEnabled` | `true` | Decide quale delle due cose accade |
| `autolinkFormFieldId` / `autolinkRecordFieldId` | la domanda sull'email / il campo email del contatto | La corrispondenza. Sono due identificativi distinti in due spazi di id diversi: abbinarli è l'intera configurazione |
| `linkRecordEnabled` | `false` | Non c'è nulla a cui collegarsi; l'identità è stabilita dalla risposta, non da un invio del modulo |
| `limitToSingleResponse` / `checkForExistingResponse` | `false` | **Corretto qui.** Gli invii ripetuti sono il meccanismo, non il problema |
### Il modello di creazione
Con `createRecordEnabled`, il modulo contiene un modello di record. È un **payload completo del
record, non una patch**: elenca i campi standard, compresi tutti e cinque gli slot telefono e
tutti e cinque gli slot email, per lo più vuoti:
```
{
"contactTypeId": "{sub-type-id}",
"ownerId": "{nominated-owner-id}",
"unitId": "{nominated-unit-id}",
"firstName": "",
"lastName": "",
"email1": "",
"phone1": "",
"address": "",
"city": "…", "zipCode": "…", "stateProvince": "…", "country": "…",
"email2": "", "email3": "", "phone2": "", "phone3": "",
"middleName": "", "title": "", "position": "",
"accountRelations": [], "tags": [], "staticProfiles": [],
"shareMode": "Standard",
"isUnsubscribed": false,
"comments": "Created via {a hand-typed page path}",
"customFields": {
"cfRegistrationDate": "",
"cfSource": "{the page URL}"
}
}
```
Le cinque decisioni contenute in quel payload:
- **Il sottotipo viene impostato alla creazione.** È questo che fa di «tutti coloro che hanno
fatto domanda tramite il sito web» un insieme filtrabile anziché una supposizione.
- **Proprietario e unità sono indicati, non derivati.** Entrambi sono obbligatori e nessuno dei
due può venire dal visitatore. Scelga un segnaposto deliberato anziché l'account di una persona
reale, altrimenti il segnaposto diventa per caso il carico di lavoro di qualcuno.
- **La provenienza viene marcata due volte**: una volta nel testo del commento e una volta in un
campo sorgente dedicato. Preferisca il campo: è filtrabile, utilizzabile nei report, e non si
deteriora. Il che porta al punto successivo.
- **La provenienza digitata a mano diverge.** Nel modello attivo la stringa del commento e il
campo sorgente non concordano sul percorso della pagina, perché uno dei due è stato digitato e
mai più rivisto. Nulla convalida una stringa a testo libero rispetto alla realtà. Tenga un'unica
fonte di verità e ne faccia un campo.
- **La data di registrazione viene da `CurrentDate`**, non da un processo eseguito più tardi.
> **La spunta del consenso non è sul record.** La casella della privacy è obbligatoria per l'invio
> e non compare da nessuna parte nel modello di creazione. Quindi il consenso esiste sul record
> della risposta e dentro il PDF della risposta, e **non è interrogabile sul contatto**. Se mai
> dovesse filtrare, riportare o dimostrare il consenso in blocco, lo mappi esplicitamente su un
> campo dedicato. Nulla la avverte che una domanda obbligatoria non è finita da nessuna parte.
### La notifica, e l'unica impostazione che si tende a invertire
Imposti `notificationEnabled` e la indirizzi **al proprietario del modulo**, non al proprietario
principale del record. Su un modulo di acquisizione il proprietario del record creato è il
segnaposto indicato nel modello, quindi notificare il proprietario del record significa scrivere a
un segnaposto. È l'opposto della risposta giusta su un sondaggio inviato a un cliente esistente,
dove il proprietario del record è la persona che deve saperlo.
### Il resto, in breve
- **reCAPTCHA è un flag per singolo modulo.** È disattivato su questo modulo e attivo sul modulo
di contatto generale nello stesso spazio. Un modulo pubblico senza di esso raccoglierà
spazzatura, e la spazzatura in un modulo upsert significa record spazzatura.
- **`attachResponseAsPdf`** archivia l'invio sul record. Su qualunque cosa somigli a una
candidatura o a un accordo, è ciò che rende il record difendibile un anno dopo.
- **La pagina di conferma è una promessa.** Farle dire «controlli la sua email per le istruzioni»
crea un obbligo che il §5 deve onorare.
## 05 · Automazione e logica
### Il gestore dell'invio
Un solo processo, legato tramite id a questo unico modulo, che si attiva all'invio. La sua entità
di trigger è la **risposta** e il suo tipo di record è il contatto a cui la risposta è stata
ricondotta, così il processo può leggere le risposte e agire sulla persona nella stessa
esecuzione. Nell'implementazione attiva è volutamente piccolo, un filtro e un'email, ed esiste per
onorare la frase della pagina di conferma.
**Latenza osservata:** il processo è stato eseguito l'ultima volta circa **otto secondi** dopo
l'ultima risposta registrata del modulo. È un'osservazione, non un benchmark, ma risolve la
questione di progettazione: si tratta di un passaggio in tempo reale, non di un batch, quindi
l'email di conferma può far parte dell'esperienza di invio.
### Ripristinare la metrica con un secondo modulo, inviato
Il pattern che vale la pena copiare è ciò che accade dopo. Il modulo di candidatura è incorporato,
quindi non può mai riportare un tasso. Il modulo di *accordo* che segue viene **inviato**, e un
modulo inviato riporta tutto. Il funnel attivo, dall'inizio alla fine:
| Fase | Misurato | Che cosa riporta la piattaforma |
|---|---|---|
| Modulo di candidatura incorporato | 49 invii → **41 persone distinte**, 0 senza corrispondenza | Tasso di risposta: **vuoto**. Conteggio degli invii zero |
| Modulo di accordo inviato | 144 invii a quelle 41 persone → **35 firmati** | Tasso di risposta: **85,4%**, più un elenco di chi non ha risposto |
Da quella tabella emergono due letture. Quella ovvia: **collochi la fase misurabile dove si trova
la decisione**. Quella più sottile: `sentCount ÷ sentUniqueCount` è 144 ÷ 41 ≈ 3,5, quindi il
rapporto tra i due contatori di invio indica quante volte ha sollecitato ciascuna persona, un
numero che nient'altro nella piattaforma fa emergere.
### Sollecitare chi non ha finito
Un modulo incorporato non ha un elenco di chi non ha risposto, perché non ha un elenco di invio.
Quindi il sollecito va ricostruito sul lato opposto: un **processo pianificato sui record
creati**, filtrato su quelli che hanno raggiunto lo stato di candidatura e mai quello di
completamento, che invia un promemoria.
Questa è la lezione strutturale dell'intero blueprint. Ogni misurazione che un modulo incorporato
non può fornire va ricostruita come reportistica sui record che ha creato, il che è possibile solo
perché il §4 ha insistito su un sottotipo, un campo di provenienza e una data di registrazione.
Quei tre campi sono ciò su cui filtra il processo di sollecito. Se li salta alla creazione, il
follow-up non si può proprio costruire.
### Mantenere leggibile la famiglia
Un funnel come questo arriva rapidamente a diversi processi: confermare la candidatura, reagire
alla firma, sollecitare chi non ha firmato, assegnare un punteggio al candidato, gestire la
campagna. Sono processi separati perché un processo porta un solo filtro i cui rami seguono la
regola della prima corrispondenza, e queste condizioni possono essere tutte vere
contemporaneamente: il vincolo e la disciplina dei nomi sono nel [Blueprint
011](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/).
Leghi ciascuno agli id dei moduli specifici che serve; un trigger accetta un **elenco** di moduli,
così una famiglia di moduli quasi identici può condividere un unico processo invece di
moltiplicarlo.
## 06 · Limiti e compromessi
> **Un modulo incorporato non può essere misurato dalla piattaforma.** Il tasso di risposta è
> risposte ÷ destinatari unici, e un modulo incorporato non ha destinatari: quindi il tasso è
> vuoto e l'elenco di chi ha ricevuto senza rispondere è vuoto per quante persone inviino il
> modulo. È aritmetica, non un bug, e nessuna impostazione lo cambia.
- **Una domanda obbligatoria può non finire da nessuna parte.** Verificato sul modulo attivo: la
casella della privacy è obbligatoria per l'invio e assente dal modello di creazione, quindi il
consenso viene raccolto sulla risposta e non sul contatto. Lo stesso silenzio vale per qualsiasi
domanda che nessuno abbia mappato: la risposta viene memorizzata, ma non è sul record.
- **Un upsert basato sull'email è un percorso di scrittura basato su un identificativo
indovinabile.** Chiunque invii un indirizzo noto aggiorna il record di quella persona. Su un
modulo di primo contatto l'esposizione è di solito accettabile, perché i campi scrivibili sono
comunque quelli che appartengono a quella persona, ma è una decisione, non un'impostazione
predefinita, ed è lo stesso meccanismo segnalato come pericolo per i sondaggi nel [Blueprint
012](https://blueprints.coevera.com/it/blueprints/customer-survey-answers-onto-the-record/).
Dove il modulo aggiorna qualcosa di commercialmente rilevante, basi la corrispondenza su un
valore che solo la persona prevista potrebbe possedere.
- **La stessa impostazione è giusta in un progetto e sbagliata in un altro.** Lasciare le risposte
ripetute senza restrizioni è ciò che fa funzionare l'upsert qui; su un sondaggio inviato è ciò
che spinge il tasso di risposta oltre il 100%. Non esiste un valore predefinito sicuro: decida
modulo per modulo quale dei due sta costruendo.
- **Il numero di campi obbligatori è un costo di conversione che non si vede.** Nove campi
obbligatori, compreso un indirizzo postale completo, sono molto da chiedere a uno sconosciuto, e
l'abbandono avviene dentro un frame che la pagina ospitante non può osservare. Vedrà gli invii
completati e mai quelli non completati, quindi su questo compromesso si deve ragionare anziché
misurarlo.
- **In un iframe, il modulo è invisibile ai crawler e ai visitatori senza JavaScript**, e il suo
contenuto non può portare alcun peso della pagina ai fini della ricerca o delle citazioni.
- **Nulla limita chi può incorporarlo in un frame.** Nessun frame-ancestors, nessun
X-Frame-Options: la proprietà che rende banale l'incorporamento significa anche che il modulo
funziona su qualsiasi sito che conosca il link id, e il link id si trova nel sorgente della sua
pagina.
- **La provenienza digitata come testo libero diverge**, in silenzio e per sempre. Due meccanismi
di provenienza su un unico modulo attivo sono già in disaccordo.
- **La proprietà è rimandata, non risolta.** Il proprietario indicato soddisfa la piattaforma e
non assegna il lavoro a nessuno. Un processo di instradamento o una vista condivisa sono un
lavoro separato, e dimenticarlo è il modo in cui un modulo di acquisizione finisce per
alimentare una coda che nessuno apre.
- **Le definizioni dei campi sono condivise in tutto lo spazio.** Identificativi di campo identici
compaiono su moduli non correlati nello stesso spazio. Comodo per il riutilizzo; il
comportamento di propagazione di una modifica non è stato testato, quindi consideri la
ridenominazione di una domanda condivisa come una modifica a ogni modulo che la usa finché non
sia dimostrato il contrario.
### Il compromesso da dichiarare apertamente
Ospitare il modulo nel CRM garantisce la cosa che conta di più ed è più difficile da introdurre a
posteriori: il sito web smette di sapere alcunché del suo modello dati. Le domande cambiano senza
un rilascio, nessuna credenziale lascia il CRM, e il record arriva con un tipo, un proprietario e
una marcatura. Ciò a cui rinuncia è tutto ciò che dipende dal vedere il modulo come parte della
propria pagina: un'integrazione visiva oltre lo stile proprio del modulo, analytics del funnel sui
singoli campi, contenuto indicizzabile e un modulo che funzioni senza JavaScript. Per un modulo di
iscrizione dietro un pulsante è un buon compromesso. Per un modulo che *è* la landing page non lo
è, e lì la risposta onesta è una pagina costruita a mano che invia all'API e accetta il costo di
manutenzione descritto nel §2.
## 07 · Verifica
Letto il 2026-09-10 da uno spazio in produzione e dalla pagina pubblica attiva che incorpora il
modulo: un modulo di candidatura a un programma partner in servizio da aprile 2026.
- **L'accoppiamento è stato verificato da entrambe le estremità.** Il link id memorizzato nella
definizione del modulo è identico byte per byte all'id nell'URL contenuto nel modello dei
contenuti della pagina pubblica, che contiene esattamente due chiavi per il modulo: quell'URL e
un titolo accessibile.
- **L'endpoint pubblico è stato scaricato.** Restituisce HTTP 200 con un guscio HTML di ~1,7 KB
che contiene un elemento personalizzato e tre script modulo da una CDN statica, e nessuna
intestazione `X-Frame-Options` o `frame-ancestors`: è la base di ogni affermazione
sull'incorporamento nel §3.
- **L'upsert è stato confermato rispetto ai suoi stessi contatori:** 49 risposte, 41 record nella
categoria di chi ha risposto, 0 rispondenti sconosciuti. Otto invii hanno quindi trovato
corrispondenza con un record esistente invece di crearne uno, senza che nulla restasse privo di
corrispondenza.
- **Le impostazioni e il modello di creazione sono stati letti alla lettera**: i tre flag
dell'upsert, la coppia di autolink, il sottotipo, gli id fissi di proprietario e unità, entrambe
le marcature di provenienza, e l'assenza di qualsiasi campo di consenso. L'elenco nel modello di
tutti e cinque gli slot telefono e cinque slot email è ciò che stabilisce che si tratta di un
payload completo e non di una patch.
- **L'insieme dei campi è stato letto per intero:** undici domande, nove obbligatorie,
precompilamento disattivato su ciascuna, la domanda sulla via un'area di testo dove gli altri
campi sono input a riga singola.
- **L'automazione è stata tracciata:** un processo legato solo all'id di questo modulo, entità di
trigger la risposta e tipo di record il contatto, due nodi. Il timestamp della sua ultima
esecuzione è circa otto secondi dopo il timestamp dell'ultima risposta del modulo.
- **I numeri del funnel sono stati letti dai contatori dei due moduli**, e il dato dell'85,4% si
riproduce esattamente come 35 ÷ 41: la stessa aritmetica risposte su destinatari unici
verificata su un intero parco di moduli nel [Blueprint
012](https://blueprints.coevera.com/it/blueprints/customer-survey-answers-onto-the-record/).
**Non osservato, e dichiarato come tale:**
- Un invio fatto appositamente. Ogni risultato è letto dalla configurazione memorizzata, dai
risultati memorizzati e dall'endpoint pubblico, non da dati di test inviati tramite un modulo
attivo.
- Se la modifica di una definizione condivisa di campo del modulo si propaghi agli altri moduli
che la usano.
- Se un valore vuoto nel modello di creazione scriva un valore vuoto o venga saltato.
- Il comportamento del reCAPTCHA in sé; solo che è un flag per singolo modulo, disattivato su
questo modulo e attivo su un altro nello stesso spazio.
### Che cosa segnalerebbe una regressione
- **Rispondenti sconosciuti che salgono sopra lo zero** su un modulo upsert significano che la
coppia di autolink si è rotta, e poiché la creazione funziona ancora, si presenta come un modulo
sano che produce record che nessuno riesce a trovare.
- **Il numero di record che cresce di pari passo con il numero di risposte.** Su un modulo con
persone che inviano più volte, un record per risposta significa che la corrispondenza non
avviene più e si stanno accumulando duplicati.
- **Risposte che arrivano mentre l'email di conferma smette di partire.** La pagina di conferma
continuerà a promettere un'email in ogni caso; la promessa e il processo sono configurati in
posti diversi e nulla li lega tra loro.
- **Il numero di record del proprietario indicato che cresce senza che il processo di sollecito
sia in esecuzione.** È il segno distintivo di un modulo di acquisizione che alimenta una coda su
cui nessuno lavora.
## Blueprint correlati
- [Blueprint 012 — Come gestisce un sondaggio clienti dal suo CRM e riporta le risposte sul
record?](https://blueprints.coevera.com/it/blueprints/customer-survey-answers-onto-the-record/)
— il modello dati degli online form, precompilamento e autolink per i clienti noti, e
l'aritmetica del tasso di risposta.
- [Blueprint 011 — Come mantiene gestibili centinaia di automazioni del
CRM?](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/)
— perché un funnel di acquisizione diventa diversi processi, e come denominarli.
- [Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un
oggetto?](https://blueprints.coevera.com/it/blueprints/where-should-this-data-live/) — decidere
quale entità debba diventare un invio pubblico.
- [Blueprint 001 — Come gestisce cinque tipi diversi di richieste dei clienti in un unico help
desk?](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/) — il
discriminatore di sottotipo impostato dal modello di creazione.
- [Blueprint 005 — Come migra i contatti da un altro sistema senza perdere dati senza
accorgersene?](https://blueprints.coevera.com/it/blueprints/contact-migration-without-data-loss/)
— perché l'email è una chiave di deduplicazione fragile su grandi volumi.
## Domande frequenti
### Come aggiunge al suo sito un modulo di contatto che scrive direttamente nel suo CRM?
Il CRM ospita il modulo e il sito web lo incorpora. Ogni definizione di modulo ha un link id, e il modulo pubblico si trova a un URL costruito a partire da quell'id; la pagina contiene solo quell'URL e un titolo accessibile, quindi sul sito web non ci sono markup del modulo, elenco dei campi né chiave API. Attivando insieme creazione del record, aggiornamento del record e autolink, un invio diventa un upsert: l'email inviata viene confrontata con il campo email del contatto, così chi presenta di nuovo la domanda aggiorna il proprio record invece di crearne un secondo.
### Come impedisce che un modulo pubblico crei record duplicati?
Attivi l'autolink insieme alla creazione e all'aggiornamento del record. L'autolink indica un campo del modulo e un campo del record; quando un invio corrisponde a un record esistente, aggiorna quel record, e solo un invio senza corrispondenza ne crea uno nuovo. Su un modulo di candidatura attivo, questo ha ridotto 49 invii a 41 persone distinte, senza alcuna risposta priva di corrispondenza.
### Perché un modulo incorporato non mostra alcun tasso di risposta?
Perché il tasso di risposta integrato è dato dalle risposte divise per i destinatari unici, e un modulo incorporato non ha destinatari. Il suo conteggio degli invii è zero, quindi il divisore è zero e il tasso resta vuoto per quante persone inviino il modulo. Lo stesso vale per l'elenco di chi ha ricevuto il modulo senza rispondere, per cui un modulo incorporato non ha nemmeno un elenco nativo di solleciti: entrambi vanno ricostruiti come reportistica sui record che ha creato.
### Una casella di consenso obbligatoria su un modulo diventa un campo del record?
No, a meno che non la mappi. Una casella per la privacy può essere obbligatoria per l'invio e mancare comunque dal modello di creazione del record: in quel caso il consenso sopravvive solo sul record della risposta e nel PDF allegato, e non è interrogabile sul contatto. Qualsiasi consenso che debba filtrare o dimostrare in blocco va mappato esplicitamente su un campo dedicato.
### Chi è il proprietario di un record creato da un visitatore anonimo del sito web?
La persona indicata nel modello di creazione. Ogni record richiede un proprietario e un'unità di vendita, e un invio anonimo non fornisce né l'uno né l'altra, per cui il modello contiene id fissi. L'assegnazione a una persona reale è quindi una questione separata: un processo di instradamento o una vista condivisa sui record del proprietario indicato, non qualcosa che il modulo possa decidere.
---
Pubblicato da Coevera. Ridotto allo schema riutilizzabile: nessun nome di cliente, nessun dato
dei clienti, nessun dato personale.