Hub IT / ITSM

Scopo e mappa dell’hub

L’Hub IT è il centro operativo IT secondo il framework ITIL. Da qui si raggiungono la console operativa del service desk e del NOC, la gestione di incident, richieste, problem e change, la Knowledge Base, le dashboard e la reportistica. È lo strumento quotidiano degli operatori (L1/L2/L3), dei team leader e dei manager IT, e il punto d’accesso alle viste di direzione di servizio.

Questa pagina è organizzata in schede: prima le pagine dell’hub (la landing, la console operativa, Change, Problem, Major Incident, Knowledge Base, Voicemail), poi le modal trasversali usate sui ticket (Editor, Composer, Inspector, Tassonomie, Note interne, Allegati, Link, Azioni massive, Playbook, KB, Dashboard, Controllo Qualità, Dati Storici). Le pagine ITOM, Events&AIOps, Operations Cockpit, IT Report Center e Customer Service sono richiamate qui ma descritte nelle rispettive pagine.

Landing dell’Hub IT

A cosa serve. È la pagina d’ingresso dell’hub: presenta le azioni rapide di hub e i riquadri (tile) verso le pagine operative, di direzione e di reporting.

Quando usarla. All’inizio della sessione IT, per scegliere l’area su cui lavorare, o per lanciare le azioni trasversali (KB, CMDB, Controllo Qualità, Tassonomie).

Come aprirla. Dalla Home di Core (riquadro IT Hub) o dalla barra strumenti «IT Hub» presente nelle pagine dell’hub.

Cosa mostra. In testata, una hero strip con il titolo «IT Hub — Centro operativo IT · Network Operations · Service Desk · Operations & ITSM» e le azioni rapide di hub:

Knowledge Base — apre la KB di dominio IT.
CMDB / Assets — apre il CMDB centralizzato.
Dati Storici — apre la modal dei dati archiviati (cold store); richiede un cliente selezionato (vedi Dati Storici).
Controllo di Qualità — visibile ai ruoli abilitati; apre la revisione qualità dei ticket chiusi (vedi Controllo di Qualità).
Tassonomie — visibile agli amministratori; apre la modal Tassonomie ticket (Tassonomie ticket).

Sotto, i riquadri sono raggruppati in tre sezioni:

Operatività (CORE) — tre riquadri principali:

NOC · Network Operations — coda operativa con filtro tier L1/L2/L3: monitoring, triage, investigation, escalation.
Service Desk · Assistenza & richieste — coda service desk con filtro tier L1/L2/L3: triage, reset, incident/problem, catalog. (Il dominio interno resta OPS.)
Customer Service · gruppi per-cliente — ticket CS-* sui gruppi dedicati del cliente (Customer Service, Enterprise Service e ICC).

Direzione servizi — tre cockpit (visibili ai ruoli manager/direttore, *:MGR):

NOC Service Director — P1/War Room live, SLA per cliente, copertura turno, escalation, broadcast team.
Service Desk Director — FCR, AHT, volumi per canale, CSAT, tempi di coda, performance analisti.
Customer Service Director — direzione della linea customer sui gruppi per-cliente.

Strumenti operativi & Reporting — riquadri compatti: ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Ogni riquadro riporta icona, badge di stato (LIVE/NEW/…) e una riga di feature (i tag delle funzioni principali). In fondo alla pagina è presente il bottom dock unificato con softphone, chat e presenza.

Come si usa. Si fa clic sul riquadro dell’area desiderata; le azioni rapide in testata aprono le rispettive modal/pagine. I riquadri e le azioni visibili dipendono dal ruolo (RBAC): la landing filtra i tile in base ai profili di accesso dell’utente e al tier richiesto.

Cosa succede dopo. La navigazione porta alla pagina/console scelta; lo stato di sessione (cliente/tenant corrente) è propagato alle pagine di destinazione.

Note. I KPI di hub sono stati volutamente rimossi dalla landing: con la vista cross-tenant non sarebbero significativi; le metriche vivono nelle pagine dedicate (console NOC, dashboard SLA, cockpit).

