> Miglioramento Continuo dei Processi > Gestione delle Richieste di Servizio > Freshservice > Template Dati

Il suo template dati per la gestione delle richieste di servizio

Freshservice

Attributi della gestione delle richieste di servizio (20) Attività di gestione delle richieste di servizio (15) Guide all'Estrazione (3)

Il suo template dati per la gestione delle richieste di servizio

Questo template fornisce una guida completa per raccogliere i dati necessari all'analisi del processo di gestione delle richieste. Descrive gli attributi essenziali, le attività chiave da monitorare e consigli pratici per l'estrazione dai sistemi sorgente. Utilizzi questa risorsa per costruire un event log solido e approfondito.

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 della gestione delle richieste di servizio

Questi sono i campi dati raccomandati da includere nell'event log per un'analisi completa del processo di gestione delle richieste.

5 Obbligatorio 5 Consigliato 10 Facoltativo

	Nome	Descrizione
	ID Richiesta di Servizio ServiceRequestId	L'identificatore univoco per ogni richiesta di servizio.
Descrizione L'ID della richiesta è un codice univoco assegnato a ogni nuova richiesta in Freshservice. Funge da chiave primaria per tracciarne l'intero ciclo di vita. Nel Process Mining, questo ID è fondamentale perché funge da Case ID. Tutti gli eventi correlati (cambi di stato, assegnazioni, note) sono collegati tramite questo identificatore. Analizzare il percorso di ogni ID consente una visualizzazione end-to-end completa del processo, identificando percorsi comuni, deviazioni o bottleneck che colpiscono i singoli casi. Perché è importante È il Case ID essenziale che collega tutti gli eventi correlati, permettendo di tracciare il percorso completo di ogni singola richiesta. Dove trovare È un campo primario dell'oggetto ticket in Freshservice. È visibile nell'interfaccia utente e accessibile tramite API. Esempi SR-12943SR-13501SR-14011
	Nome attività ActivityName	Il nome dell'evento o del compito accaduto in un momento specifico per una richiesta.
Descrizione Il Nome dell'attività descrive un passaggio o un evento specifico nel ciclo di vita della richiesta. Queste attività sono estratte dai log di sistema, dai cambi di stato o da azioni specifiche, come 'Richiesta assegnata all'agente', 'Nota aggiunta' o 'Richiesta risolta'. Questo attributo è fondamentale per costruire la mappa di processo, che rappresenta visivamente il flusso. Analizzando sequenza e frequenza delle attività, le aziende possono comprendere il processo reale, individuare bottleneck tra i passaggi, misurare le durate e rilevare varianti inefficienti o non conformi. Perché è importante Questo attributo definisce i passaggi nella mappa di processo, permettendo la visualizzazione e l'analisi del workflow delle richieste. Dove trovare Generato dalle 'attività' o dai 'audit' associati a un ticket in Freshservice. Spesso richiede una logica di trasformazione per mappare gli eventi di sistema in nomi di attività comprensibili per il business. Esempi Richiesta di Servizio CreataRichiesta Assegnata all'AgenteRichiesta di Servizio RisoltaRichiesta di Servizio Chiusa
	Timestamp Evento EventTime	Il timestamp preciso di quando si è verificata l'attività.
Descrizione L'Event Time acquisisce la data e l'ora in cui un'attività specifica è stata registrata. Questo timestamp è fondamentale per sequenziare correttamente gli eventi e calcolare le durate. Nel Process Mining, questo attributo ordina le attività di ogni caso e costituisce la base per ogni analisi temporale. Viene utilizzato per calcolare i tempi di ciclo, i tempi di attesa e il rispetto degli SLA. Timestamps precisi sono essenziali per identificare i colli di bottiglia e comprendere le performance del processo. Perché è importante Questo timestamp ordina gli eventi cronologicamente ed è la base per ogni analisi di performance, inclusi i tempi di ciclo e il rilevamento dei bottleneck. Dove trovare Corrisponde al timestamp di creazione di un'attività o di una voce del log di audit in Freshservice. Esempi 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Sistema di Origine SourceSystem	Identifica il sistema da cui i dati sono stati estratti.
Descrizione Questo attributo specifica il sistema di origine dei dati, in questo caso Freshservice. È utile quando si consolidano dati da più sistemi per una visione olistica del processo. Anche se può sembrare superfluo in analisi su un singolo sistema, includerlo è una best practice per la scalabilità futura e la governance dei dati, garantendo chiarezza sulla provenienza delle informazioni. Perché è importante Garantisce la provenienza e la tracciabilità dei dati, fondamentale quando si combinano informazioni da più sistemi o per scopi di governance dei dati. Dove trovare Questo è tipicamente un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati (ETL). Esempi FreshserviceFreshservice-API-v2
	Ultimo `Data Update` LastDataUpdate	Timestamp che indica l'ultimo aggiornamento dei dati dal sistema sorgente.
Descrizione Questo attributo registra data e ora dell'ultima estrazione o aggiornamento dei dati da Freshservice. Fornisce indicazioni sull'attualità dei dati analizzati. In ogni analisi di processo, conoscere la freschezza dei dati è critico. Questo timestamp permette di capire se le informazioni sono recenti, garantendo decisioni operative tempestive e fiducia negli insight derivati. Perché è importante Informa gli utenti sulla freschezza dei dati, garantendo che analisi e decisioni si basino su informazioni aggiornate. Dove trovare Questo valore viene generato e applicato al dataset durante il processo di estrazione e trasformazione dei dati (ETL). Esempi 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Agente Assegnato AssignedAgent	Il nome del singolo agente attualmente assegnato alla richiesta.
Descrizione Questo attributo identifica l'agente di supporto responsabile della richiesta in un dato momento. Le assegnazioni possono cambiare durante il ciclo di vita. Analizzare l'Agente Assegnato è fondamentale per valutare performance e carico di lavoro. Consente di calcolare KPI come il tempo medio di risoluzione per agente, il numero di richieste attive e i tassi di riassegnazione. Aiuta a individuare i top performer, chi necessita di formazione e eventuali squilibri nel carico di lavoro. Perché è importante Consente l'analisi del carico di lavoro degli operatori, delle prestazioni e dell'impatto delle riassegnazioni sui tempi di risoluzione. Dove trovare Disponibile nel campo 'agent' o 'responder' dell'oggetto ticket in Freshservice. Esempi Alice JohnsonRobert SmithNon assegnato
	Priorità Priority	Il livello di priorità della richiesta (Bassa, Media, Alta o Urgente).
