Mettere la conoscenza a portata del representative
Il knowledge management in Customer Service non è un archivio a sé: è un layer di ricerca che deve comparire dentro il flusso di lavoro. Il primo passo è concettuale, non redazionale: il knowledge management si abilita per tabella. Finché la tabella non è abilitata alla knowledge, il record non ha alcun aggancio agli articoli e il knowledge search control sul form non ha nulla da mostrare. In genere si parte da case, ma nulla vieta di abilitare anche account, contact o tabelle custom quando il servizio ruota attorno a entità diverse.
La ricerca vive in due posti che l’esame tiene distinti: il control sul form (dentro il record) e il pannello dedicato nel productivity pane del Copilot Service workspace, dove la ricerca segue la sessione e resta disponibile mentre il representative lavora su una conversation. Entrambi poggiano su Dataverse search: se la ricerca a livello di environment è spenta, la knowledge non funziona, per quanto siano ben scritti gli articoli.
Knowledge interna: articoli con un ciclo di vita
Un knowledge article è un record Dataverse a tutti gli effetti, e questo è il punto che l’esame usa come discriminante. Ha un ciclo di vita governato — draft, review, published, expired — con approvazione, versioni (major e minor), pubblicazione schedulata e scadenza. Ha translations collegate all’articolo padre, ciascuna con il proprio stato di pubblicazione: una traduzione non è una copia sciolta ma un ramo dello stesso contenuto. Ha metadati che guidano la rilevanza (keyword, description) e categories gerarchiche che servono a organizzare e a filtrare i risultati, non a sostituire la rilevanza testuale.
Da un risultato di ricerca il representative non fa solo “leggere”: associa l’articolo al case (creando la traccia che alimenta le analisi di riutilizzo), lo invia via email, ne copia il link o l’URL pubblico se è esposto su un portale. Il feedback e il rating chiudono il ciclo, indicando quali articoli meritano una revisione. Tutto questo esiste solo perché il contenuto è dentro Dataverse: è la ragione per cui si sceglie la knowledge interna quando servono governance, audit, traduzioni e workflow di approvazione.
External knowledge source: federare senza possedere
Una external knowledge source risolve il problema opposto: il contenuto autorevole esiste già altrove — un sito di documentazione, un repository SharePoint, la knowledge base di un sistema terzo — e duplicarlo dentro Dataverse significherebbe condannarsi a tenerlo allineato. L’integrazione avviene tramite un search provider configurato a livello di environment: i risultati esterni vengono federati nella stessa esperienza di ricerca, accanto agli articoli interni, ma il contenuto resta a chi lo pubblica.
Il trade-off è netto e va memorizzato così: nessun ciclo di vita, nessuna versione, nessuna traduzione gestita da te, nessuna approvazione interna; in cambio, zero manutenzione e una sola fonte di verità dove è già presidiata. Si sceglie l’external source quando il contenuto è mantenuto da un altro team o da un altro sistema; si sceglie l’articolo interno quando il servizio deve possedere e certificare il testo.
Suggerimenti AI e Copilot
Sopra la ricerca si innestano tre comportamenti diversi. I suggerimenti AI sono proattivi: senza che nessuno digiti una query, il sistema propone articoli (e case simili) in base al contesto del case o della conversation, e li mostra nel productivity pane. Ask a Question è invece esplicito: il representative pone una domanda in linguaggio naturale e Copilot risponde citando le fonti, con un filtro dei contenuti che permette di restringere l’ambito alle sole knowledge source ammesse. Draft a Response usa la stessa conoscenza per comporre la risposta al cliente.
La creazione di articoli guidata da Copilot chiude il cerchio nell’altra direzione: a partire dai dati del case e dalla sua risoluzione, Copilot propone una bozza di knowledge article che il representative rivede, corregge e sottopone al normale flusso di approvazione. L’AI accelera la stesura, non scavalca il ciclo di vita. Per i dettagli di attivazione e le aree geografiche supportate, che cambiano spesso, fai riferimento alla documentazione ufficiale.
Trappole tipiche d’esame
- Il contenuto è mantenuto da un altro team su un sistema esterno, ma deve comparire nella ricerca → external knowledge source: si configura un search provider che federa i risultati; importare o ricopiare gli articoli in Dataverse è la risposta sbagliata perché crea disallineamento.
- Servono approvazione, versioni e traduzioni → knowledge article interno: solo gli articoli in Dataverse hanno lifecycle, major/minor version e translations collegate. Una fonte esterna non offre nulla di tutto questo.
- Il knowledge search control non mostra risultati su una tabella custom → knowledge management non abilitato su quella tabella: aggiungere il control al form o aprire il productivity pane non sostituisce l’abilitazione della tabella, e Dataverse search deve essere attivo nell’environment.
- Copilot non trova un articolo appena scritto → l’articolo è ancora in draft o fuori dallo scope configurato: la generative answer attinge a contenuti pubblicati e alle sole knowledge source abilitate, non all’intero database. Non è un problema di category.
- Copilot ha generato l’articolo, quindi è pubblicato → falso: la bozza generata resta soggetta a revisione e approvazione come qualunque altro articolo.
- “Proporre articoli senza che venga digitata una query” → suggerimenti AI, non Ask a Question: i suggerimenti sono proattivi e context-driven; Ask a Question richiede una domanda esplicita e Draft a Response redige il testo per il cliente.