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

Il Suo Template dei dati per la gestione degli incidenti

Freshservice

Attributi della 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 è stato progettato per aiutarLa a preparare i dati necessari a un'analisi efficace della gestione degli incidenti. Illustra gli attributi essenziali da raccogliere, le attività critiche da monitorare e fornisce indicazioni pratiche su come estrarre queste informazioni dal Suo 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 della gestione degli incidenti

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo di gestione degli incidenti.

5 Obbligatorio 7 Consigliato 7 Facoltativo

	Nome	Descrizione
	ID incidente IncidentId	L'identificativo univoco di ogni record di incidente, che funge da chiave primaria per monitorare l'intero ciclo di vita dell'incidente.
Descrizione L'Incident ID è il fulcro dell'analisi della gestione degli incidenti. Funziona come Case ID e collega tutte le attività correlate, i timestamp e le modifiche agli attributi in un unico percorso coerente. Nel Process Mining, ogni voce dell'Event Log è associata a un Incident ID, consentendo di ricostruire il flusso end-to-end del processo per ciascun incidente. Questo è essenziale per calcolare i tempi di attraversamento, analizzare le varianti di processo e identificare 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, consentendo di monitorarne e analizzarne il ciclo di vita end-to-end, dalla creazione alla chiusura. Dove reperirlo È l'identificativo primario di un ticket, disponibile tramite la Freshservice Tickets API come campo 'id' dell'oggetto ticket. Esempi INC-10234INC-10235INC-10236
	Nome dell'attività ActivityName	Il nome della specifica attività aziendale o dell'evento verificatosi in un determinato momento del ciclo di vita dell'incidente.
Descrizione Activity Name 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à derivano dalle modifiche apportate ai dati dell'incidente nel tempo. Questo attributo è fondamentale per il Process Mining, poiché definisce i nodi della process map individuata. Analizzando la sequenza e la frequenza delle attività, le organizzazioni possono visualizzare il processo effettivo di risoluzione degli incidenti, identificare i percorsi più comuni, rilevare le deviazioni dalla procedura standard e individuare i cicli di rilavorazione, come le riassegnazioni frequenti. Perché è importante Definisce i passaggi della process map, consentendo di visualizzare e analizzare il flusso di risoluzione degli incidenti, i colli di bottiglia e le deviazioni. Dove reperirlo Questo attributo non è un campo diretto di Freshservice, ma deriva dalle modifiche alle proprietà del ticket, come stato, priorità, assegnazione ad agente o gruppo e aggiunta di note. Esempi Incidente segnalatoIncidente assegnato al gruppoNota di risoluzione aggiuntaIncidente risolto
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati, in genere 'Freshservice'.
Descrizione Questo attributo identifica l'origine dei dati. Sebbene in questo contesto il valore sia costantemente 'Freshservice', si tratta di un campo essenziale negli ambienti in cui vengono combinati dati provenienti da più sistemi per ottenere una visione completa del processo. Includere l'attributo Source System è una best practice per la governance e la tracciabilità dei dati. Garantisce chiarezza sulla provenienza dei dati, un aspetto importante per la convalida, il debugging e la futura estensione del progetto di Process Mining ad altri sistemi di gestione dei servizi o sistemi operativi. Perché è importante Garantisce la tracciabilità e la governance dei dati, identificando chiaramente l'origine dei dati di gestione degli incidenti. Dove reperirlo Si tratta in genere di un valore statico aggiunto durante il processo di trasformazione dei dati (ETL) per identificare il dataset. Esempi FreshserviceFreshservice-EUFreshservice-PROD
	Timestamp dell'evento EventTimestamp	La data e l'ora esatte in cui si è verificata l'attività o l'evento.
Descrizione Event Timestamp, o Start Time, indica il momento preciso in cui si è svolta un'attività. Ogni attività del ciclo di vita dell'incidente, dalla creazione alla chiusura, è associata a un timestamp. Questo attributo è fondamentale per tutte le analisi di Process Mining basate sul tempo. Viene utilizzato per ordinare cronologicamente gli eventi, calcolare la durata tra le attività, misurare il tempo di attraversamento complessivo del caso e analizzare i tempi di attesa. Costituisce la base per creare Dashboard che monitorano le prestazioni rispetto agli SLA, i ritardi nei passaggi di consegne e i tempi complessivi di risoluzione. Perché è importante Fornisce l'ordine cronologico degli eventi, essenziale per calcolare le durate, analizzare i tempi di attraversamento e comprendere le prestazioni del processo. Dove reperirlo Deriva da diversi campi timestamp di Freshservice, come 'created_at', 'updated_at' e i timestamp presenti nelle conversazioni del ticket o nei log di audit. Esempi 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l'ultima volta in cui i dati relativi a questo processo sono stati aggiornati o estratti.
Descrizione Questo attributo fornisce il timestamp dell'ultimo aggiornamento dell'intero dataset dal sistema di origine. È un campo di metadati che si applica all'intero dataset anziché ai singoli eventi, ma viene spesso incluso a livello di evento per garantire coerenza. Nell'analisi, queste informazioni sono fondamentali per comprendere l'aggiornamento dei dati e l'intervallo temporale coperto da Dashboard e KPI. Consentono agli utenti di avere maggiore fiducia nell'attualità degli insight e aiutano a chiarire se gli incidenti più recenti siano inclusi nell'analisi. Perché è importante Informa gli utenti sull'aggiornamento dei dati, assicurando che comprendano l'intervallo temporale coperto dall'analisi. Dove reperirlo È un timestamp di metadati generato durante il processo di 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 assegnato alla risoluzione dell'incidente.
Descrizione Assigned Agent identifica il dipendente del service desk responsabile dell'incidente in un determinato momento. Le modifiche a questo attributo rappresentano un trasferimento di responsabilità tra agenti. 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 i tassi di risoluzione al primo contatto. Viene inoltre utilizzato per analizzare i passaggi di consegne tra agenti, che possono essere fonte di ritardi e inefficienze. Monitorando le assegnazioni agli agenti, i responsabili possono individuare le esigenze formative e riconoscere i membri del team con le migliori prestazioni. 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 reperirlo Disponibile nella Freshservice Tickets API come campo 'responder_id'. Questo ID può essere collegato alla Agents API per ottenere il nome dell'agente. Esempi John DoeJane SmithSupportBot
	Categoria dell'incidente IncidentCategory	La categoria utilizzata per classificare l'incidente, ad esempio Hardware, Software o Network.
