Come gestisce un sondaggio clienti dal suo CRM e riporta le risposte sul record?

01Il problema di business

Ci sono momenti in cui un cliente le dirà qualcosa di utile: subito dopo un rinnovo, subito dopo un incontro, qualche settimana dopo la messa in produzione, nel momento in cui un rapporto viene riesaminato. Chiedere è la metà facile. La metà difficile è che la risposta deve arrivare lì dove la persona che deve agire già lavora.

Un punteggio di soddisfazione in un foglio di calcolo non è un intervento. Il manager responsabile del rapporto apre il record del cliente, e se il record non dice nulla del sondaggio, il sondaggio non è avvenuto. Quindi il requisito non è "fare un sondaggio", ma:

• chiedere in un momento attivato da qualcosa nel CRM,
• poter attribuire ogni risposta a un cliente, una trattativa o un contatto specifici,
• far arrivare le risposte su quel record come valori che un report e un filtro possono vedere,
• avvisare la persona giusta quando arriva una determinata risposta,
• e sapere chi è stato interpellato e non ha risposto.

Quest'ultimo è il requisito che si dimentica, ed è quello che decide se l'esercizio produce un elenco di follow-up o un numero di facciata.

02Perché l'approccio ovvio non funziona

Uno strumento di sondaggio più un'integrazione

La scelta istintiva è un prodotto dedicato ai sondaggi con un connettore per il CRM. Fallisce sull'attribuzione. Il connettore associa le risposte ai record tramite un indirizzo email, e un indirizzo email è proprio ciò che non sopravvive a un invio reale: il destinatario inoltra l'invito a un collega, risponde da un indirizzo personale o è una di quattro persone della stessa azienda. Ciò che arriva è una risposta che il CRM non sa collocare, e l'esito abituale è una risposta silenziosamente non associata, o peggio, associata al record sbagliato più vicino.

Costruire le domande come campi e inviare per email un link di modifica

L'idea successiva è mettere le domande sul record del cliente come campi e inviare al cliente un link per modificarli. Un link del genere non esiste. I moduli dei record sono interni; esistono dietro autenticazione e permessi dei ruoli, e nessuna configurazione ne espone uno a un rispondente non autenticato.

Rilevare un invio osservando un campo

Il consiglio abituale è aggiungere una checkbox "termini accettati" o "sondaggio completato", renderla obbligatoria nel modulo e appendervi un processo attivato dalle modifiche. Funziona, ed è davvero lo schema da usare quando un sondaggio arriva dall'esterno della piattaforma. Qui è la scelta predefinita sbagliata, per tre motivi:

• Scatta sul record sbagliato. Un processo attivato dalle modifiche sull'account vede l'account. Non può vedere quale modulo è stato compilato né quali sono state le risposte, perché queste risiedono in un record di risposta separato.
• Un secondo invio potrebbe non attivarlo. Il campo sentinella è già true. Una risposta ripetuta non cambia nulla, quindi non viene eseguito nulla.
• Non è necessario. L'invio del modulo è un tipo di trigger nativo. La sentinella è un rimedio per una lacuna che non c'è.

Un solo modulo per l'intero percorso del cliente

L'ultimo errore è strutturale anziché meccanico: presumere che un solo questionario possa seguire un cliente lungo tutto il percorso. Una definizione di modulo indica un solo tipo di entità. Un questionario pre-incontro che deve collegarsi a un lead prima della conversione e a un'opportunità dopo corrisponde a due definizioni di modulo, non a un modulo con un interruttore.

03Modello dati

Tre entità sostengono un sondaggio, e la prima cosa da chiarire è quale sia quale, perché i nomi sono fuorvianti. La prospettiva dell'amministratore sulla stessa funzionalità è quella della pagina del centro assistenza Coevera Working with online forms.

A che cosa può collegarsi una risposta

Il collegamento di relazione comprende account, contatto, lead, opportunità, preventivo, progetto ed entità personalizzata, con uno di essi contrassegnato come principale. Quindi una singola risposta può stare sull'account e sulla trattativa a cui si riferiva la domanda, e il flag principale è ciò in base a cui un report raggruppa.