Console operativa L1/L2/L3 (NOC e Service Desk)

A cosa serve. È la console di lavorazione dei ticket in coda, condivisa dal NOC e dal Service Desk tramite lo stesso motore di layout. Consente di monitorare la coda, selezionare un ticket, vederne il dettaglio e agire con azioni rapide e strumenti di contesto. Un unico schermo copre i tre livelli (L1/L2/L3) tramite filtro di tier.

Quando usarla. È la postazione di lavoro dell’operatore per tutta la giornata: presa in carico, diagnosi, escalation, risoluzione.

Come aprirla. Dalla landing IT Hub, riquadri NOC o Service Desk. La console Problem (Problem Management Console) usa lo stesso layout.

Cosa mostra. Un layout a tre pannelli:

Coda (sinistra) — l’elenco dei ticket, con:
- filtri rapidi: Tutti, P1/P2, Miei, Unassigned, + L2/L3;
- ricerca per chiave, oggetto o CI;
- aggiornamento automatico ogni 60 secondi (con orario ultimo refresh e contatore).
Dettaglio (centro) — il ticket selezionato con tutti i suoi dati; da qui si aprono l’Editor (Editor ticket) e le azioni.
Strumenti (destra) — schede di contesto che cambiano con il tier.

In alto, una striscia KPI. Per il NOC L1: Ticket aperti, P1/P2 attivi, SLA breach, MTTR (min), Risolti oggi.

Le azioni rapide (L1): Prendi in carico (assegna a me), Escalate L2/L3 (team GRP-NOC_L2), Risolvi, Apri Major Incident (escalation MIM). Gli strumenti L1: CI collegati (CMDB explorer), Runbook (KB NOC L1, Playbook incident), Monitoring (Grafana, Alertmanager), SLA timer (tempo residuo), Dashboard (apre la dashboard KPI in modal).

Al passaggio al tier L2 cambiano KPI, azioni e strumenti: KPI Incident aperti, P1/P2 aperti, Change window, MTTR, Root-cause pending; azioni Take ownership, Escalate L3, Avvia RCA (5-why + timeline), Apri Change (RFC → CAB), Escalate MIM; strumenti RCA workspace (timeline builder, template 5-why), Change mgmt (CAB calendar, RFC nuovo), Runbook L2/L3.

In basso, i collegamenti a Service Topology e ITOM Health, e il bottom dock con softphone (SIP), chat e presenza.

Come si usa. Si filtra e si cerca nella coda, si seleziona un ticket (dettaglio al centro), si agisce con le azioni rapide o si apre l’Editor per la lavorazione completa; gli strumenti di destra danno accesso a CMDB, runbook, monitoring e SLA. Le selezioni multiple abilitano le azioni massive (Azioni massive).

Cosa succede dopo. «Prendi in carico» assegna il ticket all’operatore; «Escalate» lo sposta al team superiore; «Risolvi» lo chiude; «Apri Major Incident» avvia il workbench MIM (Major Incident Workbench). Ogni azione aggiorna coda, KPI, timeline e notifiche.

Note. Il filtro di tier e le matrici di escalation, i nomi dei team (GRP-NOC_*, GRP-OPS-*) e le code sono governati centralmente; l’auto-refresh mantiene la coda allineata senza ricaricare la pagina.

Editor ticket

È la finestra più usata di tutto exoCortex Core: la descriviamo su due sezioni.

A cosa serve, quando e come si apre

A cosa serve. L’Editor ticket è il pannello (drawer) di lavorazione di un singolo ticket: consente di leggerne tutti i dati, cambiarne lo stato (transizioni di workflow), modificarne i campi, commentare, gestire allegati e note interne, consultare SLA, timeline, ticket collegati e la traccia di audit.

Quando usarla. Ogni volta che si prende in carico o si aggiorna un ticket: presa in carico, aggiornamento di avanzamento, richiesta informazioni, risoluzione, chiusura.