Descrizione Incident Category consente di classificare gli incidenti in base al tipo di problema segnalato. Questa classificazione gerarchica aiuta a indirizzare l'incidente al team corretto ed è fondamentale per l'analisi delle tendenze. Questo attributo viene utilizzato nella Dashboard 'Incident Categorization Accuracy' per analizzare se una classificazione iniziale errata comporti tempi di risoluzione più lunghi a causa delle riassegnazioni. Raggruppando gli incidenti per categoria, le organizzazioni possono identificare i problemi ricorrenti, comprendere dove viene impiegata la maggior parte dello sforzo di supporto e definire iniziative di miglioramento mirate. Perché è importante Consente di analizzare le tendenze degli incidenti e aiuta a determinare se una classificazione errata stia causando ritardi nella risoluzione. Dove reperirlo È un campo predefinito ma personalizzabile di Freshservice. È disponibile nella Tickets API 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 sul business.
Descrizione Incident Severity misura l'impatto di un incidente sul business e viene spesso classificata come Low, Medium, High o Critical. Sebbene sia correlata alla priorità, la gravità si concentra sull'impatto, mentre la priorità riguarda l'urgenza. La combinazione di gravità e impatto determina spesso la priorità finale. L'analisi per gravità aiuta a comprendere quanto efficacemente l'organizzazione gestisca gli incidenti con conseguenze rilevanti per il business. Viene utilizzata nelle Dashboard per segmentare i tempi di risoluzione e le prestazioni SLA, assicurando che ai problemi con il maggiore impatto siano riservati il livello di attenzione e le risorse adeguati durante tutto il loro ciclo di vita. Perché è importante Misura l'impatto di un incidente sul business, consentendo di concentrare l'analisi sulla mitigazione dei problemi più dannosi. Dove reperirlo È un campo predefinito di Freshservice, disponibile tramite la Tickets API come 'impact'. I valori sono numerici. Esempi BassaMediaAlta
	Gruppo assegnato AssignedGroup	Il gruppo o il team di supporto attualmente assegnato all'incidente.
Descrizione Assigned Group 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 funzionali diversi. L'analisi di Assigned Group è fondamentale per comprendere i ritardi nei passaggi di consegne e nei trasferimenti. Il Process Mining può visualizzare il flusso degli incidenti tra i gruppi, evidenziando i percorsi di escalation più comuni e misurando il tempo di attesa prima che ciascun gruppo intervenga. Questo aiuta a identificare i colli di bottiglia organizzativi e le opportunità per semplificare la collaborazione tra i team. Perché è importante Tiene traccia del team responsabile, un elemento essenziale per analizzare passaggi di consegne, escalation e ritardi tra i team. Dove reperirlo Disponibile nella Freshservice Tickets API come campo 'group_id'. Questo ID può essere collegato alla Groups API per ottenere il nome del gruppo. Esempi Service DeskGestione della reteSupporto infrastrutturale
	Priorità dell'incidente IncidentPriority	Il livello di priorità dell'incidente, che determina l'urgenza della risposta e della risoluzione.
Descrizione Incident Priority è un campo chiave che determina la rapidità e il livello di attenzione richiesti nella gestione di un incidente. In genere viene definita su una scala come Low, Medium, High e Urgent e spesso determina gli obiettivi SLA. Nel Process Mining, la priorità è una dimensione fondamentale per il filtraggio e l'analisi. Consente di confrontare i processi di risoluzione degli incidenti ad alta priorità con quelli degli incidenti a bassa priorità, verificando che i problemi critici siano gestiti in modo efficiente. Le Dashboard segmentano spesso metriche come il tempo di attraversamento e il rispetto degli SLA in base alla priorità, così da fornire insight utili ai responsabili del supporto. Perché è importante Aiuta a concentrare l'analisi sugli incidenti più critici ed è essenziale per valutare le prestazioni SLA e l'allocazione delle risorse. Dove reperirlo Disponibile nella Freshservice Tickets API come campo 'priority'. I valori sono numerici, ad esempio 1 per Low e 4 per Urgent. Esempi BassaMediaAltaUrgente
	Stato dell'incidente IncidentStatus	Lo stato corrente dell'incidente nel suo ciclo di vita, ad esempio Open, Pending, Resolved o Closed.
Descrizione Incident Status indica lo stato corrente dell'incidente. I cambiamenti di stato sono eventi chiave alla base della process map individuata, come 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 identificare i colli di bottiglia, ad esempio gli incidenti che rimangono troppo a lungo nello stato 'Pending' in attesa della risposta dell'utente. È inoltre essenziale per definire i punti di inizio e fine dei calcoli del tempo di attraversamento. Perché è importante Tiene traccia dell'avanzamento dell'incidente nel suo ciclo di vita e aiuta a identificare le fasi in cui i ritardi sono più frequenti. Dove reperirlo Disponibile nella Freshservice Tickets API come campo 'status'. I valori sono numerici. Esempi ApertoIn corsoIn attesaRisoltoChiuso
	Tempo obiettivo SLA per la risoluzione ResolutionSlaTargetTime	Il timestamp entro il quale si prevede che l'incidente venga risolto in base alla relativa policy SLA.