Un'entità personalizzata è ammessa sia dall'enum del tipo di entità sia dalla relazione. Questo è verificato sullo schema ma non sul comportamento: non era disponibile alcun esempio reale di modulo vincolato a un'entità personalizzata da esaminare. È importante perché è l'opposto del sottosistema di approvazione, che non può avere come destinazione un'entità personalizzata in alcun modo; veda il Blueprint 001.

Le risposte in sé

Una risposta è una coppia: l'id del campo del modulo e un valore stringa. Nella risposta non c'è alcuna tipizzazione. Una valutazione di 4 arriva come testo, una selezione multipla arriva come testo, una data arriva come testo. Tutto ciò che intende filtrare, mediare o rappresentare in un grafico deve essere scritto in un campo tipizzato di un record: è a questo che servono il §4 e il §5.

Chi è stato interpellato, e chi ha risposto

Le risposte vengono aggregate per modulo in quattro categorie, e sono la superficie di reportistica che conta più del numero di risposte:

L'alternativa scartata

Modellare una risposta al sondaggio come entità personalizzata è il riflesso istintivo quando il sottosistema nativo di una piattaforma sembra scarno. Qui costa più di quanto renda: dovrebbe ricostruire l'URL pubblico, il tracciamento degli invii, le quattro categorie aggregate, il contenitore dei rispondenti sconosciuti, il PDF della risposta e il trigger sull'invio, e non avrebbe comunque un motore di rendering dei moduli. Il quadro decisionale per questa valutazione è il Blueprint 003. Un'entità personalizzata è la risposta giusta quando ciò che serve è un record esaminabile con un proprio ciclo di vita e un proprio responsabile, cosa che una risposta non è. Il record di risposta accetta comunque campi personalizzati propri, quindi un punteggio derivato può stare sulla risposta senza una nuova entità.

04Configurazione a livello di campo

I tipi di campo disponibili in un modulo

Quindici, e le assenze contano quanto le presenze:

Vale la pena conoscere il campo prodotti e servizi in un sondaggio anziché in un modulo d'ordine: trasforma "è interessato a servizi aggiuntivi?" in una selezione con prezzi a fronte di un listino prezzi specifico, così una manifestazione di interesse arriva già quantificata. Il comportamento dei prezzi è descritto nel Blueprint 007.

Che cosa porta ogni campo del modulo

Campi di valutazione

Un campo di valutazione è delimitato da valueFrom e valueTo, con valueFromLabel e valueToLabel come riferimenti. Una domanda net promoter va da 0 a 10 con le etichette Most unlikely / Most likely; una domanda di soddisfazione va da 1 a 5; un semaforo va da 1 a 3. Stesso tipo di campo, tre sondaggi. Scelga i limiti una volta sola: cambiarli in seguito invalida il confronto con ogni risposta già raccolta, e nulla la avvisa.

Come la risposta trova il suo record: la decisione centrale

Tre impostazioni sul modulo, e scegliere tra di esse è l'intero progetto:

La parte elegante è il modo in cui precompilazione e autolink si combinano. Metta un campo email nel modulo, lo precompili dal campo email del record e imposti l'autolink in modo che confronti quello stesso campo del modulo con quello stesso campo del record. Inviato dal record, arriva precompilato e si collega immediatamente. Raggiunto a freddo da un link pubblicato, il rispondente digita il proprio indirizzo e si collega comunque. Una sola configurazione, entrambi i percorsi.

Accanto a questo, porti l'identità di cui si fida davvero in campi nascosti precompilati: visible: false, prefillEnabled: true, puntati sul nome dell'account e sul suo identificativo. Non vengono mai visualizzati, viaggiano nel link e danno alla risposta un'identità che non dipende da ciò che il rispondente ha digitato.

Scrivere le risposte sul record oggetto del sondaggio

Con updateRecordEnabled, il modulo porta un template di aggiornamento: un normale template di record i cui valori sono riferimenti ppl-tag a campi del modulo:

