--- title: Report – Provider description: "## A cosa serve questa sezione La sezione **Report provider** permette al Provider di monitorare l’utilizzo operativo della piattaforma all’interno dei propri tenant. Questa reportistica non è pensata per valutare come sono andati i tentativi formativi dei singoli Player, né…" url: "https://www.learningbydoingxr.com/it/help/report-provider/" updated: "2026-06-23" category: Provider --- # Report – Provider ## A cosa serve questa sezione La sezione **Report provider** permette al Provider di monitorare l’utilizzo operativo della piattaforma all’interno dei propri tenant. Questa reportistica non è pensata per valutare come sono andati i tentativi formativi dei singoli Player, né per analizzare readiness, Skill Comunicative, Griglie di Osservazione o qualità della performance conversazionale. Il suo obiettivo è diverso: fornire al Provider una vista di governance su utilizzo, consumi, capacità e continuità del servizio. Da questa sezione il Provider può controllare: - quante simulazioni sono state erogate; - quanti minuti sono stati consumati; - quali tenant stanno usando la piattaforma; - quante sessioni sono state avviate; - quante sessioni sono state completate, interrotte o hanno avuto errori; - eventuali code di accesso alle simulazioni; - eventuali interruzioni per protezione Player in forma aggregata; - utilizzo degli slot di connessione simultanea; - possibili alert operativi; - azioni consigliate per migliorare capacità, continuità e utilizzo. --- ## Differenza tra Report Provider e Report formativi Il **Report Provider** è una reportistica di utilizzo e governance. Serve a rispondere a domande come: - Quante simulazioni sono state usate? - Quanti minuti sono stati consumati? - Ci sono stati problemi di capacità? - I Player sono rimasti in coda? - Quante sessioni sono state completate? - Ci sono state interruzioni per protezione? - Quali tenant stanno consumando più risorse? - Serve aumentare slot, minuti o capacità? Non serve invece a rispondere a domande come: - Il Player ha dimostrato le Skill Comunicative previste? - Qual è la readiness del Player? - Quali momenti chiave sono emersi nella conversazione? - Quali aree comunicative deve migliorare il Player? Queste informazioni appartengono alla reportistica formativa del Tenant Admin o alla reportistica personale del Player, secondo le policy privacy configurate. --- ## Filtri ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-report1-it-1024x230.png) La sezione **Filtri** permette di restringere la vista dei dati. I filtri possono includere: - tipo di run; - tenant; - data di inizio; - data di fine. --- ## Tipo di run Il filtro sul tipo di run permette di distinguere tra diverse tipologie di sessione. Esempi: - tutte le run; - solo sessioni ufficiali; - solo internal test; - sessioni runtime dei tenant. Questo filtro è utile perché i test interni del Provider e le sessioni ufficiali dei Player possono avere finalità diverse, ma entrambe possono consumare risorse. --- ## Tenant Il filtro tenant permette di visualizzare i dati relativi a: - tutti i tenant; - un tenant specifico. È utile quando il Provider vuole capire il consumo o l’andamento operativo di un singolo cliente, reparto, dipartimento o gruppo. --- ## Intervallo date I campi data permettono di selezionare un periodo specifico di analisi. Il Provider può usare questo filtro per analizzare: - una giornata; - una settimana; - un mese; - un periodo di erogazione; - un evento formativo; - una finestra di test. --- ## Vista generale delle sessioni ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-report2-it-1024x768.png) La pagina può mostrare un riepilogo generale delle sessioni registrate. I dati principali possono includere: - numero sessioni; - minuti runtime; - ultima attività; - elenco delle simulazioni eseguite; - tenant associato; - utente o attore collegato; - minuti consumati; - stato della sessione. --- ### Numero sessioni Indica quante sessioni sono state registrate nel periodo selezionato. Esempio: **144** Questo valore aiuta a capire il volume complessivo di utilizzo della piattaforma. --- ### Minuti runtime Indica il totale dei minuti consumati dalle sessioni runtime nel periodo selezionato. Esempio: **16716.0** Questo dato è importante per monitorare il consumo rispetto ai minuti inclusi nel piano Provider o rispetto alle allocazioni dei tenant. --- ### Ultima attività Mostra la data e l’ora dell’ultima sessione registrata. È utile per capire se la piattaforma è stata usata di recente. --- ### Elenco sessioni La tabella delle sessioni mostra il dettaglio operativo delle sessioni registrate. Le colonne possono includere: - simulazione; - tenant; - player o attore; - minuti runtime; - stato. --- ### Simulazione Mostra il nome della simulazione o della sessione. Può includere anche sessioni di tipo internal test. Esempio: **Internal test — Breaking Bad News — SPIKES Protocol — Cancer Progression** Le sessioni internal test sono prove avviate dal Provider per verificare il comportamento della simulazione. --- ### Tenant Mostra il tenant associato alla sessione. Se la sessione è un internal test del Provider, il tenant può risultare non disponibile o non applicabile. --- ### Player o attore Mostra l’utente o l’attore collegato alla sessione, quando disponibile. Nel caso degli internal test può comparire il Provider o un utente amministrativo. --- ### Minuti runtime Indica quanti minuti sono stati consumati da quella sessione. Questo valore contribuisce al consumo complessivo dei minuti. --- ### Stato Mostra lo stato della sessione. Esempi: - **active** - **archived** - **deprecated** - **Solo internal test** - **Solo ufficiali** Lo stato aiuta a distinguere sessioni operative, test interni, sessioni archiviate o runtime non più correnti. --- ## Dashboard runtime Provider ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-report3-it-1024x584.png) Quando viene analizzata una specifica runtime, la piattaforma può mostrare una **Dashboard runtime Provider**. Questa dashboard offre una vista di utilizzo su una simulazione specifica, collegata a un tenant. Esempi di dati mostrati: - minuti erogati; - utenti attivi; - tentativi totali; - accessi in coda. --- ### Minuti erogati Indica quanti minuti sono stati consumati da quella runtime. Esempio: **7** --- ### Utenti attivi Indica quanti utenti hanno usato o stanno usando quella runtime nel periodo considerato. Esempio: **2** --- ### Tentativi totali Indica quanti tentativi sono stati registrati per quella runtime. Esempio: **5** --- ### Accessi in coda Indica quanti accessi sono finiti in coda perché la capacità disponibile non era immediatamente sufficiente. Esempio: **0** Se questo valore cresce, può indicare che la capacità simultanea disponibile non è adeguata ai picchi di utilizzo. --- ## Consumo minuti La sezione **Consumo minuti** mostra come la runtime contribuisce al consumo del tenant. Può includere: - minuti erogati; - minuti tenant usati; - incidenza runtime sul tenant; - minuti tenant allocati; - minuti tenant residui; - durata media tentativo. --- ### Minuti erogati Mostra i minuti consumati dalla runtime specifica. --- ### Minuti tenant usati Mostra quanti minuti sono stati consumati complessivamente dal tenant nel periodo o contesto selezionato. --- ### Incidenza runtime sul tenant Indica quanto pesa quella runtime sul consumo complessivo del tenant. Esempio: **2%** Questo dato aiuta il Provider a capire se una specifica simulazione sta consumando una quota rilevante delle risorse assegnate al tenant. --- ### Minuti tenant allocati Mostra i minuti assegnati al tenant. --- ### Minuti tenant residui Mostra quanti minuti restano disponibili al tenant. --- ### Durata media tentativo Mostra la durata media dei tentativi su quella runtime. Questo dato è utile per stimare il consumo futuro se la runtime viene usata da molti Player. --- ## Tentativi ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-report4-it-1024x562.png) La sezione **Tentativi** mostra lo stato operativo dei tentativi registrati. Può includere: - tentativi totali; - completati; - interrotti; - errori tecnici; - completati dopo retry; - in corso; - sconosciuti; - completamento sui tentativi conclusi; - completamento su tutti i tentativi. --- ### Tentativi totali Indica il numero complessivo di tentativi registrati. --- ### Completati Indica quanti tentativi sono arrivati a completamento. --- ### Interrotti Indica quanti tentativi sono stati interrotti. Le interruzioni possono dipendere da diverse cause, come uscita anticipata, protezione Player o altri eventi. --- ### Errori tecnici Indica quanti tentativi hanno avuto errori tecnici. Questo dato è importante per monitorare l’affidabilità operativa della piattaforma. --- ### Completati dopo retry Indica quanti tentativi sono stati completati dopo un nuovo tentativo o una ripresa. --- ### In corso Indica quanti tentativi risultano ancora in corso. --- ### Sconosciuti Indica tentativi per cui lo stato non è stato classificato in modo completo. --- ### Tasso di completamento La piattaforma può mostrare due valori: - completamento sui tentativi conclusi; - completamento su tutti i tentativi. Il primo considera solo i tentativi che hanno uno stato finale. Il secondo include anche tentativi in corso o sconosciuti. Questa distinzione aiuta a interpretare correttamente il tasso di completamento. --- ## Interruzioni per protezione ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-report5-it-1024x252.png) La sezione **Interruzioni per protezione** mostra informazioni aggregate sulle sessioni interrotte automaticamente per protezione del Player. Può includere: - interruzioni per protezione; - tasso interruzioni; - rilevazioni distress; - tensione massima/media. Esempio: - **Interruzioni per protezione:** 1 - **Tasso interruzioni:** 20% - **Rilevazioni distress:** 1 - **Tensione max/media:** 0.84 / 0.84 Questa sezione è **privacy-safe**: non mostra nomi dei Player, testo raw o evidenze raw. Serve al Provider per capire se una runtime sta generando un livello di tensione eccessivo o se potrebbe richiedere revisione progettuale. --- ## Capacità e coda ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-report6-it-1024x714.png) La sezione **Capacità e coda** mostra come la runtime ha utilizzato la capacità disponibile e se ci sono state attese. Può includere: - richieste accesso totali; - accessi concessi subito; - accessi in coda; - attesa media; - attesa massima; - qualità dato. --- ### Richieste accesso totali Indica quante richieste di accesso sono state registrate per quella runtime. --- ### Accessi concessi subito Indica quante richieste sono state soddisfatte immediatamente, senza coda. --- ### Accessi in coda Indica quante richieste hanno dovuto attendere prima di entrare in simulazione. Se il valore è alto, può indicare una saturazione degli slot disponibili. --- ### Attesa media Mostra il tempo medio di attesa, in secondi. --- ### Attesa massima Mostra il tempo massimo di attesa registrato. --- ### Qualità dato Indica la qualità o il livello di correlazione del dato. Esempio: **Correlato alla runtime** Questo significa che le metriche di coda sono direttamente collegate alla runtime selezionata. --- ## Alert e azioni consigliate La sezione **Alert e azioni** mostra eventuali segnali operativi che richiedono attenzione. Gli alert non sono valutazioni formative sul Player, ma indicazioni di governance. Esempio di alert: - il tasso di completamento è sotto la soglia attesa. Le azioni consigliate possono includere: - valutare top-up minuti; - valutare un aumento temporaneo degli slot; - sollecitare utenti non attivi; - verificare tentativi falliti o interrotti; - pianificare accessi in finestre orarie in presenza di code. Queste indicazioni aiutano il Provider a intervenire sul piano operativo. --- ## Come usare questa reportistica Il Provider dovrebbe usare questa sezione per governare l’utilizzo della piattaforma. Esempi di domande utili: - I tenant stanno usando le risorse assegnate? - Ci sono tenant con consumo molto basso o molto alto? - Le runtime stanno generando code? - Gli slot simultanei sono sufficienti? - Ci sono molte sessioni interrotte? - I minuti mensili sono sufficienti? - I test interni stanno consumando molte risorse? - Serve rivedere le allocazioni dei tenant? - Serve aumentare il piano o acquistare capacità aggiuntiva? --- ## Cosa non interpretare da questa sezione Questa sezione non deve essere usata per valutare la qualità formativa individuale dei Player. Non bisogna usarla per concludere che un Player: - comunica bene o male; - ha raggiunto o non raggiunto una skill; - ha una readiness alta o bassa; - ha superato o fallito una simulazione. Questi elementi appartengono ai report formativi. Il Report Provider mostra dati di utilizzo e governance, non giudizi sulla performance individuale. --- ## Internal test e consumo risorse Le sessioni di **internal test** possono comparire nella reportistica Provider. Questi test servono a verificare simulazioni e Avatar Persona prima della distribuzione. È importante ricordare che gli internal test: - consumano minuti dal monte minuti del Provider; - occupano slot di connessione simultanea condivisi; - vengono tracciati come sessioni operative; - possono comparire nella tabella delle sessioni; - non devono essere confusi con tentativi ufficiali dei Player. --- ## Buone pratiche per il Provider Per usare correttamente la sezione Report Provider, è consigliabile: 1. controllare regolarmente i minuti consumati; 2. filtrare per tenant quando si analizza un cliente o reparto specifico; 3. distinguere sessioni ufficiali e internal test; 4. monitorare gli accessi in coda; 5. valutare aumento slot se la coda diventa frequente; 6. verificare il tasso di completamento delle runtime; 7. controllare le interruzioni per protezione in forma aggregata; 8. usare gli alert come indicazioni operative; 9. non usare questa reportistica come valutazione individuale dei Player; 10. confrontare questi dati con Piano e Risorse per decidere eventuali upgrade o riallocazioni. --- ## Risultato finale La sezione **Report Provider** offre una vista di governance sull’utilizzo della piattaforma. Permette di monitorare sessioni, minuti, tenant, runtime, code, completamenti, interruzioni e consumo risorse. Il suo scopo è aiutare il Provider a gestire capacità, costi, continuità del servizio e qualità operativa dell’ecosistema. La valutazione formativa dei Player resta invece separata e viene gestita nelle sezioni report dedicate a Tenant Admin e Player, secondo le policy privacy configurate.