Descrizione La priorità indica l'importanza e l'urgenza di una richiesta, determinando tempi di risoluzione e risorse. Può essere impostata automaticamente o manualmente dagli operatori. Nel Process Mining, la Priorità è una dimensione di analisi fondamentale. Permette di segmentare le richieste per confrontare i flussi di lavoro tra elementi ad alta e bassa priorità. È essenziale per l'analisi della conformità SLA e per capire se il triage stia avvenendo in modo efficace. Perché è importante Fondamentale per l'analisi della conformità SLA e per capire se le richieste ricevano il corretto triage in base all'impatto aziendale. Dove trovare Disponibile nel campo 'priority' dell'oggetto ticket in Freshservice. Esempi BassoMedioElevatoUrgente
	Stato Status	Lo stato attuale della richiesta di servizio nel suo ciclo di vita.
Descrizione Il campo Stato rappresenta la fase della richiesta in un dato momento (es. 'Aperto', 'In sospeso', 'Risolto'). I cambi di stato sono spesso la fonte principale di attività per il Process Mining. Analizzare lo Stato fornisce contesto al flusso e aiuta a capire quanto tempo le richieste passano in determinate fasi. Ad esempio, una permanenza prolungata in 'In sospeso' può indicare un bottleneck dovuto all'attesa di informazioni dall'utente o da un fornitore. È un attributo chiave per definire i punti di inizio e fine delle varie fasi del processo. Perché è importante Fornisce un contesto fondamentale per ogni evento e aiuta a misurare il tempo trascorso nei vari stati, come 'Aperto' o 'In sospeso', per identificare i ritardi. Dove trovare Disponibile nel campo 'status' dell'oggetto ticket in Freshservice. Esempi ApertoIn SospesoRisoltoChiuso
	Team assegnato AssignedTeam	Il team di supporto o gruppo assegnato alla gestione della richiesta.
Descrizione Questo attributo indica il gruppo funzionale, come 'Supporto IT Livello 2' o 'Approvvigionamento Hardware', responsabile della richiesta. Una richiesta può essere assegnata a un team prima che un singolo agente la prenda in carico. L'analisi per Team Assegnato aiuta a comprendere le performance di gruppo e a identificare bottleneck in aree specifiche. È cruciale per valutare l'efficienza dei team e ottimizzare l'allocazione delle risorse nell'organizzazione di supporto. Perché è importante Consente l'analisi delle prestazioni e del carico di lavoro a livello di team o gruppo, essenziale per la gestione delle risorse e l'identificazione di colli di bottiglia funzionali. Dove trovare Disponibile nel campo 'group' dell'oggetto ticket in Freshservice. Esempi Service DeskOperazioni di ReteSupporto Applicativo
	Tipo di Servizio ServiceType	Il tipo specifico o la categoria del servizio richiesto.
Descrizione La tipologia di servizio classifica la richiesta in base al tipo di esigenza, come 'Richiesta nuovo hardware', 'Accesso software' o 'Reimpostazione password'. Spesso è collegata all'articolo del catalogo servizi scelto dall'utente. Questo attributo permette di segmentare le richieste per confrontare processi e performance tra diversi servizi. È fondamentale per calcolare KPI come il 'Numero medio di attività per tipo di servizio', utile a identificare i servizi più complessi o pesanti in termini di risorse. Questa analisi guida gli sforzi di semplificazione e automazione per specifiche categorie. Perché è importante Consente il confronto dei flussi e della complessità tra diverse categorie di richieste, aiutando a identificare aree da standardizzare o automatizzare. Dove trovare Spesso corrisponde a 'categoria', 'elemento' o a un campo personalizzato nel ticket di Freshservice, a seconda della configurazione. Esempi Onboarding nuovo dipendenteRichiesta licenza softwareAccesso VPN
	Canale Channel	Il metodo o canale attraverso cui è stata inviata la richiesta di servizio.
Descrizione Il Canale indica come è stata creata la richiesta: ad esempio tramite portale self-service, email, telefono o chat. Questa informazione aiuta a comprendere le preferenze degli utenti e l'efficienza dei canali. L'analisi per canale può rivelare dati importanti. Ad esempio, le richieste via portale potrebbero essere più complete e risolte più velocemente rispetto a quelle via email, che spesso richiedono più interazioni. Questa analisi guida gli sforzi per promuovere i canali più efficienti. Perché è importante Aiuta ad analizzare se il canale di invio influisca sull'efficienza del processo, sul tempo di risoluzione o sulla quantità di rielaborazione richiesta. Dove trovare Disponibile nel campo 'source' dell'oggetto ticket in Freshservice. Esempi EmailPortaleTelefonoChat
	Conteggio Riassegnazioni ReassignmentCount	Il numero totale di volte che una richiesta è stata riassegnata a un agente o team diverso.
Descrizione Questo attributo calcolato conta quante volte una richiesta è stata riassegnata. Un numero elevato di riassegnazioni indica spesso problemi nel triage iniziale, routing errato o squilibri nel carico di lavoro. Supporta la dashboard sulle performance degli agenti e il KPI sul numero medio di riassegnazioni. Analizzare questa metrica aiuta a identificare le debolezze che portano al palleggio dei ticket, riducendo i tempi di risoluzione e la frustrazione di agenti e utenti. Perché è importante Misura l'inefficienza di routing e l'attrito del processo. Un valore elevato indica problemi nel triage iniziale o nel carico di lavoro, con conseguenti ritardi. Dove trovare Viene calcolato contando le attività specifiche di cambio assegnazione per ogni ID richiesta durante la trasformazione dei dati. Esempi 013
	Data di scadenza dell'SLA SlaDueDate	Il termine entro il quale la richiesta deve essere risolta in base allo SLA.
