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 #
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 #
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 #
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 #
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 #
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 #
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:
- controllare regolarmente i minuti consumati;
- filtrare per tenant quando si analizza un cliente o reparto specifico;
- distinguere sessioni ufficiali e internal test;
- monitorare gli accessi in coda;
- valutare aumento slot se la coda diventa frequente;
- verificare il tasso di completamento delle runtime;
- controllare le interruzioni per protezione in forma aggregata;
- usare gli alert come indicazioni operative;
- non usare questa reportistica come valutazione individuale dei Player;
- 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.
