Introduzione

Le capacità di automazione di HaloPSA sono tra le più potenti del mercato PSA — e tra le più sottoutilizzate. La maggior parte degli MSP va live con un flusso di ticket di base e qualche notifica email, lasciando inesplorata la maggior parte del potenziale di automazione della piattaforma.

Il motivo è quasi sempre lo stesso: la distinzione tra i livelli di automazione di HaloPSA non è immediatamente ovvia, e senza un modello mentale chiaro di come si integrano tra loro, è difficile sapere da dove iniziare.

Questa guida scompone l'automazione di HaloPSA nei suoi due componenti principali — Workflow e Automazione — e spiega come usare ciascuno per costruire un'operazione di service delivery che scala senza aggiungere personale.

Parte 1: Workflow — Strutturare il Ciclo di Vita del Ticket

Cosa fa una Workflow

Una Workflow in HaloPSA definisce il ciclo di vita di un ticket. Determina quali fasi attraversa un ticket dalla creazione alla chiusura, quali azioni sono disponibili agli agenti in ogni fase e cosa accade automaticamente mentre il ticket progredisce.

L'insight chiave è che una Workflow ben progettata non si limita a tracciare quello che è successo a un ticket — guida attivamente quello che dovrebbe succedere dopo. Gli agenti vedono solo quello che è rilevante per la loro fase attuale. Le opzioni che non si applicano sono nascoste. La piattaforma fa il ragionamento al posto del team.

Questa è una differenza fondamentale rispetto a un setup di ticketing di base, dove gli agenti vedono ogni possibile azione su ogni ticket in ogni momento e si affidano alla conoscenza informale per sapere cosa fare quando.

Forzare il Processo con i Passi della Workflow

Uno degli usi più efficaci delle Workflow di HaloPSA è imporre un passaggio di triage prima che qualsiasi altro lavoro possa essere fatto su un ticket.

Il pattern è ampiamente usato ed altamente efficace: quando un ticket viene creato, l'unica azione disponibile all'agente è un'Azione di Triage. Finché non la completa — assegnando categoria, priorità, team e qualsiasi altro campo richiesto — non vengono presentate altre opzioni. Il ticket non può essere aggiornato, escalato o fatturato finché non è stato correttamente profilato.

L'impatto operativo è significativo. La qualità dei dati dei ticket migliora immediatamente. L'accuratezza del routing aumenta. I calcoli SLA diventano affidabili perché basati su ticket correttamente categorizzati. I tecnici smettono di perdere tempo a smistare lavoro mal categorizzato e il management ottiene una reportistica su cui può davvero contare.

Questo è il tipo di risultato che il design dei processi produce — non la tecnologia. Il motore Workflow di HaloPSA lo rende applicabile.

Cosa Contiene un Passo della Workflow

Ogni passo di una Workflow può contenere tre tipi di elementi: Actions, Ticket Rule e trigger per Runbook. Capire cosa fa ciascuno e quando usarlo è la base di un'automazione HaloPSA efficace.

Parte 2: Actions — Cosa Possono Fare gli Agenti

Il Ruolo delle Actions

Le Actions sono le operazioni disponibili a un agente in un determinato passo della workflow. Possono essere manuali — presentate come pulsanti che l'agente clicca quando è pronto — oppure automatizzate, che si attivano senza input dell'agente quando le condizioni sono soddisfatte.

Le Actions possono essere semplici: cambiare lo stato del ticket, riassegnare a un team o agente diverso, aggiungere una nota, inviare un'email, avviare un processo di approvazione, allegare un report. Oppure possono sfruttare un System Use — un comportamento funzionale predefinito integrato in HaloPSA — per fare qualcosa di più specifico.

System Use: Estendere le Capacità delle Actions

I System Use sono dove le Actions diventano genuinamente potenti. Tre esempi direttamente rilevanti per la gestione dei ticket:

Create Child Ticket permette a un agente di creare un sotto-task da un ticket padre. Il caso d'uso è qualsiasi scenario in cui un ticket coinvolge flussi di lavoro paralleli — il setup di un nuovo dispositivo, ad esempio, potrebbe generare ticket figlio per l'installazione software, la configurazione di rete e la registrazione dell'asset, ciascuno assegnato a un tecnico diverso. Il ticket padre traccia il progresso complessivo; i ticket figlio tracciano i deliverable individuali. HaloPSA può essere configurato per aggiornare automaticamente lo stato del ticket padre quando tutti i figli sono chiusi.