Come aprirla. Facendo clic su un ticket in una qualsiasi lista (console operativa, code, risultati di ricerca, widget), oppure con la scorciatoia ⌘O (Ctrl+O) che apre un picker per digitare la chiave del ticket.

Caratteristica distintiva — multi-ticket. L’Editor gestisce fino a 6 ticket aperti contemporaneamente, ciascuno in una propria linguetta (tab) in alto. Si passa da un ticket all’altro con un clic o con ⌘Tab. Una linguetta con modifiche non salvate mostra l’indicatore «sporco» (dirty). Ogni ticket si chiude dalla «x» sulla linguetta.

Modalità di visualizzazione. Il drawer supporta tre modi: ancorato a lato (side-by-side), a schermo ampio (focus) e ridotto a icona (PIP) in basso. Esc riduce il drawer (collapse) senza perderne il contenuto.

Cosa mostra: barra di stato e schede interne

Sotto le linguette dei ticket, una barra di stato con gli attributi chiave e i controlli rapidi: stato corrente e pulsanti di transizione (conferma ⌘↵); priorità (Highest/High/Medium/Low/Lowest); assegnatario (controllo «Assegna» che apre il selettore utente); indicatori di coda/team, tipo e chiave.

Il corpo è organizzato in schede interne:

Dettaglio — i campi del ticket: oggetto, descrizione (testo semplice), priorità e i campi personalizzati (custom field) dell’issue type, caricati dal catalogo ed editabili insieme agli altri. Si salva con ⌘S.
Timeline — la cronologia degli eventi (creazione, transizioni, commenti, modifiche).
Commenti — lo storico dei commenti (autore, data), reso in Markdown, con l’area di scrittura e il pulsante Invia commento (attivo solo con una bozza).
SLA — gli SLA associati con conto alla rovescia «live».
Linked — gli oggetti collegati (ticket, chiamate, chat, link) con data e origine; si aggiungono con il Link Picker (Collega ticket).
Allegati — l’elenco dei file con Visualizza, Scarica, Elimina e caricamento; gli allegati sono immutabili (per «modificare» si elimina e ricarica).
Note interne — annotazioni riservate al team (Note interne).
Audit — la timeline di lifecycle.
Postmortem — la scheda di post-incident review, per i tipi che la prevedono (Major Incident, SOC Incident).

Quando il ticket riguarda un CI/host è disponibile Console PAM (accesso privilegiato zero-knowledge verso il sistema).

Come si usa e cosa succede dopo

Cambiare stato: si sceglie la transizione; il workflow avanza, la timeline registra l’evento e scattano notifiche e automazioni (assegnazioni, SLA, escalation).
Modificare i campi: si edita nella scheda Dettaglio e si salva con ⌘S; le modifiche sono inviate in blocco. Descrizione e commenti sono in testo semplice (single source): ciò che si scrive è ciò che viene salvato e riletto.
Commentare: si scrive nella scheda Commenti e si invia; il commento entra nello storico e notifica secondo la matrice di notifica.
Gestire allegati / assegnare: dalle rispettive schede/controlli.

Scorciatoie: ⌘O apri picker · ⌘S salva · ⌘↵ transizione · Esc riduci · ⌘Tab ticket successivo.

Note. Le azioni disponibili (transizioni, modifica campi, eliminazione allegati, visibilità note interne) dipendono dai permessi del ruolo. La scheda Postmortem compare solo per i tipi che la prevedono.

Composer, creazione ticket

A cosa serve. È la finestra di creazione di un nuovo ticket da parte dell’operatore (per conto di un utente/cliente o a fronte di una chiamata/chat).

Quando usarla. All’apertura di un nuovo caso: telefonata al service desk, richiesta via chat, segnalazione da monitorare, creazione manuale di incident/request/change.

Come aprirla. Dal pulsante di creazione nelle liste/cockpit o con Ctrl+N. Il contesto può essere ereditato da una chat o telefonata attiva: reporter, oggetto, descrizione, CI, allegati, incident correlato, tipo.

