Copilot Studio e Power Automate: agenti e workflow

Copilot Studio e Power Automate possono collegare una richiesta in linguaggio naturale a un processo operativo. L’agente aiuta a interpretare ciò che serve; il workflow organizza dati, condizioni, approvazioni e azioni. La progettazione migliore mantiene riconoscibile il momento in cui si passa dalla conversazione a un’operazione sui sistemi.

Per una PMI il caso utile può essere molto concreto: raccogliere una richiesta di sconto, verificare i dati essenziali e preparare la decisione del responsabile. L’opportunità è ridurre passaggi ripetitivi e informazioni mancanti. Non occorre affidare all’agente l’intera negoziazione per rendere il processo più semplice.

In questa guida usiamo una richiesta di sconto interamente ipotetica, senza risultati cliente o prezzi di progetto inventati. Le funzioni Microsoft sono verificate su fonti ufficiali al 10 ottobre 2026; il tenant reale deve confermare disponibilità e licenze del percorso scelto.

La chat raccoglie il bisogno, il flusso esegue il percorso

Un commerciale potrebbe scrivere «Mi serve il 12% per questa offerta». La frase non contiene necessariamente cliente, offerta, durata o motivazione. L’agente può aiutare a raccogliere questi elementi prima di chiamare uno strumento. Il flusso deve invece ricevere un input sufficientemente definito per eseguire i controlli previsti.

Microsoft descrive gli agent flow dello standard harness come sequenze basate su regole, con condizioni, connettori e passaggi di intervento umano. Sono una capacità specifica di Studio; un cloud flow Power Automate rimane un oggetto distinto finché non viene convertito. Fonte: agent flows overview.

Una regola deterministica può controllare che una percentuale sia numerica e appartenga all’intervallo accettato. Il fatto che la regola sia deterministica non rende vero un dato di partenza sbagliato. Per questo è utile distinguere controlli di formato, verifica della fonte e autorizzazione a procedere.

La guida a Copilot Studio e agenti aziendali aiuta a definire il mandato. Qui approfondiamo il percorso esecutivo: quali dati entrano, quali passaggi avvengono e come il risultato viene restituito alla persona che ha iniziato la richiesta.

Disegnare la pratica prima di scegliere le azioni

Nell’esempio ipotetico, la pratica contiene identificativo offerta, cliente, valore di riferimento, percentuale richiesta, motivo e responsabile. Il risultato desiderato è una richiesta pronta per decisione. Non è ancora una modifica dell’offerta inviata al cliente: la distinzione permette di avviare un pilota controllabile.

Definisci gli stati comprensibili al team: bozza, dati da completare, in approvazione, approvata, respinta e problema tecnico da risolvere. Gli stati descrivono il lavoro; i messaggi della chat devono rifletterli. Una risposta come «fatto» è insufficiente se il responsabile non ha ancora deciso.

La tabella è uno schema progettuale, non una lista di azioni garantite per ogni connettore. La guida all’automazione dei processi aziendali aiuta a individuare quali passaggi siano ripetitivi e quali richiedano davvero una decisione.

Definire input e output che il sistema possa controllare

Il numero dell’offerta dovrebbe essere un identificatore stabile, non una descrizione come «quella di ieri per Rossi». Se l’utente non lo conosce, l’agente può proporre una ricerca e mostrare candidati. Prima della scrittura va risolta l’ambiguità: una somiglianza di nome non è una conferma dell’identità del record.

Il contratto di input deve indicare quali campi sono obbligatori, quali valori sono ammessi e dove possono essere recuperati. Una nota libera può spiegare il motivo dello sconto; non dovrebbe sostituire il campo percentuale che il workflow deve validare. I dati strutturati rendono più chiara anche la successiva manutenzione.

Il contratto di output dovrebbe distinguere successo, richiesta incompleta ed errore. Nel successo comprende almeno identificativo pratica e stato effettivo. Nella richiesta incompleta indica esattamente cosa manca. Nell’errore evita di dichiarare che nessuna operazione sia avvenuta se il sistema non consente di verificarlo.

Per migliorare le richieste iniziali, usa gli esempi di prompt Copilot per l’ufficio. Il prompt può guidare la raccolta; validazione e autorizzazione appartengono al percorso tecnico. Questa separazione permette di cambiare il tono della conversazione senza indebolire le regole della pratica.

Mettere l’approvazione sul punto in cui cambia l’effetto

Un’approvazione utile mostra ciò che la persona sta autorizzando. Nell’esempio: cliente, numero offerta, percentuale richiesta, motivazione e valore di riferimento recuperato. Il responsabile deve riconoscere l’oggetto della decisione, senza rileggere tutta la conversazione per ricostruirlo.