Descrizione Questo attributo specifica la scadenza per la risoluzione della richiesta secondo la policy SLA. È un timestamp calcolato in base all'ora di creazione, alla priorità e agli orari lavorativi. È un dato fondamentale per monitorare le performance in tempo reale e per l'analisi post-mortem della conformità. Confrontando il tempo di risoluzione effettivo con la SlaDueDate, si determina se lo SLA è stato 'Rispettato' o 'Violato'. È la base per calcolare il KPI del tasso di conformità SLA. Perché è importante È il termine ultimo per la risoluzione, base per calcolare se una richiesta ha rispettato o violato lo SLA. Dove trovare Si tratta di un campo calcolato in Freshservice, visibile sul ticket come 'Scade il'. È disponibile tramite API. Esempi 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	Dipartimento del richiedente RequestorDepartment	Il dipartimento a cui appartiene il richiedente.
Descrizione Questo attributo specifica il dipartimento dell'utente (es. 'Vendite', 'Amministrazione', 'Risorse Umane'), solitamente tratto dal profilo utente. Analizzare le performance per dipartimento è un requisito comune. Può evidenziare se certi settori subiscono tempi più lunghi o hanno esigenze specifiche. Questi insight aiutano nell'allocazione delle risorse, nella formazione o nella creazione di servizi dedicati a singoli dipartimenti. Perché è importante Consente di segmentare il processo per business unit, aiutando a identificare problemi specifici di un dipartimento o variazioni nelle prestazioni. Dove trovare Questa informazione è collegata tramite il profilo del richiedente. Può trovarsi nel campo 'dipartimento' predefinito o in un campo utente personalizzato in Freshservice. Esempi FinanzaMarketingTecnologia dell'Informazione
	È una Rilavorazione IsRework	Un flag booleano che indica se la richiesta ha comportato attività di rielaborazione (rework).
Descrizione Questo flag calcolato è impostato su 'vero' se una richiesta subisce attività indicative di rework, come la riapertura dopo la risoluzione, riassegnazioni multiple o continue richieste di informazioni all'utente. Semplifica l'analisi delle inefficienze, permettendo di isolare i casi di rework per confrontarne mappe e tempi con i casi 'lineari'. Supporta direttamente la dashboard di analisi del rework e aiuta a quantificare l'impatto di passaggi inefficienti o informazioni iniziali incomplete. Perché è importante Offre un modo semplice per contrassegnare e analizzare i casi che presentano loop inefficienti o passaggi ripetuti, aiutando a quantificare i costi legati alla scarsa qualità. Dove trovare Calcolato durante la trasformazione dei dati applicando la logica di business alla sequenza di attività per ogni 'ServiceRequestId'. Esempi truefalse
	Nome policy SLA SlaPolicyName	Il nome della policy SLA applicata alla richiesta.
Descrizione Questo attributo identifica la policy SLA specifica che regola i tempi di risposta e risoluzione. Le policy si basano solitamente su priorità, tipo di servizio o gruppo del richiedente. Sapere quale policy è applicata è fondamentale per la dashboard di analisi della conformità. Permette di misurare accuratamente le performance e capire quali policy vengono violate più spesso, portando a una revisione delle prestazioni del processo o della fattibilità degli obiettivi SLA stessi. Perché è importante Identifica i target di servizio specifici su cui viene misurata la richiesta, essenziale per una reportistica accurata della conformità SLA. Dove trovare Queste informazioni fanno parte dei dati SLA associati al ticket. Potrebbe essere necessario interrogare specifici endpoint API o campi relativi agli SLA. Esempi Incidenti alta priorità - 4hRichieste standard - 3 giorniSupporto VIP - 1 ora
	Ora di Fine EndTime	Il timestamp preciso di quando l'attività è stata completata.
Descrizione L'ora di fine (End Time) rappresenta il timestamp di completamento di un'attività. In Freshservice, per molti eventi l'ora di inizio e di fine coincidono. Per le attività basate sullo stato, l'ora di fine corrisponde al timestamp del cambio di stato successivo. Questo attributo è essenziale per calcolare la durata delle attività e i tempi di attesa. Sottraendo l'ora di inizio dall'ora di fine, si determina il tempo di elaborazione di un task, dato fondamentale per identificare le attività più lente e prioritarie per l'ottimizzazione. Perché è importante Consente il calcolo della durata delle attività, fondamentale per identificare i colli di bottiglia e misurare i tempi di elaborazione dei singoli passaggi. Dove trovare Non è un campo diretto nei log di Freshservice. Deve essere derivato prendendo il timestamp dell'evento successivo nella sequenza per quella specifica richiesta. Esempi 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Richiedente Requestor	L'utente che ha inviato la richiesta di servizio.
Descrizione Questo attributo identifica la persona (solitamente un dipendente) che ha avviato la richiesta, fornendo contesto su chi utilizza il service desk. Sebbene non sia sempre la dimensione principale per l'analisi del flusso, l'analisi per richiedente o dipartimento può svelare pattern interessanti. Ad esempio, se un dipartimento invia spesso richieste incomplete, potrebbe indicare la necessità di formazione mirata. È inoltre essenziale per le analisi sull'esperienza del cliente. Perché è importante Fornisce il contesto sull'utente che ha avviato la richiesta, permettendo di analizzare i modelli di richiesta per individuo, dipartimento o sede. Dove trovare Disponibile nel campo 'requester' dell'oggetto ticket in Freshservice. Esempi John DoeJane SmithAccount di servizio
	SLA Violato IsSlaBreached	Un flag booleano che indica se la richiesta di servizio ha superato l'obiettivo SLA di risoluzione.
Descrizione Questo attributo calcolato è un flag booleano che indica se la richiesta è stata chiusa dopo la scadenza SLA. Si ottiene confrontando il timestamp di chiusura o risoluzione con la 'SlaDueDate'. Semplifica l'analisi per la dashboard di conformità SLA, permettendo di filtrare e aggregare facilmente i dati per calcolare il KPI del tasso di conformità. Segmentare per questo flag aiuta a isolare e analizzare le caratteristiche dei processi delle richieste violate rispetto a quelle puntuali. Perché è importante Semplifica l'analisi della conformità agli SLA fornendo un flag chiaro per filtrare e aggregare le richieste che non hanno rispettato i target. Dove trovare È un campo calcolato durante la trasformazione dei dati confrontando il timestamp della risoluzione finale con il campo 'SlaDueDate'. Esempi truefalse
	Tempo di Elaborazione ProcessingTime	La durata del tempo trascorso lavorando attivamente su un'attività.
Descrizione Il tempo di elaborazione (Processing Time) è una metrica calcolata che rappresenta la durata di una singola attività. Si ottiene sottraendo l'ora di inizio (StartTime) dall'ora di fine (EndTime). Questa metrica è fondamentale per l'analisi dei bottleneck. Aggregando i tempi di elaborazione per ogni tipo di attività, emerge chiaramente dove viene impiegata la maggior parte del tempo nel processo. Ciò consente agli analisti di concentrare gli sforzi di miglioramento sulle fasi più critiche, come 'Revisione interna eseguita' o 'Fornitore esterno coinvolto'. Perché è importante Quantifica la durata dei singoli passaggi del processo, evidenziando direttamente le attività più lunghe e i bottleneck. Dove trovare Calcolato durante la preparazione dei dati sottraendo l' 'EventTime' (StartTime) di un evento dall' 'EndTime' (il timestamp dell'evento successivo). Esempi 360086400300