Descrizione Questo attributo memorizza la data e l'ora specifiche che costituiscono la scadenza per la risoluzione di un incidente. L'obiettivo è determinato dalla policy del Service Level Agreement (SLA) applicata al ticket, che in genere dipende da fattori come la priorità. Questo orario obiettivo è essenziale per calcolare il KPI 'SLA Adherence Rate' e alimentare la 'SLA Performance Dashboard'. Confrontando il timestamp effettivo di risoluzione con questo obiettivo, è possibile determinare se un incidente sia stato risolto nei tempi previsti o se abbia violato lo SLA. Si tratta di un elemento fondamentale per misurare la conformità ai livelli di servizio. Perché è importante Fornisce la scadenza per la risoluzione, necessaria per calcolare la conformità SLA e identificare gli incidenti a rischio. Dove reperirlo Disponibile nella Freshservice Tickets API come campi 'fr_due_by' (prima risposta) e 'due_by' (risoluzione). Esempi 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Canale di segnalazione ReportingChannel	Il metodo o canale attraverso il quale è stato segnalato l'incidente, ad esempio Email, Portal o Phone.
Descrizione Reporting Channel, noto anche come origine, identifica il modo in cui un incidente è entrato nel sistema di supporto. I canali più comuni includono e-mail, portale self-service, telefonate e 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, così da determinare quali metodi siano più efficaci e quali richiedano miglioramenti. Ad esempio, gli incidenti segnalati tramite il portale potrebbero essere risolti più rapidamente se contengono fin dall'inizio informazioni più strutturate. Perché è importante Aiuta a identificare i canali di segnalazione più efficienti e mette in evidenza le opportunità per migliorare il processo di acquisizione degli incidenti. Dove reperirlo Disponibile nella Freshservice Tickets API come campo 'source'. I valori sono numerici. Esempi Posta elettronicaPortaleTelefonoChat
	Causa principale RootCause	La ragione sottostante o causa principale identificata per l'incidente dopo l'indagine.
Descrizione L'attributo Root Cause acquisisce il problema fondamentale che ha causato l'incidente. Queste informazioni vengono in genere inserite dagli agenti di supporto durante o dopo la risoluzione, nell'ambito di un processo di analisi della causa principale (RCA). Questo attributo è fondamentale per la Dashboard 'Recurring Incidents And Root Causes' e per il KPI 'Root Cause Analysis Completion Rate'. Analizzando le cause principali ricorrenti, le organizzazioni possono passare dalla correzione reattiva degli incidenti a una gestione proattiva dei problemi, implementando soluzioni permanenti che prevengano incidenti futuri e riducano quelli ricorrenti. Perché è importante Consente una gestione proattiva dei problemi, aiutando a identificare ed eliminare le cause sottostanti degli incidenti ricorrenti. Dove reperirlo È spesso un campo personalizzato di Freshservice, poiché le funzionalità predefinite potrebbero essere limitate. Verificare la configurazione 'Ticket Fields' per individuare un campo denominato 'Root Cause' o simile. Esempi Bug softwareErrore di configurazione della reteProblema di formazione dell'utenteGuasto hardware
	Numero di passaggi di consegna HandoffCount	Il numero di volte in cui un incidente è stato trasferito tra agenti o gruppi diversi.
Descrizione Handoff Count è una metrica calcolata che quantifica il numero di riassegnazioni subite da un incidente durante il suo ciclo di vita. Ogni modifica all'attributo 'AssignedAgent' o 'AssignedGroup' incrementa questo conteggio. Un numero elevato di passaggi di consegne è spesso indice di inefficienza del processo, instradamento iniziale errato o competenze insufficienti degli agenti. Questa metrica supporta direttamente il KPI 'Incident Handoff Count' e la Dashboard 'Handoff And Transfer Delay Analysis', aiutando a identificare gli incidenti o i percorsi di processo caratterizzati da trasferimenti eccessivi che causano ritardi. Perché è importante Quantifica la rilavorazione e le riassegnazioni, aiutando a identificare le inefficienze causate da un instradamento errato o da lacune nelle conoscenze. Dove reperirlo È una metrica calcolata ottenuta contando il numero di valori distinti o di 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 'Sales', 'Finance' o 'IT'. Le informazioni provengono in genere dal profilo dell'utente in Freshservice. Analizzare gli incidenti in base al reparto del richiedente può rivelare se alcune unità aziendali siano colpite dai problemi in misura sproporzionata o se esistano problematiche specifiche di un reparto. Fornisce un contesto prezioso per comprendere l'impatto degli incidenti sul business e può aiutare a dare priorità alle correzioni che interessano i reparti critici. Perché è importante Fornisce un contesto aziendale che consente di analizzare le tendenze degli incidenti e il loro impatto su reparti specifici. Dove reperirlo Queste informazioni sono collegate al richiedente del ticket. Possono essere recuperate dall'endpoint API 'Requesters' utilizzando 'requester_id' del ticket, quindi accedendo a 'department_id' e al nome. Esempi VenditeMarketingFinanzaRisorse umane
	Riaperto IsReopened	Un indicatore calcolato che assume valore true se un incidente è stato riaperto dopo essere stato risolto o chiuso.
