Prima del contenuto, il vocabolario

In MB-230 la parola agent indica un agente AI, non la persona che lavora i case: quella si chiama representative (il dominio ufficiale si intitola “Configure representative experience and routing”). Anche il nome dell’app è cambiato: l’ambiente di lavoro è il Copilot Service workspace. Questo non è un dettaglio cosmetico, perché molte domande sono costruite proprio sull’ambiguità: uno scenario che dice “l’agent deve creare il case senza intervento” parla di automazione autonoma, non di una persona. Le funzionalità AI si dividono in due famiglie con logiche opposte: Copilot in Service, che assiste il representative mentre lavora (è lui a chiedere e a decidere), e gli agent autonomi, che agiscono su eventi senza che nessuno li invochi.

Ask a Question e Draft a Response

Ask a Question è l’interazione conversazionale: il representative pone una domanda in linguaggio naturale (“come si gestisce un reso oltre i 30 giorni?”) e Copilot risponde citando le fonti da cui ha attinto. Il punto d’esame non è che “risponde”, ma da dove attinge: le risposte sono ancorate alle knowledge source configurate — knowledge article interni, siti e repository esterni abilitati dall’amministratore — e il representative può filtrare i contenuti di riferimento per restringere l’ambito quando le risposte risultano generiche o pescano dalla fonte sbagliata. Se lo scenario lamenta risposte fuori tema, la leva è la configurazione delle knowledge source e il filtro, non un prompt diverso.

Draft a Response produce invece un artefatto: una bozza di risposta al cliente costruita a partire dal contesto del case o della conversation (descrizione, note, cronologia degli scambi) più la knowledge disponibile. Serve quando l’obiettivo è ridurre il tempo di scrittura, non quando il representative deve capire qualcosa. In entrambi i casi resta un human in the loop: la bozza va rivista, modificata e inviata dal representative, quindi nessuna delle due funzionalità “risolve” il case da sola.

I riepiloghi: case, timeline, conversation

I summary risolvono il problema del contesto perso nei passaggi di mano. Il case summary condensa i dati salienti del case (oggetto, cliente, descrizione, note e scambi recenti) in un blocco leggibile in pochi secondi: è ciò che serve a chi prende in carico un case già avviato o a chi lo riapre dopo giorni. Il riepilogo della timeline sintetizza la sequenza di attività registrate sul record, utile quando la cronologia è lunga e frammentata. Il conversation summary riguarda invece la sessione di dialogo ed è il candidato tipico degli scenari di transfer, consult ed escalation: chi riceve la conversation vede sintetizzato il problema del cliente e quanto già tentato, senza rileggere la trascrizione. La distinzione case contro conversation ritorna qui esattamente come nel routing: il case è il record di servizio persistente, la conversation è l’interazione.

Agent autonomi e Case Management Agent

Gli agent operano senza invocazione da parte di una persona: reagiscono a un evento (per esempio l’arrivo di una richiesta via email) e portano avanti passi ripetitivi del ciclo di vita del case. Il Case Management Agent è l’esempio canonico: automatizza attività di gestione come la creazione e l’aggiornamento dei case a partire dalle comunicazioni in ingresso e il presidio dei follow-up, riducendo il lavoro manuale a basso valore. Si configura dandogli istruzioni in linguaggio naturale, knowledge source su cui fondare le risposte e plug-in/action per compiere operazioni sui dati: la distinzione è netta e viene chiesta, perché la knowledge source dà all’agent qualcosa da sapere, il plug-in gli dà qualcosa da fare. Come tutto in Dynamics 365, l’agent lavora dentro Dataverse e resta soggetto alla sicurezza del record: non vede né modifica ciò che il suo contesto di sicurezza non consente. Il criterio di scelta è il volume e la ripetitività: assistenza al representative per il lavoro giudiziale, agent autonomo per il flusso standardizzato ad alta frequenza. Per le impostazioni puntuali e la disponibilità per area geografica, fai sempre riferimento alla documentazione ufficiale.

Trappole tipiche d’esame

  • Lo scenario dice “l’agent deve ricevere il case” → attenzione al vocabolario: in MB-230 “agent” è l’agente AI; se lo scenario parla di una persona in coda parla di representative, e la risposta corretta riguarda routing, queue e capacity profile, non l’AI.
  • Il representative deve capire una policy interna → Ask a Question, non Draft a Response: la prima risponde a una domanda con citazione delle fonti, la seconda produce una bozza di comunicazione verso il cliente. Confonderle è l’errore più frequente della coppia.
  • Le risposte di Copilot pescano da contenuti irrilevanti → agire su knowledge source e filtro dei contenuti di riferimento: non è un problema di formulazione della domanda né di permessi; si restringe l’ambito delle fonti abilitate.
  • Serve contesto a chi riceve un transfer o un’escalation → conversation summary, non case summary: il riepilogo del case descrive il record di servizio, quello della conversation descrive la sessione di dialogo in corso.
  • I case devono nascere dalle email in ingresso senza intervento umano → Case Management Agent: Copilot in-app assiste chi sta già lavorando; solo un agent autonomo agisce su evento in assenza di un representative.
  • L’automazione deve leggere o aggiornare dati applicativi → plug-in/action, non knowledge source: aggiungere altri articoli non darà mai all’agent la capacità di eseguire un’operazione sui dati.