Obbligatorio Consigliato Facoltativo

Attività di gestione delle richieste di servizio

Questi sono i passaggi chiave e le pietre miliari da acquisire nell'event log per una mappatura e un'analisi accurata dei flussi di lavoro delle richieste.

6 Consigliato 9 Facoltativo

	Activity	Descrizione
	Fornitore esterno incaricato	Questa attività indica quando un ticket viene passato a un fornitore esterno per la risoluzione. Si deduce dal cambio di stato in 'In attesa del fornitore' o 'In attesa di terze parti'.
Perché è importante Il coinvolgimento dei fornitori può causare ritardi notevoli. Monitorare questa attività è fondamentale per misurare le loro performance e l'impatto sul ciclo di vita totale della richiesta. Dove trovare Dedotto dalla cronologia dei cambi di stato. Ricerca uno stato configurato per tracciare la dipendenza da fornitori esterni. Acquisisci Rileva quando lo stato del ticket cambia in un valore che indica l'attesa di una terza parte. Tipo di evento inferred
	Obiettivo SLA violato	Un evento calcolato che si verifica quando il tempo di risoluzione di una richiesta supera l'obiettivo definito nel Service Level Agreement (SLA). Non è un evento diretto del sistema, ma deriva dal confronto tra il tempo di risoluzione e la data di scadenza dello SLA.
Perché è importante Misura direttamente le prestazioni rispetto agli impegni ed è un KPI fondamentale per il management. Aiuta a capire quali tipi di richiesta o priorità sono più a rischio. Dove trovare Calcolato confrontando il timestamp 'Resolved' con quello 'SLA Due By'. Se il tempo di risoluzione è successivo, viene generato questo evento. Acquisisci Confronta il timestamp di risoluzione con quello di scadenza SLA. Se resolved_at > sla_due_by, genera questo evento. Tipo di evento calculated
	Richiesta Assegnata all'Agente	Segna il momento in cui una richiesta viene assegnata a un operatore specifico. È un traguardo chiave dedotto monitorando i campi 'Assigned Agent' o 'Owner'.
Perché è importante Questa attività è fondamentale per analizzare il carico di lavoro degli agenti e identificare i bottleneck nell'assegnazione. Il tempo tra la creazione e l'assegnazione è un KPI essenziale. Dove trovare Dedotto dal log delle attività del ticket monitorando le modifiche ai campi 'Agent' o 'Assignee'. Acquisisci Acquisisce il timestamp quando il campo 'Assigned Agent' viene popolato o il suo valore cambia. Tipo di evento inferred
	Richiesta di Servizio Chiusa	Questa è l'attività finale, che segna la conclusione del ciclo di vita della richiesta. Solitamente avviene in automatico dopo un periodo prestabilito in stato 'Risolto' senza riaperture.
Perché è importante Questo evento segna la fine definitiva dell'istanza di processo. Il tempo tra 'Risolto' e 'Chiuso' rappresenta la finestra di conferma per il richiedente. Dove trovare Dedotto dalla cronologia dei cambi di stato. Corrisponde al timestamp in cui lo stato diventa 'Closed'. Acquisisci Acquisisce il timestamp quando lo stato del ticket passa a 'Closed'. Tipo di evento inferred
	Richiesta di Servizio Creata	Questa attività segna l'inizio del ciclo di vita della richiesta quando viene registrata formalmente in Freshservice. L'evento viene catturato alla creazione del ticket (tramite catalogo, email o altro canale), generando un ID richiesta univoco.
Perché è importante Questo è l'evento di inizio primario per il processo. L'analisi del tempo da questa attività ad altre è fondamentale per misurare i tempi di ciclo complessivi e identificare i ritardi iniziali di elaborazione. Dove trovare Questo evento è registrato esplicitamente in Freshservice. Si trova nel log delle attività o nel registro di audit del ticket, solitamente in corrispondenza del timestamp di creazione. Acquisisci Utilizzi il timestamp di creazione del ticket dai dati di Freshservice. Tipo di evento explicit
	Richiesta di Servizio Risolta	Questo traguardo cruciale indica il momento in cui l'agente ha fornito una soluzione e considera il lavoro concluso. Si deduce dal passaggio del ticket allo stato 'Risolto'.
Perché è importante Questa attività segna la fine della fase di lavoro attivo. La durata fino a questo punto è una misura chiave dell'efficienza degli agenti e del processo, nonché la base per il calcolo degli SLA. Dove trovare Dedotto dalla cronologia dei cambi di stato. Corrisponde al momento in cui lo stato è stato impostato per la prima volta su 'Resolved'. Acquisisci Acquisisce il timestamp quando lo stato del ticket passa per la prima volta a 'Resolved'. Tipo di evento inferred
	Informazioni fornite dal richiedente	Si verifica quando l'utente fornisce le informazioni richieste, permettendo all'operatore di riprendere il lavoro. Si deduce in genere dal cambio automatico di stato da 'In sospeso' a 'Aperto'.
Perché è importante Questa attività chiude il ciclo delle richieste di informazioni. Il tempo che intercorre tra la richiesta e la ricezione dei dati è un tempo di attesa critico da analizzare e ottimizzare. Dove trovare Dedotto da un cambio di stato da 'In sospeso' a 'Aperto' o 'In corso', spesso attivato da una risposta del richiedente. Acquisisci Rileva quando lo stato del ticket passa da in sospeso a aperto. Tipo di evento inferred
	Informazioni richieste al richiedente	Rappresenta il momento in cui l'agente assegnato richiede maggiori informazioni all'utente e sospende l'avanzamento. Questo evento è dedotto dal cambio di stato del ticket in 'In sospeso' o 'In attesa dell'utente'.
Perché è importante Questa attività evidenzia una fonte comune di ritardo e rework. Analizzarne la frequenza aiuta a identificare opportunità per migliorare i template delle richieste e la raccolta dati iniziale. Dove trovare Dedotto dalla cronologia dei cambi di stato. Ricerca passaggi a stati come 'Pending Customer Response' o 'Awaiting Information'. Acquisisci Rileva quando lo stato del ticket cambia in un valore che indica l'attesa di un input utente. Tipo di evento inferred
	Nota aggiunta	Rappresenta qualsiasi nota pubblica o privata aggiunta alla richiesta di servizio da un agente o dal richiedente. Si tratta di un evento esplicito registrato nella cronologia delle conversazioni o nel log delle attività del ticket.