Re-assign è più di un semplice cambio di campo. Come System Use, controlla chi può eseguire la riassegnazione in base ai permessi, cambia opzionalmente lo stato del ticket contemporaneamente e può essere configurato per funzionare anche su ticket bloccati. Per gli MSP con percorsi di escalation definiti, questo è il modo per rendere l'escalation un evento controllato e verificabile piuttosto che un passaggio informale.

Send Webhook / Queue Integration Runbook è il ponte tra il livello delle Actions e quello dell'automazione. Quando un agente completa questa Action, attiva un Runbook — aprendo l'intera gamma delle capacità di automazione. Tratteremo i Runbook in dettaglio nella Parte 4.

Quick Actions

Le Quick Actions sono un sottoinsieme di Actions che si eseguono immediatamente senza richiedere all'agente di compilare campi aggiuntivi. Sono ideali per operazioni ad alta frequenza e bassa frizione — prendere in carico un ticket, segnare un'attività standard come completata, passare al passo successivo della workflow — dove aggiungere un form rallenterebbe il team senza aggiungere valore.

Usate bene, le Quick Actions fanno la differenza tra una workflow che guida i tecnici e una che li frustra.

Parte 3: Ticket Rule — Automazione nella Workflow

Come Funzionano le Ticket Rule

Una Ticket Rule si attiva automaticamente quando i criteri definiti sono soddisfatti. A differenza delle Actions — che richiedono che un agente faccia qualcosa — le Ticket Rule vengono eseguite in background, valutando le condizioni ed eseguendo gli outcome senza alcun touchpoint umano.

Ogni regola ha due componenti: criteri (le condizioni che devono essere vere affinché la regola si attivi) e outcome (cosa accade quando si attiva).

Ticket Rule Dentro e Fuori le Workflow

Le Ticket Rule possono essere create in due modi: all'interno di un passo della Workflow, oppure a livello globale di sistema. Quando vengono create a livello globale — fuori dalle Workflow — le regole vengono valutate in sequenza, e l'ordine in cui vengono elaborate è importante. Una regola creata in seguito può interagire con o sovrascrivere la logica di una precedente, e senza una gestione attenta questo è una fonte comune di comportamenti inaspettati — un ticket instradato correttamente da una regola che viene immediatamente reindirizzato da un'altra, o un cambio di stato sovrascritto prima che l'agente lo veda.

Per gestire questo, HaloPSA fornisce l'opzione "Stop Matching" sulle singole regole globali. Quando abilitata, se una regola si attiva con successo, nessun'altra regola nella sequenza viene valutata per quel ticket — dandoti controllo sulla priorità delle regole e prevenendo interazioni indesiderate.

Le Ticket Rule create all'interno di un passo della Workflow non presentano questo rischio. Sono vincolate a una fase specifica del ciclo di vita del ticket, il che rende la loro logica esplicita e il loro comportamento prevedibile. Per questa ragione, come buona prassi, le Ticket Rule vengono create e gestite all'interno dei passi della Workflow piuttosto che come regole globali standalone.

Opzioni di Trigger

Le regole all'interno di un passo della workflow possono essere attivate in tre modi:

Immediatamente quando il passo viene raggiunto o il ticket viene aggiornato e le condizioni sono soddisfatte.

Dopo un numero predeterminato di minuti dalla condizione di trigger — utile per escalation a tempo ritardato o promemoria.

Un numero predeterminato di giorni prima o dopo il valore di un campo — utile per date legate ai contratti, revisioni programmate o sequenze di follow-up.

Questa flessibilità significa che le Ticket Rule possono gestire sia l'automazione reattiva (qualcosa cambia, qualcos'altro accade immediatamente) che quella proattiva (una scadenza si avvicina, agisci ora).

Outcome Comuni

Gli outcome più comunemente usati nelle Ticket Rule:

Cambio Team / Agente — routing automatico basato sugli attributi del ticket.

Cambio Stato — spostamento dei ticket attraverso il ciclo di vita senza input dell'agente.

Cambio Priorità o Categoria — escalation basata sul tier del cliente, vicinanza SLA o rilevamento di parole chiave.