Cosa mostra. Un modal centrato (con modalità focus a schermo ampio e PIP in basso a sinistra), in tre step a rivelazione progressiva:

Identify — progetto/tenant di destinazione, canale, richiedente (reporter).
Classify — tipo di ticket (issue type) e dominio (menu filtrato per la sezione del dominio), priorità e categoria.
Detail — oggetto, descrizione, campi specifici, allegati, eventuale nota interna iniziale.

Ogni step ha un indicatore di stato (da fare/in corso/completato). A fianco, il pannello AI Copilot: suggerimento del titolo, proposta di priorità, categorizzazione, rilevamento duplicati, articoli KB e runbook pertinenti.

Come si usa. Si compilano i tre step (il tipo determina i campi obbligatori — Richieste di servizio). Multi-bozza: fino a 5 bozze aperte, persistite lato server e in locale, con autosalvataggio ogni 3 secondi. Invio con Ctrl+Enter o dal pulsante: il ticket è creato; l’eventuale nota interna iniziale è aggiunta subito dopo. Scorciatoie: Ctrl+N nuova bozza · Ctrl+S salva · Ctrl+Enter invia · Esc riduci.

Cosa succede dopo. Il ticket entra nel workflow del suo tipo, è instradato alla coda/team competente secondo le regole di routing del dominio, e generate le notifiche. Il ticket può essere aperto subito nell’Editor (Editor ticket).

Note. Il tenant di destinazione deve essere concreto: i valori jolly (*, __ALL__) sono rifiutati. Senza dominio indicato non viene forzato alcun tipo di default.

Anteprima ticket

A cosa serve. Mostra un ticket in sola lettura con anteprima, stampa ed esportazione, senza aprirlo in modifica.

Quando usarla. Per una consultazione rapida, per stampare o per copiare il link a un ticket da condividere.

Come aprirla. Da liste e widget con l’azione di anteprima.

Cosa mostra. I dati del ticket e i commenti: oggetto, richiedente, stato, priorità, descrizione e storico commenti.

Come si usa. Pulsanti di stampa/export e Copia link.

Cosa succede dopo. Nessuna modifica ai dati (sola lettura). Per intervenire si passa all’Editor.

Note. I commenti sono opzionali (se non presenti la vista resta valida).

Tassonomie ticket

A cosa serve. Definisce le categorie e sottocategorie di servizio usate dal Composer per classificare i ticket. È lo strumento di configurazione della tassonomia globale.

Quando usarla. Quando l’amministratore deve creare/modificare le categorie di classificazione dei ticket.

Come aprirla. Dall’azione Tassonomie nella hero della landing IT (visibile agli amministratori).

Cosa mostra. L’albero Category/Subcategory globali con le voci esistenti e i controlli di creazione/modifica/rimozione.

Come si usa. Si aggiungono o si modificano categorie e sottocategorie; queste popolano il selettore «Tipo/Categoria» del Composer (Composer, creazione ticket) e sono usate per routing e reportistica.

Cosa succede dopo. Le modifiche diventano disponibili nel Composer e negli strumenti di classificazione; le tassonomie sono una sorgente unica.

Note. È una funzione amministrativa.

Note interne

A cosa serve. Gestisce le annotazioni riservate al team su un ticket, non visibili al richiedente.

Quando usarla. Per appuntare informazioni di lavorazione, ipotesi, contatti o dettagli sensibili che non devono comparire nella comunicazione con l’utente.

Come aprirla. Dalla scheda Note interne dell’Editor (Editor ticket).

Cosa mostra. L’elenco delle note interne del ticket con autore e data, e l’area di inserimento di una nuova nota.

Come si usa. Si aggiunge una nota; resta visibile ai soli operatori/team con permesso.

Cosa succede dopo. La nota è registrata sul ticket (canale separato dai commenti pubblici) e concorre alla tracciabilità interna.

Note. La visibilità delle note interne è soggetta ai permessi del ruolo.

Visualizzatore allegati

A cosa serve. Consente di visualizzare, stampare e scaricare gli allegati di un ticket senza scaricarli localmente per aprirli.