Se il richiedente modifica la percentuale dopo l’approvazione, la decisione precedente non dovrebbe essere trattata come valida per il nuovo valore. Questa regola va progettata: collegare approvazione e versione della richiesta riduce ambiguità. Non si può dedurre la versione corretta dal semplice fatto che la chat contenga un «sì».

Schema concettuale: l’approvazione riguarda dati e azione proposti, mentre l’esito conclusivo arriva dalla verifica sul sistema. La figura non rappresenta una schermata Microsoft né un workflow già installato.

Per il passaggio dalla posta al processo, leggi Copilot in Outlook e email aziendali. Una bozza di risposta, l’invio di un messaggio e la registrazione nel gestionale sono operazioni distinte: l’autorizzazione deve riguardare quella che il progetto intende realmente eseguire.

Gestire esiti incerti prima di aggiungere tentativi automatici

Un errore di rete dopo la scrittura è diverso da un input respinto prima della scrittura. Nel primo caso l’operazione potrebbe essere avvenuta anche se la risposta non è arrivata. Ripeterla immediatamente può creare un duplicato. Il progetto dovrebbe prevedere un controllo dello stato attraverso un identificatore riconoscibile.

La stessa attenzione serve quando una sequenza riesce solo in parte. Se una richiesta viene creata ma l’aggiornamento del riepilogo fallisce, il team deve sapere che la pratica esiste. Un messaggio generico di errore potrebbe spingere l’operatore a ricrearla manualmente, aumentando proprio il lavoro che l’automazione dovrebbe ridurre.

Stabilisci quali errori possono essere ritentati e quali richiedono intervento. Una indisponibilità temporanea può avere un comportamento diverso da un permesso mancante. Un tentativo automatico dovrebbe avere un limite e un esito osservabile, così una pratica non resta nascosta in una ripetizione indefinita.

Le integrazioni Copilot con CRM ed ERP sono il punto in cui verificare identificativi, operazioni disponibili e permessi. La robustezza del flusso dipende anche dalle risposte dell’API o del connettore, non soltanto dalle istruzioni linguistiche dell’agente.

Verificare l’identità usata da ogni collegamento

L’operatore che parla con l’agente e l’identità della connessione al sistema possono essere differenti. Prima del pilota, chiarisci quale identità legge l’offerta e quale può registrare la richiesta. La scelta deve corrispondere al pubblico e alla delega prevista, con il responsabile del tenant.

Se una connessione ha permessi ampi, il workflow deve evitare di trasformarli in operazioni disponibili a chiunque inizi una chat. Il riepilogo delle autorizzazioni dovrebbe mostrare destinatari, dati leggibili e azioni ammesse. Un’istruzione che invita alla prudenza non sostituisce un confine di accesso effettivo.

Anche la prova deve includere utenti con diritti diversi. Una richiesta che funziona per l’amministratore potrebbe non funzionare per il commerciale; la risposta corretta in quel caso non è fingere di aver concluso. Il test dovrebbe verificare che il team riceva un messaggio chiaro e una procedura alternativa.

La guida a privacy e dati aziendali Microsoft Copilot aiuta a preparare questa valutazione. Il fine pratico è avere un percorso utilizzabile dal destinatario reale, evitando di basare il pilota sulle autorizzazioni eccezionali di chi lo ha costruito.

Conversione da Power Automate: preparare la scelta concreta

La conversione di un cloud flow Power Automate ad agent flow cambia il percorso di fatturazione ed è a senso unico nella documentazione Microsoft. Richiede un flow in una solution e capacità Studio nell’ambiente. È una scelta da valutare su una copia o prova prima della produzione. Fonte: conversione e gestione degli agent flow.

La domanda utile è: che cosa migliora con la conversione? Se il processo esistente funziona e l’agente deve soltanto raccogliere input, non è sufficiente cambiare etichetta per ottenere valore. Confronta gestione, distribuzione, costi e comportamento degli strumenti sulla soluzione concreta.

Prima della decisione conserva la descrizione del percorso corrente, delle dipendenze e delle condizioni economiche. Prepara l’alternativa in un ambiente di prova, evitando di scoprire dopo il cambio che un passaggio richiede una configurazione diversa. La documentazione dovrebbe consentire a un’altra persona di ricostruire il funzionamento.

Per il budget, usa prezzi e crediti Copilot Studio. Un cloud flow ordinario non diventa automaticamente incluso perché il progetto usa Copilot. Nel percorso standard, l’inclusione dei flow riguarda il trigger When an agent calls the flow e l’utente autenticato con licenza; altri trigger hanno consumo. Fonte: condizioni di billing.

