> Miglioramento Continuo dei Processi > Incident Management > Freshservice > Template Dati

Template dati: Gestione degli Incidenti

Freshservice

Attributi di Incident Management (20) Attività di Incident Management (14) Guide all'Estrazione (3)

Il Suo template per i dati di gestione degli incidenti

Questo template è progettato per aiutarLa a preparare i Suoi dati per un'analisi efficace della gestione degli incidenti. Delinea gli attributi essenziali da raccogliere, le attività critiche da tracciare e fornisce indicazioni pratiche su come estrarre queste informazioni dal Suo sistema sorgente. Utilizzi questa risorsa per ottimizzare il Suo processo di preparazione dei dati.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

Attributi di Incident Management

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

5 Obbligatorio 7 Consigliato 8 Facoltativo

	Nome	Descrizione
	ID incidente IncidentId	L'identificativo univoco di ogni record di incidente, che funge da chiave primaria per tracciare l'intero ciclo di vita dell'incidente.
Descrizione L'Incident ID è la pietra angolare dell'analisi della gestione degli incidenti. Funziona come Case ID, collegando tutte le attività correlate, i timestamp e i cambiamenti degli attributi in un unico, coeso percorso. Nel Process Mining, ogni event log è associato a un Incident ID, consentendo la ricostruzione del flusso di processo end-to-end per ogni incidente. Questo è essenziale per calcolare i tempi di ciclo, analizzare le varianti di processo e identificare i bottleneck specifici per i singoli casi. Senza un identificatore unico, sarebbe impossibile distinguere tra diversi incidenti e analizzare i loro percorsi dalla segnalazione alla risoluzione. Perché è importante Identifica in modo univoco ogni incidente, consentendo il tracciamento e l'analisi end-to-end del suo ciclo di vita dalla creazione alla chiusura. Dove trovare Questo è l'identificatore primario per un ticket, disponibile tramite l'API dei Ticket di Freshservice come campo 'id' nell'oggetto ticket. Esempi INC-10234INC-10235INC-10236
	Nome attività ActivityName	Il nome della specifica attività di business o evento che si è verificato in un dato momento all'interno del ciclo di vita dell'incidente.
Descrizione Il Nome Attività descrive un singolo passaggio o evento nel processo di gestione degli incidenti, come 'Incidente Assegnato al Gruppo', 'Stato Modificato in In Sospeso' o 'Incidente Risolto'. Queste attività derivano dai cambiamenti nei dati dell'incidente nel tempo. Questo attributo è fondamentale per il Process Mining in quanto definisce i nodi nella mappa di processo scoperta. Analizzando la sequenza e la frequenza di queste attività, le organizzazioni possono visualizzare il processo di risoluzione degli incidenti effettivo, identificare percorsi comuni, rilevare deviazioni dalla procedura standard e individuare loop di rilavorazione come frequenti riassegnazioni. Perché è importante Definisce i passaggi nella mappa di processo, consentendo la visualizzazione e l'analisi del flusso di risoluzione degli incidenti, dei bottleneck e delle deviazioni. Dove trovare Questo attributo non è un campo diretto in Freshservice, ma deriva dalle modifiche alle proprietà del ticket come stato, priorità, assegnazione ad agente/gruppo e aggiunta di note. Esempi Incidente segnalatoIncidente assegnato al 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. Sebbene in questo contesto sarà sempre 'Freshservice', è un campo cruciale in ambienti in cui i dati di più sistemi possono essere combinati per una vista complessiva del processo. Includere l'attributo Sistema di origine è una best practice di data governance e tracciabilità. Garantisce chiarezza sulla provenienza dei dati, fondamentale per la validazione, il debug e per l'eventuale estensione del progetto di Process Mining ad altri sistemi di service management o operativi. Perché è importante Garantisce la tracciabilità e la governance dei dati identificando chiaramente l'origine dei dati di gestione degli incidenti. Dove trovare Questo è tipicamente un valore statico aggiunto durante il processo di trasformazione dei dati (ETL) per etichettare il dataset. Esempi FreshserviceFreshservice-EUFreshservice-PROD
	Timestamp Evento EventTimestamp	La data e l'ora esatte in cui l'attività o l'evento si è verificato.
Descrizione L'Event Timestamp, o Ora di Inizio, segna il momento preciso in cui un'attività ha avuto luogo. Ogni attività nel ciclo di vita dell'incidente, dalla creazione alla chiusura, ha un timestamp associato. Questo attributo è critico per tutte le analisi di Process Mining basate sul tempo. È utilizzato per ordinare gli eventi cronologicamente, calcolare la durata tra le attività, misurare il tempo di ciclo totale del caso e analizzare i tempi di attesa. È la base per costruire dashboard che tracciano le prestazioni degli SLA, i ritardi nei passaggi di consegne e i tempi di risoluzione complessivi. Perché è importante Fornisce l'ordine cronologico degli eventi, essenziale per calcolare le durate, analizzare i cycle time e comprendere le prestazioni del processo. Dove trovare Questo è derivato da vari campi timestamp in Freshservice, come 'created_at', 'updated_at' e dai timestamp all'interno dei log di conversazione o di audit del ticket. Esempi 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Ultimo Data Update LastDataUpdate	Il timestamp che indica l'ultima volta in cui i dati di questo processo sono stati aggiornati o estratti.
Descrizione Questo attributo fornisce il timestamp dell'ultimo aggiornamento dell'intero dataset dal sistema di origine. È un metadato che si applica all'intero dataset più che ai singoli eventi, ma spesso è riportato anche a livello di evento per coerenza. In analisi, questa informazione è fondamentale per comprendere l'attualità dei dati e la finestra temporale coperta da dashboard e KPI. Offre agli utenti fiducia sulla freschezza degli insight e aiuta a gestire le aspettative rispetto all'inclusione degli incidenti più recenti nell'analisi. Perché è importante Informa gli utenti sulla recentezza dei dati, assicurando che comprendano il periodo di tempo coperto dall'analisi. Dove trovare Questo è un timestamp di metadati generato durante il processo di estrazione 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 per risolvere l'incidente.
Descrizione L'Agente Assegnato identifica il singolo dipendente del service desk responsabile dell'incidente in un dato momento. I cambiamenti a questo attributo rappresentano un trasferimento di proprietà tra gli agenti. Questo attributo è essenziale per l'analisi delle prestazioni, abilitando dashboard che tracciano il carico di lavoro degli agenti, il tempo medio di risoluzione per agente e i tassi di risoluzione al primo contatto. È anche utilizzato per analizzare i passaggi di consegne tra agenti, che possono essere una fonte di ritardo e inefficienza. Tracciando le assegnazioni degli agenti, i manager possono identificare le esigenze di formazione e riconoscere i membri del team più performanti. Perché è importante Consente l'analisi delle prestazioni degli agenti, della distribuzione del carico di lavoro e dell'impatto dei passaggi di consegne tra agenti sui tempi di risoluzione. Dove trovare Disponibile nell'API Freshservice Tickets come il campo 'responder_id'. Questo ID può essere unito all'API Agents per ottenere il nome dell'agente. Esempi John DoeJane SmithSupportBot
	Categoria incidente IncidentCategory	La categoria utilizzata per classificare l'incidente, come Hardware, Software o Rete.
