Copilot Service workspace, connettori e modalità embedded

Copilot Service workspace: l’app e il suo profilo di esperienza

Il Copilot Service workspace è l’applicazione rivolta al representative, cioè la persona che gestisce le conversazioni con i clienti: da non confondere con gli agent, che nel vocabolario di questo prodotto sono gli agenti AI. È un desktop multisessione che raccoglie in un’unica finestra i canali — live chat, SMS, voce, Microsoft Teams, canali social — e le funzionalità di Copilot, e si collega alla soluzione CRM dell’organizzazione per portare al representative conoscenza contestuale e dati del cliente.

Due dettagli operativi ricorrono spesso. Il primo: l’app è installata automaticamente in tutte le organizzazioni Dynamics 365 Contact Center, si apre dalla pagina delle app di Dynamics 365 e richiede il ruolo Omnichannel Agent. Il secondo: il modello multisessione prevede fino a nove sessioni contemporanee e fino a dieci schede dentro ciascuna sessione. Una nuova sessione nasce quando il representative apre un case dalla sessione Home oppure accetta una conversazione in arrivo, mentre le pagine aperte dal site map si caricano nella sessione già a fuoco.

La configurazione, però, non si fa dentro il workspace: si fa nel Copilot Service admin center, alla voce Experience profiles in Support experience > Workspaces. Tre profili predefiniti esistono già e non possono essere eliminati né modificati; per crearne di propri servono il ruolo App Profile Manager Administrator e il ruolo Basic User. Dentro un profilo si assegnano gli utenti, si collegano gli entity session template, si accende la Productivity pane scegliendo quali strumenti mostrare — fra gli altri Copilot, Knowledge search, Agent scripts, Teams chats, Smart assist, Screen Recording — e nella sezione Channel providers si abilitano i canali attivi e gli eventuali Third party voice channel providers. La pagina dei profili di esperienza è dichiarata valida sia per Contact Center standalone sia per la modalità embedded sia per Dynamics 365 Customer Service: è uno dei casi in cui la documentazione condivisa fra i due prodotti vale davvero per entrambi.

I connettori verso i CRM non Microsoft: due strade, non una

Il connettore serve a portare le anagrafiche del CRM esistente dentro Dataverse, così che routing, identificazione del cliente e Copilot abbiano un contesto su cui lavorare. Le tabelle sincronizzate sono Account e Contact: non è una migrazione del CRM, è un allineamento delle anagrafiche.

Per Salesforce esiste una procedura guidata nativa. Nel Copilot Service admin center si va in Support experience > Workspaces e, alla voce Data synchronization from external CRMs, si sceglie Manage; in alternativa, dalla home page, CRM connection wizard > Open. La creazione passa da una connessione Power Apps verso l’istanza Salesforce, dalla scelta delle tabelle Contacts e Accounts, dal mapping delle colonne e da una pagina Teams permissions, in cui il Team ID indicato deve avere permessi di lettura e scrittura sulle tabelle selezionate, altrimenti la sincronizzazione fallisce. Fra i prerequisiti compare anche una licenza Salesforce che dia accesso al change data capture. Attenzione a un vincolo esplicito: le modifiche fatte in Dataverse ai dati sincronizzati non tornano indietro verso Salesforce, quindi si aggiorna solo nel CRM di origine.

Per ServiceNow, Zendesk e per qualunque altro CRM la strada è diversa: si usano flussi Power Automate scaricati da GitHub e importati come pacchetto legacy. Servono la disponibilità del connettore msdyn_ContactCenterCRMConnector nell’ambiente Power Apps e le colonne Source CRM, Source CRM ID e Source CRM URL sulle tabelle Account e Contact. Qui la distinzione da tenere a mente è fra initial sync, copia manuale per cui è consigliata la paginazione, e incremental sync, aggiornamento automatico innescato da webhook, business rule o Apex trigger a seconda del CRM di origine. Estendere un connettore significa esattamente questo: aprire il flusso, modificare mapping ed espressioni, aggiungere i trigger che il CRM mette a disposizione. I flussi importati, va ricordato, arrivano disattivati e vanno accesi uno per uno.

La modalità embedded: il widget dentro il CRM di qualcun altro

Nella modalità embedded il representative non entra nel Copilot Service workspace: resta nel CRM che già usa, e la conversazione arriva dentro un widget incorporabile in qualsiasi pagina o applicazione che supporti HTML e JavaScript. L’URL del widget si recupera sempre allo stesso posto — pagina di benvenuto del Copilot Service admin center, Open sotto Your default contact center, scheda Conversation widget, sezione Integration into third-party systems — ma il modo di ospitarlo cambia da CRM a CRM. In Salesforce si importa un file di definizione del call center scaricato da GitHub sostituendo l’URL dell’adattatore CTI, si aggiungono gli utenti in Manage Call Center Users e si crea un’utility Open CTI Softphone nella Service Console; alla fine si sceglie il sign-in URI e la versione v58.0 dell’API Salesforce. In ServiceNow serve invece il plugin OpenFrame e si crea un record in OpenFrame > Configurations indicando nome, dimensioni e URL del widget.

I prerequisiti comuni sono l’abilitazione delle funzionalità omnicanale nell’organizzazione, i permessi di amministratore di sistema nel CRM di terze parti e il rispetto dei requisiti di sistema del CRM ospitante. Alcune funzionalità Copilot esistono solo qui — il riepilogo dei case nei CRM non Microsoft e le Resolution Notes — mentre Copilot analytics non è disponibile in embedded: è la prova che le tre superfici non sono intercambiabili.

Tre superfici distinte, e che cosa verifica l’esame

La terza superficie è ancora un’altra cosa: se l’organizzazione vuole tenere il proprio provider di canale telefonico e portarlo dentro l’app Microsoft, si usa Dynamics 365 Channel Integration Framework. La versione 2.0 serve le app multisessione, fra cui il Copilot Service workspace, supporta più provider di telefonia e mostra il pannello di comunicazione a sinistra; la versione 1.0 serve le app model-driven a sessione singola come Customer Service, Sales, Project Service e Field Service, gestisce un solo provider alla volta e mostra il pannello a destra.

L’esame insiste sulla distinzione, perché è quella che si sbaglia più facilmente. Il connettore muove dati verso Dataverse, la modalità embedded muove l’interfaccia dentro il CRM altrui, il Channel Integration Framework muove un provider di canale dentro l’app Microsoft. Si possono combinare, ma restano configurazioni separate, con prerequisiti, ruoli e punti di ingresso diversi. Davanti a uno scenario, la domanda giusta non è “quale prodotto”, ma “dove lavora il representative e dove vivono i dati”.