Claude in Microsoft 365 e Teams: dal connettore allo smistamento del service desk IT

Claude in Microsoft 365 e Teams si usa in due modi. Il primo è il connettore Microsoft 365, che permette a ciascun utente di interrogare posta, file e chat dalla propria sessione di Claude. Il secondo è un assistente costruito dentro Teams, che fa da punto d'ingresso ai sistemi aziendali, per esempio smistando le richieste IT verso Zoho Desk.

Il connettore Microsoft 365 è l'integrazione ufficiale di Anthropic che collega Claude a SharePoint, OneDrive, Outlook e Teams tramite il Model Context Protocol. Il Model Context Protocol (MCP) è uno standard open source per collegare l'AI a strumenti e fonti di dati esterni. Il connettore serve la singola persona: legge ciò che lei può già vedere e agisce per suo conto.

Un assistente per il service desk serve invece un processo condiviso. Riceve le richieste di tutti i colleghi, le classifica e le consegna al sistema giusto. Le due soluzioni non si escludono, ma rispondono a esigenze diverse e hanno regole diverse.

Questa guida tratta entrambi i livelli. Spiega che cosa offre il connettore, che cosa deve impostare l'amministratore, dove il connettore si ferma e quando conviene costruire un assistente dedicato. Contiene anche un esempio pratico di richiesta IT, una tabella delle impostazioni e i passi concreti per partire.

Il connettore Microsoft 365 richiede un tenant Microsoft Entra legato a un piano Microsoft Business. Un tenant è l'istanza Microsoft 365 della Sua organizzazione, con i propri utenti e le proprie regole di accesso. Gli account personali, come gli indirizzi @outlook.com, @hotmail.com o @live.com, non possono collegarsi.

Sul lato Claude il requisito è minimo. Secondo la guida Set up the Microsoft 365 connector del centro assistenza di Claude, il connettore è disponibile su tutti i piani: Free, Pro, Max, Team ed Enterprise. Sul Microsoft Marketplace compare con prezzo di partenza gratuito.

Il passaggio che blocca più spesso è il consenso. In ogni tenant un Global Administrator di Microsoft Entra deve concedere una sola volta il consenso che autorizza l'integrazione. Finché questo non avviene, nessun utente può collegarsi. Nella configurazione manuale il processo aggiunge due service principal al tenant, cioè due identità applicative che l'amministratore vedrà nel proprio elenco.

Dopo il collegamento, la connessione ha una scadenza normale di 90 giorni. Alcuni criteri di accesso possono interromperla prima. Il codice AADSTS70043 indica che un criterio di frequenza di accesso ha bloccato la richiesta. Il codice AADSTS53003 indica invece un criterio di Conditional Access impostato per bloccare l'accesso. Conviene che l'amministratore conosca entrambi prima di aprire il connettore agli utenti.

Il connettore Microsoft 365 legge solo ciò che l'utente può già vedere. Usa permessi delegati: Claude agisce per conto di ciascun utente e non dispone di un accesso proprio più ampio. Inoltre consulta Microsoft 365 solo quando una domanda lo richiede e non esegue ricerche in background.

Il perimetro di lettura, secondo le pagine di Anthropic e la scheda sul Marketplace, comprende queste aree:

• Outlook: thread di posta, da riassumere e analizzare.
• SharePoint e OneDrive: file Word, Excel e PowerPoint, anche nei vecchi formati .doc, .xls e .ppt, oltre a PDF e testo semplice come .txt, .md e .csv.
• Teams: conversazioni in chat individuali e di gruppo.

Tre limiti di lettura vanno conosciuti prima di collegare gli utenti:

• La ricerca SharePoint copre l'intero tenant con i permessi dell'utente. Non si può restringere a siti specifici, perché Sites.Selected non è supportato.
• La ricerca nella posta esclude l'Online Archive, la casella separata chiamata anche In-Place Archive. I messaggi spostati lì da un criterio di conservazione non compaiono nei risultati.
• OneNote non è leggibile. I blocchi appaiono nei risultati, ma la lettura restituisce un errore di tipo MIME.

Il primo limite ha una conseguenza pratica. Se i permessi SharePoint sono troppo larghi, Claude trova documenti che l'utente poteva già aprire senza saperlo. Il connettore non crea il problema, ma lo rende visibile.

Il connettore Microsoft 365 è in sola lettura per impostazione predefinita. Claude può inviare, creare o aggiornare contenuti solo se l'amministratore abilita gli strumenti di scrittura. Gli strumenti di scrittura sono le funzioni con cui Claude agisce per conto dell'utente dentro Microsoft 365.

Una volta abilitati, questi strumenti permettono a Claude di:

• inviare email e gestire le bozze;
• creare, aggiornare ed eliminare eventi di calendario;
• aggiornare le impostazioni della casella di posta;
• creare e aggiornare file in OneDrive e SharePoint;
• inviare messaggi in chat e pubblicare nei canali di Teams.