Descrizione La Categoria incidente offre un modo per classificare gli incidenti in base al tipo di problema segnalato. Questa classificazione gerarchica aiuta a indirizzare l'incidente al team corretto ed è vitale per l'analisi delle tendenze. Questo attributo è utilizzato nella dashboard 'Accuratezza della categorizzazione degli incidenti' per analizzare se una categorizzazione iniziale errata porti a tempi di risoluzione più lunghi a causa delle riassegnazioni. Raggruppando gli incidenti per categoria, le organizzazioni possono identificare problemi ricorrenti, comprendere dove viene impiegato il maggior sforzo di supporto e personalizzare le iniziative di miglioramento. Perché è importante Consente l'analisi delle tendenze degli incidenti e aiuta a determinare se una categorizzazione errata sta causando ritardi nella risoluzione. Dove trovare Questo è un campo predefinito ma personalizzabile in Freshservice. È disponibile nell'API dei Ticket come 'category', con i campi correlati 'sub_category' e 'item_category'. Esempi HardwareSoftwareProblema di ReteAccesso all'Account
	Gruppo Assegnato AssignedGroup	Il gruppo o il team di supporto attualmente assegnato all'incidente.
Descrizione Il Gruppo Assegnato indica quale team, come 'Supporto di Livello 1', 'Team di Rete' o 'Amministratori di Database', è responsabile dell'incidente. I cambiamenti a questo attributo significano un'escalation o un trasferimento tra diversi team funzionali. L'analisi del Gruppo Assegnato è fondamentale per comprendere i ritardi di passaggio di consegne e trasferimento. Il Process Mining può visualizzare il flusso di incidenti tra i gruppi, evidenziando i percorsi di escalation comuni e misurando il tempo trascorso in attesa che ciascun gruppo agisca. Questo aiuta a identificare i bottleneck organizzativi e le opportunità per ottimizzare la collaborazione inter-team. Perché è importante Traccia quale team è responsabile, cruciale per analizzare i passaggi di consegne, le escalation e i ritardi tra i team. Dove trovare Disponibile nell'API Freshservice Tickets come il campo 'group_id'. Questo ID può essere unito all'API Groups per ottenere il nome del gruppo. Esempi Service DeskOperazioni di ReteSupporto Infrastrutturale
	Priorità incidente IncidentPriority	Il livello di priorità dell'incidente, che determina l'urgenza di risposta e risoluzione.
Descrizione La Priorità incidente è un campo chiave che detta la velocità e l'attenzione richieste per la gestione di un incidente. È tipicamente definita su una scala come Bassa, Media, Alta e Urgente, e spesso influenza gli obiettivi SLA. Nel process mining, la priorità è una dimensione critica per il filtraggio e l'analisi. Permette di confrontare i processi di risoluzione per gli incidenti ad alta priorità rispetto a quelli a bassa priorità, assicurando che le questioni critiche siano gestite in modo efficiente. Le dashboard spesso segmentano metriche come il tempo di ciclo e l'aderenza agli SLA per priorità, per fornire insight azionabili ai manager del supporto. Perché è importante Aiuta a prioritizzare l'analisi sugli incidenti più critici ed è essenziale per valutare le prestazioni degli SLA e l'allocazione delle risorse. Dove trovare Disponibile nell'API Freshservice Tickets come il campo 'priority'. I valori sono numerici (ad esempio, 1 per Bassa, 4 per Urgente). Esempi BassoMedioElevatoUrgente
	Severità incidente IncidentSeverity	Il livello di gravità dell'incidente, che indica l'impatto sull'operatività aziendale.
Descrizione La Severità incidente misura l'impatto che un incidente ha sull'attività, spesso categorizzato come Bassa, Media, Alta o Critica. Sebbene correlata alla priorità, la severità si concentra sull'impatto, mentre la priorità sull'urgenza. La combinazione di severità e impatto determina spesso la priorità finale. L'analisi per severità aiuta a comprendere quanto bene l'organizzazione gestisca gli incidenti con significative conseguenze per il business. Viene utilizzata nelle dashboard per segmentare i tempi di risoluzione e le prestazioni degli SLA, garantendo che i problemi più impattanti ricevano il livello appropriato di attenzione e risorse durante tutto il loro ciclo di vita. Perché è importante Misura l'impatto aziendale di un incidente, consentendo un'analisi focalizzata sulla mitigazione dei problemi più dannosi. Dove trovare Questo è un campo predefinito in Freshservice, disponibile tramite l'API dei Ticket come 'impact'. I valori sono numerici. Esempi BassoMedioElevato
	Stato incidente IncidentStatus	Lo stato attuale dell'incidente nel suo ciclo di vita, come Aperto, In Sospeso, Risolto o Chiuso.