{"customFields": {
  "cfLikelyToRecommend":
    "<ppl-tag data-id=\"{rating-form-field-id}\" data-relation-type=\"Responses\"></ppl-tag>",
  "cfSurveyDateFilled":
    "<ppl-tag data-id=\"CurrentDate\"></ppl-tag>",
  "cfSurveyRespondent":
    "<ppl-tag data-id=\"{first-name-field-id}\" data-relation-type=\"Responses\"></ppl-tag> <ppl-tag data-id=\"{last-name-field-id}\" data-relation-type=\"Responses\"></ppl-tag>",
  "cfSurveysCompleted": ["{option-uuid}"]
}}

• data-relation-type="Responses" è ciò che preleva il valore dall'invio.
• CurrentDate è un tag integrato: imprima qui la data dell'invio, non in un processo.
• Due tag in un unico valore di destinazione si concatenano, ed è così che nome e cognome diventano un solo campo.
• Una destinazione dropdown o a selezione multipla si imposta tramite UUID dell'opzione, mai tramite etichetta.
• Ogni chiave del template fa parte della scrittura. Si limiti ai campi che intende modificare: una chiave con un valore vuoto è comunque nel payload. Non è stato testato se un valore vuoto svuoti il campo di destinazione o venga ignorato.

Le altre impostazioni che vale la pena impostare deliberatamente

05Automazione e logica

L'invio è un tipo di trigger

La piattaforma ha esattamente quattro tipi di trigger di processo: modifica del record, pianificazione, manuale e invio di un modulo online. Una risposta al sondaggio è quindi un evento a tutti gli effetti, non qualcosa dedotto da un campo che si è mosso.

Il trigger indica tre cose, e la prima sorprende:

Quell'elenco è la parte utile. Dove un sondaggio viene distribuito in diversi moduli quasi identici (uno per reparto, uno per pubblico), l'intero insieme può dipendere da un unico processo anziché da un processo per modulo.

Un modulo, più processi

Vale anche il contrario, e non è un campanello d'allarme. Un processo porta esattamente un filtro alla radice, e i rami di quel filtro seguono la regola per cui vince la prima corrispondenza. Quindi quattro cose indipendenti da fare con un solo invio (confermarne la ricezione, instradare la valutazione, aprire un'attività se è stato richiesto un incontro, avvisare un product owner se è stata citata una funzionalità) sono quattro processi, perché ciascuna può essere vera contemporaneamente alle altre. È lo stesso vincolo che decide il numero di processi ovunque nella piattaforma; il Blueprint 011 lo tratta insieme alla disciplina di denominazione che mantiene leggibile una famiglia di questo tipo.

Lo smistatore delle valutazioni

Lo schema che si ripaga: filtrare sulla fascia di valutazione e inviare un messaggio diverso per ogni fascia. Un punteggio basso invia subito un'email al responsabile del rapporto; un punteggio alto la invia a chi raccoglie le referenze. Entrambi sono rami di un unico filtro, perché una risposta ha esattamente una valutazione: è un vero insieme di alternative, quindi un solo processo è corretto.

Trasformare le risposte in struttura

Due strade, con costi molto diversi:

Ricorra prima al template. La strada del record collegato è la risposta giusta quando la cronologia conta, ma è quella costosa ed è il punto in cui l'automazione dei sondaggi diventa ingestibile più in fretta.

Inviare il sondaggio

Un modulo ha un link pubblico, quindi l'invio è una normale azione email che porta quel link con i parametri di precompilazione. La conseguenza è che l'invio è l'identità: un processo che invia il link dal record è anche ciò che mette quel record nella categoria Sent, ed è ciò che fa esistere SentAndNotResponded, l'elenco dei solleciti. Un sondaggio pubblicato su una pagina web non ha un elenco dei solleciti, per costruzione.

06Limiti e compromessi

In un parco in produzione di 74 definizioni di modulo con tre anni di cronologia, il calcolo è risultato esatto su tutti i 30 moduli che riportavano un tasso, e:

• 10 di quei 30 riportavano oltre il 100%.
• 44 moduli non riportavano alcun tasso, e 21 di essi contenevano complessivamente 491 risposte. Un modulo pubblicato anziché inviato ha un divisore pari a zero, quindi non ha alcun tasso, per quante persone abbiano risposto.