Preparare una prova che segua tutto il ciclo della pratica

Una prova completa inizia prima della chiamata al flow e termina quando l’operatore conosce l’esito. Misura raccolta delle informazioni, approvazione, registrazione e gestione delle eccezioni. Limitarsi al tempo della chiamata tecnica può nascondere attese e correzioni che dominano il processo reale.

Nel caso ipotetico prepara offerte sintetiche: una ordinaria, una senza cliente valido, due con nomi simili, una già approvata e una modificata dopo approvazione. Aggiungi un sistema non disponibile e una risposta senza conferma conclusiva. Il risultato atteso deve essere scritto prima, non scelto per far sembrare riuscita la demo.

Apri una scheda di prova per la richiesta di sconto

Definisci richiesta iniziale, record di riferimento, identità dell’utente e stato atteso. Verifica che dati mancanti e candidati ambigui producano una domanda mirata prima di procedere.

Controlla il riepilogo mostrato al responsabile, la versione approvata e l’azione ammessa. Modifica un dato dopo l’approvazione per verificare che il progetto riconosca la nuova richiesta.

Simula ripetizione, indisponibilità del sistema ed esito parziale. Registra identificativo pratica, operazioni confermate, passaggi ancora da fare e tempo dell’intervento manuale. Il test serve a valutare il processo, non soltanto la fluidità della risposta.

Il pilota Copilot per PMI permette di collegare queste misure a qualità e valore. Un passaggio manuale in più può essere accettabile se evita errori onerosi; deve però comparire nel tempo e nel costo complessivi, invece di restare fuori dal confronto.

Affrontare l’attesa dell’approvazione come parte del processo

Una pratica può restare ferma anche quando tutte le integrazioni funzionano. Il responsabile è assente, manca una motivazione oppure il commerciale modifica l’offerta nel frattempo. Prima del pilota, chiarisci quanto dura una richiesta valida e quale comportamento deve seguire il team quando la decisione non arriva.

Nell’esempio, una scadenza della pratica può significare che la richiesta torna al richiedente per verifica. Non significa approvazione automatica dello sconto. Questa scelta appartiene all’azienda e va descritta nel progetto: un timeout tecnico non dovrebbe essere confuso con un consenso commerciale.

Anche il passaggio a un responsabile sostitutivo deve mantenere riconoscibile la versione da decidere. Il nuovo referente dovrebbe vedere gli stessi dati essenziali e sapere se il precedente ha già risposto. La registrazione della decisione serve al lavoro quotidiano, evitando che due persone interpretino diversamente lo stato della stessa pratica.

Per le richieste sospese, prepara un riepilogo breve: cosa è stato verificato, cosa manca e chi deve intervenire. Questo evita che ogni operatore ripeta l’intera raccolta. Quando il caso torna alla procedura manuale, conserva l’identificativo già assegnato e la distinzione fra azioni concluse e azioni soltanto proposte.

Durante la prova misura anche l’attesa, separandola dal tempo lavorato. Un workflow può ridurre minuti di compilazione senza ridurre i giorni necessari alla decisione. La distinzione aiuta a capire se il prossimo miglioramento debba riguardare l’agente, la regola di approvazione o l’organizzazione del reparto.

Rendere l’automazione gestibile dal team

Alla consegna, il team dovrebbe sapere chi approva, chi interviene su una pratica ferma e chi mantiene le connessioni. In una PMI questi ruoli possono essere concentrati, ma la sostituzione del referente durante un’assenza va preparata. Un processo operativo non può dipendere dalla presenza costante di chi ha costruito la demo.

Documenta inoltre le modifiche che richiedono un nuovo test: campo rinominato nel gestionale, nuova politica di sconto, cambiamento del destinatario dell’approvazione o ampliamento delle azioni. Questo evita che un aggiornamento apparentemente piccolo renda incoerenti istruzioni, controlli e riepilogo.

Il collegamento fra agenti e workflow è utile quando rende più semplice il lavoro delle persone, non quando moltiplica strumenti. Per confrontare questa soluzione con alternative, la guida Make, Zapier e n8n offre un altro percorso; il criterio resta la compatibilità con processo, sistemi e gestione disponibili.

Giallo può aiutarti a definire una prima automazione con il servizio agenti AI su misura. Se devi scegliere quali pratiche meritano il pilota, parti da una consulenza AI: input, approvazione ed esito vengono progettati insieme, così la prova misura un lavoro concreto e utilizzabile.