Descrizione Lo Stato Incidente indica lo stato attuale dell'incidente. I cambiamenti di stato sono eventi chiave che costituiscono la base della mappa di processo scoperta, come il passaggio da 'In Corso' a 'In Sospeso' o da 'Risolto' a 'Chiuso'. Questo attributo è fondamentale per comprendere il percorso dell'incidente. L'analisi del tempo trascorso in ogni stato aiuta a identificare i bottleneck, come gli incidenti che rimangono troppo a lungo in uno stato 'In Sospeso' in attesa di una risposta dell'utente. È anche cruciale per definire i punti di inizio e fine per i calcoli del tempo di ciclo. Perché è importante Traccia il progresso dell'incidente lungo il suo ciclo di vita e aiuta a identificare le fasi in cui i ritardi sono comuni. Dove trovare Disponibile nell'API Freshservice Tickets come il campo 'status'. I valori sono numerici. Esempi ApertoIn CorsoIn SospesoRisoltoChiuso
	Tempo obiettivo dello SLA di risoluzione ResolutionSlaTargetTime	Il timestamp entro il quale l'incidente deve essere risolto secondo la policy SLA applicata.
Descrizione Questo attributo memorizza la data e l'ora che rappresentano la scadenza per la risoluzione di un incidente. Questa scadenza è determinata dalla policy SLA applicata al ticket, che in genere dipende da fattori come la priorità. Questa scadenza è essenziale per calcolare il KPI 'SLA Adherence Rate' e per alimentare la dashboard 'SLA Performance'. Confrontando il timestamp di risoluzione effettivo con questa scadenza, è possibile stabilire se un incidente è stato risolto in tempo oppure ha violato l'SLA. È fondamentale per misurare la conformità ai livelli di servizio. Perché è importante Fornisce la scadenza per la risoluzione, necessaria per calcolare la conformità agli SLA e identificare gli incidenti a rischio. Dove trovare Disponibile nell'API Freshservice Tickets come i 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 il canale attraverso il quale l'incidente è stato segnalato, come Email, Portale o Telefono.
Descrizione Il Canale di segnalazione, noto anche come origine, indica come un incidente è entrato nel sistema di supporto. I canali più comuni includono email, portale self-service, telefonate o chat. L’analisi di questo attributo aiuta a valutare l’efficacia dei diversi canali. La dashboard 'Reporting Channel Efficiency' confronta volume degli incidenti e tempo medio di risoluzione per canale, per capire quali metodi sono più efficaci e quali richiedono miglioramenti di processo. Ad esempio, gli incidenti segnalati dal portale possono essere risolti più rapidamente se contengono fin dall’inizio informazioni più strutturate. Perché è importante Aiuta a identificare i canali di segnalazione più efficienti e rivela opportunità per migliorare il processo di acquisizione degli incidenti. Dove trovare Disponibile nell'API Freshservice Tickets come il campo 'source'. I valori sono numerici. Esempi EmailPortaleTelefonoChat
	Causa Radice RootCause	Il motivo alla base, ossia la causa radice individuata per l'incidente a seguito dell'indagine.
Descrizione L'attributo Root Cause registra il problema di fondo che ha provocato l'incidente. Questa informazione viene in genere compilata dagli agenti di supporto durante o dopo la risoluzione, come parte del processo di analisi delle cause (RCA). Questo attributo è cruciale per la dashboard 'Recurring Incidents And Root Causes' e per il KPI 'Root Cause Analysis Completion Rate'. Analizzando le cause radice più frequenti, l'organizzazione può passare dalla gestione reattiva degli incidenti a una gestione proattiva dei problemi, adottando soluzioni permanenti che prevengono nuovi incidenti e riducono le ricorrenze. Perché è importante Abilita una gestione dei problemi proattiva aiutando a identificare ed eliminare le cause sottostanti degli incidenti ricorrenti. Dove trovare Questo è spesso un campo personalizzato in Freshservice, poiché le funzionalità predefinite potrebbero essere limitate. Controlli la configurazione dei 'Campi Ticket' per un campo denominato 'Causa Radice' o simile. Esempi Bug SoftwareErrore di Configurazione della ReteProblema di Formazione UtenteGuasto Hardware
	Dipartimento del richiedente RequestersDepartment	Il dipartimento a cui appartiene l'utente che ha segnalato l'incidente.
Descrizione Questo attributo identifica la funzione aziendale del richiedente, ad esempio 'Vendite', 'Finanza' o 'IT'. Queste informazioni provengono in genere dal profilo utente all'interno di Freshservice. Analizzare gli incidenti per reparto del richiedente può rivelare se alcune unità di business sono colpite in modo sproporzionato o se esistono problemi specifici di reparto. Offre un contesto prezioso per comprendere l'impatto sul business e aiuta a dare priorità agli interventi che incidono sulle funzioni critiche. Perché è importante Fornisce il contesto aziendale, consentendo l'analisi delle tendenze degli incidenti e degli impatti su dipartimenti specifici. Dove trovare Questa informazione è collegata al richiedente del ticket. Può essere recuperata dall'endpoint API 'Requesters' utilizzando il 'requester_id' del ticket, quindi accedendo a 'department_id' e al nome. Esempi VenditeMarketingFinanzaRisorse Umane
	È Riaperto IsReopened	Un flag calcolato che è vero se un incidente è stato riaperto dopo essere stato risolto o chiuso.