Descrizione Questo attributo booleano è un indicatore calcolato che identifica gli incidenti riaperti. Assume valore true se, dopo aver raggiunto lo stato 'Resolved' o 'Closed', lo stato dell'incidente torna a uno stato aperto o in corso. Questo indicatore è fondamentale per calcolare il 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 principale o una chiusura prematura. Analizzare questi casi aiuta a migliorare la qualità e la sostenibilità delle correzioni. Perché è importante Identifica le criticità nel processo di risoluzione, evidenziando gli incidenti in cui la correzione iniziale è stata inefficace e ha generato rilavorazione. Dove reperirlo È un campo calcolato derivato dalla sequenza delle attività nell'Event Log. Assume valore true se si verifica un'attività come 'Incident Reopened' oppure se, per lo stesso Incident ID, un'attività relativa a uno stato aperto segue un'attività relativa a uno stato chiuso. Esempi truefalse
	SLA violato IsSlaBreached	Un indicatore calcolato che assume valore true se l'incidente non è stato risolto entro il tempo obiettivo SLA definito.
Descrizione Questo attributo booleano è una metrica calcolata che indica se il tempo di risoluzione di un incidente ha superato l'obiettivo SLA. Deriva dal confronto tra il timestamp effettivo di risoluzione e 'ResolutionSlaTargetTime'. Questo indicatore alimenta direttamente il KPI 'SLA Adherence Rate' e la 'SLA Performance Dashboard'. Semplifica l'analisi fornendo un esito binario chiaro per le prestazioni SLA di ogni incidente e consentendo una facile aggregazione e analisi delle tendenze. Aiuta a identificare rapidamente il volume e la percentuale di incidenti che non rispettano gli impegni di servizio. Perché è importante Misura direttamente la conformità SLA per ogni incidente, rendendo semplice calcolare i tassi complessivi di rispetto degli SLA e identificare le aree problematiche. Dove reperirlo È un campo calcolato, derivato durante la trasformazione dei dati confrontando il timestamp 'Incident Resolved' con il campo 'ResolutionSlaTargetTime'. Esempi truefalse
	Soluzione temporanea fornita WorkaroundProvided	Un indicatore che segnala se all'utente è stata fornita una soluzione temporanea prima della risoluzione definitiva.
Descrizione Questo attributo booleano indica se è stata implementata una correzione temporanea o una soluzione alternativa per mitigare l'impatto dell'incidente mentre veniva sviluppata una soluzione permanente. Spesso viene monitorato 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 tali correzioni riducano efficacemente l'interruzione del business e contribuiscano 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 accelerare la risoluzione percepita. Dove reperirlo È in genere un campo booleano personalizzato, ossia una casella di controllo. La sua presenza deve essere verificata nella configurazione 'Ticket Fields' di Freshservice. Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione degli incidenti

Questi sono i passaggi chiave e le tappe fondamentali del processo da acquisire nell’Event Log per una corretta individuazione del processo e dei colli di bottiglia.

7 Consigliato 7 Facoltativo

	Attività	Descrizione
	Incidente assegnato al gruppo	Rappresenta l’assegnazione iniziale di un incidente a un gruppo di supporto. Può essere eseguita automaticamente tramite regole di instradamento oppure manualmente da un dispatcher. L’attività viene acquisita monitorando la prima valorizzazione del campo «Group» nell’audit log dell’incidente.
Perché è importante Monitorare le assegnazioni è fondamentale per misurare i tempi di prima risposta e individuare i colli di bottiglia nel processo di smistamento. Aiuta ad analizzare l’efficienza con cui gli incidenti vengono indirizzati al team corretto. Dove reperirlo Dedotto dalla prima voce dell’activity log dell’incidente che valorizza o modifica il campo «Group». Acquisizione Individui il primo timestamp in cui il campo «Group» viene valorizzato per un incidente. Tipo di evento inferred
	Incidente chiuso	Rappresenta la chiusura formale e definitiva del record dell'incidente. In genere avviene automaticamente dopo un determinato periodo nello stato 'Resolved', oppure può 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 definitivo del processo. Il tempo totale fino a questo evento corrisponde all'intera durata del ciclo di vita dell'incidente, inclusi eventuali periodi di attesa della conferma dell'utente. Dove reperirlo Dedotto dal log delle attività dell'incidente identificando il momento in cui il campo 'Status' viene aggiornato a 'Closed'. Acquisizione Utilizzare il timestamp della voce del log delle attività relativa al cambiamento di stato a 'Closed'. Tipo di evento inferred
	Incidente prioritizzato	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’evento viene acquisito monitorando le modifiche al campo «Priority» nella cronologia dell’incidente.
Perché è importante Una prioritizzazione errata o tardiva può causare violazioni degli SLA e un’allocazione inefficiente delle risorse. Analizzare questa attività aiuta a garantire che gli incidenti critici ricevano un’attenzione immediata. Dove reperirlo Dedotto dall’activity log dell’incidente, che registra tutti gli aggiornamenti al campo «Priority». Acquisizione Utilizzi i timestamp dell’audit log in corrispondenza dell’impostazione o della modifica del valore del campo «Priority». Tipo di evento inferred
	Incidente risolto	Indica il momento in cui l’agente ha implementato una correzione e considera risolto l’incidente. Viene acquisito quando lo stato dell’incidente viene modificato in «Resolved». In Freshservice rappresenta una milestone fondamentale, poiché arresta il conteggio dello SLA.
