> Miglioramento continuo dei processi > Gestione degli incidenti > Freshservice > Template dei dati

Il Suo template dei dati per la gestione degli incidenti

Freshservice

Attributi per la gestione degli incidenti(19) Attività di gestione degli incidenti(14) Guide all’estrazione(3)

Il Suo template dei dati per la gestione degli incidenti

Questo template La aiuta a preparare i dati per analizzare efficacemente la gestione degli incidenti. Indica gli attributi essenziali da raccogliere e le attività principali da monitorare, oltre a fornire indicazioni pratiche per estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per semplificare la preparazione dei dati.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi per la gestione degli incidenti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo di gestione degli incidenti.

5 Obbligatorio 7 Consigliato 7 Facoltativo

	Nome	Descrizione
	ID incidente IncidentId	Identificativo univoco di ciascun record di incidente, utilizzato come chiave primaria per tracciare l’intero ciclo di vita dell’incidente.
Descrizione L’ID incidente è il riferimento fondamentale per l’analisi della gestione degli incidenti. Funge da ID del caso e collega tutte le attività correlate, le date e le ore e le modifiche agli attributi in un unico percorso coerente. Nel Process Mining, ogni voce dell’Event Log è associata a un ID incidente, consentendo di ricostruire il flusso del processo dall’inizio alla fine per ciascun incidente. Questo è essenziale per calcolare i tempi di ciclo, analizzare le varianti del processo e individuare i colli di bottiglia specifici dei singoli casi. Senza un identificativo univoco, sarebbe impossibile distinguere i diversi incidenti e analizzarne il percorso dalla segnalazione alla risoluzione. Perché è importante Identifica in modo univoco ogni incidente e ne consente il monitoraggio e l’analisi dall’inizio alla fine, dalla creazione alla chiusura. Dove reperirli È l’identificativo principale di un ticket, disponibile nell’API Tickets di Freshservice come campo 'id' dell’oggetto ticket. Esempi INC-10234INC-10235INC-10236
	Data e ora dell’evento EventTimestamp	La data e l’ora esatte in cui si è verificata l’attività o l’evento.
Descrizione La data e l’ora dell’evento, o ora di inizio, indicano il momento preciso in cui si è svolta un’attività. Ogni attività del ciclo di vita dell’incidente, dalla creazione alla chiusura, è associata a una data e a un’ora. Questo attributo è essenziale per tutte le analisi di Process Mining basate sul tempo. Serve a ordinare cronologicamente gli eventi, calcolare la durata tra le attività, misurare il tempo di ciclo totale del caso e analizzare i tempi di attesa. È la base per creare Dashboard che monitorano le prestazioni SLA, i ritardi nei passaggi di consegne e i tempi complessivi di risoluzione. Perché è importante Fornisce l’ordine cronologico degli eventi, indispensabile per calcolare le durate, analizzare i tempi di ciclo e comprendere le prestazioni del processo. Dove reperirli Si ricava da diversi campi data e ora di Freshservice, come 'created_at' e 'updated_at', e dalle date e ore presenti nelle conversazioni o nei registri di audit del ticket. Esempi 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Nome dell’attività ActivityName	Nome dell’attività aziendale o dell’evento specifico che si è verificato in un determinato momento del ciclo di vita dell’incidente.
Descrizione Il nome dell’attività descrive un singolo passaggio o evento nel processo di gestione degli incidenti, ad esempio 'Incident Assigned to Group', 'Status Changed to Pending' o 'Incident Resolved'. Queste attività si ricavano dalle modifiche ai dati dell’incidente nel tempo. Questo attributo è fondamentale nel Process Mining, perché definisce i nodi della mappa del processo individuata. Analizzando la sequenza e la frequenza delle attività, le organizzazioni possono visualizzare il processo effettivo di risoluzione degli incidenti, individuare i percorsi più comuni, rilevare gli scostamenti dalla procedura standard e identificare i cicli di rilavorazione, come le riassegnazioni frequenti. Perché è importante Definisce i passaggi nella mappa del processo e consente di visualizzare e analizzare il flusso di risoluzione degli incidenti, i colli di bottiglia e gli scostamenti. Dove reperirli Questo attributo non corrisponde a un campo diretto di Freshservice, ma si ricava dalle modifiche a proprietà del ticket quali stato, priorità, assegnazione dell’agente o del gruppo e aggiunta di note. Esempi Incidente segnalatoIncidente assegnato a un gruppoNota di risoluzione aggiuntaIncidente risolto
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati, in genere 'Freshservice'.
Descrizione Questo attributo identifica l’origine dei dati. In questo contesto il valore sarà sempre 'Freshservice', ma il campo è fondamentale negli ambienti in cui si combinano dati provenienti da più sistemi per ottenere una visione completa del processo. Includere l’attributo del sistema di origine è una buona pratica per la governance e la tracciabilità dei dati. Permette di sapere con chiarezza da dove provengono i dati, un aspetto importante per la convalida, la risoluzione dei problemi e l’eventuale ampliamento del progetto di Process Mining ad altri sistemi di gestione dei servizi o operativi. Perché è importante Garantisce la tracciabilità e la governance dei dati, identificando chiaramente l’origine dei dati relativi alla gestione degli incidenti. Dove reperirli In genere è un valore statico aggiunto durante la trasformazione dei dati (ETL) per identificare il set di dati. Esempi FreshserviceFreshservice-EUFreshservice-PROD
	Ultimo aggiornamento dei dati LastDataUpdate	La data e l’ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati relativi a questo processo.
