Progettare il setup: le decisioni strutturali
Il primo bivio è quale ruolo gioca il CRM. Microsoft pubblica due reference architecture distinte: una in cui Dynamics 365 Customer Service Premium è anche il CRM e Dataverse ospita i dati che alimentano bot, IVR, case management e knowledge; e una in cui l’organizzazione mantiene il CRM esistente e sostituisce solo la piattaforma di contact center con Dynamics 365 Contact Center. Le due pagine differiscono anche nelle assunzioni dichiarate, quindi non sono intercambiabili: sceglierne una significa scegliere dove vivranno i dati di conversazione e quanto lavoro di integrazione resta da fare. Dynamics 365 Contact Center esiste inoltre in due forme, standalone ed embedded, e molte pagine della documentazione lo dichiarano esplicitamente nella riga “Applies to”.
La seconda decisione è geografica, ed è quella che più spesso viene presa male. La pagina International availability chiarisce che il tenant Microsoft 365 deve essere colocato in una delle aree supportate, e che quelle aree si riferiscono al tenant Microsoft 365, non al data center in cui risiede l’ambiente Power Platform. La copertura non è uniforme: in Francia, Germania e India il canale digitale è disponibile ma la voce no; GCC High non ha né digitale né voce. Anche le lingue divergono fra digitale e voce (l’inglese India, per esempio, è supportato solo sul digitale). Un progetto che dà per scontata la voce in una region che non la offre va rifatto dall’inizio.
Il provisioning vero e proprio avviene nel Copilot Service admin center, in Customer Support > Channels > Manage channels, dove si selezionano i canali da abilitare: Chat, Voice, SMS, Social e Microsoft Teams. Le caselle dei canali per cui mancano le licenze restano disabilitate. Serve il ruolo Dynamics 365 System Administrator sulla root business unit. Attenzione a un dettaglio operativo esplicito nella doc: si può spegnere un singolo canale, ma se li si spegne tutti, qualunque canale riabilitato in seguito va riconfigurato da zero perché le configurazioni precedenti non funzionano più.
Infine l’ALM, che è una scelta di setup a tutti gli effetti. La raccomandazione è impacchettare le configurazioni in una soluzione unmanaged nell’ambiente sorgente, esportarla come managed e importarla nel target, mantenendo parità fra gli ambienti e stesse versioni delle soluzioni installate. Non si modificano i record di configurazione managed direttamente in produzione: si crea un active layer che ha sempre la precedenza sul managed e che blocca in silenzio gli aggiornamenti successivi. E non si cancellano quei record: si cancella la soluzione managed che li ha portati. L’esame tende a verificare proprio questo, cioè se sai riconoscere la causa di una configurazione che “non si aggiorna nonostante l’import sia riuscito”.
Best practice per la voce
Sul piano telefonico la scelta è fra bring your own telephony (SIP trunk via Azure Communication Services direct routing o Teams direct routing) e i Microsoft calling plan numbers (Azure Communication Services direct offer o Teams calling plan). La prima riusa carrier e numeri esistenti e preserva il contesto SIP (caller ID, intent, token di autenticazione): è indicata per blind transfer, callback e handoff verso sistemi non Microsoft, dove perdere quel contesto rompe la continuità. La seconda semplifica provisioning, fatturazione e compliance, ma il contesto SIP può essere rimosso dai carrier PSTN fuori dalla rete Microsoft. Da ricordare il confine di responsabilità: la responsabilità Microsoft inizia quando la chiamata entra in Azure Communication Services, e se la chiamata torna al vostro Session Border Controller il contesto SIP e la qualità tornano vostri. Sull’outbound in bring your own telephony la doc è ancora più netta: Microsoft non ha SLA.
Sul lato postazione — pagina ospitata sotto /customer-service/ ma valida per entrambi i prodotti — le indicazioni sono concrete: connessione Ethernet cablata o wireless stabile, cuffie USB con microfono con cancellazione del rumore (gli altoparlanti del portatile introducono rumore di fondo), microfono vicino alla bocca con sensibilità regolata per togliere l’eco. I system requirements chiedono minimo 4 GB di RAM, microfono e altoparlanti, e una banda minima di 4 Mbps in upload e 8 in download, raccomandata 8 e 16. Vanno messi in allowlist gli URL e gli indirizzi IP indicati, e i cookie di terze parti non devono essere bloccati perché l’autenticazione li usa. Come diagnostica, la doc indica che dentro la stessa geo la latenza di rete sta di norma sotto i 150 ms e suggerisce di abilitare i telemetry insights per capire da dove arrivano i ritardi; se i representative (gli operatori umani) lamentano ritardo nell’entrare in chiamata dopo aver accettato la notifica, esiste la Desktop companion application.
Best practice per lo sviluppo delle capacità AI
La guida Copilot Studio parte da due decisioni, non da una: come viene controllata la conversazione (orchestrazione Classic, Hybrid o Generative) e come viene gestito il parlato end-to-end (speech mode Basic o Streaming). La formulazione della doc è secca: “Conversation orchestration and speech mode shape cost, latency, flexibility, compliance, and operational complexity”. Sono quindi scelte di architettura, non impostazioni di dettaglio, e vanno riviste man mano che l’implementazione matura. Sui prompt la raccomandazione è pianificare system prompt strutturati in JSON per rendere il ragionamento più prevedibile e ridurre la latenza, e trattare la scelta del modello come una decisione operativa che sposta costo ed esperienza utente.
Il transparency note sui real-time agent aggiunge le pratiche che fanno la differenza in produzione: progettare i fallimenti e i fallback (una tool call può fallire o andare in timeout), tenere semplici i messaggi sensibili alla latenza preferendo contenuto statico nel saluto iniziale, usare topic e logica guidata da tool dove serve determinismo invece di affidarsi alle sole risposte generative, validare in condizioni reali (telefonia, accenti, rumore di fondo, qualità di linea) e tarare deliberatamente la soglia di escalation. Due limiti vanno conosciuti a memoria: la configurazione del tipo di voce è one-time, e tornare a Classic richiede di creare un nuovo agente; e le istruzioni di sistema da sole possono non vincolare il comportamento, per cui commitment, azioni finanziarie e passaggi compliance-sensitive vanno protetti con controlli deterministici e revisione umana, non con un prompt. L’adozione si governa dal Agent hub, dove il rollout manager crea piani di rilascio graduali per gli agenti autonomi (fra cui Customer Knowledge Management agent e Quality Evaluation agent), con possibilità di modificarli, disattivarli o schedularli.
Valutare il costo totale di proprietà
Niente cifre: quello che l’esame verifica è se sai da quali voci è composto il costo e quali scelte lo spostano. Il canale voce è costruito su Azure Communication Services con modello pay-as-you-go che varia per paese, e la fatturazione è per minuto e per partecipante. Questo è il punto che confonde di più: non si paga “la chiamata”, si pagano le gambe della chiamata. In un singolo caso reale coesistono la gamba PSTN inbound del cliente, la gamba VOIP verso il representative, la gamba VOIP verso il bot Copilot Studio dell’IVR, la gamba del supervisor che entra a monitorare o in consultazione (addebitata solo mentre è dentro) e la registrazione, con il suo costo al minuto. La chiamata continua a essere addebitata anche mentre è in hold. Con direct routing si aggiungono le tariffe del vostro carrier a contratto oltre alla gamba SIP verso Azure Communication Services. Le gambe Teams sono coperte dalla licenza Teams, più gli eventuali addebiti Teams. Azure Communication Services non addebita il traffico in uscita. Un dettaglio che vale un’intera domanda: la chiamata VOIP verso il bot Copilot Studio non rientra nei minuti di intelligent voice bot inclusi nella licenza Voice Channel Add-in.
La seconda voce è l’AI. Le capacità Copilot e gli agenti selezionati usano consumption-based billing con i Copilot Credits, e l’unità di misura sono i messages, il cui numero per evento dipende dalla complessità dell’evento. Esistono due modelli, prepaid capacity tramite message pack e pay-as-you-go collegato a una sottoscrizione Azure; la capacità prepagata viene consumata per prima. La conseguenza operativa è dura e va ricordata: quando la quota si esaurisce, la capacità AI diventa non disponibile finché non se ne aggiunge altra. Alcune funzionalità, come la conversation orchestration in preview, richiedono esplicitamente il piano pay-as-you-go.
Da qui si legge quali decisioni di architettura muovono davvero il TCO: quanta parte del traffico viene contenuta in self-service invece di arrivare a un representative, quanto aggressivamente si registra e si monitora, se si porta la propria telefonia o si comprano numeri Microsoft, quale orchestrazione e quale speech mode si sceglie, in quale region si atterra, e quanti ambienti si è disposti a mantenere in parità per un ALM pulito. Sono tutte scelte che si fanno una volta e si pagano per anni.