Perché è importante È una milestone fondamentale per misurare il Time to Resolution, TTR. Il periodo tra «Resolved» e «Closed» è importante per analizzare i ritardi nella conferma da parte dell’utente e le policy di chiusura automatica. Dove reperirlo Dedotto dall’activity log dell’incidente individuando il momento in cui il campo «Status» viene aggiornato a «Resolved». Acquisizione Utilizzi il timestamp della voce dell’activity log relativa alla modifica dello stato in «Resolved». Tipo di evento inferred
	Incidente segnalato	Indica la creazione di un nuovo record di incidente in Freshservice. È il punto di partenza del ciclo di vita dell’incidente, generalmente attivato da un utente finale tramite portale o e-mail, oppure da un agente dell’help desk che crea un ticket per suo conto. Questo evento viene registrato esplicitamente con un timestamp di creazione.
Perché è importante Questa attività rappresenta l’evento iniziale principale dell’intero processo. Analizzare il tempo che intercorre tra questo evento e la risoluzione è fondamentale per misurare i tempi complessivi di ciclo e il rispetto degli SLA. Dove reperirlo Acquisito dal timestamp di creazione della tabella degli incidenti. Freshservice lo registra esplicitamente per ogni nuovo ticket. Acquisizione Utilizzi il timestamp «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 si tratta di un’azione distinta, eseguita prima della modifica dello stato in «Resolved». L’azione e il relativo contenuto vengono registrati esplicitamente.
Perché è importante Indica l’identificazione di una soluzione. Il tempo che intercorre tra questa attività e lo stato «Incident Resolved» può evidenziare attività di revisione interna o un sovraccarico di documentazione. Dove reperirlo Acquisito dal timestamp dell’aggiunta di una nota di risoluzione all’incidente, registrata nella cronologia delle conversazioni. Acquisizione Individui il timestamp della voce «Resolution Note» nel registro delle conversazioni dell’incidente. Tipo di evento explicit
	Stato modificato in In Progress	Questa attività indica l’inizio ufficiale dell’analisi attiva e del lavoro sull’incidente. Viene acquisita 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 milestone aiuta a distinguere il tempo di attesa dal tempo di lavoro effettivo. Analizzare la durata della permanenza di un incidente nello stato «In Progress» è fondamentale per comprendere l’impegno richiesto dalla risoluzione. Dove reperirlo Dedotto dall’activity log dell’incidente individuando il momento in cui il campo «Status» viene aggiornato a «In Progress». Acquisizione Filtri l’activity log per individuare una modifica di stato a «In Progress» e ne utilizzi il timestamp. Tipo di evento inferred
	Agente assegnato all’incidente	Questa attività indica il momento in cui un agente specifico viene incaricato di gestire l’incidente. Rappresenta l’attribuzione della responsabilità individuale sul ticket. L’assegnazione viene registrata nella cronologia delle attività del ticket, indicando quale agente è stato assegnato e quando.
Perché è importante Consente di analizzare il carico di lavoro e le prestazioni degli agenti, nonché il tempo necessario affinché un incidente venga preso in carico da una persona dopo l’assegnazione al gruppo. È fondamentale per le Dashboard sulle prestazioni degli agenti. Dove reperirlo Monitorato attraverso le modifiche al campo «Agent» nell’activity log o nell’audit trail dell’incidente. Acquisizione Individui i timestamp 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, generalmente perché l’utente non concorda con la risoluzione. Viene dedotto da una modifica dello stato da «Resolved» a uno stato come «Open» o «In Progress».
Perché è importante Un tasso elevato di riapertura indica problemi nella qualità della risoluzione o correzioni incomplete. È una metrica fondamentale per analizzare la rilavorazione e le prestazioni degli agenti. Dove reperirlo Dedotto dal log delle attività dell'incidente rilevando un cambiamento di stato da 'Resolved' a uno stato attivo. Acquisizione Filtrare il log delle attività per individuare un cambiamento di 'Status' da 'Resolved' a 'Open' o 'In Progress'. Tipo di evento inferred
	Incidente riassegnato	Indica che l’incidente è stato trasferito da un agente o gruppo a un altro. Rappresenta 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, indicano spesso inefficienze di processo, lacune di conoscenza o un instradamento iniziale errato. Analizzare questi eventi aiuta a individuare e ridurre i ritardi. Dove reperirlo Dedotto dall’activity log dell’incidente monitorando qualsiasi modifica ai campi «Agent» o «Group» dopo la prima assegnazione. Acquisizione Rilevi le modifiche ai campi «Agent» o «Group» nella cronologia di audit del ticket. Tipo di evento inferred
	Obiettivo SLA violato	È un evento calcolato che si verifica quando il tempo trascorso per un incidente supera l’obiettivo SLA definito per la risposta o la risoluzione. Freshservice monitora internamente lo stato SLA e questo evento può essere derivato confrontando i timestamp con le policy SLA.
Perché è importante Misura direttamente il rispetto degli impegni relativi ai livelli di servizio. Individuare quando e perché si verificano le violazioni è essenziale per la Dashboard SLA Performance e per il miglioramento continuo. Dove reperirlo Calcolato confrontando il timestamp della risoluzione o della risposta con l’orario di scadenza previsto dallo SLA. Freshservice spesso contrassegna i ticket come «SLA Violated». Acquisizione Derivi l’evento confrontando il timestamp «Resolved at» con il timestamp «Due by», oppure quando il campo «SLA Status» cambia in «Violated». Tipo di evento calculated
	Prima risposta inviata	Questa attività rappresenta la prima comunicazione di 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 i relativi timestamp.
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 reperirlo Individuata cercando il timestamp della prima nota pubblica o risposta aggiunta da un agente nel registro delle conversazioni dell’incidente. Acquisizione Filtri la cronologia delle conversazioni dell’incidente per individuare la prima voce inserita da un agente. Tipo di evento explicit
	Soluzione temporanea fornita	Questa attività indica che all’utente è stata comunicata una soluzione temporanea o un workaround per mitigare l’impatto dell’incidente. Per acquisirla sono spesso necessarie configurazioni specifiche del sistema, come una casella di controllo dedicata, un tipo di nota specifico o l’analisi delle parole chiave nelle note degli agenti.