Descrizione Questo attributo indica la data e l’ora dell’ultimo aggiornamento dell’intero set di dati dal sistema di origine. È un campo di metadati riferito all’intero set di dati, non ai singoli eventi, ma spesso viene incluso a livello di evento per coerenza. Nell’analisi, questa informazione è essenziale per capire quanto sono aggiornati i dati e quale intervallo temporale coprono le Dashboard e gli indicatori KPI. Consente agli utenti di valutare l’attualità delle informazioni e di capire se nell’analisi sono inclusi gli incidenti più recenti. Perché è importante Indica agli utenti quanto sono aggiornati i dati e chiarisce l’intervallo temporale coperto dall’analisi. Dove reperirli È una data e un’ora di metadati generate durante l’estrazione dei dati (ETL). Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Agente assegnato AssignedAgent	Il nome o l’ID dell’agente di supporto attualmente incaricato di risolvere l’incidente.
Descrizione L’agente assegnato identifica la persona del Service Desk responsabile dell’incidente in un determinato momento. Le modifiche a questo attributo indicano il trasferimento della responsabilità da un agente a un altro. Questo attributo è essenziale per l’analisi delle prestazioni e consente di creare Dashboard che monitorano il carico di lavoro degli agenti, il tempo medio di risoluzione per agente e il tasso di risoluzione al primo contatto. Serve inoltre ad analizzare i passaggi di consegne tra agenti, che possono causare ritardi e inefficienze. Monitorando le assegnazioni, i responsabili possono individuare le esigenze di formazione e riconoscere i membri del team con prestazioni elevate. Perché è importante Consente di analizzare le prestazioni degli agenti, la distribuzione del carico di lavoro e l’impatto dei passaggi di consegne sui tempi di risoluzione. Dove reperirli Disponibile nell’API Tickets di Freshservice come campo 'responder_id'. È possibile collegare questo ID all’API Agents per recuperare il nome dell’agente. Esempi John DoeJane SmithSupportBot
	Categoria dell’incidente IncidentCategory	La categoria utilizzata per classificare l’incidente, ad esempio Hardware, Software o Rete.
Descrizione La categoria dell’incidente consente di classificarlo in base al tipo di problema segnalato. Questa classificazione gerarchica aiuta a indirizzare l’incidente al team corretto ed è fondamentale per l’analisi dell’andamento. Questo attributo viene utilizzato nella Dashboard 'Incident Categorization Accuracy' per verificare se una classificazione iniziale errata allunga i tempi di risoluzione a causa delle riassegnazioni. Raggruppando gli incidenti per categoria, le organizzazioni possono individuare i problemi ricorrenti, capire dove si concentra la maggior parte del lavoro di supporto e definire iniziative di miglioramento mirate. Perché è importante Consente di analizzare l’andamento degli incidenti e di verificare se una classificazione errata causa ritardi nella risoluzione. Dove reperirli È un campo predefinito ma personalizzabile di Freshservice. È disponibile nell’API Tickets come 'category', con i campi correlati 'sub_category' e 'item_category'. Esempi HardwareSoftwareProblema di reteAccesso all’account
	Gravità dell’incidente IncidentSeverity	Il livello di gravità dell’incidente, che ne indica l’impatto sull’attività aziendale.
Descrizione La gravità dell’incidente misura l’impatto sull’attività aziendale e viene spesso classificata come Bassa, Media, Alta o Critica. Sebbene sia correlata alla priorità, la gravità riguarda l’impatto, mentre la priorità riguarda l’urgenza. La combinazione di gravità e impatto determina spesso la priorità finale. L’analisi per gravità aiuta a capire quanto efficacemente l’organizzazione gestisce gli incidenti con conseguenze rilevanti per l’attività aziendale. Le Dashboard la utilizzano per suddividere i tempi di risoluzione e le prestazioni SLA, così da garantire che i problemi con maggiore impatto ricevano l’attenzione e le risorse adeguate durante tutto il loro ciclo di vita. Perché è importante Misura l’impatto di un incidente sull’attività aziendale e consente di concentrare l’analisi sulla riduzione dei problemi più dannosi. Dove reperirli È un campo predefinito di Freshservice, disponibile nell’API Tickets come 'impact'. I valori sono numerici. Esempi BassaMediaAlta
	Gruppo assegnato AssignedGroup	Il gruppo o il team di supporto attualmente incaricato dell’incidente.
Descrizione Il gruppo assegnato indica quale team, ad esempio 'Level 1 Support', 'Network Team' o 'Database Admins', è responsabile dell’incidente. Le modifiche a questo attributo segnalano un’escalation o un trasferimento tra team con funzioni diverse. Analizzare il gruppo assegnato è fondamentale per comprendere i ritardi nei passaggi di consegne e nei trasferimenti. Il Process Mining può visualizzare il flusso degli incidenti tra i gruppi, evidenziare i percorsi di escalation più comuni e misurare il tempo di attesa prima che ciascun gruppo intervenga. Questo aiuta a individuare i colli di bottiglia organizzativi e le opportunità per rendere più efficace la collaborazione tra team. Perché è importante Indica quale team è responsabile, un’informazione essenziale per analizzare i passaggi di consegne, le escalation e i ritardi tra team. Dove reperirli Disponibile nell’API Tickets di Freshservice come campo 'group_id'. È possibile collegare questo ID all’API Groups per recuperare il nome del gruppo. Esempi Service DeskOperazioni di reteSupporto infrastruttura
	Priorità dell’incidente IncidentPriority	Il livello di priorità dell’incidente, che determina l’urgenza della risposta e della risoluzione.
Descrizione La priorità dell’incidente è un campo fondamentale che determina la rapidità e l’attenzione necessarie per gestirlo. In genere è definita su una scala, ad esempio Bassa, Media, Alta e Urgente, e spesso determina gli obiettivi SLA. Nel Process Mining, la priorità è una dimensione essenziale per filtrare e analizzare i dati. Consente di confrontare i processi di risoluzione degli incidenti ad alta e bassa priorità e di verificare che i problemi critici siano gestiti in modo efficiente. Spesso le Dashboard suddividono per priorità metriche come il tempo di ciclo e il rispetto degli SLA, offrendo ai responsabili del supporto informazioni utili per intervenire. Perché è importante Aiuta a concentrare l’analisi sugli incidenti più critici ed è essenziale per valutare le prestazioni SLA e l’allocazione delle risorse. Dove reperirli Disponibile nell’API Tickets di Freshservice come campo 'priority'. I valori sono numerici, ad esempio 1 per Bassa e 4 per Urgente. Esempi BassaMediaAltaUrgente
	Scadenza SLA per la risoluzione ResolutionSlaTargetTime	La data e l’ora entro cui l’incidente dovrebbe essere risolto secondo la relativa politica SLA.