Descrizione Questo attributo booleano è un flag calcolato che identifica gli incidenti riaperti. È impostato su true se, dopo aver raggiunto lo stato 'Resolved' o 'Closed', lo stato dell'incidente torna a uno stato aperto o 'In Progress'. Questo flag è fondamentale per calcolare il KPI 'Incident Reopening Rate' e per la dashboard 'Recurring Incidents'. Un tasso elevato di riaperture può indicare problemi nella qualità della risoluzione iniziale, un'analisi della causa radice incompleta o chiusure premature. L'analisi di questi casi aiuta a migliorare la qualità e la sostenibilità delle soluzioni. Perché è importante Identifica i fallimenti nel processo di risoluzione, evidenziando gli incidenti in cui la correzione iniziale è stata inefficace e ha portato a rilavorazioni. Dove trovare Questo è un campo calcolato derivato dalla sequenza di attività nell'Event Log. È vero se si verifica un'attività come 'Incidente Riaperto' o se un'attività in stato aperto segue un'attività in stato chiuso per lo stesso ID Incidente. Esempi truefalse
	Handoff Count HandoffCount	Il numero di volte in cui un incidente è stato trasferito tra diversi agenti o gruppi.
Descrizione Handoff Count è una metrica calcolata che quantifica il numero di riassegnazioni che un incidente subisce durante il suo ciclo di vita. Ogni modifica nell'attributo 'AssignedAgent' o 'AssignedGroup' incrementa questo conteggio. Un handoff count elevato è spesso un indicatore di inefficienza del processo, routing iniziale errato o una mancanza di competenza dell'agente. Questa metrica supporta direttamente il KPI 'Incident Handoff Count' e la dashboard 'Handoff And Transfer Delay Analysis', aiutando a identificare incidenti o percorsi di processo con trasferimenti eccessivi che portano a ritardi. Perché è importante Quantifica le rilavorazioni e le riassegnazioni, aiutando a identificare le inefficienze causate da instradamenti errati o lacune di conoscenza. Dove trovare Questa è una metrica calcolata, derivata dal conteggio del numero di valori distinti o di modifiche nei campi 'AssignedAgent' o 'AssignedGroup' durante il ciclo di vita di un singolo incidente. Esempi 0125
	SLA Violato IsSlaBreached	Un flag calcolato che è vero se l'incidente non è stato risolto entro il tempo target SLA definito.
Descrizione Questo attributo booleano è una metrica calcolata che indica se il tempo di risoluzione di un incidente ha superato la scadenza SLA. Si ottiene confrontando il timestamp di risoluzione effettivo con 'ResolutionSlaTargetTime'. Questo flag alimenta direttamente il KPI 'SLA Adherence Rate' e la dashboard 'SLA Performance'. Semplifica l'analisi fornendo un esito chiaro e binario sulla performance SLA di ciascun incidente, consentendo aggregazioni agevoli 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à agli SLA per ogni incidente, rendendo facile calcolare i tassi di aderenza complessivi e identificare le aree problematiche. Dove trovare Questo è un campo calcolato, derivato durante la trasformazione dei dati confrontando il timestamp di 'Incidente Risolto' con il campo 'ResolutionSlaTargetTime'. Esempi truefalse
	Tempo di ciclo di risoluzione ResolutionCycleTime	Il tempo totale trascorso da quando un incidente è stato segnalato per la prima volta a quando è stato risolto.
Descrizione Il Tempo di ciclo di risoluzione è un indicatore chiave calcolato per ogni incidente. Misura la durata complessiva del processo di gestione dell’incidente dal punto di vista dell’utente, dalla segnalazione iniziale alla conferma della risoluzione. Questa metrica calcolata è la base della dashboard 'Incident Resolution Cycle Time'. È utilizzata per misurare l’efficienza complessiva del processo ed è spesso analizzata secondo dimensioni come priorità, categoria e agente. Individuare gli incidenti con tempi di ciclo lunghi aiuta a evidenziare ritardi e inefficienze sistemiche. Perché è importante È una misura primaria delle prestazioni del processo, indicando direttamente quanto tempo è necessario per risolvere gli incidenti dall'inizio alla fine. Dove trovare Questa è una metrica calcolata. È la differenza tra il timestamp dell'attività 'Incidente Risolto' e l'attività 'Incidente Segnalato'. Esempi 259200000864000003600000
	Workaround Fornito WorkaroundProvided	Un flag che indica se è stata fornita una soluzione temporanea all'utente prima della risoluzione finale.
Descrizione Questo attributo booleano indica se è stata implementata una soluzione temporanea o un workaround per mitigare l'impatto dell'incidente mentre si sviluppava una soluzione definitiva. Spesso viene tracciato tramite una checkbox o uno stato specifico. Nel Process Mining, questo attributo alimenta la dashboard 'Workaround Effectiveness Metrics'. Consente di confrontare i tempi di risoluzione degli incidenti con e senza workaround, aiutando a capire se fornire soluzioni temporanee riduce efficacemente le interruzioni di business e contribuisce 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 trovare Questo è tipicamente un campo booleano (checkbox) personalizzato. La sua esistenza deve essere verificata nella configurazione dei 'Campi Ticket' di Freshservice. Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di Incident Management

Queste sono le fasi chiave del processo e le milestone da registrare nel tuo event log per un'accurata scoperta dei processi e l'identificazione dei colli di bottiglia.

7 Consigliato 7 Facoltativo

	Activity	Descrizione
	Incidente assegnato al gruppo	Rappresenta l’assegnazione iniziale di un incidente a un gruppo di supporto. Può avvenire automaticamente tramite regole di instradamento oppure manualmente da parte di un dispatcher. Questa attività è rilevata tracciando il primo popolamento del campo 'Group' nell’audit log dell’incidente.