Perché è importante Aiuta ad analizzare l’efficacia delle soluzioni temporanee nel ridurre l’impatto aziendale e la loro relazione con il tempo di risoluzione finale. Supporta la Dashboard Workaround Effectiveness Metrics. Dove reperirlo Probabilmente non si tratta di un evento esplicito. Può essere dedotto contrassegnando le note che contengono parole chiave come «workaround» oppure utilizzando un campo personalizzato «Workaround Provided», la cui modifica viene registrata. Acquisizione Dedotto dalla modifica di un campo personalizzato o dall’analisi delle parole chiave nelle note degli agenti. Tipo di evento inferred
	Stato modificato in Pending	Rappresenta un momento in cui il processo di risoluzione viene sospeso, generalmente in attesa di informazioni da parte dell’utente o di terzi. Viene dedotto da una modifica dello stato a un valore «Pending». Il tempo trascorso in questo stato è spesso escluso dai calcoli degli SLA.
Perché è importante Individuare il tempo trascorso negli stati Pending è fondamentale per comprendere le dipendenze esterne e i ritardi. Aiuta a separare il tempo di lavoro degli agenti dal tempo di attesa. Dove reperirlo Dedotto dall’activity log dell’incidente quando il campo «Status» viene aggiornato a un valore come «Pending» o «Awaiting User Response». Acquisizione Filtri l’activity log per individuare le modifiche di stato a qualsiasi valore Pending e utilizzi il timestamp associato. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Freshservice

Passaggi

Acceda ad Analisi di Freshservice: acceda alla Sua istanza Freshservice con un account autorizzato ad accedere e creare report. Dal menu principale, acceda al modulo Analisi.
Crei un nuovo report: faccia clic sul pulsante New Report. Inserisca un nome descrittivo, ad esempio "Incident Management Event Log". Quando Le viene richiesto di scegliere un’origine dei dati, selezioni il modulo Incident Management.
Selezioni il widget del report: nell’editor del report, aggiunga un nuovo widget e selezioni il tipo Table. Questo costituirà la base dei dati dell’event log.
Aggiunga le colonne principali dei dati: dal pannello dell’origine dei dati sulla destra, trascini nella configurazione delle colonne della tabella i campi necessari. Inizi con Incident ID, Created at, Agent, Group, Priority, Severity, Status e Category.
Includa i dati delle attività: per acquisire i singoli eventi, dovrà unire o includere i dati delle attività dei ticket. Aggiunga l’origine dei dati Activities al widget. Da questa origine, aggiunga Performed at, da utilizzare come timestamp dell’evento, e Activity description 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 tradurre i dati grezzi delle attività nei valori ActivityName richiesti. Consulti la sezione Query per la logica dettagliata di ciascuna delle 14 attività.
Configuri 'EventTimestamp': crei un’altra colonna calcolata per EventTimestamp. La logica di questa colonna deve selezionare il timestamp Created at per l’attività 'Incident Reported' e il timestamp Performed at dell’attività per tutti gli altri eventi.
Applichi i filtri del report: configuri i filtri del report per circoscrivere i dati. Come minimo, imposti un filtro sull’intervallo di date del campo 'Created at'. Si consiglia un intervallo relativo agli ultimi 3-6 mesi. Aggiunga inoltre un filtro per includere solo i ticket con 'Ticket Type' uguale a 'Incident'.
Esegua e perfezioni il report: esegua il report per generare un’anteprima dei dati. Riveda l’output per verificare che le colonne ActivityName ed EventTimestamp siano valorizzate correttamente. Modifichi formule e filtri secondo necessità.
Salvi ed esporti il report: quando è soddisfatto dell’output del report, lo salvi. Utilizzi l’opzione Export e selezioni CSV come formato.
Pianifichi l’esportazione, se necessario: per l’analisi continuativa, può pianificare l’esecuzione e l’esportazione automatica del report. Configuri una pianificazione, ad esempio giornaliera o settimanale, per consegnare il CSV al Suo indirizzo e-mail o a un’altra destinazione.
Prepari i dati per il caricamento: apra il file CSV esportato. Rinomini le intestazioni delle colonne affinché 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 il timestamp corrente. Il file è ora pronto per il caricamento.

Configurazione

Modulo Analytics: questa estrazione richiede l'accesso al modulo Analytics di Freshservice, disponibile nei piani di livello superiore, ad esempio Pro ed Enterprise.
Autorizzazioni necessarie: il Suo account utente deve disporre di un ruolo autorizzato a creare, modificare ed eseguire report nel modulo Analytics.
Intervallo di date: è fondamentale impostare un filtro sull'intervallo di date relativo alla creazione degli incidenti, così da gestire il volume dei dati. È consigliato un periodo mobile di 3-6 mesi, per bilanciare contesto storico e prestazioni.
Filtri del report: applichi sempre il filtro 'Ticket Type' uguale a 'Incident' per escludere le richieste di servizio o altri tipi di ticket dall'analisi del processo.
Campi calcolati: il metodo si basa in larga misura sull'uso di campi calcolati, ovvero formule, per ricavare ActivityName ed EventTimestamp per ogni evento. È utile conoscere l'editor delle formule di Freshservice.
Volume dei dati: consideri che, per ogni incidente, questa estrazione genera più righe, una per ciascuna attività. Nelle istanze Freshservice di grandi dimensioni, il file CSV risultante può diventare molto voluminoso, con ripercussioni sui tempi di generazione e sulla velocità di esportazione del report.