Perché è importante L'analisi della frequenza e della tempistica delle note può rivelare modelli di comunicazione, l'efficienza della collaborazione e i punti di confusione nel processo. Dove trovare Registrato esplicitamente nella cronologia della conversazione del ticket in Freshservice. Ogni nota ha un timestamp e un autore. Acquisisci Estrae ogni voce dalla cronologia della conversazione o dal log dei commenti del ticket. Tipo di evento explicit
	Revisione interna effettuata	Indica che una soluzione proposta richiede una revisione o approvazione interna. Viene dedotto da un cambio di stato verso 'Pending Approval' o 'Internal Review'.
Perché è importante Le revisioni interne possono essere fonte di colli di bottiglia, specie nelle richieste ad alto impatto. Misurare questa durata aiuta a snellire i flussi di approvazione. Dove trovare Dedotto dalla cronologia dei cambi di stato. Richiede l'uso di uno stato specifico come 'Pending Internal Approval' nel workflow. Acquisisci Rileva quando lo stato del ticket cambia in un valore che indica una revisione o approvazione interna. Tipo di evento inferred
	Richiesta di Servizio Riaperta	Si verifica quando un utente segnala che il problema persiste dopo che era stato segnato come 'Risolto', riportando il ticket in stato aperto. Si deduce dal cambio di stato da 'Resolved' a 'Open' o 'In Progress'.
Perché è importante Le richieste riaperte sono un chiaro indicatore di bassi tassi di risoluzione alla prima chiamata e di insoddisfazione dei clienti. Monitorare questo loop di rework è fondamentale per migliorare la qualità del servizio. Dove trovare Dedotto dalla cronologia dei cambi di stato. Si tratta di una transizione diretta da 'Resolved' a 'Open'. Acquisisci Rileva un cambio di stato da risolto a aperto. Tipo di evento inferred
	Richiesta in Triage	Rappresenta la valutazione iniziale e la categorizzazione di una nuova richiesta. Questa attività viene solitamente dedotta dalla prima impostazione di una priorità o dall'assegnazione della richiesta a un gruppo, indicando che è stata esaminata ed è entrata in coda.
Perché è importante Monitorare il triage aiuta a misurare l'efficienza del team di prima risposta. Ritardi in questa fase possono influire pesantemente sui tempi totali e sulla conformità SLA. Dove trovare Dedotto dal log delle attività. Viene identificato dal timestamp del primo evento 'Priority Set' o 'Group Assigned' dopo la creazione. Acquisisci Identifica il timestamp più vecchio tra una modifica del campo priorità o una modifica del gruppo di assegnazione. Tipo di evento inferred
	Richiesta Prioritizzata	Questa attività si verifica quando viene assegnato un livello di priorità (Bassa, Media, Alta) alla richiesta. Si rileva tramite i cambiamenti nel campo 'Priorità' nella cronologia del ticket.
Perché è importante La prioritizzazione è critica per l'allocazione delle risorse e il rispetto degli SLA. Analizzare questa fase aiuta a verificare che le richieste siano valutate correttamente e in tempi brevi. Dove trovare Dedotto dalla cronologia delle modifiche dei campi in Freshservice. Monitora gli aggiornamenti al campo 'Priority' e ne acquisisce il timestamp. Acquisisci Rileva una modifica nel campo 'Priority' dal valore nullo o precedente e registra il timestamp. Tipo di evento inferred
	Richiesta Riassegnata	Questa attività registra ogni cambio di agente o gruppo dopo l'assegnazione iniziale. Viene dedotta rilevando gli aggiornamenti successivi nei campi 'Agente assegnato' o 'Gruppo assegnato'.
Perché è importante Le riassegnazioni frequenti indicano possibili problemi nel triage, nel matching delle competenze o nel bilanciamento del carico. Questa attività è vitale per il KPI del conteggio riassegnazioni e per l'analisi del rework. Dove trovare Dedotto dalla cronologia delle modifiche. L'evento viene registrato ogni volta che i campi 'Assigned Agent' o 'Assigned Group' vengono aggiornati dopo l'assegnazione iniziale. Acquisisci Rileva qualsiasi modifica ai campi 'Assigned Agent' o 'Assigned Group' dopo la prima assegnazione. Tipo di evento inferred
	Risoluzione confermata dall'utente	Questa attività rappresenta la conferma esplicita dell'utente che la soluzione fornita è soddisfacente. Può essere dedotta da un feedback positivo o da un commento specifico prima della chiusura.
Perché è importante La conferma fornisce un feedback diretto sulla qualità della risoluzione. Un basso tasso di conferma può indicare che le soluzioni non soddisfano pienamente le esigenze dell'utente, anche se il ticket non viene riaperto. Dove trovare Difficile da catturare direttamente, potrebbe richiedere configurazioni personalizzate. Può essere dedotto da sondaggi di soddisfazione collegati al ticket o dall'applicazione di tag specifici. Acquisisci Richiede l'analisi di dati correlati, come sondaggi sulla soddisfazione o tag applicati dopo la risoluzione. Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi `dati` da `Freshservice`

Fasi

Verifica dei prerequisiti: Assicuratevi di avere un ruolo utente Freshservice con i permessi per accedere e creare report nel modulo Analytics. Di norma, ciò richiede un piano Pro o Enterprise.
Configurazione Automazioni (se necessario): Per un'acquisizione accurata degli eventi, verificate o create due automazioni specifiche in Amministrazione -> Workflow Automator. Prima: un'automazione che aggiunga una nota privata o un tag specifico (es. 'SLA_Breached') al ticket quando scade il timer dello SLA di risoluzione. Seconda: un'automazione che aggiunga un tag specifico (es. 'Resolution_Confirmed') quando viene ricevuto un sondaggio sulla soddisfazione del cliente positivo.
Creazione del report 'Creation Events': Andate alla scheda Analytics in Freshservice. Create un nuovo report selezionando il modulo 'Tickets' come origine dati. Questo report acquisirà il primo evento per ogni richiesta di servizio.
Configurazione Widget del report 'Creation Events': Aggiungete un widget 'Data Table'. Configurate le colonne (metriche) includendo: Ticket ID, Created at, Assigned to, Group, Priority, Status e Category. Applicate un filtro per l'intervallo temporale desiderato, ad esempio gli ultimi 6 mesi.
Esportazione dati 'Creation Events': Eseguite il report ed esportate il widget della tabella dati in un file CSV nominato 'creation_events.csv'.
Creazione del report 'Update Events': Create un secondo report selezionando questa volta il modulo 'Ticket Activities'. Questo report cattura tutte le modifiche e le note successive per ogni richiesta.
Configurazione Widget del report 'Update Events': Aggiungete un widget 'Data Table'. Includete le colonne: Ticket ID, Activity Date, Performed by, Activity Type e, sotto 'Changes', includete Field, Old Value e New Value. Aggiungete anche attributi a livello di ticket come Group, Assigned to, Priority, Status e Category per contestualizzare ogni evento.
Filtro del report 'Update Events': Applicate un filtro su 'Activity Date' coerente con il report di creazione. Filtrate ulteriormente 'Activity Type' per includere solo eventi rilevanti come 'Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added' e 'Public Note added'.
Esportazione dati 'Update Events': Eseguite il report ed esportate la tabella in un file CSV nominato 'update_events.csv'.
Combinazione e trasformazione dati: Aprite i due file in un foglio di calcolo o usate uno script. Copiate i dati di 'update_events.csv' e incollateli sotto quelli di 'creation_events.csv' in un nuovo file chiamato 'event_log.csv'.
Mappatura Attività e Attributi: Nel file 'event_log.csv' combinato, create le nuove colonne: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status e ServiceType. Popolatele seguendo la logica definita nella sezione Query sottostante per tradurre i dati grezzi nel formato finale.
Esportazione finale: Salvate il file 'event_log.csv' trasformato. Assicuratevi che il formato data per EventTime e LastDataUpdate sia standard (es. ISO 8601). Il file è pronto per l'upload nello strumento di Process Mining.