Quando usarla. Per esaminare un file allegato (immagine, PDF, log) durante la lavorazione.

Come aprirla. Dall’azione Visualizza nella scheda Allegati dell’Editor, o dai punti in cui è mostrato un allegato.

Cosa mostra. L’anteprima del file con i comandi di stampa e download.

Come si usa. Si apre l’allegato, lo si consulta, eventualmente lo si stampa o scarica.

Cosa succede dopo. Nessuna modifica al file (gli allegati sono immutabili).

Note. Per «modificare» un allegato lo si elimina e si ricarica una nuova versione.

Collega ticket

A cosa serve. Crea un collegamento tra ticket (relazione tipizzata: es. «duplica», «blocca», «correlato»).

Quando usarla. Per correlare un ticket ad altri (incident allo stesso problem, richieste duplicate, dipendenze).

Come aprirla. Dalla scheda Linked dell’Editor.

Cosa mostra. Il tipo di collegamento e un campo di ricerca del ticket di destinazione (con esclusione del ticket sorgente per evitare auto-collegamenti) e un commento opzionale.

Come si usa. Si sceglie il tipo, si cerca e seleziona il ticket destinazione, si conferma.

Cosa succede dopo. Il collegamento è creato e la scheda Linked del ticket si ricarica mostrando la nuova relazione.

Note. Il catalogo dei tipi di link è sorgente unica; l’auto-collegamento è impedito.

Azioni massive

A cosa serve. Esegue azioni su più ticket selezionati in una volta: chiusura massiva ed escalation massiva.

Quando usarla. Per smaltire in blocco più ticket omogenei (es. chiudere una serie di alert rientrati, o escalare un gruppo di ticket allo stesso team).

Come aprirla. Selezionando più ticket nella coda/lista e scegliendo l’azione massiva.

Cosa mostra. L’elenco dei ticket selezionati, la scelta dell’azione (chiudi/escala), e i parametri richiesti (risoluzione per la chiusura, team di destinazione per l’escalation — forniti dal contesto, non hardcoded).

Come si usa. Si conferma l’azione: chiudi chiude i ticket selezionati, escala li porta al livello successivo. È richiesta una selezione valida.

Cosa succede dopo. I ticket sono aggiornati in blocco; coda e KPI si ricaricano; ogni variazione è registrata in audit.

Note. Le risoluzioni e i team disponibili derivano dalla configurazione del tenant.

Playbook launcher

A cosa serve. Elenca ed esegue i playbook/runbook applicabili al contesto della pagina o del ticket.

Quando usarla. Per applicare una procedura standardizzata (diagnosi, remediation, comunicazione) a un incident o a un CI.

Come aprirla. Dal quick-action Playbook delle pagine di gestione o dall’icona registrata nel bottom dock.

Cosa mostra. I playbook applicabili filtrati per dominio e tag e abilitati per il tenant, con la possibilità di fornire input di contesto (es. CI interessato).

Come si usa. Si sceglie un playbook e lo si esegue in Dry-run (simulazione) o Esegui (esecuzione reale), riusando l’API dei playbook.

Cosa succede dopo. L’esecuzione produce i suoi effetti (azioni automatiche, aggiornamenti al ticket/CI) e ne registra l’esito.

Note. Il tenant è quello della sessione e non si indica a mano; le azioni sensibili sono protette da barriere.

Knowledge Base

A cosa serve. Cerca e consulta gli articoli di Knowledge Base direttamente durante la lavorazione, per la risoluzione rapida e il KB-deflection.

Quando usarla. Durante il triage/diagnosi, per trovare una procedura o un articolo utile senza lasciare la pagina.

Come aprirla. Dal quick-action KB negli strumenti della console operativa, o dai punti che integrano la ricerca KB.

Cosa mostra. Un campo di ricerca e la lista dei risultati; selezionando un articolo, la vista articolo con titolo, metadati e corpo.