Perché è importante Monitorare le assegnazioni è fondamentale per misurare i tempi di prima risposta e identificare i colli di bottiglia nel processo di smistamento. Aiuta ad analizzare l'efficienza con cui gli incidenti vengono indirizzati al team corretto. Dove trovare Inferito dalla prima voce nel log delle attività dell'incidente che popola o modifica il campo 'Gruppo'. Acquisisci Identificare il primo timestamp in cui il campo 'Group' viene popolato per un incidente. Tipo di evento inferred
	Incidente chiuso	Rappresenta la chiusura finale e formale del ticket di incidente. In genere avviene automaticamente dopo un periodo prestabilito 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à è il punto di chiusura definitivo del processo. Il tempo totale fino a questo evento rappresenta l'intera durata del ciclo di vita dell'incidente, inclusi eventuali periodi di conferma da parte dell'utente. Dove trovare Inferito dal log delle attività dell'incidente identificando quando il campo 'Stato' viene aggiornato a 'Chiuso'. Acquisisci Utilizzi il timestamp dalla voce del log attività per il cambio di stato a 'Chiuso'. Tipo di evento inferred
	Incidente con priorità	Si verifica quando la priorità dell'incidente viene impostata o aggiornata. Il livello di priorità determina l'urgenza e gli obiettivi di SLA per la risoluzione. Si rileva monitorando le modifiche al campo 'Priority' nello storico dell'incidente.
Perché è importante Una prioritizzazione errata o ritardata può portare a violazioni degli SLA e a un'allocazione inefficiente delle risorse. L'analisi di questa attività aiuta a garantire che gli incidenti critici ricevano un'attenzione immediata. Dove trovare Inferito dal log delle attività dell'incidente, che traccia tutti gli aggiornamenti al campo 'Priorità'. Acquisisci Utilizzi i timestamp dal log di audit dove il valore del campo 'Priorità' è stato impostato o modificato. Tipo di evento inferred
	Incidente risolto	Segna il punto in cui l'agente ha implementato una correzione e considera l'incidente risolto. Ciò viene registrato quando lo stato dell'incidente viene modificato in 'Risolto'. In Freshservice, questo è un milestone chiave che ferma il conteggio dell'SLA.
Perché è importante Questa è una tappa fondamentale per misurare il Tempo di Risoluzione (TTR). Il periodo tra 'Risolto' e 'Chiuso' è importante per analizzare i ritardi di conferma da parte dell'utente e le politiche di chiusura automatica. Dove trovare Inferito dal log delle attività dell'incidente identificando quando il campo 'Stato' viene aggiornato a 'Risolto'. Acquisisci Utilizzi il timestamp dalla voce del log attività per il cambio di stato a 'Risolto'. Tipo di evento inferred
	Incidente segnalato	Segna la creazione di un nuovo record di incidente in Freshservice. Questo è il punto di partenza del ciclo di vita dell'incidente, attivato solitamente da un utente finale tramite portale o email, oppure da un agente del service desk che apre un ticket a nome dell'utente. Questo evento è esplicitamente registrato con un timestamp di creazione.
Perché è importante Questa attività è l'evento di avvio principale dell'intero processo. Analizzare il tempo da questo evento alla risoluzione è fondamentale per misurare i tempi di ciclo complessivi e l'aderenza agli SLA. Dove trovare Catturato dal timestamp di creazione della tabella degli incidenti. Freshservice lo registra esplicitamente per ogni nuovo ticket. Acquisisci Utilizzi il timestamp 'Creato il' dal 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 rispetto al cambio di stato a 'Resolved'. Questa azione e il suo contenuto sono registrati esplicitamente.
Perché è importante Questo segna l'identificazione di una soluzione. Il tempo tra questo e lo stato 'Incidente Risolto' può indicare una revisione interna o un sovraccarico di documentazione. Dove trovare Catturato dal timestamp nel momento in cui una nota di risoluzione viene aggiunta all'incidente, la quale viene registrata nella cronologia delle conversazioni. Acquisisci Identificare il timestamp della voce 'Resolution Note' nel log della conversazione dell'incidente. Tipo di evento explicit
	Stato cambiato in In Corso	Questa attività segna l'avvio ufficiale dell'analisi e del lavoro sull'incidente. Viene rilevata quando un agente imposta lo stato dell'incidente su 'In Progress'. Si tratta di una modifica di stato standard registrata nella cronologia delle attività del ticket.
Perché è importante Questa tappa aiuta a differenziare tra tempo di attesa e tempo di lavoro attivo. Analizzare la durata in cui un incidente rimane 'In Corso' è fondamentale per comprendere lo sforzo di risoluzione. Dove trovare Inferito dal log delle attività dell'incidente identificando quando il campo 'Stato' viene aggiornato a 'In Corso'. Acquisisci Filtrare il log delle attività per un cambio di status in 'In Progress' e utilizzare il suo timestamp. Tipo di evento inferred
	Agente Assegnato all'Incidente	Questa attività indica il momento in cui un agente specifico viene assegnato alla gestione dell'incidente. Rappresenta la presa in carico individuale del ticket. L'assegnazione è registrata nella cronologia delle attività del ticket, indicando quale agente è stato assegnato e quando.