Configurazione

Piano Freshservice: È necessario un piano che includa il modulo Analytics (solitamente Pro o Enterprise).
Permessi Utente: L'utente che esegue l'esportazione deve disporre dei permessi necessari per creare ed eseguire report in Analytics.
Intervallo di date: Si consiglia di estrarre i dati relativi agli ultimi 3-6 mesi per mantenere il set di dati gestibile. Utilizzate un filtro temporale coerente basato su 'Created at' per il report di creazione e su 'Activity Date' per quello degli aggiornamenti.
Filtri del report: Nel modulo report 'Tickets', filtrate per 'Type' = 'Service Request' per isolare il processo corretto. Per il report 'Ticket Activities', filtrate l' 'Activity Type' includendo solo le modifiche rilevanti (Stato, Priorità, Assegnazione, Note) per ridurre il rumore nei dati esportati.
Automazioni richieste: L'estrazione delle attività 'SLA Target Breached' e 'Resolution Confirmed by Requestor' dipende da regole preesistenti nel Workflow Automator che aggiungono una nota o un tag al ticket al verificarsi di tali eventi. Senza queste regole, non sarà possibile acquisire tali attività con questo metodo.

a Query di Esempio config

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Fasi

Prerequisiti: Assicuratevi di avere Python 3.6 o superiore installato, insieme alle librerie requests e pandas. È inoltre necessaria una chiave API di Freshservice con permessi di lettura per i ticket.
Ottenere la Chiave API: Accedete a Freshservice come amministratore. Fate clic sull'icona del profilo in alto a destra, andate su 'Profile Settings' e troverete la chiave API nel pannello di destra. Copiatela e conservatela in modo sicuro.
Salvataggio dello script: Salvate il codice Python fornito in un file denominato extract_freshservice_srm.py sul vostro computer.
Configurazione dei parametri: Aprite lo script con un editor di testo. Individuate la sezione di configurazione iniziale e sostituite i segnaposto per FRESHSERVICE_DOMAIN, API_KEY, START_DATE e END_DATE. Se necessario, modificate il dizionario STATUS_MAPPING se la vostra istanza utilizza ID numerici differenti per gli stati personalizzati.
Installazione delle librerie: Se non avete ancora le librerie necessarie, aprite il terminale e digitate: pip install requests pandas.
Esecuzione dello script: Dal terminale, posizionatevi nella cartella dove avete salvato il file ed eseguite il comando: python extract_freshservice_srm.py.
Monitoraggio: Lo script mostrerà i progressi nella console, indicando quale pagina di ticket sta elaborando. A seconda del volume di dati, l'operazione potrebbe richiedere alcuni minuti.
Recupero del Log degli Eventi: Al termine dell'esecuzione, verrà generato un file freshservice_event_log.csv nella stessa cartella. Questo file contiene il log degli eventi estratto.
Preparazione all'upload: Il file CSV generato è già strutturato con le colonne richieste (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) ed è pronto per essere caricato in ProcessMind senza ulteriori formattazioni.

Configurazione

FRESHSERVICE_DOMAIN: L'URL di Freshservice della vostra organizzazione (es. vostraazienda.freshservice.com).
API_KEY: La chiave API personale ottenuta dal vostro profilo utente in Freshservice. Deve essere trattata come informazione riservata.
START_DATE / END_DATE: L'intervallo temporale per l'estrazione dei ticket, nel formato 'AAAA-MM-GG'. Per un'analisi iniziale, consigliamo un periodo compreso tra 3 e 6 mesi per bilanciare volume di dati e profondità dell'analisi.
STATUS_MAPPING: Un dizionario Python fondamentale nello script che mappa i nomi degli stati personalizzati usati per dedurre gli eventi (come 'Fornitore esterno incaricato') ai relativi ID numerici nel vostro sistema Freshservice. È necessario verificare e aggiornare questi ID affinché corrispondano alla vostra configurazione.
Limiti di velocità delle API: Prestate attenzione ai limiti di velocità delle API previsti dal vostro piano Freshservice. Lo script elabora i ticket in sequenza per rispettare tali limiti, ma per set di dati molto ampi potrebbe essere necessario eseguire l'estrazione in lotti temporali più piccoli.
Ambito dei dati: Lo script è configurato per estrarre esclusivamente i ticket di tipo 'Service Request'. Questo filtro viene applicato durante la fase iniziale di recupero dei ticket.

a Query di Esempio python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain and API key
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com" 
API_KEY = class="hl-string">"[YOUR_API_KEY]"

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Map your custom status names to their numeric IDs in Freshservice ---
class=class="hl-string">"hl-comment"># To find these IDs, you may need to inspect API responses or admin settings
class=class="hl-string">"hl-comment"># Common defaults: Open: 2, Pending: 3, Resolved: 4, Closed: 5
STATUS_MAPPING = {
    class="hl-string">'Open': 2,
    class="hl-string">'Pending': 3, 
    class="hl-string">'Resolved': 4, 
    class="hl-string">'Closed': 5,
    class="hl-string">'Awaiting Customer': 3, class=class="hl-string">"hl-comment"># Example, often maps to Pending
    class="hl-string">'Pending Vendor': [6], class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
    class="hl-string">'Pending Approval': [7]  class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
}
class=class="hl-string">"hl-comment"># --- END CONFIGURATION ---