Tre regole limitano la scrittura. Le email inviate da Claude contengono un'intestazione che le identifica come avviate da un agente. Scritture su file, eventi di calendario e messaggi Teams, invece, al momento non sono contrassegnati. Gli allegati non sono supportati: invio, inoltro e bozze con allegati vengono rifiutati.

La terza regola è decisiva per il service desk. L'invio di un messaggio in chat e la pubblicazione o risposta in un canale richiedono sempre la conferma dell'utente. L'amministratore non può impostarli come automatici. Con il connettore standard, quindi, Claude non risponde da solo ai colleghi in Teams. Per un assistente che deve rispondere a tutto il personale serve un'architettura diversa.

Il connettore standard non consente di cercare nei canali di Teams. La scheda sul Marketplace cita le discussioni di canale, ma una richiesta nel repository GitHub claude-ai-mcp di Anthropic, aperta nel giugno 2026, documenta il contrario. Lo strumento chat_message_search copre solo le chat individuali e di gruppo e non restituisce nulla dai canali.

La stessa richiesta elenca gli strumenti mancanti. Non esiste uno strumento per elencare i team, i canali o i messaggi di un canale. Un singolo messaggio di canale si legge solo se si conoscono già gli identificativi di team, canale e messaggio. La richiesta è stata chiusa come "not planned".

Il limite non dipende dai permessi. Secondo la richiesta, resta anche quando l'app Entra del connettore ha Channel.ReadBasic.All e ChannelMessage.Read.All con consenso amministrativo. Mancano gli strumenti che espongono quei dati, non le autorizzazioni.

La richiesta segnala anche un rischio di governance. ChannelMessage.Read.All come permesso applicativo vale per tutto il tenant e consente di leggere ogni messaggio di canale dell'organizzazione. L'alternativa proposta è il Resource-Specific Consent (RSC), un modello di consenso che limita l'accesso a team o canali specifici. Tra le soluzioni valutate c'è un server MCP su misura sull'endpoint Graph dei messaggi di canale. È fattibile, ma va costruito, protetto e mantenuto da ogni azienda.

Un assistente in Teams per il service desk è un agente che riceve le richieste dei colleghi nella chat che usano già e le trasforma in ticket ordinati. A differenza del connettore Microsoft 365, non lavora per un solo utente. Serve tutto il personale e scrive nel sistema di ticketing, per esempio Zoho Desk.

Questa architettura supera i due vincoli del connettore visti sopra. Non dipende dalla conferma manuale di ogni messaggio in Teams, perché risponde come servizio e non per conto di un utente. Non ha bisogno di cercare nei canali, perché riceve le richieste direttamente nella propria chat.

Il collegamento con Zoho Desk passa di solito da un server MCP. La documentazione MCP di Anthropic raccomanda i server HTTP per le connessioni remote e indica come deprecato il trasporto SSE. Avverte anche che i server che recuperano contenuti esterni espongono al rischio di prompt injection. Il prompt injection è un'istruzione nascosta nei dati che tenta di deviare il comportamento del modello.

Anthropic raccomanda inoltre che un solo team centrale configuri i server MCP, così tutti gli utenti lavorano con la stessa configurazione. Per un service desk il principio vale doppio: l'IT decide quali azioni l'assistente può compiere in Zoho Desk. Lo stesso schema, applicato a un'altra chat aziendale, è descritto nella guida su Claude in Slack per il supporto interno con Zoho Desk. La logica dei permessi è analoga a quella spiegata per collegare Claude a Zoho CRM con MCP.

Una richiesta IT tipica attraversa cinque passi, dal messaggio in Teams al ticket assegnato. Il flusso seguente è illustrativo e usa le impostazioni descritte nelle fonti.

1. Un'impiegata scrive nella chat Teams dell'assistente: "Da stamattina Outlook non sincronizza la posta sul portatile." Tutti i modelli Claude attuali supportano più lingue e l'uso di strumenti, quindi la richiesta in italiano non richiede traduzioni.
2. L'assistente classifica la richiesta: categoria posta elettronica, priorità in base all'impatto, reparto della richiedente.
3. Se mancano informazioni, l'assistente fa una domanda mirata, per esempio il nome del dispositivo.
4. L'assistente crea il ticket in Zoho Desk tramite il server MCP, con categoria e riepilogo già compilati, e lo assegna al gruppo di supporto previsto.
5. L'assistente risponde in chat con il riferimento del ticket. Il tecnico riceve la richiesta già smistata e completa.

Il passo delicato è il secondo. Se la classificazione sbaglia, il ticket arriva al gruppo sbagliato e rimbalza tra i tecnici. Per questo la metrica principale è lo smistamento corretto al primo tentativo, spesso chiamato first-time-right.

La scelta del modello incide sulla qualità della classificazione. Per chi non sa da dove partire, la panoramica dei modelli di Anthropic suggerisce Claude Opus 5.5 per la maggior parte dei carichi di lavoro. Le categorie e i gruppi di Zoho Desk, invece, vanno definiti prima: l'assistente non può smistare verso una struttura che non esiste.