Perché è importante Questo consente di analizzare il carico di lavoro degli agenti, le prestazioni e il tempo necessario prima che un incidente venga preso in carico da un singolo agente dopo l'assegnazione al gruppo. È fondamentale per le dashboard sulle prestazioni degli agenti. Dove trovare Tracciato attraverso le modifiche al campo 'Agente' nel log delle attività o nel registro di audit dell'incidente. Acquisisci Identificare i timestamp corrispondenti alle modifiche nel 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 concorda con la risoluzione. Si deduce da un cambio di stato da 'Resolved' a uno stato quale 'Open' o 'In Progress'.
Perché è importante Un'elevata percentuale di riaperture indica problemi con la qualità della risoluzione o correzioni incomplete. Questa è una metrica chiave per analizzare il rilavorato e le prestazioni degli agenti. Dove trovare Inferito dal log delle attività dell'incidente rilevando un cambio di stato da 'Risolto' a uno stato attivo. Acquisisci Filtrare il log delle attività per una modifica dello '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. Ciò denota un passaggio di consegne nel processo di risoluzione. Questo evento è inferito rilevando modifiche successive ai campi 'Agente' o 'Gruppo' dopo l'assegnazione iniziale.
Perché è importante Frequenti riassegnazioni, o handoffs, spesso indicano inefficienze di processo, lacune di conoscenza o un routing iniziale errato. L'analisi di questi eventi aiuta a identificare e ridurre i ritardi. Dove trovare Inferito dal log delle attività dell'incidente monitorando qualsiasi modifica ai campi 'Agente' o 'Gruppo' dopo la prima assegnazione. Acquisisci Rilevare modifiche nei campi 'Agent' o 'Group' nella cronologia di audit del ticket. Tipo di evento inferred
	Obiettivo SLA violato	Questo è un evento calcolato che si verifica quando il tempo trascorso su un incidente supera la scadenza SLA definita per la risposta o la risoluzione. Freshservice traccia internamente lo stato SLA e questo evento può essere ricavato confrontando i timestamp con le policy SLA.
Perché è importante Misura direttamente la conformità agli impegni di livello di servizio. Identificare quando e perché si verificano le violazioni è essenziale per la Dashboard delle Prestazioni SLA e per il miglioramento continuo. Dove trovare Calcolato confrontando il timestamp di risoluzione o risposta con il target di scadenza SLA. Freshservice spesso contrassegna i ticket come 'SLA Violated'. Acquisisci Determinare confrontando il timestamp 'Resolved at' con il timestamp 'Due by', o quando il campo 'SLA Status' cambia in 'Violated'. Tipo di evento calculated
	Prima Risposta Inviata	Questa attività rappresenta la prima comunicazione di un agente verso l'utente dopo la segnalazione dell'incidente. Può essere una nota pubblica o una risposta diretta. Freshservice registra tutte le comunicazioni degli agenti con relativo timestamp.
Perché è importante Il raggiungimento dell'SLA di prima risposta è un KPI critico per la soddisfazione del cliente. Questa attività consente la misurazione e l'analisi della velocità con cui gli agenti si impegnano con i nuovi incidenti. Dove trovare Viene identificato trovando il timestamp della prima nota pubblica o risposta aggiunta da un agente nel log della conversazione dell'incidente. Acquisisci Filtrare la cronologia della conversazione dell'incidente per la prima voce inserita da un agente. Tipo di evento explicit
	Stato cambiato in In Sospeso	Rappresenta un punto in cui il processo di risoluzione è in pausa, in genere in attesa di informazioni dall’utente o da terze parti. Si deduce da un cambio di stato a uno stato 'Pending'. Il tempo trascorso in questo stato è spesso escluso dai calcoli degli SLA.
Perché è importante Identificare il tempo trascorso negli stati di attesa è cruciale per comprendere le dipendenze esterne e i ritardi. Aiuta a isolare il tempo di lavoro dell'agente dal tempo di attesa. Dove trovare Inferito dal log delle attività dell'incidente quando il campo 'Stato' viene aggiornato a un valore come 'In Attesa' o 'In Attesa di Risposta Utente'. Acquisisci Filtrare il log delle attività per i cambiamenti di status a qualsiasi stato in sospeso e utilizzare il timestamp associato. Tipo di evento inferred
	Workaround Fornito	Questa attività indica che all'utente è stata comunicata una soluzione temporanea o un workaround per mitigare l'impatto dell'incidente. Il tracciamento richiede spesso una configurazione specifica del sistema, ad esempio una checkbox dedicata, un tipo di nota specifico o l'analisi di parole chiave nelle note degli agenti.
Perché è importante Questo aiuta ad analizzare l'efficacia dei workaround nel ridurre l'impatto sul business e il loro rapporto con il tempo di risoluzione finale. Supporta la dashboard 'Workaround Effectiveness Metrics'. Dove trovare Questo probabilmente non è un evento esplicito. Può essere inferito contrassegnando le note che contengono parole chiave come 'workaround', o se viene utilizzato un campo checkbox personalizzato 'Workaround Provided' e la sua modifica viene registrata. Acquisisci Inferito da una modifica di un campo personalizzato o dall'analisi delle parole chiave nelle note dell'agente. Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi dati da Freshservice

Fasi

