Dove si colloca Customer Voice nel ciclo di servizio

Il case si chiude quando il problema è risolto, ma la qualità percepita si misura solo dopo, chiedendola al cliente. Dynamics 365 Customer Voice è lo strumento con cui l’organizzazione raccoglie quel feedback: un project contiene uno o più survey, le domande possono essere rating, Net Promoter Score, scelta multipla o testo libero, e sulle risposte si calcolano metriche di soddisfazione come CSAT, NPS e sentiment.

La collocazione è la parte concettuale che l’esame verifica. Customer Voice sta a valle del lavoro operativo: non è un form che il representative compila dentro Copilot Service workspace, non è il posto dove si registrano le informazioni raccolte durante la lavorazione. Quelle stanno su colonne e form Dataverse del case, o vengono guidate da un agent script. Customer Voice parla al cliente, quando il servizio è finito.

Serve anche tenere separati i due oggetti che possono generare feedback: il case è il record di servizio, la conversation è la sessione di dialogo (chat, voce, canale asincrono). Una conversation può chiudersi senza aver mai creato un case, e in quello scenario il questionario va agganciato alla conversation, non forzato su un case inesistente.

Progettare un questionario che resti interpretabile

Due decisioni contano più delle altre. La prima è la lunghezza: due-quattro domande, una metrica primaria più un campo aperto. Un survey lungo abbassa il response rate e rende il dato meno rappresentativo, non più ricco.

La seconda è la personalizzazione tramite variabili. Le variabili del survey si valorizzano al momento dell’invio e servono a due scopi distinti: rendere il testo dell’invito e delle domande contestuale (nome del cliente, riferimento del case, prodotto, nome del representative) e — soprattutto — trasportare il contesto dentro la risposta. Senza variabili di contesto, una risposta è solo un voto anonimo rispetto al processo che l’ha generata. Sulla stessa logica si costruiscono branching condizionale, versioni multilingua e branding coerente.

Distribuzione automatica con Power Automate

Customer Voice sa inviare inviti via email direttamente dal project, ma la distribuzione event-driven è il pattern che l’esame propone: un flow di Power Automate con trigger Dataverse sulla tabella del case, condizione sul passaggio a stato Resolved (in alternativa, trigger sulla creazione del record di case resolution), poi l’azione di invio del survey con le variabili popolate dai campi del record.

Criteri di progetto che distinguono una risposta corretta da una plausibile: filtrare il più possibile nella trigger condition invece che con un ramo dentro il flow; escludere case interni, di test o riaperti; introdurre un piccolo ritardo per non far arrivare il questionario nello stesso istante della comunicazione di chiusura; prevedere una regola anti-flooding se lo stesso cliente chiude molti case. Se invece il requisito è “invia il questionario a tutti i clienti serviti questo mese”, non è event-driven: è una distribuzione pianificata o un flow ricorrente, non un trigger sul record.

Riportare il risultato sul case (o sulla conversation)

Le risposte di Customer Voice atterrano in tabelle Dataverse, e questo è ciò che rende possibile il passaggio decisivo: correlare la risposta al record d’origine, valorizzando la variabile che porta l’identificatore del case o della conversation e usando il riferimento (regarding) su invito e risposta.

Con quel legame ottieni analisi che valgono qualcosa: CSAT per queue, per team o per prodotto, correlazione tra rispetto degli SLA item e soddisfazione, view e dashboard nativi, e automazioni di secondo livello — un flow che, su un punteggio sotto soglia, crea un case di follow-up o lo instrada a una queue di escalation. Senza quel legame resti con una media generale che non spiega nulla e non si può azionare. È il tipo di distinzione su cui si giocano i punti nel dominio più pesante dell’esame, quello sulla gestione dei case, in una prova che si supera con 700/1000.

Trappole tipiche d’esame

  • Inviare un questionario di soddisfazione quando un case viene risolto → soluzione: flow Power Automate con trigger Dataverse sul case e azione di invio Customer Voice. Non serve codice custom né un job schedulato: lo scenario è event-driven e la risposta corretta è il flow, non l’invio manuale dal project.
  • I risultati devono essere analizzabili per case, team o prodotto → soluzione: variabili di personalizzazione che trasportano l’identificatore del record. Inviare il survey al solo indirizzo email è la distrattore classica: l’invio funziona, ma la risposta resta scollegata e non produce alcuna metrica segmentabile.
  • Raccogliere informazioni obbligatorie dal representative durante la chiusura del case → soluzione: colonne e form Dataverse sul case, business process flow o agent script. Customer Voice è fuori scope: raccoglie feedback dal cliente dopo, non struttura il lavoro interno prima.
  • Misurare la soddisfazione su un’interazione chiusa senza case → soluzione: agganciare il survey alla conversation. L’opzione che forza la creazione di un case solo per poterci appendere il questionario è sbagliata: case e conversation sono entità distinte.
  • Evitare che lo stesso cliente riceva più questionari ravvicinati → soluzione: logica di controllo nel flow (o nelle impostazioni di distribuzione), non nel questionario. Il survey non conosce lo storico degli invii; la deduplica è responsabilità dell’automazione.
  • Reagire automaticamente a un punteggio negativo → soluzione: flow sulla risposta memorizzata in Dataverse che crea un case di follow-up o instrada a una queue. Non è una funzione interna del questionario, ed è il motivo per cui la correlazione con il record d’origine va impostata fin dall’invio.