Descrizione Questo attributo memorizza la data e l’ora che costituiscono la scadenza per la risoluzione di un incidente. L’obiettivo è determinato dalla politica dell’accordo sul livello di servizio (SLA) applicata al ticket e dipende in genere da fattori come la priorità. Questa scadenza è essenziale per calcolare l’indicatore KPI 'SLA Adherence Rate' e alimentare la Dashboard 'SLA Performance Dashboard'. Confrontando la data e l’ora effettive della risoluzione con l’obiettivo, è possibile determinare se l’incidente è stato risolto in tempo o se ha violato lo SLA. È un elemento fondamentale per misurare il rispetto dei livelli di servizio. Perché è importante Fornisce la scadenza per la risoluzione, necessaria per calcolare il rispetto degli SLA e individuare gli incidenti a rischio. Dove reperirli Disponibile nell’API Tickets di Freshservice nei campi 'fr_due_by' (prima risposta) e 'due_by' (risoluzione). Esempi 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Stato dell’incidente IncidentStatus	Lo stato attuale dell’incidente nel suo ciclo di vita, ad esempio Open, Pending, Resolved o Closed.
Descrizione Lo stato dell’incidente ne indica la condizione attuale. I cambi di stato sono eventi fondamentali su cui si basa la mappa del processo individuata, ad esempio il passaggio da 'In Progress' a 'Pending' o da 'Resolved' a 'Closed'. Questo attributo è fondamentale per comprendere il percorso dell’incidente. Analizzare il tempo trascorso in ciascuno stato aiuta a individuare i colli di bottiglia, ad esempio gli incidenti che restano troppo a lungo nello stato 'Pending' in attesa di una risposta dell’utente. È inoltre essenziale per definire i punti iniziali e finali dei calcoli del tempo di ciclo. Perché è importante Tiene traccia dell’avanzamento dell’incidente durante il suo ciclo di vita e aiuta a individuare le fasi in cui si verificano spesso ritardi. Dove reperirli Disponibile nell’API Tickets di Freshservice come campo 'status'. I valori sono numerici. Esempi ApertoIn corsoIn attesaRisoltoChiuso
	Canale di segnalazione ReportingChannel	Il metodo o il canale utilizzato per segnalare l’incidente, ad esempio e-mail, portale o telefono.
Descrizione Il canale di segnalazione, detto anche origine, indica come l’incidente è stato inserito nel sistema di supporto. Tra i canali più comuni figurano l’e-mail, il portale self-service, le telefonate e la chat. L’analisi di questo attributo aiuta a valutare l’efficienza dei diversi canali di segnalazione. La Dashboard 'Reporting Channel Efficiency' confronta il volume degli incidenti e il tempo medio di risoluzione per canale, per determinare quali metodi sono più efficaci e quali potrebbero richiedere miglioramenti. Ad esempio, gli incidenti segnalati tramite il portale potrebbero essere risolti più rapidamente se fin dall’inizio includono informazioni più strutturate. Perché è importante Aiuta a individuare i canali di segnalazione più efficienti e mette in luce le opportunità per migliorare la gestione iniziale degli incidenti. Dove reperirli Disponibile nell’API Tickets di Freshservice come campo 'source'. I valori sono numerici. Esempi E-mailPortaleTelefonoChat
	Causa profonda RootCause	La ragione di fondo o la causa profonda individuata per l’incidente dopo l’indagine.
Descrizione L’attributo della causa profonda registra il problema fondamentale che ha provocato l’incidente. In genere, gli agenti di supporto compilano queste informazioni durante o dopo la risoluzione, nell’ambito dell’analisi della causa profonda (RCA). Questo attributo è fondamentale per la Dashboard 'Recurring Incidents And Root Causes' e per l’indicatore KPI 'Root Cause Analysis Completion Rate'. Analizzando le cause profonde più comuni, le organizzazioni possono passare dalla risoluzione reattiva degli incidenti a una gestione proattiva dei problemi, adottando soluzioni permanenti che prevengono nuovi incidenti e riducono il ripetersi dei problemi. Perché è importante Favorisce una gestione proattiva dei problemi, aiutando a individuare ed eliminare le cause profonde degli incidenti ricorrenti. Dove reperirli Spesso si tratta di un campo personalizzato in Freshservice, poiché le funzionalità predefinite potrebbero essere limitate. Verificare nella configurazione 'Ticket Fields' se è presente un campo denominato 'Root Cause' o simile. Esempi Errore softwareErrore di configurazione della reteProblema di formazione dell’utenteGuasto hardware
	Numero di passaggi di consegne HandoffCount	Il numero di volte in cui un incidente è stato trasferito tra agenti o gruppi diversi.
Descrizione Il numero di passaggi di consegne è una metrica calcolata che quantifica le riassegnazioni di un incidente durante il suo ciclo di vita. Ogni modifica all’attributo 'AssignedAgent' o 'AssignedGroup' incrementa il conteggio. Un numero elevato di passaggi di consegne indica spesso inefficienze nel processo, un instradamento iniziale errato o una carenza di competenze degli agenti. Questa metrica supporta direttamente l’indicatore KPI 'Incident Handoff Count' e la Dashboard 'Handoff And Transfer Delay Analysis', aiutando a individuare gli incidenti o i percorsi di processo caratterizzati da trasferimenti eccessivi che causano ritardi. Perché è importante Quantifica le rilavorazioni e le riassegnazioni, aiutando a individuare le inefficienze dovute a un instradamento errato o a lacune nelle conoscenze. Dove reperirli È una metrica calcolata contando i valori distinti o le modifiche nei campi 'AssignedAgent' o 'AssignedGroup' durante il ciclo di vita di un singolo incidente. Esempi 0125
	Reparto del richiedente RequestersDepartment	Il reparto a cui appartiene l’utente che ha segnalato l’incidente.
Descrizione Questo attributo identifica il reparto aziendale del richiedente, ad esempio 'Vendite', 'Finanza' o 'IT'. In genere, queste informazioni provengono dal profilo dell’utente in Freshservice. Analizzare gli incidenti in base al reparto del richiedente può rivelare se alcuni reparti sono colpiti dai problemi in misura sproporzionata o se esistono criticità specifiche. Fornisce un contesto utile per comprendere l’impatto degli incidenti sull’attività aziendale e può aiutare a dare priorità agli interventi che riguardano reparti essenziali. Perché è importante Fornisce un contesto aziendale che consente di analizzare l’andamento degli incidenti e il loro impatto sui singoli reparti. Dove reperirli Queste informazioni sono associate al richiedente del ticket. Si possono recuperare dall’endpoint API 'Requesters' utilizzando il valore 'requester_id' del ticket e consultando poi 'department_id' e il nome del reparto. Esempi VenditeMarketingFinanzaRisorse umane
	Riaperto IsReopened	Indicatore calcolato, impostato su vero se un incidente è stato riaperto dopo essere stato risolto o chiuso.