Consideri il dato significativo solo per un modulo che viene inviato anziché pubblicato e che limita ogni destinatario a una sola risposta. Altrimenti calcoli un tasso proprio a partire dalle categorie Sent e Responded, tenendo presente che Responded conta i record, non le risposte.

Altri limiti, nell'ordine in cui si fanno sentire

• Un modulo appartiene a un solo tipo di entità. Un questionario che deve collegarsi a un lead prima della conversione e a un'opportunità dopo corrisponde a due definizioni, due mappature delle risposte e due processi oppure un processo che indica entrambi i moduli. Tra di essi non c'è ereditarietà: una domanda aggiunta a uno non viene aggiunta all'altro.
• Un modulo pubblico con autolink e aggiornamento del record entrambi attivi è un endpoint di scrittura. Chiunque fornisca un valore che corrisponde al campo del record usato dall'autolink scrive su quel record. Se il campo di corrispondenza è un indirizzo email, il modulo è sicuro solo quanto è difficile indovinare gli indirizzi email dei suoi clienti. Limiti i moduli pubblici a createRecordEnabled e riconcili, oppure usi l'autolink su un valore che solo il destinatario previsto potrebbe possedere.
• Le risposte non associate vengono conservate, ma nulla le lavora. Finiscono in UnknownRespondents, il che è molto meglio che essere scartate o attribuite al record sbagliato, e in un sondaggio incorporato reale ne conteneva 10 su 39. Ma è un contenitore, non una coda: nessun responsabile, nessuna attività, nessun monitoraggio dei tempi di attesa. Gli assegni una persona e una cadenza, altrimenti diventa un luogo in cui il feedback dei clienti finisce per essere contato e non letto.
• Le risposte sono stringhe. Nulla di una risposta è tipizzato o aggregabile sul posto. Tutto ciò che deve essere rappresentato in un grafico, mediato o filtrato va scritto in un campo tipizzato dal template o da un processo: il che significa che una domanda che nessuno ha mappato è una domanda su cui nessuno può fare reportistica, anche se la risposta è memorizzata.
• Una risposta sopravvive al record a cui punta. Sia la risposta sia il riepilogo per record portano un flag di disponibilità, quindi un record eliminato o inaccessibile lascia risposte che non puntano a nulla. La cronologia dei sondaggi non è un motivo per conservare un record, ed eliminare un record non ripulisce le sue risposte.
• Non si può fare affidamento sul valore di risposta riepilogato della piattaforma. Il campo esiste sia sul modulo sia sul riepilogo per record, ed era nullo su tutti i 74 moduli esaminati. Calcoli il punteggio che le interessa in un campo proprio; non costruisca un report su quella proprietà.
• Disattivare un modulo ne conserva le risposte. Undici moduli disattivati nel parco contenevano ancora risposte. Disattivare è quindi sicuro come passo di archiviazione, ma non è un'eliminazione, e le risposte restano collegate ai loro record e visibili nei report. Un modulo disattivato smette anche di accettarne di nuove: il centro assistenza documenta che un modulo inattivo resta online ma non può memorizzare le risposte, e chi tenta di inviarne una vede solo una pagina statica.
• I limiti delle valutazioni non hanno versioni. Modificare valueFrom o valueTo rende silenziosamente le nuove risposte non confrontabili con quelle vecchie. Nulla segnala la discontinuità.

Il compromesso da dichiarare apertamente

I moduli nativi offrono attribuzione, un trigger sull'invio, un elenco dei solleciti e una mappatura dalle risposte ai campi che non richiede codice. Ciò che non offrono è una piattaforma di sondaggi: non c'è gestione dei panel, né una propria pianificazione dei promemoria, né benchmarking tra moduli, né analisi statistica. Se il requisito è uno strumento di ricerca, questo è lo strumento sbagliato. Se il requisito è che il record dell'account sappia che cosa ha detto il cliente e che qualcuno venga avvisato, che è quasi sempre il requisito reale, è quello giusto, ed è l'unica opzione in cui la risposta arriva sul record senza un'integrazione di mezzo.

