Ingegnerizzazione di campi, automazioni, contratti e documentazione su SuperOps — coerente con la nostra organizzazione, i quattro brand e il modello Unified Secure IT. Pochi campi, molta automazione: dati che diventano metriche, operatività e — domani — un agente AI allenato su di noi.
SuperOps automatizza con tre meccanismi: Event Triggers (azioni atomiche quando un ticket cambia), Time Triggers (scansione ogni 30' su condizioni di tempo, ideale per SLA), Runbook (SOP per problemi ricorrenti). Tutta la configurazione poggia su questi tre più la logica contratti. La filosofia: il dato si inserisce una volta e lavora per sempre.
| 1 | Campi minimi, obbligatori e a tendina. Mai testo libero dove serve un dato strutturato. Si misura solo ciò che è categorizzato. |
| 2 | Incident e Service Request separati all'origine. Due nature diverse, due flussi, un solo sistema. |
| 3 | La priorità nasce dalla matrice, non a mano. Impatto × Urgenza → P1–P4 calcolato dall'automazione. |
| 4 | Assegnazione automatica dove possibile. Brand + categoria + priorità → team/tecnico, senza dispatch manuale sui casi standard. |
| 5 | Il contratto decide dentro/fuori. Voci incluse, escluse, da approvare: il sistema sa cosa è coperto prima del tecnico. |
| 6 | Ogni soluzione alimenta la KB. Risolvere una volta, documentare per sempre: è il carburante del futuro agente AI. |
| 7 | Snello e iterabile. Si parte minimo, si misura, si affina. Mai una configurazione ingessata: i campi si rivedono ogni trimestre. |
Il cuore della configurazione. Pochi campi strutturati alla creazione del ticket: da questi il sistema calcola priorità, assegnazione, SLA e copertura contrattuale. Niente di più del necessario.
La natura della richiesta. Determina il flusso intero.
Quale dei quattro brand. Guida TOV, firma e team.
Quanto è esteso il danno. Metà della matrice priorità.
Quanto in fretta serve. L'altra metà della matrice.
Non si inserisce: lo deriva l'Event Trigger dalla matrice.
Cosa riguarda. Guida assegnazione e KB. Tenuta corta.
Da dove è arrivato. Misura l'efficacia dei canali.
Dentro o fuori contratto. Lo decide la logica contratti.
Dove si trova nel ciclo di vita. Guida SLA e notifiche.
Il principio Unified IT: un solo sistema, un solo standard operativo, ma risposte e TOV coerenti col brand di ciascun cliente. Il campo brand guida mailbox, firma, template di risposta e — dove ha senso — il team. La gestione resta unica e coerente; la voce si adatta.
B2C / micro-SMB · "That's IT"
TOV diretto, rassicurante, vicino. Pill ambra.
MSP/MSSP B2B 10–300 utenti · "Get IT Done"
TOV professionale, orientato al risultato. Pill electric blue.
Performance umana / AI literacy · "Kia Kaha"
TOV empatico, coaching. Verde + koru (solo qui e youMANA).
brand automaticamente. I template di risposta sono per-brand col TOV giusto. Il koru appartiene solo a MANAzone e alla fusione youMANA — mai a PRAGMAcore o OMEGAtech, neanche nei template. I tier non si mescolano mai tra brand.Il percorso che ogni ticket compie. Gran parte è automatica: l'intervento umano si concentra dove serve testa, non dove serve solo smistamento.
Centralino/email/RMM/portale crea il ticket. Brand e canale ereditati in automatico.
Impatto × urgenza → priorità. Categoria e tipo guidano il resto. Contratto associato.
Brand + categoria + priorità → team/tecnico. P1–P2 notificano subito.
Runbook sui casi noti. SLA monitorati da time trigger, escalation se sfora.
Notifica cliente, CSAT, e la soluzione alimenta la knowledge base.
Gli Event Trigger scansionano il ticket quando cambia (creazione, update, reply cliente) e compiono un'azione atomica: imposta proprietà, assegna tecnico o altra azione (template, runbook). Si usano operatori ALL/ANY. Ecco le regole fondamentali da creare.
impatto = Critico AND urgenza = Altapriorità = P1 · applica SLA P1categoria = Sicurezza OR categoria = ServerTeam L2-3 (Giuseppe/Carlo)brand = OMEGAtech / PRAGMAcore / MANAzoneTOV del brandincluded items del contratto associatocopertura = Extra · notifica SPOC per approvazione clienteI Time Trigger scansionano i ticket ogni 30 minuti e agiscono su condizioni di tempo. Sono il motore degli SLA e dell'escalation automatica del Decalogo: il percorso L1→L2→L3→CTO codificato, senza che nessuno debba ricordarsene.
priorità = P1 AND stato ≠ In lavorazione AND tempo trascorso > 15 minL2-3 + notifica SPOC e Coord. Opsstato = In attesa cliente AND nessun reply > 48hSLA in scadenza entro il 20% del tempo residuoI Runbook sono il motore di aderenza ai processi: SOP per problemi che si ripetono, fatte di task e reply template. Si attaccano al ticket a mano o via Event Trigger. Sono il primo passo dello shift-left: il caso noto si risolve seguendo lo standard, non reinventando.
| Runbook | Si attiva quando | Cosa contiene | Verso |
|---|---|---|---|
| Onboarding nuovo utente | SR categoria = Postazione, tipo "nuovo utente" | Account, gruppi, M365, EDR, asset, consegna | Automazione |
| Offboarding utente | SR tipo "cessazione" | Disattiva account, revoca accessi, backup dati, wipe | Automazione + sicurezza |
| Reset / sblocco accessi | INC categoria = Sicurezza/Postazione | Verifica identità, reset, MFA, log | Shift-left L1 |
| Device offline (da RMM) | INC alert RMM | Diagnosi remota, riavvio, check rete, escalation | Auto-remediation |
| Onboarding nuovo cliente | SR attivazione contratto | Asset discovery, policy, stack, documentazione, baseline | Standard |
SuperOps associa automaticamente il contratto al ticket per eligibilità (data valida, non scaduto, sito corrispondente) e per precedenza (Recurring > Time&Material). Le voci del contratto — incluse, escluse, da approvare — determinano la copertura. Qui il listino youMANA v3.1 si traduce in service catalog.
| Logica | Comportamento del sistema | Effetto operativo |
|---|---|---|
| Voce inclusa Incluso | Worklog matcha un included item → coperto, attiva il contratto | Nessuna approvazione: si lavora, è già pagato nel ricorrente |
| Voce da approvare Extra | Non tra gli inclusi → flag copertura = Extra | SPOC chiede ok al cliente prima di procedere · trasparenza |
| Voce blacklisted Fuori | Esplicitamente esclusa dal contratto | Fuori contratto certo · va a Time&Material o preventivo |
| Block hour / money Monte ore | Scala dal monte solo quando il contratto è fatturato | Consumo tracciato · alert quando il monte si esaurisce |
BRAND.FAMIGLIA.NNN diventano service item nel catalogo SuperOps. I tier (IGNITE/BOOST/QUANTUM, ADVISORY/RESCUE/TRANSFORM) sono modelli di contratto ricorrente con i propri included item e SLA. La modularità NMS ("paghi per ciò che vedo e gestisco") si mappa su voci di contratto per device monitorato.I modelli di documentazione in SuperOps vanno costruiti coerenti col nostro lavoro e con le certificazioni. Ogni modello cita il riferimento normativo, così la conformità è strutturale, non un'aggiunta. Allineamento a ISO 9001, ISO 27001, NIS2 e TISAX.
Il passo successivo: un agente AI allenato sulle nostre necessità. Ma un agente vale quanto i dati che lo nutrono. Per questo, da subito, ogni ticket risolto alimenta una knowledge base strutturata — il carburante dell'AI di domani.
Alla chiusura, il campo soluzione segue uno schema minimo: sintomo · causa · risoluzione · categoria. Dati puliti oggi = AI affidabile domani.
I problemi che tornano diventano articoli KB. La categoria del ticket li indicizza. Si riduce il reattivo e si abilita il self-service.
La KB pulita e categorizzata è il dataset su cui (step successivo) si costruisce l'agente AI — allenato sul nostro modo di lavorare, non generico.
L'agente suggerisce, il tecnico valida, la validazione torna nella KB. Il sistema impara su di noi e migliora continuamente.
Reiteriamo il pre-mortem sulla configurazione: siamo tra 12 mesi e SuperOps è un peso, non uno strumento. Perché? Sette modi di sbagliare e il guardrail. Sezione interna.
Si aggiungono campi "utili" finché aprire un ticket diventa un modulo burocratico. I tecnici scelgono a caso pur di chiudere.
Regole su regole, finché un ticket finisce nel posto sbagliato e nessuno capisce perché. La fiducia nel sistema crolla.
Categorie troppo fini o ambigue: i dati non dicono nulla, il dispatch automatico sbaglia, la KB è caotica.
Nessuno documenta le soluzioni perché "non c'è tempo". Tra un anno la KB è deserta e l'agente AI non si può fare.
Included item nel sistema diversi dal contratto firmato: si lavora gratis o si fattura il coperto. Conflitti col cliente.
Auto-remediation su sistemi critici senza supervisione: un'azione automatica fa danni più velocemente di quanto un umano possa fermarla.
Si configura una volta e non si tocca più. Dopo un anno il sistema riflette un'azienda che non esiste più.
Non si configura tutto insieme. Si parte dalle fondamenta (campi), si sale verso l'automazione, infine si abilita l'AI. Ogni fase è usabile da sola.
I 9 campi core, le mailbox per brand, le 9 categorie. La matrice impatto×urgenza come tabella di riferimento. Senza questo, niente automazione regge.
Calcolo priorità (le celle della matrice), dispatch per categoria, template per brand, flag fuori contratto. Il triage manuale sparisce sui casi standard.
Soglie SLA per priorità, escalation a tempo, solleciti attesa-cliente, allerta breach. Il Decalogo diventa sistema.
Runbook per i casi ricorrenti, service catalog dal listino v3.1, contratti per tier con included item e SLA. Shift-left avviato.
I modelli IT citati ai framework (ISO 9001/27001, NIS2, TISAX). La documentazione vive accanto a ticket e asset.
KB strutturata che cresce a ogni chiusura, script di automazione sui runbook maturi, e infine l'agente AI allenato su di noi. Lo step successivo che abbiamo già in mente.