Come si usa. Si digita una query e si cerca; si apre l’articolo e lo si consulta; si torna alla lista con «indietro».

Cosa succede dopo. L’articolo può risolvere il caso (deflection) o fornire i passi da seguire; la KB alimenta anche i suggerimenti dell’AI Copilot del Composer.

Note. L’endpoint di ricerca è canonico; la KB completa si gestisce nella pagina dedicata (Knowledge Base).

Dashboard KPI

A cosa serve. Apre in overlay una dashboard editoriale di KPI, senza aprire una pagina separata.

Quando usarla. Per consultare al volo i KPI di un’area (es. NOC L1 Monitoring) mentre si lavora sulla console.

Come aprirla. Dal quick-action Apri Dashboard KPI negli strumenti della console.

Cosa mostra. Il report editoriale renderizzato dai dati reali: KPI, trend, breakdown.

Come si usa. Si apre, si consultano i grafici e i valori; sostituisce le vecchie dashboard separate.

Cosa succede dopo. Nessuna modifica ai dati (sola lettura); la chiusura riporta alla console.

Note. Se il runtime del report non è disponibile la modal fallisce in modo esplicito (fail-loud), senza dati finti.

Change Management

A cosa serve. Governa il ciclo di vita dei change infrastrutturali secondo ITIL: Standard (pre-approvato, senza CAB), Normal (approvazione CAB) ed Emergency (approvazione eCAB), con le finestre di Change Freeze.

Quando usarla. Per registrare, valutare, approvare e pianificare i cambiamenti; per gestire le riunioni CAB e le finestre di blocco.

Come aprirla. Dalla landing IT Hub, riquadro Change Management, o dalla console operativa (azione «Apri Change» al tier L2).

Cosa mostra. Una riga di KPI e quattro schede:

Lista — i change con stato, tipo, rischio, finestra ed esito.
CAB — l’agenda del Change Advisory Board: RFC in discussione, partecipanti, voti (tipo IT-CAB-MEETING).
Calendar Window — il calendario delle finestre di cambio (griglia mensile), con la «Window proposta».
Audit Trail — la traccia delle azioni sui change.

Come si usa. Si crea/valuta un change (RFC), lo si porta in CAB per l’approvazione, si pianifica la finestra di esecuzione; da ogni change si apre l’Editor per l’avanzamento e la registrazione delle approvazioni (Approvazione change (CAB)).

Cosa succede dopo. Un Normal Change richiede l’approvazione CAB prima dell’esecuzione; un Emergency segue l’iter eCAB (approvazione retroattiva). Durante un freeze i change non sono approvabili senza autorizzazione esplicita del Change Manager.

Note. Le riunioni CAB possono essere generate periodicamente; il verbale e l’esito voto sono tracciati sul relativo IT-CAB-MEETING.

Approvazione change (CAB)

A cosa serve. Registra la decisione di approvazione su un change (tipicamente Normal Change in CAB).

Quando usarla. In sede CAB/eCAB, quando il change è in attesa di approvazione e l’utente è tra gli approvatori.

Come aprirla. Dalla scheda CAB o dall’Editor del change (scheda Approvazioni). È la stessa modal descritta in Approvazione, qui applicata ai change.

Cosa mostra e come si usa. La catena di approvazione con gli step e il loro stato, e le decisioni Approva / Respingi / Chiedi informazioni / Delega, con commento. Se richiesta, la firma.

Cosa succede dopo. L’approvazione dell’ultimo step abilita l’esecuzione del change nella finestra pianificata; un rifiuto lo rimanda; tutte le decisioni sono notificate e tracciate.

Note. Le regole CAB/eCAB e i freeze condizionano l’esito (vedi Cockpit e viste di direzione/Processi IT).

Problem Management Console

A cosa serve. Gestisce i problem e l’analisi delle cause radice (RCA), fino ai Known Error con workaround documentato.

Quando usarla. Quando più incident condividono una causa comune, o per condurre un’analisi strutturata di causa radice.

Come aprirla. Dalla landing IT Hub, riquadro Problem Management.

