Revisione della copertura dei campi e gestione avanzata: manutenzione schedulata, codici IMAC, cyber che attiva altro, radar cross-sell tra i brand, causa e resolution code, e — il nodo vero — i cambi di assegnazione senza rompere gli SLA né perdere lo storico.
I 9 campi gestivano bene triage e dispatch — ma trattavano SuperOps come un service desk. In ottica IT unificato emergono quattro lacune reali, più una grande opportunità mancata.
Impatto, urgenza, priorità auto: solido.
Categoria → team, brand → TOV: solido.
Solo Incident/SR. Mancano Manutenzione e Change (dove vivono i codici IMAC).
I ticket preventivi auto-generati a calendario non erano previsti: è il cuore del modello proattivo.
La sicurezza non è una categoria come le altre: deve far partire NIS2, CISO, task.
Senza dato strutturato in chiusura, la KB e l'agente AI partono ciechi.
Il ticket come segnale di domanda verso i tre brand: la gemma a CAC zero.
Riassegnazioni, lab, approvvigionamento senza rompere SLA né storico.
Il principio che salva la velocità: l'attrito vive all'apertura. Aggiungiamo campi, ma quasi tutti sono auto, in chiusura o opzionali. Chi apre un ticket compila sempre e solo 4 campi manuali — gli altri il sistema li deriva o si compilano dove c'è già contesto.
| Campo | Quando | Valori | A cosa serve |
|---|---|---|---|
| tipo_ticket | Apertura | Incident · Service Request · Manutenzione · Change | La natura. Guida flusso, IMAC, schedulazione |
| impatto | Apertura | Critico · Alto · Medio · Basso | Metà matrice priorità |
| urgenza | Apertura | Alta · Media · Bassa | Altra metà matrice |
| categoria | Apertura | Rete · Postazione · Server · Cloud/M365 · Sicurezza · Gestionale · Telefonia · Stampa · Altro | Area tecnica → dispatch & KB |
| brand | Auto | OMEGAtech · PRAGMAcore · MANAzone · youMANA | TOV, firma, team — da mailbox |
| canale_origine | Auto | Centralino · Email · Portale · RMM · Chat | Efficacia dei canali |
| priorità | Auto | P1 · P2 · P3 · P4 | Da impatto × urgenza |
| copertura | Auto | Incluso · Extra · Fuori contratto | Da contratto associato |
| causa | Chiusura | Errore utente · Config · Hardware · Software · Rete · Sicurezza · Fornitore · Competenza | Root cause → problem mgmt & ricorrenze |
| resolution_code | Chiusura | Risolto-remoto · Risolto-onsite · Sostituzione · Workaround · Formazione · Escalation-fornitore · Non-riproducibile | Carburante strutturato KB / AI |
| imac_code | Condizionale | Install · Move · Add · Change | Solo per SR/Change. Traccia il ciclo asset/utente |
| segnale_ecosistema | Opzionale | Hardware(O) · Processo(P) · Persone(M) · Strategico(Y) · Nessuno | Radar cross-sell (sez. 06) |
IMAC (Install, Move, Add, Change) non è una categoria tecnica: è il tipo di movimento su un asset o un utente. Vive dentro Service Request e Change, come campo condizionale. Mappa il lavoro ripetibile sui runbook — ed è già metà automazione.
| Codice IMAC | Cosa rappresenta | Runbook collegato | Supporto utente? |
|---|---|---|---|
| Install | Nuovo asset / software / servizio | Provisioning, imaging (LAB), policy | Sì — setup postazione |
| Move | Spostamento utente / sede / device | Trasferimento config, rete, accessi | Sì — continuità utente |
| Add | Nuovo utente / licenza / accesso | Onboarding utente (account, M365, EDR) | Sì — nuovo collaboratore |
| Change | Modifica config / upgrade / cessazione | Change controllato + offboarding | Sì — modifica servizio |
Il ticket manutentivo non aspetta una chiamata: lo genera il sistema su schedulazione. È l'incarnazione operativa del livello "Preventivo" del Modello — ogni ticket di manutenzione fatto è un incident reattivo evitato.
| Tipo manutenzione | Schedulazione | Genera | Tracciabilità |
|---|---|---|---|
| Patch & aggiornamenti | Mensile / a finestra | Ticket auto + policy RMM | Asset patchati, esiti, eccezioni |
| Health check parco | Trimestrale | Ticket auto per cliente/sito | Stato sistemi, segnali precoci |
| Verifica backup | Settimanale | Ticket auto + test ripristino | Backup testati, non solo schedulati |
| Review proattiva cliente | Trimestrale (QBR) | Ticket auto pre-QBR | Capacità, rischi, obsolescenza |
| Rinnovo obsolescenza | Da fine-vita asset | Ticket auto + segnale OMEGAtech | Hardware a fine vita → cross-sell |
Time Trigger (scansione ogni 30') e le policy schedulate generano questi ticket con tipo = Manutenzione, priorità bassa, già assegnati. Lavorati a saturazione, senza interrompere il reattivo. La metrica "% preventivo" del Modello Operativo si alimenta da qui — e diventa visibile la crescita anno su anno.Un ticket di sicurezza deve far scattare più cose di un semplice dispatch: clock di notifica NIS2, allerta alla funzione CISO, runbook di risposta, registro incidenti. È un caso dove un campo attiva una catena.
| Evento | Cosa attiva in automatico | Riferimento |
|---|---|---|
| Incident di sicurezza categoria = Sicurezza | Priorità minima P2, runbook risposta, notifica CISO (Carlo) | ISO 27001 A.5.24-26 |
| Alert EDR critico (da RMM) | Ticket auto P1, isolamento device, escalation L3 | ISO 27001 A.5.25 |
| Sospetta violazione dati | Clock notifica NIS2, registro incidenti, valutazione perimetro | NIS2 (tempi di notifica) |
| Accesso anomalo | Runbook verifica identità, reset, log accessi | ISO 27001 A.5.15-18 · TISAX |
La gemma. Ogni problema ricorrente è il sintomo di una lacuna più profonda. Un campo opzionale segnale_ecosistema permette a tecnico e SPOC di taggare quella lacuna — e di girarla, a CAC zero, verso il brand giusto. Il service desk diventa un radar di domanda. È il nostro modello organico fatto macchina.
Parco obsoleto, guasti ripetuti su device vecchi, postazioni inadeguate.
Problemi che nascono da assenza di soluzione strutturata, infrastruttura non gestita.
La causa = Competenza ricorre: l'utente non sa, non è formato, sbaglia.
Il problema è di direzione IT, non operativo: serve visione, non un fix.
segnale_ecosistema ≠ Nessuno, un Event Trigger genera un lead collegato (non muta il ticket!) e lo gira al commerciale (Simo per offerte/strategia). Il tecnico non vende: segnala. La causa Competenza ricorrente è il trigger naturale verso MANA. È demand-sensing puro: la domanda emerge dai dati operativi, non da una campagna.La tua domanda era giusta: sì, tracciamo causa e resolution code. Non per burocrazia — perché sono la differenza tra una KB di testo libero (inutile per l'AI) e un dataset strutturato (su cui l'agente parte allenato). Si compilano in chiusura, dove il tecnico è già in contesto.
| Dimensione | Perché serve | Cosa abilita |
|---|---|---|
| Causa (root cause) | Capire perché è successo, non solo cosa | Problem management · ricorrenze · radar (causa=Competenza→MANA) |
| Sotto-causa opzionale | Dettaglio quando la causa è ricca | Analisi fine sui pattern · solo dove serve, mai forzata |
| Resolution code | Come è stato risolto, in modo strutturato | KB indicizzata · base RAG dell'agente AI · metrica shift-left |
| Soluzione (schema) | Sintomo · causa · risoluzione, non prosa | Articoli KB automatici · self-service · training AI |
Il nodo vero. Un ticket parte dal tecnico, va al commerciale per una valutazione, torna; oppure passa al LAB per preparazione (con tempi di approvvigionamento), poi rientra. Come farlo senza rompere gli SLA e senza perdere lo storico? Un principio netto risolve tutto.
Il lavoro passa di mano ma resta lo stesso problema: si riassegna dentro lo stesso ticket. Tecnico → LAB → tecnico. Lo storico è la timeline del ticket: ogni passaggio è loggato, nulla si perde.
Se serve lavoro parallelo (una quotazione mentre il tecnico continua) o emerge un bisogno di altro brand, si crea un ticket/task collegato — con clock e proprietario propri. Il ticket originale non si muta: resta pulito, col suo SLA e la sua storia.
Gli stati che fermano l'orologio: la chiave per non farti penalizzare dai tempi che non controlli (fornitore, cliente, logistica).
Il tecnico ci sta lavorando attivamente.
Preso in carico, in coda di lavorazione.
Aspettiamo una risposta o un'approvazione del cliente.
Ordine al fornitore: i tempi di consegna non sono nostri.
Preparazione/allestimento al LAB prima del rientro al tecnico.
Passato al commerciale per quotazione o decisione contrattuale.
side conversation di SuperOps tengono la comunicazione col fornitore separata dal thread cliente.Reiteriamo sulle estensioni. Sette modi di sbagliare e il guardrail. Sezione interna.
Causa e resolution code restano vuoti perché "il ticket è risolto, chi se ne importa". La KB muore.
Ogni ticket genera un'opportunità, il commerciale annega, i segnali veri si perdono nel rumore.
Stati di pausa proliferano, i tecnici non sanno quale scegliere, l'SLA si ferma o corre a casaccio.
Si mette "in attesa cliente" per fermare l'orologio anche quando non è vero, gonfiando le metriche.
Un ticket cambia brand a metà, perde storico e SLA, le metriche per brand diventano inaffidabili.
Troppi ticket schedulati sommergono la coda e nascondono il reattivo urgente.
I tecnici mettono "Install" come categoria o "Server" come IMAC: i dati si sporcano.
Le estensioni in sintesi, pronte da portare nella configurazione reale.
| Aggiunta | Cosa risolve | Come (SuperOps) |
|---|---|---|
| tipo: + Manutenzione, Change | Natura del lavoro, IMAC, schedulazione | Campo tipo esteso + Time Trigger per manutenzione |
| imac_code (condizionale) | Ciclo vita asset/utente, supporto utente misurabile | Campo condizionale su SR/Change → runbook |
| causa + resolution_code | KB strutturata, problem mgmt, base AI | Campi in chiusura, schema fisso, obbligatori P1-P2 |
| segnale_ecosistema | Radar cross-sell a CAC zero | Campo opzionale → Event Trigger genera lead collegato |
| Catena cyber | NIS2, CISO, risposta automatica | Event Trigger su categoria=Sicurezza + clock NIS2 |
| Stati di pausa SLA | Handoff senza penalità né perdita storico | Stati personalizzati con regola stop-clock |
| Ticket collegati | Lavoro parallelo e cross-brand puliti | Task figli + ticket linkati, mai mutazione |