Descrizione Questo attributo booleano è un indicatore calcolato che identifica gli incidenti riaperti. Viene impostato su vero se, dopo aver raggiunto lo stato 'Resolved' o 'Closed', lo stato dell’incidente torna a essere aperto o in corso. Questo indicatore è fondamentale per calcolare l’indicatore KPI 'Incident Reopening Rate' e per la Dashboard 'Recurring Incidents'. Un tasso elevato di incidenti riaperti può segnalare problemi nella qualità della risoluzione iniziale, un’analisi incompleta della causa profonda o una chiusura prematura. Analizzare questi casi aiuta a migliorare la qualità e la durata delle soluzioni. Perché è importante Individua le criticità nel processo di risoluzione, evidenziando gli incidenti in cui l’intervento iniziale non è stato efficace e ha generato rilavorazioni. Dove reperirli È un campo calcolato ricavato dalla sequenza delle attività nell’Event Log. È impostato su vero se si verifica un’attività come 'Incident Reopened' o se, per lo stesso ID incidente, un’attività con stato aperto segue un’attività con stato chiuso. Esempi truefalse
	SLA violato IsSlaBreached	Indicatore calcolato, impostato su vero se l’incidente non è stato risolto entro la scadenza prevista dall’obiettivo SLA.
Descrizione Questo attributo booleano è una metrica calcolata che indica se il tempo di risoluzione di un incidente ha superato l’obiettivo SLA. Si ricava confrontando la data e l’ora effettive della risoluzione con 'ResolutionSlaTargetTime'. Questo indicatore alimenta direttamente l’indicatore KPI 'SLA Adherence Rate' e la Dashboard 'SLA Performance Dashboard'. Semplifica l’analisi fornendo un esito chiaro e binario per le prestazioni SLA di ciascun incidente, che può essere facilmente aggregato e analizzato nel tempo. Aiuta a individuare rapidamente il numero e la percentuale di incidenti che non rispettano gli impegni sul livello di servizio. Perché è importante Misura direttamente il rispetto degli SLA per ciascun incidente, facilitando il calcolo dei tassi complessivi di conformità e l’individuazione delle aree problematiche. Dove reperirli È un campo calcolato durante la trasformazione dei dati, confrontando la data e l’ora dell’evento 'Incident Resolved' con il campo 'ResolutionSlaTargetTime'. Esempi truefalse
	Soluzione alternativa fornita WorkaroundProvided	Indicatore che segnala se all’utente è stata fornita una soluzione temporanea prima della risoluzione definitiva.
Descrizione Questo attributo booleano indica se è stata implementata una soluzione temporanea per ridurre l’impatto dell’incidente mentre si sviluppava una soluzione definitiva. Spesso viene registrato tramite una casella di controllo o uno stato specifico. Nel Process Mining, questo attributo supporta la Dashboard 'Workaround Effectiveness Metrics'. Consente di confrontare i tempi di risoluzione degli incidenti con e senza soluzioni temporanee, aiutando a determinare se queste riducono efficacemente le interruzioni dell’attività aziendale e contribuiscono a una risoluzione complessiva più rapida dal punto di vista dell’utente. Perché è importante Aiuta a misurare l’efficacia delle soluzioni temporanee nel ridurre l’impatto degli incidenti e nel far percepire una risoluzione più rapida. Dove reperirli In genere è un campo booleano personalizzato, rappresentato da una casella di controllo. Verificarne la presenza nella configurazione 'Ticket Fields' di Freshservice. Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione degli incidenti

Queste sono le fasi e le tappe principali da registrare nell’Event Log per individuare con precisione il processo e i colli di bottiglia.

7 Consigliato 7 Facoltativo

	Attività	Descrizione
	Incidente assegnato a un gruppo	Indica l’assegnazione iniziale di un incidente a un gruppo di supporto. Può avvenire automaticamente tramite regole di instradamento oppure manualmente da parte di un addetto al coordinamento. L’attività viene rilevata registrando il primo inserimento del valore nel campo «Group» nel registro di controllo dell’incidente.
Perché è importante Monitorare le assegnazioni è essenziale per misurare i tempi della prima risposta e individuare i colli di bottiglia nel processo di smistamento. Aiuta a valutare l’efficienza con cui gli incidenti vengono instradati al team corretto. Dove reperirli Dedotto dalla prima voce del registro delle attività dell’incidente che inserisce o modifica il valore del campo «Group». Acquisizione Individui la prima data e ora in cui viene compilato il campo «Group» per un incidente. Tipo di evento inferred
	Incidente chiuso	Indica la chiusura definitiva e formale del record dell’incidente. In genere avviene automaticamente dopo un periodo prestabilito nello stato 'Resolved', ma può anche essere eseguita manualmente da un agente. Questo evento segna la fine del ciclo di vita dell’incidente.
Perché è importante Questa attività rappresenta il punto finale del processo. Il tempo totale fino a questo evento corrisponde all’intero ciclo di vita dell’incidente, compresi gli eventuali periodi di attesa della conferma dell’utente. Dove reperirli Ricavato dal registro delle attività dell’incidente, individuando l’aggiornamento del campo 'Status' a 'Closed'. Acquisizione Utilizzare la data e l’ora della voce nel registro delle attività relativa al passaggio di stato a 'Closed'. Tipo di evento inferred
	Incidente risolto	Indica il momento in cui l’agente ha applicato una correzione e considera risolto l’incidente. Viene rilevato quando lo stato dell’incidente passa a «Resolved». In Freshservice, questa tappa fondamentale arresta il conteggio del tempo SLA.
Perché è importante È una tappa fondamentale per misurare il tempo di risoluzione (TTR). Il periodo tra «Resolved» e «Closed» è importante per analizzare i ritardi nella conferma dell’utente e le regole di chiusura automatica. Dove reperirli Ricavato dal registro delle attività dell’incidente, individuando l’aggiornamento del campo 'Status' a 'Resolved'. Acquisizione Utilizzare la data e l’ora della voce nel registro delle attività relativa al passaggio di stato a 'Resolved'. Tipo di evento inferred
	Incidente segnalato	Indica la creazione di un nuovo record di incidente in Freshservice. È il punto di partenza del ciclo dell’incidente, in genere attivato da un utente finale tramite il portale o e-mail, oppure da un agente del Service Desk che crea un ticket per suo conto. L’evento viene registrato esplicitamente con la data e l’ora di creazione.