Cosa mostra. Il layout a coda della console operativa (KPI, lista con auto-refresh 60s), specializzato per i problem, con il collegamento al CAB calendar e agli incident correlati. Espone la RCA (5-why + engine) e il Known Error DB (KEDB).

Come si usa. Si apre un problem, si conducono l’analisi RCA (template 5-why, timeline) e si documentano causa radice e workaround; da un problem si promuove un Known Error e si crea l’articolo KB corrispondente.

Cosa succede dopo. Un Known Error pubblicato rende disponibile il workaround al primo livello (KB-deflection) e riduce il tempo di risoluzione degli incident ricorrenti. Il template KEDB raccoglie: Sintomo, Root cause, Workaround temporaneo, Fix permanente / change associato, CI impattati, Incident correlati.

Note. La RCA può essere avviata anche dal tier L2 della console operativa (azione «Avvia RCA»).

Major Incident Workbench

A cosa serve. È la plancia di gestione delle crisi (Major Incident): coordina la war room, gli aggiornamenti, le azioni e la chiusura.

Quando usarla. Quando è dichiarato un Major Incident (manualmente o da regola automatica quando un Incident P1 supera i 30 minuti).

Come aprirla. Dall’azione Apri/Escalate Major Incident della console operativa, o dai collegamenti diretti.

Cosa mostra. Il titolo Major Incident Workbench, il pulsante Resolve Major Incident, il pannello Impact e quattro schede:

Timeline — la cronologia degli eventi dell’incidente.
Actions — gli Action items, le azioni assegnate durante la crisi.
Comms — le comunicazioni (aggiornamenti a stakeholder/cliente).
Postmortem — la post-incident review.

È presente l’Incident Bridge (pulsante Config MI / modifica bridge): link alla call di crisi, Incident Commander, partecipanti, timeline degli aggiornamenti in tempo reale. La sezione Linked tickets mostra i ticket collegati all’incidente.

Come si usa. Si apre/aggiorna il bridge, si registrano gli action item e le comunicazioni, si aggiorna la timeline; alla chiusura si preme Resolve Major Incident.

Cosa succede dopo. Alla risoluzione è previsto un PIR (Post-Incident Review) obbligatorio, compilato nella scheda Postmortem. Gli aggiornamenti sono comunicati agli stakeholder secondo le comunicazioni impostate.

Note. Le soglie e la classificazione dei Major Incident (P0–P3) si configurano nella modal Config MI (Configurazione Major Incident (Config MI)) e nella pagina Admin MI Config (Admin MI Config).

Configurazione Major Incident (Config MI)

A cosa serve. Configura i parametri dei Major Incident: soglie di attivazione e classificazione di severità.

Quando usarla. In fase di setup o revisione delle politiche MIM.

Come aprirla. Dal pulsante Config MI del Major Incident Workbench o dalla pagina Admin MI Config (Admin MI Config).

Cosa mostra e come si usa. I parametri di soglia (es. tempo oltre il quale un Incident P1 diventa Major) e la classificazione P0–P3 (Classificazione Major Incident). Si impostano e si salvano.

Cosa succede dopo. Le regole automatiche di creazione del Major Incident usano questi parametri.

Note. È una funzione amministrativa.

Knowledge Base

A cosa serve. È la gestione completa della Knowledge Base: ricerca, articoli, redazione, analisi d’uso e amministrazione. Alimenta la self-service e il KB-deflection.

Quando usarla. Per cercare, creare, aggiornare e analizzare gli articoli KB (tipo IT-KB).

Come aprirla. Dall’azione Knowledge Base della landing IT o dal riquadro KB.

Cosa mostra. Cinque schede:

Search — ricerca articoli con campo query, risultati e test di una query (per verificare cosa troverebbe l’utente) e suggerimenti.
Articles — l’elenco degli articoli con filtro per categoria e la lista delle categorie; pulsante Nuovo articolo.
Editor — la redazione dell’articolo: 1 frase riassuntiva, categoria, tag, corpo, allegati e stato di pubblicazione.
Analytics — le metriche d’uso (numero articoli, articoli per categoria).
Admin — l’amministrazione della KB (categorie, applicabilità per Paese — es. «IT, FR, DE»).