Il caso Asset Services Group mostra che cosa si può misurare quando un assistente in Teams lavora in produzione. Svennis ha costruito per Asset Services Group (Message Direct) un service desk IT su Claude dentro Microsoft Teams, davanti a Zoho Desk. Il caso studio del service desk AI in Microsoft Teams riporta il 99,7% di smistamento corretto al primo tentativo e un guadagno di efficienza del 40%, citati dal responsabile tecnologico del cliente.

Le due cifre rispondono a domande diverse. Lo smistamento corretto al primo tentativo misura la qualità della classificazione: quante richieste arrivano subito al gruppo giusto. Il guadagno di efficienza misura l'effetto sul lavoro del team di supporto nel suo insieme.

Per un progetto simile conviene fissare entrambe le metriche prima del lancio. Serve un valore di partenza, misurato sul processo attuale, e un metodo di calcolo condiviso con il responsabile del service desk. Senza un riferimento iniziale, qualsiasi risultato resta un'impressione.

Il caso chiarisce anche la differenza con il connettore standard. Qui Claude non assiste un singolo utente nella sua sessione. Fa da punto d'ingresso unico per tutte le richieste IT e consegna a Zoho Desk ticket già classificati.

L'amministratore Microsoft 365 decide la maggior parte delle impostazioni del connettore, ma alcune non sono modificabili. La tabella riassume ciascuna impostazione, il suo valore di partenza e l'indicazione pratica.

Alcune impostazioni vanno lasciate intatte. I criteri di Conditional Access e le policy di conservazione esistenti non si allentano per far funzionare il connettore. Si verifica invece che l'intervallo IP di Anthropic sia gestito correttamente dai criteri già in vigore.

Lo stesso vale per posta e calendario. Gli strumenti di scrittura restano spenti finché non esiste un bisogno concreto, con un responsabile che ne controlla l'uso.

La scelta dipende da chi deve usare Claude e da dove deve scrivere. Esistono tre strade, con destinatari, ambienti e costi diversi. La tabella le confronta sui punti che le fonti documentano.

La seconda strada è meno nota. Un'analisi pubblicata su LinkedIn da Debbie Richards descrive la scelta tra modelli GPT e Claude dentro Microsoft 365 Copilot. Secondo l'autrice, la funzione va abilitata dall'amministratore del tenant. Se il selettore del modello non compare, consiglia di verificare con l'IT i permessi di trattamento dati per la propria regione.

I prezzi di Copilot provengono dal confronto tra Claude e Copilot pubblicato da Fabric. Per un service desk, però, il criterio decisivo non è il costo per utente. È la capacità di scrivere nel sistema di ticketing senza una conferma manuale per ogni messaggio.

Per un'azienda italiana il primo controllo riguarda il tipo di account Microsoft. Il connettore richiede un tenant Entra legato a un piano Business. Un piccolo ufficio che lavora con indirizzi @outlook.com o @hotmail.com non può collegarlo finché non passa a un account di lavoro.

La lingua non è un ostacolo. Tutti i modelli Claude attuali supportano più lingue, quindi richieste, ticket e risposte possono restare in italiano. Questo conta per un service desk interno, dove i colleghi scrivono come parlano.

La collocazione dei dati merita una verifica con l'IT. Secondo la scheda sul Marketplace, la versione di Claude in Microsoft Foundry ospitata su Azure è disponibile in generale e mantiene i dati in Azure. La versione ospitata da Anthropic esegue l'elaborazione su infrastruttura gestita da Anthropic. La scelta tra le due va fatta con chi gestisce la conformità in azienda.

La trasparenza verso i colleghi va gestita in modo esplicito. Le email inviate da Claude portano un'intestazione che le identifica come avviate da un agente, ma i messaggi Teams e le scritture su file no. Una regola interna chiara evita malintesi su chi ha scritto cosa. Per una realtà di piccole dimensioni può aiutare anche la guida sui plugin Claude per una piccola impresa e i sistemi da collegare.

Il percorso più sicuro parte dal connettore in sola lettura e arriva all'assistente solo quando il processo lo richiede. Questi sono i passi, nell'ordine consigliato:

1. Verifichi che tutti gli utenti interessati abbiano un account di lavoro su un tenant Entra con piano Business.
2. Chieda al Global Administrator di rivedere i permessi SharePoint, poi di concedere il consenso per il tenant.
3. Controlli che i criteri di Conditional Access gestiscano l'intervallo IP 160.79.104.0/21 senza bloccarlo.
4. Avvii un gruppo pilota con il connettore in sola lettura e raccolga i casi in cui serve davvero scrivere.
5. Se il service desk riceve molte richieste in Teams, mappi categorie e gruppi di supporto in Zoho Desk prima di progettare un assistente.
6. Fissi le metriche prima del lancio: smistamento corretto al primo tentativo ed efficienza del team.

Per preparare istruzioni e materiali condivisi del gruppo pilota, può essere utile la guida su Projects e Skills di Claude per un piccolo team. Se l'obiettivo è lo smistamento delle richieste IT, il riferimento più vicino su questo sito resta il caso studio di Asset Services Group in Microsoft Teams, che descrive un assistente di questo tipo in produzione.