Perché è importante Questa attività è l’evento di inizio principale dell’intero processo. Analizzare il tempo che intercorre tra questo evento e la risoluzione è fondamentale per misurare i tempi di ciclo complessivi e il rispetto degli SLA. Dove reperirli Rilevato dalla data e ora di creazione nella tabella degli incidenti. Freshservice registra esplicitamente questo dato per ogni nuovo ticket. Acquisizione Utilizzi la data e l’ora «Created at» del record principale dell’incidente. Tipo di evento explicit
	Nota di risoluzione aggiunta	Si verifica quando un agente documenta la soluzione dell’incidente aggiungendo una nota di risoluzione. In Freshservice è un’azione distinta, che precede la modifica dello stato in «Resolved». L’azione e il relativo contenuto vengono registrati esplicitamente.
Perché è importante Segna il momento in cui viene individuata una soluzione. Il tempo che intercorre tra questa attività e lo stato «Incident Resolved» può indicare tempi aggiuntivi dovuti a verifiche interne o alla documentazione. Dove reperirli Rilevato dalla data e ora in cui viene aggiunta una nota di risoluzione all’incidente, registrata nella cronologia della conversazione. Acquisizione Individui la data e l’ora della voce «Resolution Note» nella cronologia della conversazione dell’incidente. Tipo di evento explicit
	Priorità dell’incidente impostata	Si verifica quando la priorità dell’incidente viene impostata o aggiornata. Il livello di priorità determina l’urgenza e gli obiettivi SLA per la risoluzione. L’attività viene rilevata monitorando le modifiche al campo «Priority» nella cronologia dell’incidente.
Perché è importante Un’impostazione errata o tardiva della priorità può causare il mancato rispetto degli SLA e un’allocazione inefficiente delle risorse. Analizzare questa attività aiuta a garantire che gli incidenti critici ricevano attenzione immediata. Dove reperirli Dedotto dal registro delle attività dell’incidente, che tiene traccia di tutti gli aggiornamenti del campo «Priority». Acquisizione Utilizzi le date e le ore del registro di controllo in cui il valore del campo «Priority» è stato impostato o modificato. Tipo di evento inferred
	Stato modificato in In Progress	Questa attività segna l’inizio ufficiale dell’analisi e del lavoro attivo sull’incidente. Viene rilevata quando un agente modifica lo stato dell’incidente in «In Progress». Si tratta di una modifica di stato standard, registrata nella cronologia delle attività del ticket.
Perché è importante Questa tappa consente di distinguere il tempo di attesa dal tempo di lavoro effettivo. Analizzare quanto a lungo un incidente rimane «In Progress» è fondamentale per capire l’impegno richiesto per risolverlo. Dove reperirli Dedotto dal registro delle attività dell’incidente, individuando quando il campo «Status» viene aggiornato a «In Progress». Acquisizione Filtri il registro delle attività per individuare una modifica dello stato a «In Progress» e utilizzi la relativa data e ora. Tipo di evento inferred
	Agente assegnato all’incidente	Questa attività indica quando viene assegnato all’incidente un agente specifico. Segna l’attribuzione della responsabilità individuale per il ticket. L’assegnazione viene registrata nella cronologia delle attività del ticket, con il nome dell’agente e la data e l’ora dell’assegnazione.
Perché è importante Consente di analizzare il carico di lavoro e i risultati degli agenti, nonché il tempo che intercorre tra l’assegnazione al gruppo e la presa in carico da parte di un singolo agente. È un dato essenziale per le Dashboard sui risultati degli agenti. Dove reperirli Rilevato tramite le modifiche al campo «Agent» nel registro delle attività o nel registro di controllo dell’incidente. Acquisizione Individui le date e le ore corrispondenti alle modifiche del campo «Agent». Tipo di evento inferred
	Incidente riaperto	Si verifica quando un incidente precedentemente contrassegnato come 'Resolved' torna a uno stato aperto, in genere perché l’utente non ritiene soddisfacente la risoluzione. Si deduce dal passaggio di stato da 'Resolved' a uno stato come 'Open' o 'In Progress'.
Perché è importante Un tasso elevato di riapertura segnala problemi nella qualità della risoluzione o interventi incompleti. È una metrica importante per analizzare le rilavorazioni e le prestazioni degli agenti. Dove reperirli Ricavato dal registro delle attività dell’incidente, rilevando il passaggio di stato da 'Resolved' a uno stato attivo. Acquisizione Filtrare il registro delle attività per individuare un cambio di 'Status' da 'Resolved' a 'Open' o 'In Progress'. Tipo di evento inferred
	Incidente riassegnato	Indica il trasferimento dell’incidente da un agente o gruppo a un altro e segna un passaggio di consegne nel processo di risoluzione. L’evento viene dedotto rilevando le modifiche successive ai campi «Agent» o «Group» dopo l’assegnazione iniziale.
Perché è importante Riassegnazioni frequenti, o passaggi di consegne, spesso indicano inefficienze del processo, lacune nelle conoscenze o un instradamento iniziale errato. Analizzare questi eventi aiuta a individuare e ridurre i ritardi. Dove reperirli Dedotto dal registro delle attività dell’incidente monitorando ogni modifica ai campi «Agent» o «Group» dopo la prima assegnazione. Acquisizione Rilevi le modifiche ai campi «Agent» o «Group» nella cronologia di controllo del ticket. Tipo di evento inferred
	Obiettivo SLA non rispettato	Si tratta di un evento calcolato che si verifica quando il tempo trascorso dall’apertura di un incidente supera l’obiettivo SLA definito per la risposta o la risoluzione. Freshservice tiene traccia internamente dello stato SLA; l’evento può essere ricavato confrontando le date e le ore con le politiche SLA.
Perché è importante Misura direttamente il rispetto degli impegni sui livelli di servizio. Individuare quando e perché si verificano le violazioni è essenziale per la Dashboard Prestazioni SLA e per il miglioramento continuo. Dove reperirli Si calcola confrontando la data e l’ora della risposta o della risoluzione con la scadenza prevista dall’obiettivo SLA. Freshservice spesso contrassegna i ticket come 'SLA Violated'. Acquisizione Ricavare l’evento confrontando la data e l’ora di 'Resolved at' con quelle di 'Due by', oppure rilevando il passaggio del campo 'SLA Status' a 'Violated'. Tipo di evento calculated
	Prima risposta inviata	Questa attività rappresenta la prima comunicazione inviata da un agente all’utente dopo la segnalazione dell’incidente. Può trattarsi di una nota pubblica o di una risposta diretta. Freshservice registra tutte le comunicazioni degli agenti con la relativa data e ora.