a 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 la chiave API: acceda alla Sua istanza Freshservice come amministratore. Apra le impostazioni del profilo facendo clic sulla Sua immagine del profilo nell'angolo in alto a destra. Acceda alla sezione 'API Key' e copi la Sua chiave API personale. Tratti questa chiave come una password.
Configuri lo script: salvi il codice Python fornito in un file denominato extract_freshservice_incidents.py sul Suo computer locale.
Configuri i parametri: apra il file dello script in un editor di testo. Aggiorni i valori segnaposto di FRESHSERVICE_DOMAIN, ad esempio 'yourcompany.freshservice.com', API_KEY, cioè la chiave appena copiata, e START_DATE_STR, ovvero 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. Quindi scorre ogni pagina dei risultati restituiti dall'API. Per ciascun ticket, effettua una seconda chiamata API per recuperare lo storico dettagliato delle attività.
Generazione dell'Event Log: lo script elabora i dati principali del ticket e il relativo registro delle attività per identificare 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: eventi come 'SLA Target Breached' vengono ricavati. Lo script verifica se l'SLA di risoluzione di un ticket è stato violato. In caso affermativo, crea un evento con timestamp corrispondente alla data due_by, indicando il momento in cui si è verificata la violazione.
Esegua lo script: apra un terminale o un prompt dei comandi, raggiunga la directory in cui ha salvato lo script ed esegua il comando: python extract_freshservice_incidents.py.
Monitori l'esecuzione: lo script mostrerà nella console gli aggiornamenti sull'avanzamento, indicando quanti ticket sono stati elaborati. A seconda del numero di ticket e dei limiti di frequenza dell'API, l'operazione potrebbe richiedere del tempo.
Esamini il risultato: al termine, lo script genererà nella stessa directory un file CSV denominato freshservice_incident_event_log.csv. Questo file contiene l'Event Log completo.
Prepari il caricamento: apra il file CSV in un programma per fogli di calcolo e verifichi che le colonne, tra cui IncidentId, ActivityName ed EventTimestamp, siano valorizzate come previsto. Il file è ora pronto per essere caricato in ProcessMind o in un altro strumento di Process Mining.

Configurazione

FRESHSERVICE_DOMAIN: l'URL Freshservice specifico della Sua azienda, 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 nel formato 'YYYY-MM-DD'. Per un'analisi significativa, è consigliato estrarre inizialmente un periodo di dati di 3-6 mesi.
PAGE_SIZE: impostato su 100, il valore massimo consentito dall'API Freshservice, per ridurre al minimo il numero di chiamate API e migliorare le prestazioni. In genere non è consigliabile modificare questo valore.
Limitazione della frequenza API: lo script include una chiamata time.sleep(1) di base dopo l'elaborazione di ogni ticket, per rispettare i limiti di frequenza dell'API Freshservice. Nelle istanze ad alto volume potrebbe essere necessario modificarla per evitare errori.
Autorizzazioni necessarie: la chiave API utilizzata deve appartenere a un account utente, ad esempio un account di servizio dedicato, con almeno le autorizzazioni del ruolo 'SD Agent', così da garantire l'accesso a tutti i campi dei ticket e ai registri delle attività necessari nei diversi gruppi del service desk.

a 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 Suo piano Freshservice e le autorizzazioni di amministratore consentano l'uso di regole Workflow Automator, azioni webhook, accesso agli incidenti e accesso allo storico delle attività dei ticket. Verifichi con il team che riceve i dati l'endpoint di destinazione, il metodo di autenticazione, i requisiti TLS e la policy di conservazione.
Definisca il contratto degli eventi prima di configurare l'automazione. Utilizzi un unico oggetto JSON per ogni consegna webhook, con IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory e ResolutionSlaTargetTime. Configuri il ricevitore affinché conservi il payload webhook originale e il timestamp di consegna.
Crei una regola Workflow Automator per la creazione degli incidenti. Configuri la regola affinché venga eseguita quando viene creato un incidente, quindi aggiunga un'azione webhook che invii l'attività Incident Reported. Imposti EventTimestamp sul timestamp di creazione dell'incidente e ActivityName su Incident Reported.
Crei regole di aggiornamento per le modifiche relative ad assegnazione, priorità, stato, comunicazioni, note, SLA e chiusura. Configuri le condizioni utilizzando i campi dell'incidente e lo storico delle attività disponibili nel Suo account Freshservice. Ogni regola deve inviare un evento webhook separato ogni volta che si verifica l'attività corrispondente. Non faccia affidamento su ProcessMind per dedurre le attività da uno snapshot 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 impostata o modificata, First Response Sent quando viene registrata la prima risposta o nota pubblica qualificante dell'agente, Incident Reassigned quando Agent o Group cambiano 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 viene soddisfatta 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à, il timestamp dell'evento, il sistema di origine, l'ultimo aggiornamento dei dati e gli attributi contestuali consigliati. Utilizzi le variabili webhook di Freshservice esposte dal Suo account. Se una variabile obbligatoria non è disponibile nell'editor webhook, valorizzi il campo nel servizio ricevente chiamando un'interfaccia Freshservice approvata oppure lo lasci vuoto, senza inventare il valore.
Configuri l'idempotenza e la gestione delle consegne sull'endpoint. Utilizzi un identificativo stabile dell'evento, se Freshservice ne espone uno. In caso contrario, costruisca una chiave di deduplicazione a partire da IncidentId, ActivityName, EventTimestamp e dall'identificativo della consegna di origine. Restituisca una risposta HTTP positiva solo dopo aver accettato il payload in modo durevole.
Testi ogni regola con incidenti controllati. Crei un incidente, assegni un gruppo e un agente, modifichi priorità e stato, invii una risposta qualificante, aggiunga una soluzione temporanea e una nota di risoluzione se configurate, risolva, riapra e chiuda l'incidente. Testi separatamente una violazione SLA utilizzando una policy o una coda di test controllata. Verifichi che ogni attività prevista arrivi come payload webhook distinto.
Depositi i payload webhook in un'area di staging durevole, normalizzi i timestamp in 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 il timestamp di aggiornamento dell'estrazione o dell'acquisizione, non con il timestamp dell'evento aziendale.
Convalidi l'Event Log in staging, rimuova solo le consegne duplicate esatte e conservi le ripetizioni legittime, come più modifiche della priorità o transizioni di stato. Verifichi che IncidentId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate siano presenti in ogni riga.
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 o colleghi la fonte dati preparata a ProcessMind, mappando IncidentId come identificativo del caso e ActivityName come campo dell'attività.