Accedere a Freshservice Analytics: Acceda alla Sua istanza Freshservice con un account che disponga delle autorizzazioni per accedere e creare report. Navighi al modulo Analytics dal menu principale.
Creare un Nuovo Report: Clicchi sul pulsante Nuovo Report. Fornisca un nome descrittivo, come "Event Log Gestione Incidenti". Selezioni il modulo Gestione Incidenti quando Le viene richiesto di scegliere una sorgente dati.
Selezionare il Widget del Report: All'interno dell'editor di report, aggiunga un nuovo widget e selezioni il tipo Tabella. Questo costituirà la base dei Suoi dati event log.
Aggiungere Colonne Dati Primari: Dal pannello della sorgente dati sulla destra, trascini e rilasci i campi necessari nella configurazione delle colonne della tabella. Inizi con Incident ID, Created at, Agent, Group, Priority, Severity, Status e Category.
Incorporare i Dati delle Attività: Per catturare eventi individuali, deve unire o includere i dati delle attività del ticket. Aggiunga la sorgente dati Activities al Suo widget. Da questa sorgente, aggiunga Performed at (per il timestamp dell'evento) e Activity description o campi simili che descrivono la modifica avvenuta.
Creare una Colonna Calcolata 'ActivityName': Questo è il passaggio più critico. Crei una nuova colonna calcolata o un campo formula. Utilizzi istruzioni IF annidate o una funzione CASE per tradurre i dati di attività grezzi nei valori ActivityName richiesti. Consulti la sezione Query per la logica dettagliata di ciascuna delle 14 attività.
Configurare l'EventTimestamp: Crei un'altra colonna calcolata per l'EventTimestamp. La logica per questa colonna dovrebbe selezionare il timestamp Created at per l'attività 'Incident Reported' e il timestamp Performed at dell'attività per tutti gli altri eventi.
Applicare i Filtri del Report: Configuri i filtri del report per restringere i dati. Come minimo, imposti un filtro per intervallo di date sul campo 'Created at'. Si raccomanda un range degli ultimi 3-6 mesi. Dovrebbe anche aggiungere un filtro per includere solo ticket in cui 'Tipo di Ticket' è 'Incidente'.
Eseguire e Perfezionare il Report: Esegua il report per generare un'anteprima dei dati. Riveda l'output per assicurarsi che le colonne ActivityName ed EventTimestamp vengano popolate correttamente. Regoli formule e filtri secondo necessità.
Salvare ed Esportare il Report: Una volta soddisfatto dell'output del report, lo salvi. Utilizzi l'opzione Esporta e selezioni CSV come formato.
Pianificare l'Esportazione (Opzionale): Per un'analisi continua, può pianificare l'esecuzione e l'esportazione automatica del report. Imposti una pianificazione (ad esempio, giornaliera o settimanale) per ricevere il CSV via email o a un'altra destinazione.
Preparare i Dati per l'Upload: Apra il file CSV esportato. Rinomini le intestazioni delle colonne per corrispondere allo schema richiesto per ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, ecc. Aggiunga le colonne statiche SourceSystem (con il valore 'Freshservice') e LastDataUpdate (con il timestamp attuale). Il file è ora pronto per l'upload.

Configurazione

Analytics Module: Questa estrazione richiede l'accesso al modulo Analytics di Freshservice, disponibile nei piani di livello superiore (es. Pro, Enterprise).
Required Permissions: Il Suo account utente necessita di un ruolo con autorizzazioni per creare, modificare ed eseguire report nel modulo Analytics.
Date Range: È fondamentale impostare un filtro per intervallo di date sulla data di creazione dell'incidente per gestire il volume dei dati. Si raccomanda un periodo mobile di 3-6 mesi per bilanciare contesto storico e prestazioni.
Report Filters: Filtrare sempre per 'Tipo di Ticket' uguale a 'Incidente' per escludere richieste di servizio o altri tipi di ticket dalla Sua analisi di processo.
Calculated Fields: Il metodo si basa molto sull'uso di campi calcolati (formule) per derivare il ActivityName e l'EventTimestamp per ogni evento. La familiarità con l'editor di formule di Freshservice è vantaggiosa.
Data Volume: Tenga presente che per ogni incidente, questa estrazione genera più righe (una per ogni attività). Per istanze Freshservice di grandi dimensioni, il file CSV risultante può diventare molto grande, influenzando il tempo di generazione del report e la velocità di export.

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'

Fasi

Prerequisiti: Si assicuri di avere Python 3.6+ installato, insieme alle librerie requests e pandas. Può installarle usando pip: pip install requests pandas.
Generare la Chiave API: Acceda alla Sua istanza Freshservice come amministratore. Navighi alle Impostazioni del Suo Profilo cliccando sulla Sua immagine del profilo nell'angolo in alto a destra. Vada alla sezione 'API Key' e copi la Sua chiave API personale. Tratti questa chiave come una password.
Configurare lo Script: Salvi il codice Python fornito in un file chiamato extract_freshservice_incidents.py sulla Sua macchina locale.
Configurare i Parametri: Apra il file dello script in un editor di testo. Aggiorni i valori segnaposto per FRESHSERVICE_DOMAIN (ad esempio, 'yourcompany.freshservice.com'), API_KEY (la chiave che ha appena copiato) e START_DATE_STR (l'inizio del periodo di estrazione desiderato nel formato 'YYYY-MM-DD').
Comprendere la Logica dello Script: Lo script recupera prima tutti i ticket di incidente creati dopo la data di inizio specificata. Itera attraverso ogni pagina di risultati restituiti dall'API. Per ogni ticket, effettua una seconda chiamata API per recuperarne la cronologia dettagliata delle attività.
Generazione del Log degli Eventi: Lo script elabora i dati principali del ticket e il suo log delle attività per identificare e creare registrazioni per ognuna delle 14 attività aziendali richieste. Ad esempio, 'Incident Reported' è creato dalla data di creazione del ticket, mentre 'Status Changed to In Progress' è derivato da una specifica voce nel log delle attività.
Derivare Eventi Complessi: Vengono derivati eventi come 'SLA Target Breached'. Lo script verifica se l'SLA di risoluzione di un ticket è stato violato. In tal caso, crea un evento con timestamp la data due_by, segnando il momento in cui la violazione è avvenuta.
Eseguire lo Script: Apra un terminale o un prompt dei comandi, navighi nella directory dove ha salvato lo script, e lo esegua utilizzando il comando: python extract_freshservice_incidents.py.
Monitorare l'Esecuzione: Lo script stamperà aggiornamenti di progresso sulla console, mostrando quanti ticket sono stati elaborati. A seconda del numero di ticket e dei limiti di rate API, questo potrebbe richiedere del tempo.
Verificare l'Output: Una volta terminato lo script, genererà un file CSV denominato freshservice_incident_event_log.csv nella stessa directory. Questo file contiene il log completo degli eventi.
Preparare per il Caricamento: Apra il file CSV in un programma di foglio di calcolo per assicurarsi che le colonne (IncidentId, ActivityName, EventTimestamp, ecc.) siano popolate come previsto. Il file è ora pronto per il caricamento in ProcessMind o in un altro strumento di process mining.

Configurazione

FRESHSERVICE_DOMAIN: L'URL specifico della Sua azienda Freshservice, ad esempio mycompany.freshservice.com. Questo è un parametro richiesto nello script.
API_KEY: La chiave API personale per un utente con autorizzazioni sufficienti per leggere tutti i dati relativi agli incidenti. Questo è un parametro richiesto.
START_DATE_STR: La data di inizio per l'estrazione dei dati nel formato 'YYYY-MM-DD'. Si raccomanda di estrarre un periodo iniziale di 3-6 mesi di dati per un'analisi significativa.
PAGE_SIZE: Impostato su 100, il massimo consentito dall'API di Freshservice, per minimizzare il numero di chiamate API e migliorare le prestazioni. Generalmente non è consigliato modificare questo valore.
API Rate Limiting: Lo script include una chiamata time.sleep(1) di base dopo l'elaborazione di ogni ticket per rispettare i limiti di frequenza dell'API di Freshservice. Per istanze ad alto volume, questo potrebbe richiedere una regolazione per evitare errori.
Required Permissions: 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' per garantire che possa accedere a tutti i campi ticket e ai log delle attività necessari tra i 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()

Fasi

Accedere a Freshservice Analytics: Acceda alla Sua istanza Freshservice con un account che disponga delle autorizzazioni per accedere e creare report. Navighi al modulo Analytics dal menu principale.
Creare un Nuovo Report: Clicchi sul pulsante Nuovo Report. Fornisca un nome descrittivo, come "Event Log Gestione Incidenti". Selezioni il modulo Gestione Incidenti quando Le viene richiesto di scegliere una sorgente dati.
Selezionare il Widget del Report: All'interno dell'editor di report, aggiunga un nuovo widget e selezioni il tipo Tabella. Questo costituirà la base dei Suoi dati event log.
Aggiungere Colonne Dati Primari: Dal pannello della sorgente dati sulla destra, trascini e rilasci i campi necessari nella configurazione delle colonne della tabella. Inizi con Incident ID, Created at, Agent, Group, Priority, Severity, Status e Category.
Incorporare i Dati delle Attività: Per catturare eventi individuali, deve unire o includere i dati delle attività del ticket. Aggiunga la sorgente dati Activities al Suo widget. Da questa sorgente, aggiunga Performed at (per il timestamp dell'evento) e Activity description o campi simili che descrivono la modifica avvenuta.
Creare una Colonna Calcolata 'ActivityName': Questo è il passaggio più critico. Crei una nuova colonna calcolata o un campo formula. Utilizzi istruzioni IF annidate o una funzione CASE per tradurre i dati di attività grezzi nei valori ActivityName richiesti. Consulti la sezione Query per la logica dettagliata di ciascuna delle 14 attività.
Configurare l'EventTimestamp: Crei un'altra colonna calcolata per l'EventTimestamp. La logica per questa colonna dovrebbe selezionare il timestamp Created at per l'attività 'Incident Reported' e il timestamp Performed at dell'attività per tutti gli altri eventi.
Applicare i Filtri del Report: Configuri i filtri del report per restringere i dati. Come minimo, imposti un filtro per intervallo di date sul campo 'Created at'. Si raccomanda un range degli ultimi 3-6 mesi. Dovrebbe anche aggiungere un filtro per includere solo ticket in cui 'Tipo di Ticket' è 'Incidente'.
Eseguire e Perfezionare il Report: Esegua il report per generare un'anteprima dei dati. Riveda l'output per assicurarsi che le colonne ActivityName ed EventTimestamp vengano popolate correttamente. Regoli formule e filtri secondo necessità.
Salvare ed Esportare il Report: Una volta soddisfatto dell'output del report, lo salvi. Utilizzi l'opzione Esporta e selezioni CSV come formato.
Pianificare l'Esportazione (Opzionale): Per un'analisi continua, può pianificare l'esecuzione e l'esportazione automatica del report. Imposti una pianificazione (ad esempio, giornaliera o settimanale) per ricevere il CSV via email o a un'altra destinazione.
Preparare i Dati per l'Upload: Apra il file CSV esportato. Rinomini le intestazioni delle colonne per corrispondere allo schema richiesto per ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, ecc. Aggiunga le colonne statiche SourceSystem (con il valore 'Freshservice') e LastDataUpdate (con il timestamp attuale). Il file è ora pronto per l'upload.

Configurazione

Analytics Module: Questa estrazione richiede l'accesso al modulo Analytics di Freshservice, disponibile nei piani di livello superiore (es. Pro, Enterprise).
Required Permissions: Il Suo account utente necessita di un ruolo con autorizzazioni per creare, modificare ed eseguire report nel modulo Analytics.
Date Range: È fondamentale impostare un filtro per intervallo di date sulla data di creazione dell'incidente per gestire il volume dei dati. Si raccomanda un periodo mobile di 3-6 mesi per bilanciare contesto storico e prestazioni.
Report Filters: Filtrare sempre per 'Tipo di Ticket' uguale a 'Incidente' per escludere richieste di servizio o altri tipi di ticket dalla Sua analisi di processo.
Calculated Fields: Il metodo si basa molto sull'uso di campi calcolati (formule) per derivare il ActivityName e l'EventTimestamp per ogni evento. La familiarità con l'editor di formule di Freshservice è vantaggiosa.
Data Volume: Tenga presente che per ogni incidente, questa estrazione genera più righe (una per ogni attività). Per istanze Freshservice di grandi dimensioni, il file CSV risultante può diventare molto grande, influenzando il tempo di generazione del report e la velocità di export.

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'

Template dati: Gestione degli Incidenti

Il Suo template per i dati di gestione degli incidenti

Attributi di Incident Management

Attività di Incident Management

Guide all'Estrazione

Freshservice Analytics Module Esportazione dati in CSV

Fasi

Configurazione

a Query di Esempio config

Estrazione con script Python tramite REST API di Freshservice

Fasi

Configurazione

a Query di Esempio python

Invio dei dati in tempo reale tramite webhook di Workflow Automator

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Fermi le violazioni degli SLA: Ottimizzi la gestione degli incidenti oggi