Perché è importante Rispettare lo SLA della prima risposta è un KPI fondamentale per la soddisfazione dei clienti. Questa attività consente di misurare e analizzare la rapidità con cui gli agenti prendono in carico i nuovi incidenti. Dove reperirli Individuata tramite la data e l’ora della prima nota pubblica o risposta aggiunta da un agente nella cronologia della conversazione dell’incidente. Acquisizione Filtri la cronologia della conversazione dell’incidente per individuare la prima voce inserita da un agente. Tipo di evento explicit
	Soluzione alternativa fornita	Questa attività indica che è stata comunicata all’utente una soluzione temporanea per limitare l’impatto dell’incidente. Per rilevarla può essere necessaria una configurazione specifica del sistema, ad esempio una casella di controllo dedicata, un tipo di nota specifico o l’analisi di parole chiave nelle note degli agenti.
Perché è importante Consente di analizzare l’efficacia delle soluzioni alternative nel ridurre l’impatto sulle attività aziendali e il loro rapporto con i tempi di risoluzione definitiva. Supporta la Dashboard delle metriche sull’efficacia delle soluzioni alternative. Dove reperirli Probabilmente non si tratta di un evento esplicito. Può essere dedotto segnalando le note che contengono parole chiave come «workaround» oppure registrando le modifiche a un campo personalizzato «Workaround Provided». Acquisizione Dedotto da una modifica a un campo personalizzato o dall’analisi delle parole chiave nelle note degli agenti. Tipo di evento inferred
	Stato modificato in Pending	Indica una pausa nel processo di risoluzione, in genere in attesa di informazioni da parte dell’utente o di terzi. Si deduce da una modifica dello stato a un valore «Pending». Il tempo trascorso in questo stato è spesso escluso dal calcolo degli SLA.
Perché è importante Individuare il tempo trascorso negli stati in attesa è fondamentale per capire le dipendenze esterne e i ritardi. Aiuta a distinguere il tempo di lavoro degli agenti dal tempo di attesa. Dove reperirli Dedotto dal registro delle attività dell’incidente quando il campo «Status» viene aggiornato a un valore come «Pending» o «Awaiting User Response». Acquisizione Filtri il registro delle attività per individuare le modifiche a uno stato di attesa e utilizzi la data e l’ora corrispondenti. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Freshservice

Passaggi

Acceda ad Analisi di Freshservice: acceda alla Sua istanza Freshservice con un account autorizzato ad accedere ai report e a crearli. Dal menu principale, apra il modulo Analisi.
Crei un nuovo report: selezioni il pulsante Nuovo report. Assegni un nome descrittivo, ad esempio "Event Log della gestione degli incidenti". Quando Le viene chiesto di scegliere un’origine dati, selezioni il modulo Gestione degli incidenti.
Selezioni il widget del report: nell’editor del report, aggiunga un nuovo widget e scelga il tipo Tabella. La tabella costituirà la base dei dati dell’Event Log.
Aggiunga le colonne dei dati principali: nel pannello delle origini dati a destra, trascini i campi necessari nella configurazione delle colonne della tabella. Inizi con ID incidente, Data di creazione, Agente, Gruppo, Priorità, Gravità, Stato e Categoria.
Includa i dati delle attività: per registrare i singoli eventi, deve unire o includere i dati delle attività dei ticket. Aggiunga al widget l’origine dati Attività. Da questa origine, aggiunga Data di esecuzione (per la data e ora dell’evento) e Descrizione attività, o campi analoghi che descrivano la modifica avvenuta.
Crei una colonna calcolata 'ActivityName': questo è il passaggio più importante. Crei una nuova colonna calcolata o un campo formula. Utilizzi istruzioni IF annidate o una funzione CASE per convertire i dati grezzi delle attività nei valori richiesti per ActivityName. Per la logica dettagliata di ciascuna delle 14 attività, consulti la sezione Query.
Configuri 'EventTimestamp': crei un’altra colonna calcolata per EventTimestamp. La logica deve selezionare la data e ora di creazione per l’attività 'Incident Reported' e la data e ora di esecuzione dell’attività per tutti gli altri eventi.
Applichi i filtri al report: configuri i filtri per restringere i dati. Come minimo, imposti un intervallo di date sul campo 'Data di creazione'. Si consiglia un periodo degli ultimi 3-6 mesi. Aggiunga anche un filtro per includere solo i ticket con 'Tipo di ticket' uguale a 'Incident'.
Esegua e perfezioni il report: esegua il report per generare un’anteprima dei dati. Verifichi che le colonne ActivityName ed EventTimestamp siano compilate correttamente. Se necessario, modifichi le formule e i filtri.
Salvi ed esporti il report: quando il risultato è soddisfacente, salvi il report. Utilizzi l’opzione Esporta e selezioni CSV come formato.
Pianifichi l’esportazione (facoltativo): per le analisi continuative, può pianificare l’esecuzione e l’esportazione automatica del report. Imposti una pianificazione, ad esempio giornaliera o settimanale, per ricevere il CSV via e-mail o in un’altra destinazione.
Prepari i dati per il caricamento: apra il file CSV esportato. Rinomini le intestazioni delle colonne in modo che corrispondano allo schema richiesto da ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup e così via. Aggiunga le colonne statiche SourceSystem (con il valore 'Freshservice') e LastDataUpdate (con la data e ora correnti). Il file è pronto per il caricamento.

Configurazione

Modulo Analisi: per questa estrazione è necessario accedere al modulo Analisi di Freshservice, disponibile nei piani di livello superiore, ad esempio Pro ed Enterprise.
Autorizzazioni necessarie: l’account utente deve disporre di un ruolo che consenta di creare, modificare ed eseguire report nel modulo Analisi.
Intervallo di date: è fondamentale impostare un filtro sull’intervallo di date di creazione degli incidenti per gestire il volume dei dati. Si consiglia un periodo mobile di 3-6 mesi, che offre un buon equilibrio tra contesto storico e prestazioni.
Filtri del report: applichi sempre il filtro 'Tipo di ticket' uguale a 'Incident' per escludere le richieste di servizio e gli altri tipi di ticket dall’analisi del processo.
Campi calcolati: il metodo si basa ampiamente sull’uso di campi calcolati (formule) per ricavare ActivityName ed EventTimestamp di ciascun evento. È utile conoscere l’editor delle formule di Freshservice.
Volume dei dati: tenga presente che l’estrazione genera più righe per ogni incidente, una per ciascuna attività. Nelle istanze Freshservice di grandi dimensioni, il file CSV risultante può essere molto voluminoso e incidere sui tempi di generazione del report e di esportazione.

Query di esempio config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Passaggi