07Verifica

Letti da uno spazio in produzione il 2026-09-10: 74 definizioni di modulo accumulate in tre anni, le loro impostazioni, la loro configurazione a livello di campo, le loro aggregazioni delle risposte e i processi da esse attivati.

• La formula del tasso di risposta è stata verificata aritmeticamente su ogni modulo che ne riportava uno: 30 moduli, zero discrepanze rispetto a risposte ÷ destinatari unici × 100. I 44 moduli che non riportavano alcun tasso avevano tutti zero invii registrati.
• Le quattro categorie aggregate sono state lette per ciascun modulo, ed è un sondaggio incorporato ad aver fissato il calcolo: 170 inviati, 155 inviati e senza risposta, 23 con risposta, 10 rispondenti sconosciuti, a fronte di un numero di risposte pari a 39. Risposto più sconosciuti non è uguale al numero di risposte perché Responded conta i record; inviati meno senza risposta non è uguale a risposto perché otto rispondenti non lo avevano mai ricevuto e sono arrivati tramite l'incorporamento.
• Sono state lette per intero due configurazioni reali contrapposte. Un sondaggio incorporato con autolinkEnabled e updateRecordEnabled attivi e linkRecordEnabled disattivato; e una distribuzione inviata con linkRecordEnabled attivo ed entrambi gli altri disattivati: identità dall'invio nel primo caso, da una risposta nel secondo.
• Il template di aggiornamento è stato letto alla lettera da un modulo reale, ed è da lì che provengono la forma di ppl-tag, il tipo di relazione Responses, il tag CurrentDate, la concatenazione di tag in un'unica destinazione e le destinazioni dropdown tramite UUID dell'opzione.
• L'automazione attivata dai moduli è stata conteggiata: 32 processi nello spazio usano il trigger del modulo online, ognuno con la risposta come entità del trigger. Uno è vincolato a sei moduli gemelli contemporaneamente; un modulo è servito da quattro processi separati.
• La visibilità condizionale delle domande è stata confermata in uso: una domanda prodotti e servizi in un sondaggio reale porta un filtro sui campi e compare solo quando una risposta precedente lo giustifica.

Non osservato, e dichiarato come tale:

• Il percorso di invio pubblico in sé: ogni risultato qui è letto dalla configurazione memorizzata e dai risultati memorizzati, non da un invio effettuato allo scopo.
• Un valore di risposta riepilogato valorizzato. Era nullo ovunque compaia.
• Un modulo vincolato a un'entità personalizzata. Verificato sullo schema ma non sul comportamento.
• Se un valore vuoto nel template di aggiornamento svuoti il campo di destinazione o venga ignorato.

Che cosa segnalerebbe una regressione

• Un modulo solo inviato il cui conteggio Sent si ferma mentre le risposte continuano ad arrivare significa che gli invii hanno smesso di essere registrati, il che distrugge in silenzio l'elenco dei solleciti.
• Un numero crescente di rispondenti sconosciuti è l'allarme più utile in assoluto qui: significa che il percorso dell'identità (precompilazione, autolink o l'invio stesso) si è rotto, e su ogni altra misura apparirà come "il sondaggio funziona bene".
• Un numero di risposte in crescita mentre i campi mappati sui record restano fermi significa che il template di aggiornamento ha smesso di essere applicato. Controlli il record, mai la conferma di invio.

Blueprint correlati

• Blueprint 011 — Come mantiene gestibili centinaia di automazioni del CRM? — perché un modulo ha bisogno di più processi, e come chiamarli.
• Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un oggetto? — il quadro alla base della scelta di non usare un'entità personalizzata per le risposte.
• Blueprint 001 — Come gestisce cinque tipi diversi di richieste dei clienti in un unico help desk? — il limite del sottosistema di approvazione sulle entità personalizzate, che i moduli non condividono.
• Blueprint 007 — Come fissa prezzi diversi per lo stesso prodotto per regione, segmento o contratto? — a fronte di che cosa viene prezzata la domanda prodotti e servizi.