Associazione di un Template Ticket — applicazione di una struttura predefinita ai ticket che corrispondono a certi criteri.

Trigger di una Notifica — avviso a tecnici, manager o clienti in base allo stato del ticket.

Aggiornamento di un Campo — scrittura su qualsiasi campo di sistema o personalizzato, abilitando logica downstream e reportistica.

La potenza delle Ticket Rule sta nella loro componibilità. Un singolo ticket che attraversa una workflow multi-step potrebbe attivare una dozzina di regole — instradarlo, categorizzarlo, notificare gli stakeholder, escalarlo se rimane fermo troppo a lungo e contrassegnarlo per la fatturazione alla chiusura — tutto senza alcun input dell'agente oltre al lavoro stesso.

Parte 4: Runbook — Automazione Oltre il PSA

Cosa Fanno i Runbook

I Runbook sono il livello di automazione più avanzato di HaloPSA. Dove le Ticket Rule operano sui dati dei ticket all'interno di HaloPSA, i Runbook possono interagire con qualsiasi sistema che espone un'API — incluso HaloPSA stesso.

Un Runbook è una sequenza di passi che può leggere dati, prendere decisioni, chiamare endpoint esterni e scrivere i risultati in HaloPSA. Il trigger può essere un'Action (un agente clicca un pulsante), una Ticket Rule (le condizioni sono soddisfatte) o un evento schedulato (eseguito a un orario definito).

Cosa È Possibile

L'ambito di ciò che i Runbook possono automatizzare è determinato da quali API sono disponibili — il che nel toolstack di la maggior parte degli MSP significa quasi tutto.

Le API native di HaloPSA sono completamente accessibili dai Runbook, il che significa che puoi automatizzare operazioni all'interno di HaloPSA stesso — creando ticket correlati, aggiornando record contrattuali, generando report, attivando azioni di fatturazione o sincronizzando dati tra clienti e asset in base a logica che sarebbe troppo complessa da esprimere in una Ticket Rule.

Oltre HaloPSA, i Runbook possono connettersi al tuo RMM, al tuo stack di sicurezza, alla tua piattaforma di documentazione o a qualsiasi altro strumento nel tuo ambiente. Le possibilità di automazione si moltiplicano man mano che la tua libreria di Runbook cresce — ogni integrazione che costruisci diventa un blocco riutilizzabile per workflow future.

Iniziare con i Runbook

I Runbook hanno una curva di apprendimento più ripida rispetto alle Workflow Rule o alle Actions. Richiedono familiarità con i concetti API, le strutture dati JSON e la logica sequenziale. Per gli MSP senza questo bandwidth tecnico internamente, l'approccio giusto è iniziare con il caso d'uso di maggior valore per la propria operazione e costruire da lì, internamente o con l'aiuto di un consulente.

Il ritorno composto su una libreria di Runbook ben costruita è significativo. Ogni ora di lavoro manuale automatizzata da un Runbook è un'ora che i tuoi tecnici trascorrono su lavoro che richiede davvero il loro giudizio.

Mettere Tutto Insieme

I quattro livelli — struttura Workflow, Actions, Ticket Rule e Runbook — non sono funzionalità indipendenti. Sono progettati per lavorare insieme. Un setup HaloPSA ben progettato usa ogni livello per quello che fa meglio:

Workflow — definiscono il processo e lo rendono applicabile.

Actions — danno agli agenti gli strumenti giusti al momento giusto.

Ticket Rule — gestiscono automaticamente la logica ripetitiva.

Runbook — collegano HaloPSA al resto del tuo toolstack.

Gli MSP che progettano questi livelli in modo deliberato — piuttosto che configurarli in modo reattivo man mano che le esigenze emergono — finiscono con una piattaforma che gestisce attivamente la loro operazione di servizio piuttosto che limitarsi a registrarla.

Vuoi Aiuto nel Progettare la tua Architettura di Automazione HaloPSA?

Impostare correttamente i livelli di Workflow e Automazione fin dall'inizio fa risparmiare mesi di rework in seguito. In Kinesys progettiamo implementazioni HaloPSA costruite per scalare — dalla struttura delle Workflow allo sviluppo dei Runbook.

→ Prenota la tua consulenza gratuita

kinesys.it • info@kinesys.it • Partner Ufficiale HaloPSA & Esperti Autotask