Prerequisiti: verifichi di avere installato Python 3.6 o versione successiva, insieme alle librerie requests e pandas. Può installarle con pip: pip install requests pandas.
Generi una chiave API: acceda alla Sua istanza Freshservice come amministratore. Apra le impostazioni del profilo selezionando l’immagine del profilo nell’angolo in alto a destra. Vada alla sezione 'API Key' e copi la Sua chiave API personale. La custodisca come una password.
Configuri lo script: salvi il codice Python fornito in un file denominato extract_freshservice_incidents.py sul computer locale.
Configuri i parametri: apra il file dello script in un editor di testo. Aggiorni i valori segnaposto di FRESHSERVICE_DOMAIN, ad esempio 'azienda.freshservice.com', API_KEY (la chiave appena copiata) e START_DATE_STR (l’inizio del periodo di estrazione desiderato, nel formato 'YYYY-MM-DD').
Comprenda la logica dello script: lo script recupera innanzitutto tutti i ticket di incidente creati dopo la data di inizio specificata. Scorre ogni pagina dei risultati restituiti dall’API. Per ciascun ticket, effettua una seconda chiamata API per recuperare la cronologia dettagliata delle attività.
Generi l’Event Log: lo script elabora i dati principali dei ticket e il relativo registro delle attività per individuare e creare i record delle 14 attività aziendali richieste. Ad esempio, 'Incident Reported' viene creato a partire dalla data di creazione del ticket, mentre 'Status Changed to In Progress' deriva da una voce specifica del registro delle attività.
Ricavi gli eventi complessi: gli eventi come 'SLA Target Breached' vengono ricavati. Lo script verifica se è stato violato lo SLA di risoluzione del ticket. In caso affermativo, crea un evento con data e ora corrispondenti alla scadenza, indicando il momento in cui si è verificata la violazione.
Esegua lo script: apra un terminale o il prompt dei comandi, raggiunga la cartella in cui ha salvato lo script ed esegua il comando: python extract_freshservice_incidents.py.
Controlli l’esecuzione: lo script mostrerà nella console gli aggiornamenti sullo stato di avanzamento e il numero di ticket elaborati. A seconda del numero di ticket e dei limiti di frequenza dell’API, l’operazione potrebbe richiedere del tempo.
Verifichi il risultato: al termine, lo script genererà nella stessa cartella un file CSV denominato freshservice_incident_event_log.csv, contenente l’Event Log completo.
Prepari il file per il caricamento: apra il CSV con un programma per fogli di calcolo e verifichi che le colonne (IncidentId, ActivityName, EventTimestamp e così via) siano compilate come previsto. Il file è pronto per essere caricato in ProcessMind o in un altro strumento di Process Mining.

Configurazione

FRESHSERVICE_DOMAIN: l’URL specifico della Sua azienda per Freshservice, ad esempio mycompany.freshservice.com. È un parametro obbligatorio dello script.
API_KEY: la chiave API personale di un utente con autorizzazioni sufficienti per leggere tutti i dati degli incidenti. È un parametro obbligatorio.
START_DATE_STR: la data di inizio dell’estrazione dei dati, nel formato 'YYYY-MM-DD'. Per un’analisi significativa, si consiglia di estrarre inizialmente un periodo di 3-6 mesi.
PAGE_SIZE: impostato su 100, il valore massimo consentito dall’API di Freshservice, per ridurre al minimo il numero di chiamate API e migliorare le prestazioni. In genere, si sconsiglia di modificarlo.
Limiti di frequenza dell’API: dopo l’elaborazione di ogni ticket, lo script include una chiamata di base time.sleep(1) per rispettare i limiti di frequenza dell’API di Freshservice. Nelle istanze con volumi elevati potrebbe essere necessario modificare questo intervallo per evitare errori.
Autorizzazioni necessarie: la chiave API deve appartenere a un account utente, ad esempio un account di servizio dedicato, con almeno le autorizzazioni del ruolo 'SD Agent', così da poter accedere a tutti i campi dei ticket e ai registri delle attività necessari nei diversi gruppi del service desk.

Query di esempio python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

Passaggi

Verifichi che il piano Freshservice e le autorizzazioni di amministratore consentano di usare le regole di Workflow Automator, le azioni webhook, l’accesso agli incidenti e la cronologia delle attività dei ticket. Con il team che riceve i dati, verifichi l’endpoint di destinazione, il metodo di autenticazione, i requisiti TLS e le regole di conservazione.
Definisca il contratto degli eventi prima di configurare l’automazione. Utilizzi un oggetto JSON per ogni invio webhook, con IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory e ResolutionSlaTargetTime. Configuri il sistema ricevente in modo da conservare il payload webhook originale e la data e ora di invio.
Crei una regola di Workflow Automator per la creazione degli incidenti. Configuri la regola affinché si attivi alla creazione di un incidente, quindi aggiunga un’azione webhook che invii l’attività Incident Reported. Imposti EventTimestamp sulla data e ora di creazione dell’incidente e ActivityName su Incident Reported.
Crei regole di aggiornamento per le modifiche ad assegnazione, priorità, stato, comunicazioni, note, SLA e chiusura. Configuri le condizioni usando i campi dell’incidente e la cronologia delle attività disponibili nel Suo account Freshservice. Ogni regola deve inviare un evento webhook distinto quando si verifica l’attività corrispondente. Non faccia affidamento su ProcessMind per dedurre le attività da una fotografia finale dell’incidente.
Configuri una mappatura esplicita delle attività. Invii Incident Assigned to Group quando il campo Group riceve il valore iniziale, Agent Assigned to Incident quando il campo Agent riceve il valore iniziale, Incident Prioritized quando Priority viene impostato o modificato, First Response Sent quando viene registrata la prima risposta o nota pubblica dell’agente che soddisfa i criteri, Incident Reassigned quando Agent o Group cambia dopo l’assegnazione iniziale, Status Changed to In Progress e Status Changed to Pending per le transizioni di stato corrispondenti, Workaround Provided solo quando è presente un indicatore di soluzione temporanea configurato, Resolution Note Added quando viene aggiunta una nota di risoluzione, Incident Resolved quando lo stato passa a Resolved, SLA Target Breached quando si verifica la condizione di violazione SLA configurata, Incident Reopened quando lo stato passa da Resolved a uno stato aperto e Incident Closed quando lo stato passa a Closed.
Configuri il corpo della richiesta webhook in formato JSON e includa l’identificativo dell’incidente, il nome dell’attività, la data e ora dell’evento, il sistema di origine, la data e ora dell’ultimo aggiornamento dei dati e gli attributi contestuali consigliati. Utilizzi le variabili webhook rese disponibili dal Suo account Freshservice. Se una variabile obbligatoria non è disponibile nell’editor webhook, la valorizzi nel servizio ricevente tramite un’interfaccia Freshservice approvata oppure lasci il campo vuoto, senza inventare il dato.
Configuri l’idempotenza e la gestione delle consegne sull’endpoint. Utilizzi un identificativo evento stabile, se Freshservice lo rende disponibile. In caso contrario, crei una chiave di deduplicazione a partire da IncidentId, ActivityName, EventTimestamp e dall’identificativo della consegna di origine. Restituisca una risposta HTTP di esito positivo solo dopo aver acquisito il payload in modo duraturo.
Verifichi ogni regola con incidenti di prova controllati. Crei un incidente, assegni un gruppo e un agente, modifichi priorità e stato, invii una risposta conforme ai criteri, aggiunga una soluzione temporanea e una nota di risoluzione se configurate, quindi risolva, riapra e chiuda l’incidente. Verifichi separatamente una violazione SLA usando una regola o una coda di prova controllata. Confermi che ogni attività prevista arrivi in un payload webhook distinto.
Acquisisca i payload webhook in un’area di preparazione persistente, uniformi le date e le ore a un unico fuso orario e trasformi ogni payload in una riga dell’Event Log. Mantenga una riga per ogni attività webhook esplicita. Valorizzi LastDataUpdate con la data e ora di aggiornamento dell’estrazione o dell’acquisizione, non con la data e ora dell’evento aziendale.
Convalidi l’Event Log nell’area di preparazione, rimuova solo le consegne duplicate esatte e conservi le ripetizioni legittime, come più modifiche di priorità o transizioni di stato. Verifichi che ogni riga contenga IncidentId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate.
Esporti l’Event Log normalizzato in CSV o in un altro formato supportato da ProcessMind. Utilizzi esattamente i nomi di colonna IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory e ResolutionSlaTargetTime. Carichi il file oppure colleghi a ProcessMind la sorgente dati preparata, associando IncidentId all’identificativo del caso e ActivityName al campo dell’attività.

