Analizzare backlog e feedback degli utenti

Il feedback è un segnale di portafoglio, non un ticket

Un architetto non legge il feedback per rispondere all’utente. Lo legge per decidere una cosa sola: se un caso d’uso va esteso, corretto o ritirato. È questa la decisione che il blueprint chiede di saper prendere, e cambia completamente il modo in cui la raccolta va progettata a monte.

La documentazione del Center of Excellence parte da un’affermazione forte: gli agenti sono prodotti, non progetti. Un progetto ha una data di fine e un team che si scioglie; un prodotto ha un owner che resta, ne segue le prestazioni e lo migliora. Il ciclo di vita che ne deriva ha sette stadi con owner e criterio di uscita espliciti — Intake, Triage, Build, Deploy, Monitor, Improve, Retire — e il backlog è l’oggetto che collega Monitor e Improve a Intake. Il Cloud Adoption Framework per gli agenti è ancora più diretto nella sezione sui cicli di miglioramento continuo: mantenere un backlog prioritizzato di query irrisolte e richieste di funzionalità, per orientare lo sviluppo verso ciò che blocca davvero la creazione di valore.

Scenario tipico d’esame. Un agente Microsoft Copilot Studio per l’HR interno è in produzione da quattro mesi; il 30% delle conversazioni finisce in escalation verso una persona. Il vincolo: una sola finestra di rilascio a trimestre e nessun budget aggiuntivo. La proposta corretta non è “miglioriamo le istruzioni”: prima bisogna sapere se quel 30% sono domande che l’agente non è mai stato progettato per gestire. Nel primo caso è un problema di ambito e va nel backlog come estensione; nel secondo è un difetto e va corretto; se le due categorie insieme non giustificano il costo, l’opzione onesta è il ritiro.

Dove arrivano davvero i segnali, e dove non arrivano

Qui sta la trappola più costosa. Nelle app di Dynamics 365 finance and operations la funzionalità Enhanced user feedback for Copilot and related experiences mostra i pulsanti thumbs-up e thumbs-down e raccoglie anche un commento scritto. Sembra il canale ideale per il backlog: non lo è. La documentazione precisa che il feedback viene raccolto tramite l’in-product feedback system comune ai prodotti Microsoft, e che gli amministratori lo rileggono nel Microsoft 365 admin center, sotto Health > Product feedback. È feedback verso Microsoft, non un flusso che alimenta il vostro backlog di prodotto.

Va aggiunto un secondo vincolo architetturale: quella funzionalità è governata su tre livelli — l’impostazione Copilot feedback nei tenant settings del Power Platform admin center, la colonna Allow users to provide feedback to improve Copilot experiences sulla tabella Organization in Dataverse, e la voce in Feature management nell’ambiente finance and operations. Se è disattivata a un livello superiore non può essere attivata a uno inferiore. “Non riceviamo feedback” può quindi essere un problema di catena di governance, non di adozione: prima di riprogettare l’esperienza, verificate i tre interruttori.

I segnali che alimentano davvero il vostro backlog stanno altrove. In Copilot Studio la pagina Activity registra le attività in tempo reale e offre transcript e activity map, con filtri per Failed, Blocked, In progress, Waiting for user e Completed: è il posto dove il triage inizia. Due vincoli da conoscere: la funzionalità richiede la generative orchestration, e vedete solo le vostre interazioni finché l’amministratore non abilita la condivisione dei transcript di attività con altri utenti. Su scala, l’architettura di riferimento pubblicata usa la tabella ConversationTranscript in Dataverse come sorgente, un cloud flow di Power Automate che passa i transcript ad AI Builder per sentiment, frasi chiave, indicatori di escalation e riepiloghi, il salvataggio strutturato in Dataverse e la visualizzazione in Power BI.

Per gli agenti in SharePoint il quadro è diverso ancora: le File statistics di un file .agent danno views e unique viewers, Site usage elenca i contenuti più popolari, e l’audit log di Microsoft Purview registra chi ha interagito, dove e quando. Sono segnali di adozione e di audit, non di qualità. Scambiarli per misure di soddisfazione è l’errore classico.

Difetto di qualità o aspettativa sbagliata

Il CoE elenca quattro cause di deriva che spiegano quasi tutte le lamentele: la conoscenza invecchia, i documenti sorgente cambiano fuori dalla vista dell’agente, i pattern d’uso si spostano verso domande mai previste, le integrazioni si rompono. Solo le prime due e la quarta sono difetti. La terza è domanda nuova: appartiene all’ambito, non alla qualità, e la risposta architetturale è una decisione di roadmap, non una correzione.

È qui che l’esame verifica la separazione fra tre pratiche che i candidati fondono: evaluation, monitoring e testing. In Microsoft Foundry l’osservabilità è descritta con tre capacità distinte — evaluation, monitoring e tracing — e in post-produzione prevede continuous evaluation su traffico campionato, scheduled evaluation contro dataset di test per rilevare la deriva, e alert di Azure Monitor. Il monitoring vi dice che qualcosa è cambiato; l’evaluation vi dice se l’agente fa ancora ciò per cui è stato progettato; il testing conferma una singola correzione. Una segnalazione utente non è un difetto finché non è riproducibile: la si triaga, la si trasforma in test case e la si lascia nel regression set perché resti risolta. La documentazione sull’evaluation degli agenti di Microsoft 365 Copilot aggiunge un limite che vale come criterio di progetto: l’evaluation non sostituisce la user research, la revisione di responsible AI, la content moderation né il security testing.

Ultima confusione da evitare: non si risponde a un problema di feedback cambiando modello. Un segnale di produzione su qualità, latenza o consumo è un motivo legittimo per riesaminare il modello, ma il cambio è una migrazione con evaluation, approvazione, deploy e monitoraggio successivo — e l’errore più comune, dice la guida, è lo scarto di use category: spostare un agente FAQ ad alto volume su un modello deep migliora poco la qualità e peggiora molto latenza e consumo.

Far rientrare il segnale nella pianificazione

Il backlog serve solo se ha una cadenza. Il CAF raccomanda audit periodici del parco agenti — con revisioni trimestrali per ritirare quelli che non producono più valore — e di validare l’espansione per valore dimostrato, non per prontezza tecnica: si parte da unità di business o casi ad alto impatto, si misura l’impatto reale, si raccoglie feedback qualitativo e solo dopo si allarga. Vale la pena ricordare la formula del CoE, perché nelle domande a scenario l’opzione “ritirare” è spesso quella corretta e quasi mai quella scelta: “Retirement is a healthy outcome, not a failure.”

Perché il triage sia difendibile serve infine una baseline. Il CAF chiede di definire una AI measurement baseline con KPI legati ai principi di responsible AI e mappati sui singoli carichi. Senza baseline, il feedback resta aneddotica; con la baseline, diventa la sola fonte che dica se la soluzione serve davvero a qualcosa.