Come si usa. Si cerca e si consulta; con permesso di redazione si crea/aggiorna un articolo (riassunto, categoria, tag, corpo, allegati) e lo si pubblica; la scheda Search consente di testare l’efficacia della ricerca; l’Analytics misura l’adozione.

Cosa succede dopo. Gli articoli pubblicati sono disponibili nella KB modal (Knowledge Base), nel triage (deflection) e nella self-service; l’applicabilità per Paese ne governa la visibilità.

Note. Esiste una vista pubblica (KB di dominio, articolo e pubblica) per la consultazione esterna.

KB di dominio, articolo e pubblica

KB di dominio — la vista degli articoli filtrata per dominio (IT/NOC/OPS/ITSM), raggiunta dall’azione KB dell’hub.
Articolo KB — la pagina di dettaglio/redazione del singolo articolo con categoria, tag, autore e corpo.
KB pubblica — la vista di consultazione pubblica degli articoli destinati all’esterno.

Voicemail

A cosa serve. Raccoglie i messaggi vocali instradati al service desk (utenti / segnalazioni IT) e permette di ascoltarli, leggerne la trascrizione e trasformarli in ticket.

Quando usarla. Per gestire le VM ricevute fuori orario o quando il softphone non ha risposto.

Come aprirla. Dalla landing IT Hub, riquadro Voicemail (con contatore VM non lette).

Cosa mostra. L’inbox delle VM con audio player, trascrizione AI (Whisper), risk scoring (Claude) e il callback integrato nel softphone.

Come si usa. Si ascolta/legge la VM, si valuta il rischio, si richiama il mittente con un clic (callback softphone) o si apre un ticket dal contenuto.

Cosa succede dopo. Il callback avvia una chiamata; l’apertura ticket porta al Composer con il contesto della VM.

Note. La pagina è condivisa con le aree collegate (stesso endpoint canonico).

Controllo di Qualità

A cosa serve. Esegue la revisione di qualità dei ticket chiusi: documentazione, ownership, rispetto SLA, processo, esito e sicurezza.

Quando usarla. Per le verifiche di qualità a campione o sistematiche sui ticket IT chiusi.

Come aprirla. Dall’azione Controllo di Qualità della landing IT (visibile ai ruoli abilitati al controllo qualità).

Cosa mostra e come si usa. La lista dei ticket chiusi da revisionare e la griglia dei criteri di qualità; si valuta ciascun criterio e si registra l’esito della review.

Cosa succede dopo. Gli esiti alimentano gli indicatori di qualità del servizio e possono riaprire/segnalare i ticket non conformi (QC-Gate).

Note. È una funzione riservata ai ruoli di qualità/gestione.

Dati Storici

A cosa serve. Consulta i dati storici archiviati non più presenti nel database operativo.

Quando usarla. Per recuperare ticket/dati archiviati oltre la finestra operativa.

Come aprirla. Dall’azione Dati Storici della landing IT.

Cosa mostra e come si usa. L’interfaccia di ricerca sull’archivio storico; richiede un cliente selezionato (se il contesto è «Tutti i tenant» / *, la modal chiede di selezionarlo).

Cosa succede dopo. I risultati sono mostrati in sola lettura dall’archivio freddo.

Note. Riguarda i dati spostati nell’archivio storico secondo la politica di archiviazione.

Pagine collegate all’hub (descritte altrove)

Dalla landing IT si raggiungono anche pagine trattate nelle rispettive pagine, a cui si rimanda: ITOM e Events & AIOps (NOC, Observability e ITOM), IT Operations Dashboard / Operations Cockpit e le viste Service Director (Cockpit e viste di direzione), IT Report Center (Cockpit e viste di direzione/Reporting), Customer Service (Customer Service, Enterprise Service e ICC), CMDB / Assets (Asset Management e CMDB).