Configurazione

Ambito di attivazione: configuri regole Workflow Automator separate per la creazione degli incidenti e per ciascuna condizione di aggiornamento. Una sola regola di aggiornamento generica può generare eventi duplicati o ambigui, a meno che il sistema ricevente non applichi una mappatura rigorosa delle attività.
Payload webhook: includa tutti gli attributi obbligatori in ogni payload. Aggiunga gli attributi consigliati quando sono disponibili al momento dell’evento. Conservi il payload grezzo per gli audit e la riproduzione.
Significato delle attività: distingua le assegnazioni iniziali di gruppo e agente dalle modifiche successive. Le modifiche successive generano Incident Reassigned, mentre l’assegnazione iniziale genera l’attività di assegnazione corrispondente.
Gestione degli stati: associ i valori di stato esatti configurati nell’account Freshservice. Se l’account utilizza stati personalizzati di attesa o apertura, configuri associazioni esplicite per tali valori.
Prima risposta: definisca se è considerata valida una risposta pubblica, una nota pubblica o un altro tipo di comunicazione. Applichi la definizione in modo coerente e generi l’evento solo per la prima comunicazione valida di ciascun incidente.
Rilevamento delle soluzioni temporanee: configuri un campo dedicato, una casella di controllo, un tipo di nota o una regola basata su parole chiave approvate. Senza questa configurazione, non è possibile identificare in modo affidabile Workaround Provided.
Violazione SLA: configuri un’attivazione esplicita per la violazione SLA oppure un processo pianificato separato che confronti l’ora corrente con ResolutionSlaTargetTime. La sola fotografia finale dell’incidente non basta a ricostruire la data e ora della violazione.
Intervallo di date: per la convalida iniziale, utilizzi gli incidenti di un periodo di circa 3-6 mesi. Per l’elaborazione in tempo reale, avvii l’acquisizione prima del periodo di analisi previsto e conservi la cronologia dei webhook per poterli riprodurre.
Filtri: applichi solo filtri approvati per azienda, area di lavoro, reparto, servizio, categoria o data. Non presuma nomi di campi Freshservice o sintassi dei filtri che non siano disponibili nella configurazione dell’account.
Prestazioni: utilizzi l’elaborazione asincrona dei webhook, accodi le richieste in ingresso, raggruppi le scritture successive e indicizzi IncidentId ed EventTimestamp. Eviti chiamate sincrone per arricchire i dati durante la ricezione dei webhook.
Affidabilità: configuri nuovi tentativi, gestione delle consegne non riuscite, monitoraggio e soppressione dei duplicati. Registri le consegne non riuscite e le riproduca dopo aver corretto il problema.
Prerequisiti: accesso di amministratore, disponibilità di Workflow Automator, autorizzazioni per i webhook, un endpoint HTTPS, configurazione dell’autenticazione, funzionalità adeguate del piano Freshservice e un processo di acquisizione o caricamento compatibile con ProcessMind.
Sicurezza: utilizzi HTTPS, limiti ove possibile l’accesso in ingresso, rinnovi periodicamente le credenziali, riduca al minimo i campi sensibili e protegga le descrizioni e le note degli incidenti se incluse nei payload.

Query di esempio config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

È pronto a iniziare?

Utilizzi questo template per configurare correttamente i dati e ottenere informazioni utili sui flussi di lavoro di gestione degli incidenti. Inizi oggi a ridurre i tempi di risoluzione.

Torna alla guida al miglioramento

Scarica il template

Prevenga le violazioni degli SLA: ottimizzi oggi la gestione degli incidenti

Si unisca alle aziende che hanno ridotto del 35% il tempo medio di risoluzione (MTTR) e prevenuto costose violazioni degli SLA.

Inizi la prova gratuita

Prova gratuita di 14 giorni, senza carta di credito.

Il Suo template dei dati per la gestione degli incidenti

Il Suo template dei dati per la gestione degli incidenti

Attributi per la gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Esportare i dati dal modulo Analisi di Freshservice in CSV

Passaggi

Configurazione

Query di esempio config

Estrazione tramite script Python e API REST di Freshservice

Passaggi

Configurazione

Query di esempio python

Invio di dati in tempo reale tramite webhook di Workflow Automator

Passaggi

Configurazione

Query di esempio config

È pronto a iniziare?

Prevenga le violazioni degli SLA: ottimizzi oggi la gestione degli incidenti