BASE_URL = fclass="hl-string">"https://{FRESHSERVICE_DOMAIN}/api/v2"
AUTH = (API_KEY, class="hl-string">"X")

class=class="hl-string">"hl-comment"># Caching for agent and group lookups to reduce API calls
agent_cache = {}
group_cache = {}

def get_api_data(url):
    class="hl-string">"""Helper function to handle API requests and rate limiting."""
    while True:
        try:
            response = requests.get(url, auth=AUTH)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            return response.json()
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue
            else:
                print(fclass="hl-string">"HTTP Error: {e}")
                return None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            return None

def get_agent_name(agent_id):
    class="hl-string">"""Fetch agent name by ID with caching."""
    if not agent_id: return None
    if agent_id in agent_cache:
        return agent_cache[agent_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/agents/{agent_id}")
    if data and class="hl-string">'agent' in data:
        name = data[class="hl-string">'agent'][class="hl-string">'first_name'] + class="hl-string">' ' + data[class="hl-string">'agent'][class="hl-string">'last_name']
        agent_cache[agent_id] = name
        return name
    return None

def get_group_name(group_id):
    class="hl-string">"""Fetch group name by ID with caching."""
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/groups/{group_id}")
    if data and class="hl-string">'group' in data:
        name = data[class="hl-string">'group'][class="hl-string">'name']
        group_cache[group_id] = name
        return name
    return None

def parse_iso_datetime(dt_string):
    if not dt_string: return None
    return datetime.fromisoformat(dt_string.replace(class="hl-string">'Z', class="hl-string">'+00:00'))

def main():
    event_log = []
    last_data_update = datetime.now().isoformat()

    page = 1
    while True:
        print(fclass="hl-string">"Fetching tickets, page {page}...")
        query = fclass="hl-string">'"created_at:>\\'{START_DATE}\\class="hl-string">' AND created_at:<\\'{END_DATE}\\class="hl-string">' AND ticket_type:\\\'Service Request\\\class="hl-string">'"'
        url = fclass="hl-string">"{BASE_URL}/tickets?query={query}&page={page}&per_page=100"

        data = get_api_data(url)

        if not data or class="hl-string">'tickets' not in data or not data[class="hl-string">'tickets']:
            break

        tickets = data[class="hl-string">'tickets']

        for ticket in tickets:
            service_request_id = ticket[class="hl-string">'id']
            created_at = parse_iso_datetime(ticket[class="hl-string">'created_at'])
            due_by = parse_iso_datetime(ticket[class="hl-string">'due_by'])
            resolved_at = parse_iso_datetime(ticket[class="hl-string">'resolved_at'])
            closed_at = parse_iso_datetime(ticket[class="hl-string">'closed_at'])

            class=class="hl-string">"hl-comment"># --- Activity: Service Request Created ---
            event_log.append({
                class="hl-string">'ServiceRequestId': service_request_id,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
                class="hl-string">'EventTime': created_at,
                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                class="hl-string">'LastDataUpdate': last_data_update,
                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                class="hl-string">'Status': ticket[class="hl-string">'status'],
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
            })
            
            class=class="hl-string">"hl-comment"># Fetch conversations for detailed history
            conv_url = fclass="hl-string">"{BASE_URL}/tickets/{service_request_id}/conversations"
            conversations = get_api_data(conv_url)
            
            if not conversations or class="hl-string">'conversations' not in conversations:
                continue
                
            class=class="hl-string">"hl-comment"># Sort conversations chronologically
            sorted_convos = sorted(conversations[class="hl-string">'conversations'], key=lambda x: parse_iso_datetime(x[class="hl-string">'created_at']))

            initial_group_assigned = False
            initial_priority_set = False
            initial_agent_assigned = False
            triaged = False

            for conv in sorted_convos:
                conv_time = parse_iso_datetime(conv[class="hl-string">'created_at'])

                class=class="hl-string">"hl-comment"># --- Activity: Note Added ---
                if conv[class="hl-string">'body_text']:
                     event_log.append({
                        class="hl-string">'ServiceRequestId': service_request_id,
                        class="hl-string">'ActivityName': class="hl-string">'Note Added',
                        class="hl-string">'EventTime': conv_time,
                        class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                        class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                        class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                        class="hl-string">'Status': ticket[class="hl-string">'status'],
                        class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                    })

                class=class="hl-string">"hl-comment"># Process system activities from the activity log within conversations
                if class="hl-string">'activities' in conv and conv[class="hl-string">'activities']:
                    for activity in conv[class="hl-string">'activities']:
                        shipping_info = activity.get(class="hl-string">'shipping_info', {})
                        changes = shipping_info.get(class="hl-string">'changes', {})
                        
                        class=class="hl-string">"hl-comment"># --- Priority Change Activities ---
                        if class="hl-string">'priority' in changes:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Request Prioritized',
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': changes[class="hl-string">'priority'][1], class=class="hl-string">"hl-comment"># New value
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            if not initial_priority_set and not triaged:
                                initial_priority_set = True
                                triaged = True
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Request Triaged'})
                        
                        class=class="hl-string">"hl-comment"># --- Assignment Change Activities ---
                        if class="hl-string">'responder_id' in changes:
                            activity_name = class="hl-string">'Request Assigned to Agent' if not initial_agent_assigned else class="hl-string">'Request Reassigned'
                            initial_agent_assigned = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(changes[class="hl-string">'responder_id'][1]),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        if class="hl-string">'group_id' in changes:
                            activity_name = class="hl-string">'Request Reassigned' class=class="hl-string">"hl-comment"># Any group change after creation is a reassignment
                            if not initial_group_assigned and not triaged:
                                activity_name = class="hl-string">'Request Triaged'
                                initial_group_assigned = True
                                triaged = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(changes[class="hl-string">'group_id'][1]),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        class=class="hl-string">"hl-comment"># --- Status Change Activities ---
                        if class="hl-string">'status' in changes:
                            old_status, new_status = changes[class="hl-string">'status']
                            
                            if new_status == STATUS_MAPPING[class="hl-string">'Resolved']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Closed']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Closed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Requested from Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer'] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Provided by Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status in [STATUS_MAPPING[class="hl-string">'Resolved'], STATUS_MAPPING[class="hl-string">'Closed']] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Reopened', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Vendor']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'External Vendor Engaged', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Approval']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Internal Review Performed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
            
            class=class="hl-string">"hl-comment"># --- Derived/Calculated Activities ---
            class=class="hl-string">"hl-comment"># --- Activity: SLA Target Breached ---
            resolution_time = closed_at or resolved_at
            if due_by and resolution_time and resolution_time > due_by:
                event_log.append({
                    class="hl-string">'ServiceRequestId': service_request_id,
                    class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                    class="hl-string">'EventTime': due_by,
                    class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                    class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                    class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                    class="hl-string">'Status': ticket[class="hl-string">'status'],
                    class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                })

            class=class="hl-string">"hl-comment"># --- Activity: Resolution Confirmed by Requestor (Inferred from survey) ---
            if ticket.get(class="hl-string">'satisfaction_ratings'):
                for rating in ticket[class="hl-string">'satisfaction_ratings']:
                    if rating.get(class="hl-string">'ratings'): class=class="hl-string">"hl-comment"># Check if there is a rating
                        rating_time = parse_iso_datetime(rating.get(class="hl-string">'created_at'))
                        if resolved_at and rating_time > resolved_at:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Resolution Confirmed by Requestor',
                                class="hl-string">'EventTime': rating_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            break class=class="hl-string">"hl-comment"># Only add one confirmation event

        page += 1

    if not event_log:
        print(class="hl-string">"No events were generated. Please check your configuration and date range.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTime'])
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df[class="hl-string">'LastDataUpdate'] = pd.to_datetime(df[class="hl-string">'LastDataUpdate']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    output_filename = class="hl-string">'freshservice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {output_filename}")

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

Fasi

Verifica dei prerequisiti: Assicuratevi di avere un ruolo utente Freshservice con i permessi per accedere e creare report nel modulo Analytics. Di norma, ciò richiede un piano Pro o Enterprise.
Configurazione Automazioni (se necessario): Per un'acquisizione accurata degli eventi, verificate o create due automazioni specifiche in Amministrazione -> Workflow Automator. Prima: un'automazione che aggiunga una nota privata o un tag specifico (es. 'SLA_Breached') al ticket quando scade il timer dello SLA di risoluzione. Seconda: un'automazione che aggiunga un tag specifico (es. 'Resolution_Confirmed') quando viene ricevuto un sondaggio sulla soddisfazione del cliente positivo.
Creazione del report 'Creation Events': Andate alla scheda Analytics in Freshservice. Create un nuovo report selezionando il modulo 'Tickets' come origine dati. Questo report acquisirà il primo evento per ogni richiesta di servizio.
Configurazione Widget del report 'Creation Events': Aggiungete un widget 'Data Table'. Configurate le colonne (metriche) includendo: Ticket ID, Created at, Assigned to, Group, Priority, Status e Category. Applicate un filtro per l'intervallo temporale desiderato, ad esempio gli ultimi 6 mesi.
Esportazione dati 'Creation Events': Eseguite il report ed esportate il widget della tabella dati in un file CSV nominato 'creation_events.csv'.
Creazione del report 'Update Events': Create un secondo report selezionando questa volta il modulo 'Ticket Activities'. Questo report cattura tutte le modifiche e le note successive per ogni richiesta.
Configurazione Widget del report 'Update Events': Aggiungete un widget 'Data Table'. Includete le colonne: Ticket ID, Activity Date, Performed by, Activity Type e, sotto 'Changes', includete Field, Old Value e New Value. Aggiungete anche attributi a livello di ticket come Group, Assigned to, Priority, Status e Category per contestualizzare ogni evento.
Filtro del report 'Update Events': Applicate un filtro su 'Activity Date' coerente con il report di creazione. Filtrate ulteriormente 'Activity Type' per includere solo eventi rilevanti come 'Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added' e 'Public Note added'.
Esportazione dati 'Update Events': Eseguite il report ed esportate la tabella in un file CSV nominato 'update_events.csv'.
Combinazione e trasformazione dati: Aprite i due file in un foglio di calcolo o usate uno script. Copiate i dati di 'update_events.csv' e incollateli sotto quelli di 'creation_events.csv' in un nuovo file chiamato 'event_log.csv'.
Mappatura Attività e Attributi: Nel file 'event_log.csv' combinato, create le nuove colonne: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status e ServiceType. Popolatele seguendo la logica definita nella sezione Query sottostante per tradurre i dati grezzi nel formato finale.
Esportazione finale: Salvate il file 'event_log.csv' trasformato. Assicuratevi che il formato data per EventTime e LastDataUpdate sia standard (es. ISO 8601). Il file è pronto per l'upload nello strumento di Process Mining.

Configurazione

Piano Freshservice: È necessario un piano che includa il modulo Analytics (solitamente Pro o Enterprise).
Permessi Utente: L'utente che esegue l'esportazione deve disporre dei permessi necessari per creare ed eseguire report in Analytics.
Intervallo di date: Si consiglia di estrarre i dati relativi agli ultimi 3-6 mesi per mantenere il set di dati gestibile. Utilizzate un filtro temporale coerente basato su 'Created at' per il report di creazione e su 'Activity Date' per quello degli aggiornamenti.
Filtri del report: Nel modulo report 'Tickets', filtrate per 'Type' = 'Service Request' per isolare il processo corretto. Per il report 'Ticket Activities', filtrate l' 'Activity Type' includendo solo le modifiche rilevanti (Stato, Priorità, Assegnazione, Note) per ridurre il rumore nei dati esportati.
Automazioni richieste: L'estrazione delle attività 'SLA Target Breached' e 'Resolution Confirmed by Requestor' dipende da regole preesistenti nel Workflow Automator che aggiungono una nota o un tag al ticket al verificarsi di tali eventi. Senza queste regole, non sarà possibile acquisire tali attività con questo metodo.

a Query di Esempio config

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Il suo template dati per la gestione delle richieste di servizio

Il suo template dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività di gestione delle richieste di servizio

Guide all'Estrazione

Esportazione dati modulo Analytics Freshservice

Fasi

Configurazione

a Query di Esempio config

Script Python tramite le API REST di Freshservice

Fasi

Configurazione

a Query di Esempio python

Esportazione dati pianificata Freshservice su Cloud Storage

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Migliora oggi l'efficienza delle richieste in Freshservice

Il suo template dati per la gestione delle richieste di servizio

Il suo template dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività di gestione delle richieste di servizio

Guide all'Estrazione

Esportazione dati modulo Analytics Freshservice

Fasi

Configurazione

a Query di Esempio config

Script Python tramite le API REST di Freshservice

Fasi

Configurazione

a Query di Esempio python

Esportazione dati pianificata Freshservice su Cloud Storage

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Migliora oggi l'efficienza delle richieste in Freshservice