Configurazione

Ambito dei trigger: configuri regole Workflow Automator separate per la creazione degli incidenti e per ciascuna condizione di aggiornamento. Un'unica regola di aggiornamento generica può creare eventi duplicati o ambigui, a meno che il ricevitore non applichi una mappatura rigorosa delle attività.
Payload webhook: includa tutti gli attributi obbligatori in ogni payload. Includa gli attributi consigliati quando sono disponibili al momento dell'evento. Conservi il payload grezzo per finalità di audit e riproduzione.
Semantica delle attività: distingua le assegnazioni iniziali di gruppo e agente dalle modifiche successive. Le modifiche successive generano Incident Reassigned, mentre la valorizzazione iniziale genera l'attività di assegnazione iniziale corrispondente.
Gestione degli stati: mappi gli esatti valori di stato configurati nell'account Freshservice. Se l'account utilizza stati personalizzati per le condizioni pending o open, configuri mappature esplicite per tali valori.
Prima risposta: definisca se sono qualificanti una risposta pubblica, una nota pubblica o un altro tipo di comunicazione. Applichi la definizione in modo coerente ed emetta l'evento solo per la prima comunicazione qualificante 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, Workaround Provided non può essere identificato in modo affidabile.
Violazione SLA: configuri un trigger esplicito per la violazione SLA oppure un processo pianificato separato che confronti l'ora corrente con ResolutionSlaTargetTime. Uno snapshot finale dell'incidente non è sufficiente per ricostruire il timestamp della violazione.
Intervallo di date: per la convalida iniziale, utilizzi circa 3-6 mesi di incidenti. Per il funzionamento in tempo reale, inizi l'acquisizione prima del periodo di analisi previsto e conservi lo storico dei webhook per eventuali riproduzioni.
Filtri: applichi esclusivamente filtri approvati per azienda, workspace, reparto, servizio, categoria o data. Non presuma nomi dei campi o sintassi dei filtri Freshservice che non siano esposti nella configurazione dell'account.
Prestazioni: utilizzi l'elaborazione asincrona dei webhook, accodi le richieste in ingresso, esegua scritture a valle in batch e indicizzi IncidentId ed EventTimestamp. Eviti chiamate sincrone di arricchimento durante la ricezione dei webhook.
Affidabilità: configuri tentativi automatici, gestione delle code dei messaggi non recapitabili, monitoraggio e soppressione dei duplicati. Registri le consegne non riuscite e le riproduca dopo aver corretto il problema.
Prerequisiti: accesso amministrativo, disponibilità di Workflow Automator, autorizzazioni webhook, un endpoint HTTPS, configurazione dell'autenticazione, funzionalità sufficienti del piano Freshservice e un processo di caricamento o di destinazione compatibile con ProcessMind.
Sicurezza: utilizzi HTTPS, limiti ove possibile l'accesso in ingresso, ruoti le credenziali, riduca al minimo i campi sensibili e protegga le descrizioni e le note degli incidenti qualora siano incluse nei payload.

a 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 per iniziare?

Utilizzi questo Template per configurare correttamente i dati e ottenere informazioni preziose sui Suoi Workflow di gestione degli incidenti. Inizi oggi stesso il percorso verso tempi di risoluzione ottimizzati.

Torna alla guida al miglioramento Scarica il Template

Fermi le violazioni SLA: ottimizzi oggi la gestione degli incidenti

Si unisca alle aziende che hanno ridotto l'MTTR del 35% e prevengono costose violazioni 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 della gestione degli incidenti

Attività di gestione degli incidenti

Guide all'estrazione

Esportazione dei dati del modulo Analytics di Freshservice in CSV

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite script Python con l'API REST di Freshservice

Passaggi

Configurazione

a Query di esempio python

Invio dei dati in tempo reale tramite webhook di Workflow Automator

Passaggi

Configurazione

a Query di esempio config

Pronto per iniziare?

Fermi le violazioni SLA: ottimizzi oggi la gestione degli incidenti

Il Suo Template dei dati per la gestione degli incidenti

Il Suo Template dei dati per la gestione degli incidenti

Attributi della gestione degli incidenti

Attività di gestione degli incidenti

Guide all'estrazione

Esportazione dei dati del modulo Analytics di Freshservice in CSV

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite script Python con l'API REST di Freshservice

Passaggi

Configurazione

a Query di esempio python

Invio dei dati in tempo reale tramite webhook di Workflow Automator

Passaggi

Configurazione

a Query di esempio config

Pronto per iniziare?

Fermi le violazioni SLA: ottimizzi oggi la gestione degli incidenti

La Sua privacy è importante