> Miglioramento continuo dei processi > Gestione delle richieste di servizio > Freshservice > Template dei dati

Il template dei dati per la gestione delle richieste di servizio

Freshservice

Attributi della gestione delle richieste di servizio(19) Attività di gestione delle richieste di servizio(15) Guide all’estrazione(3)

Il template dei dati per la gestione delle richieste di servizio

Questo template fornisce indicazioni complete per raccogliere i dati necessari ad analizzare il processo di gestione delle richieste di servizio. Descrive gli attributi essenziali, le attività principali da monitorare e le modalità pratiche per estrarre queste informazioni dai sistemi di origine. Utilizzi queste indicazioni per creare un Event Log affidabile e condurre un’analisi approfondita del processo.

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

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

Scarica il template

Attributi della gestione delle richieste di servizio

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

5 Obbligatorio 5 Consigliato 9 Facoltativo

	Nome	Descrizione
	ID della richiesta di servizio ServiceRequestId	Identificativo univoco di ogni richiesta di servizio.
Descrizione L’ID della richiesta di servizio è un numero o codice univoco assegnato a ogni nuova richiesta registrata in Freshservice. Funge da chiave primaria per seguire l’intero ciclo di vita della richiesta, dalla creazione alla chiusura. Nel Process Mining, questo ID è fondamentale perché funge da ID del caso. Tutti gli eventi correlati, come le modifiche di stato, le assegnazioni agli agenti e le note, vengono collegati tramite questo identificativo. Analizzare il percorso di ogni ID della richiesta di servizio consente di visualizzare il processo dall’inizio alla fine, individuare i percorsi più frequenti e rilevare le deviazioni o i colli di bottiglia che interessano i singoli casi. Perché è importante È l’ID del caso essenziale che collega tutti gli eventi correlati e permette di ricostruire il percorso completo di una singola richiesta di servizio. Dove reperirli È un campo principale dell’oggetto ticket in Freshservice, visibile nell’interfaccia e disponibile tramite l’API di Freshservice. Esempi SR-12943SR-13501SR-14011
	Nome dell’attività ActivityName	Nome dell’evento o dell’attività che si è verificata in un determinato momento per una richiesta di servizio.
Descrizione Il nome dell’attività descrive una fase o un evento specifico del ciclo di vita della richiesta di servizio. Le attività vengono ricavate dai registri di controllo del sistema, dalle modifiche di stato o da azioni specifiche degli utenti, come «Richiesta assegnata a un agente», «Nota aggiunta» o «Richiesta di servizio risolta». Questo attributo è essenziale per creare la mappa del processo, che rappresenta visivamente il flusso delle richieste di servizio. Analizzando la sequenza e la frequenza delle diverse attività, le organizzazioni possono comprendere il processo effettivo, individuare i colli di bottiglia tra una fase e l’altra, misurare la durata delle attività e rilevare varianti non conformi o inefficienti. Perché è importante Questo attributo definisce le fasi della mappa del processo e consente di visualizzare e analizzare il flusso di lavoro delle richieste di servizio. Dove reperirli Generato dalle «activities» o dagli «audits» associati a un ticket in Freshservice. Spesso è necessario applicare una logica di trasformazione per convertire gli eventi di sistema in nomi di attività comprensibili per il business. Esempi Richiesta di servizio creataRichiesta assegnata a un agenteRichiesta di servizio risoltaRichiesta di servizio chiusa
	Ora dell’evento EventTime	Data e ora esatte in cui si è verificata l’attività.
Descrizione L’ora dell’evento registra la data e l’ora in cui un’attività specifica è stata registrata per una richiesta di servizio. Questo dato temporale è fondamentale per ordinare correttamente gli eventi e calcolare gli intervalli tra di essi. Nel Process Mining, questo attributo serve a ordinare le attività di ogni caso e costituisce la base di tutte le analisi temporali. Viene utilizzato per calcolare i tempi di ciclo, i tempi di attesa tra le attività e il rispetto degli accordi sul livello del servizio (SLA). La precisione delle date e degli orari è essenziale per individuare i colli di bottiglia e comprendere le prestazioni del processo. Perché è importante Questo dato temporale ordina gli eventi cronologicamente e costituisce la base di tutte le analisi delle prestazioni, compresi il tempo di ciclo e l’individuazione dei colli di bottiglia. Dove reperirli Corrisponde alla data e all’ora di creazione di un’attività o di una voce del registro di controllo 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 sono stati estratti i dati.
Descrizione Questo attributo indica il sistema di origine dei dati del processo, in questo caso Freshservice. È particolarmente utile negli ambienti in cui si consolidano dati provenienti da più sistemi per ottenere una visione complessiva del processo. Anche se in un’analisi che riguarda un solo sistema può sembrare ridondante, includere questo attributo è una buona pratica per agevolare la scalabilità futura e la governance dei dati. Chiarisce la provenienza dei dati e aiuta a gestire i flussi di integrazione. Perché è importante Garantisce la provenienza e la tracciabilità dei dati, aspetti fondamentali quando si combinano dati provenienti da più sistemi o per finalità di governance dei dati. Dove reperirli In genere è un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati (ETL). Esempi FreshserviceFreshservice-API-v2
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione o dell’ultimo aggiornamento del dataset da Freshservice. Indica quanto sono recenti i dati analizzati. In qualsiasi analisi di processo, sapere quanto sono aggiornati i dati è fondamentale. Questo dato temporale aiuta a capire se si stanno consultando le informazioni più recenti, un aspetto essenziale per prendere decisioni operative tempestive e avere fiducia nei risultati dell’analisi. Perché è importante Indica quanto sono recenti i dati, assicurando che analisi e decisioni si basino su informazioni aggiornate. Dove reperirli Questo valore viene generato e aggiunto 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	Nome dell’agente attualmente assegnato alla richiesta di servizio.
Descrizione Questo attributo identifica l’agente di supporto responsabile della gestione della richiesta di servizio in un determinato momento. L’assegnazione può cambiare nel corso del ciclo di vita della richiesta. Analizzare l’agente assegnato è fondamentale per comprendere le prestazioni degli agenti e la distribuzione del carico di lavoro. Consente di calcolare KPI come il tempo medio di risoluzione per agente, il numero di richieste attive e la frequenza delle riassegnazioni. Queste informazioni aiutano a individuare gli agenti con i risultati migliori, quelli che potrebbero aver bisogno di ulteriore formazione e gli squilibri nella distribuzione del carico di lavoro. Perché è importante Consente di analizzare il carico di lavoro degli agenti, le loro prestazioni e l’impatto delle riassegnazioni sui tempi di risoluzione. Dove reperirli Disponibile nel campo «agent» o «responder» dell’oggetto ticket in Freshservice. Esempi Alice JohnsonRobert SmithNon assegnato
	Priorità Priority	Livello di priorità della richiesta di servizio, ad esempio bassa, media, alta o urgente.
Descrizione La priorità indica l’importanza e l’urgenza di una richiesta di servizio e spesso determina il tempo di risoluzione previsto e le risorse assegnate. Può essere impostata automaticamente in base a regole oppure manualmente dagli agenti. Nel Process Mining, la priorità è una dimensione fondamentale per l’analisi. Viene utilizzata per segmentare le richieste e confrontare i flussi di processo e le prestazioni degli elementi ad alta e bassa priorità. È essenziale per l’analisi del rispetto degli SLA e per capire se le richieste vengono classificate in modo efficace e tempestivo durante la valutazione iniziale. Perché è importante È fondamentale per analizzare il rispetto degli SLA e capire se le richieste vengono valutate e gestite in base al loro impatto sul business. Dove reperirli Disponibile nel campo «priority» dell’oggetto ticket in Freshservice. Esempi BassaMediaAltaUrgente
	Stato Status	Stato corrente della richiesta di servizio nel corso del suo ciclo di vita.
Descrizione Il campo Stato rappresenta la condizione della richiesta di servizio in un determinato momento, ad esempio «Aperto», «In attesa», «Risolto» o «Chiuso». Le modifiche di stato sono spesso la principale fonte di attività per il Process Mining. Analizzare lo stato fornisce un contesto al flusso del processo e aiuta a capire quanto tempo le richieste trascorrono nelle diverse condizioni. Per esempio, una lunga permanenza nello stato «In attesa» può indicare un collo di bottiglia dovuto all’attesa di informazioni dal richiedente o di un riscontro da parte di un fornitore esterno. È un attributo chiave per definire i punti di inizio e di fine delle diverse fasi del processo. Perché è importante Fornisce un contesto essenziale per ogni evento e aiuta a misurare il tempo trascorso nei diversi stati, come «Aperto» o «In attesa», così da individuare i ritardi. Dove reperirli Disponibile nel campo «status» dell’oggetto ticket in Freshservice. Esempi ApertoIn attesaRisoltoChiuso
	Team assegnato AssignedTeam	Team o gruppo di supporto incaricato di gestire la richiesta di servizio.
Descrizione Questo attributo indica il gruppo funzionale o il team, ad esempio «Supporto IT di livello 2» o «Approvvigionamento hardware», responsabile della richiesta di servizio. La richiesta può essere assegnata a un team prima che se ne occupi un singolo agente. L’analisi per team assegnato aiuta a comprendere le prestazioni e il carico di lavoro a livello di team e a individuare i colli di bottiglia specifici di determinate aree funzionali. È fondamentale per valutare l’efficienza con cui i diversi team gestiscono le richieste e ottimizzare l’allocazione delle risorse nell’organizzazione di supporto. Perché è importante Consente di analizzare prestazioni e carico di lavoro a livello di team o gruppo, un aspetto essenziale per la gestione delle risorse e l’individuazione dei colli di bottiglia nelle diverse aree funzionali. Dove reperirli Disponibile nel campo «group» dell’oggetto ticket in Freshservice. Esempi Service DeskOperazioni di reteSupporto applicazioni
	Tipo di servizio ServiceType	Tipo o categoria specifica del servizio richiesto.
Descrizione Il tipo di servizio classifica la richiesta in base al servizio necessario, ad esempio «Richiesta di nuovo hardware», «Accesso al software» o «Reimpostazione della password». Spesso è associato all’elemento del catalogo dei servizi selezionato dall’utente. Questo attributo consente di segmentare le richieste di servizio e confrontare i processi e le prestazioni dei diversi tipi di servizio. È essenziale per calcolare KPI come «Numero medio di attività per tipo di servizio», che aiutano a individuare i servizi più complessi o che richiedono più risorse. L’analisi può orientare gli interventi di semplificazione e automazione per specifici tipi di servizio. Perché è importante Consente di confrontare i flussi e la complessità dei processi tra diverse categorie di richieste, aiutando a individuare le aree in cui è possibile standardizzare o automatizzare. Dove reperirli A seconda della configurazione, spesso corrisponde al campo «category», «item» o a un campo personalizzato dell’oggetto ticket in Freshservice. Esempi Onboarding di un nuovo dipendenteRichiesta di licenza softwareAccesso VPN
	Canale Channel	Metodo o canale utilizzato per inviare la richiesta di servizio.
Descrizione Il canale indica come è stata creata la richiesta di servizio, ad esempio tramite il portale self-service, e-mail, telefono o chat. Queste informazioni aiutano a comprendere le preferenze degli utenti e l’efficienza dei diversi canali. L’analisi del processo per canale può rivelare informazioni importanti. Per esempio, le richieste inviate tramite il portale potrebbero essere più complete e risolversi più rapidamente di quelle inviate via e-mail, che potrebbero richiedere più scambi di comunicazioni. Questa analisi può orientare gli interventi per promuovere i canali più efficienti. Perché è importante Aiuta a capire se il canale di invio influisce sull’efficienza del processo, sui tempi di risoluzione o sulla quantità di rilavorazioni necessarie. Dove reperirli Disponibile nel campo «source» dell’oggetto ticket in Freshservice. Esempi E-mailPortaleTelefonoChat
	Nome della policy SLA SlaPolicyName	Nome della policy dell’accordo sul livello del servizio (SLA) applicata alla richiesta.
Descrizione Questo attributo identifica la policy SLA specifica che stabilisce i tempi previsti di risposta e risoluzione della richiesta di servizio. In genere, le policy si basano su fattori quali la priorità, il tipo di servizio o il gruppo del richiedente. Sapere quale policy SLA è applicata è essenziale per la Dashboard Analisi del rispetto e delle violazioni degli SLA. Consente di misurare con precisione le prestazioni rispetto agli obiettivi definiti e di analizzare quali policy vengono violate più spesso. Queste informazioni possono portare a rivedere le prestazioni del processo o la fattibilità degli obiettivi SLA. Perché è importante Identifica gli obiettivi di servizio rispetto ai quali viene misurata la richiesta ed è quindi essenziale per rendicontare con precisione il rispetto degli SLA. Dove reperirli Queste informazioni fanno parte dei dati SLA associati a un ticket. Potrebbe essere necessario interrogare endpoint o campi API specifici relativi agli SLA. Esempi Incidenti ad alta priorità - 4 oreRichieste standard - 3 giorniSupporto VIP - 1 ora
	Numero di riassegnazioni ReassignmentCount	Numero totale di volte in cui una richiesta di servizio è stata riassegnata a un altro agente o team.
Descrizione Questo attributo calcolato conta le occorrenze di attività come «Richiesta riassegnata» per ogni richiesta di servizio. Un numero elevato di riassegnazioni spesso segnala problemi nella valutazione iniziale, nell’instradamento in base alle competenze o nella distribuzione del carico di lavoro. Questo attributo supporta direttamente la Dashboard Prestazioni degli agenti e distribuzione del carico di lavoro e il KPI «Numero medio di riassegnazioni per agente e richiesta». Analizzare questa metrica aiuta le organizzazioni a individuare le debolezze del processo che portano a passare i ticket da un agente all’altro, aumentando i tempi di risoluzione e creando frustrazione sia per gli agenti sia per i richiedenti. Perché è importante Misura le inefficienze nell’instradamento e gli ostacoli nel processo. Un valore elevato segnala problemi nella valutazione iniziale o nel carico di lavoro degli agenti, che causano ritardi. Dove reperirli Si calcola contando le specifiche attività di modifica dell’assegnazione per ogni «ServiceRequestId» durante la trasformazione dei dati. Esempi 013
	Ora di fine EndTime	Data e ora esatte in cui l’attività è stata completata.
Descrizione L’ora di fine indica la data e l’ora di completamento di un’attività. Per molti eventi in Freshservice, l’ora di inizio e quella di fine coincidono, perché si tratta di eventi puntuali. Per le attività basate sullo stato, invece, l’ora di fine corrisponde a quella della modifica di stato successiva. Questo attributo è essenziale per calcolare la durata delle attività e i tempi di attesa tra di esse. Sottraendo StartTime da EndTime è possibile determinare il tempo di elaborazione di una specifica attività. Questo è fondamentale per individuare le attività che richiedono più tempo e che possono essere ottimizzate prioritariamente. Perché è importante Consente di calcolare la durata delle attività, un dato fondamentale per individuare i colli di bottiglia e misurare i tempi di elaborazione delle singole fasi. Dove reperirli Non è un campo presente direttamente nei registri di Freshservice. Deve essere ricavato usando la data e l’ora dell’evento successivo nella sequenza relativa a una determinata richiesta di servizio. Esempi 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Reparto del richiedente RequestorDepartment	Reparto di appartenenza del richiedente.
Descrizione Questo attributo specifica il reparto dell’organizzazione a cui appartiene l’utente che ha inviato la richiesta di servizio, ad esempio «Vendite», «Finanza» o «Risorse umane». In genere, queste informazioni provengono dal profilo dell’utente nel sistema. L’analisi delle prestazioni del processo per reparto è un’esigenza comune. Può evidenziare se alcuni reparti registrano tempi di risoluzione più lunghi o hanno esigenze specifiche. Queste informazioni possono orientare l’allocazione delle risorse, le iniziative di formazione o la creazione di servizi dedicati ai singoli reparti. Perché è importante Consente di segmentare il processo per unità aziendale e aiuta a individuare problemi specifici dei reparti o differenze nelle prestazioni. Dove reperirli Queste informazioni sono collegate tramite il profilo del richiedente. In Freshservice possono trovarsi nel campo predefinito «department» o in un campo utente personalizzato. Esempi FinanzaMarketingTecnologie dell’informazione
	Richiedente Requestor	Utente che ha inviato la richiesta di servizio.
Descrizione Questo attributo identifica la persona, di solito un dipendente, che ha avviato la richiesta di servizio. Fornisce informazioni su chi utilizza il service desk e sulle sue esigenze. Anche se non è sempre una dimensione primaria per l’analisi del flusso del processo, l’analisi per richiedente o per reparto di appartenenza può far emergere schemi ricorrenti. Per esempio, potrebbe rivelare che un determinato reparto invia spesso richieste incomplete, segnalando la necessità di una formazione mirata. È inoltre essenziale per le analisi incentrate sull’esperienza del cliente. Perché è importante Fornisce informazioni sull’utente che avvia la richiesta e consente di analizzare gli schemi delle richieste per persona, reparto o sede. Dove reperirli Disponibile nel campo «requester» dell’oggetto ticket in Freshservice. Esempi John DoeJane SmithAccount di servizio
	Rilavorazione IsRework	Indicatore booleano che segnala se la richiesta ha comportato attività di rilavorazione.
Descrizione Questo indicatore calcolato viene impostato su vero se una richiesta di servizio include determinate attività che segnalano una rilavorazione. Tra gli esempi figurano la riapertura dopo la risoluzione («Richiesta di servizio riaperta»), più riassegnazioni o richieste ripetute di informazioni all’utente («Informazioni richieste al richiedente»). Questo attributo semplifica l’analisi delle inefficienze del processo. Consente di filtrare facilmente i casi con rilavorazioni e confrontarne le mappe di processo e i tempi di ciclo con quelli dei casi senza rilavorazioni. Supporta direttamente la Dashboard Analisi della rilavorazione delle richieste di servizio e aiuta a quantificare l’impatto dei passaggi di consegne inefficienti o delle informazioni iniziali incomplete. Perché è importante Fornisce un modo semplice per segnalare e analizzare i casi che includono cicli inefficienti o fasi ripetute, aiutando a quantificare il costo della scarsa qualità. Dove reperirli Calcolato durante la trasformazione dei dati applicando la logica di business alla sequenza di attività di ogni «ServiceRequestId». Esempi truefalse
	Scadenza SLA SlaDueDate	Data e ora entro cui, secondo lo SLA, la richiesta di servizio dovrebbe essere risolta.
Descrizione Questo attributo specifica la scadenza per la risoluzione della richiesta di servizio, come definita dalla policy SLA applicabile. È un dato temporale calcolato in base alla data di creazione della richiesta, alla priorità e all’orario lavorativo definito nello SLA. È un dato fondamentale per monitorare le prestazioni in tempo reale e analizzare a posteriori il rispetto degli SLA. Confrontando l’ora effettiva di risoluzione con SlaDueDate, è possibile stabilire se lo SLA è stato «Rispettato» o «Violato». Questo dato costituisce la base per calcolare il KPI del tasso di rispetto degli SLA. Perché è importante È la scadenza prevista per la risoluzione e costituisce la base per calcolare se la richiesta di servizio ha rispettato o violato lo SLA. Dove reperirli È un campo calcolato in Freshservice, visibile nel ticket come «Due by» e disponibile tramite API. Esempi 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	SLA violato IsSlaBreached	Indicatore booleano che segnala se la richiesta di servizio ha superato il tempo di risoluzione previsto dallo SLA.
Descrizione Questo attributo calcolato è un semplice indicatore vero o falso che segnala se la richiesta di servizio è stata chiusa dopo la scadenza dello SLA. Si ricava confrontando la data e l’ora di «Richiesta di servizio chiusa» o «Richiesta di servizio risolta» con SlaDueDate. Questo attributo semplifica l’analisi e la visualizzazione nella Dashboard del rispetto degli SLA. Consente di filtrare e aggregare facilmente i dati per calcolare il KPI del tasso complessivo di rispetto degli SLA. La segmentazione in base a questo indicatore permette di isolare e analizzare rapidamente le caratteristiche del processo per le richieste che hanno violato lo SLA rispetto a quelle risolte in tempo. Perché è importante Semplifica l’analisi del rispetto degli SLA fornendo un indicatore chiaro per filtrare e aggregare le richieste che non hanno raggiunto gli obiettivi previsti. Dove reperirli È un campo calcolato durante la trasformazione dei dati, confrontando la data e l’ora della risoluzione finale con il campo «SlaDueDate». Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione delle richieste di servizio

Questi sono i passaggi e le tappe principali da registrare nell’Event Log per individuare e analizzare con precisione i flussi di lavoro di gestione delle richieste di servizio.

6 Consigliato 9 Facoltativo

	Attività	Descrizione
	Fornitore esterno coinvolto	Questa attività segna il momento in cui un ticket viene affidato a un fornitore esterno o a una terza parte per la risoluzione. Si deduce da una modifica dello stato a un valore specifico, come «In attesa del fornitore» o «In attesa di una terza parte».
Perché è importante Il coinvolgimento di un fornitore può causare ritardi significativi. Monitorare questa attività è essenziale per misurare le prestazioni del fornitore e il suo impatto sul tempo di ciclo complessivo della richiesta di servizio. Dove reperirli Si deduce dalla cronologia delle modifiche allo stato del ticket. Individui uno stato configurato appositamente per monitorare le dipendenze dai fornitori esterni. Acquisizione Rilevi quando il campo dello stato del ticket cambia a un valore che indica l’attesa di una terza parte. Tipo di evento inferred
	Obiettivo SLA non rispettato	Evento calcolato che si verifica quando il tempo necessario per risolvere una richiesta di servizio supera l’obiettivo definito nell’accordo sul livello di servizio (SLA). Non è un evento registrato direttamente dal sistema, ma viene ricavato confrontando il tempo di risoluzione con la scadenza SLA.
Perché è importante Misura direttamente le prestazioni del servizio rispetto agli impegni ed è un KPI fondamentale per la gestione. Aiuta a individuare i tipi di richiesta o i livelli di priorità più a rischio di mancato rispetto degli obiettivi. Dove reperirli Si calcola confrontando la data e l’ora di «Risolto» con la data e l’ora di scadenza dell’SLA. Se la risoluzione è successiva alla scadenza, l’evento viene attivato. Acquisizione Confronti la data e l’ora di risoluzione con la scadenza dell’SLA. Se resolved_at > sla_due_by, crei questo evento. Tipo di evento calculated
	Richiesta assegnata a un agente	Segna il momento in cui una richiesta di servizio viene assegnata a un agente specifico. È una tappa fondamentale, dedotta monitorando le modifiche al campo «Agente assegnato» o «Proprietario» del ticket.
Perché è importante Questa attività è fondamentale per analizzare il carico di lavoro degli agenti e individuare i colli di bottiglia nel processo di assegnazione. Il tempo che intercorre tra la creazione e l’assegnazione è un indicatore chiave delle prestazioni. Dove reperirli Si deduce dal registro delle attività o dalla traccia di audit dei campi del ticket, monitorando le modifiche al campo «Agente» o «Assegnatario». Acquisizione Registri la data e l’ora in cui il campo «Agente assegnato» viene compilato o cambia valore. Tipo di evento inferred
	Richiesta di servizio chiusa	È l’attività finale e segna la conclusione del ciclo di vita della richiesta di servizio. In genere, si verifica automaticamente dopo che il ticket è rimasto nello stato «Risolto» per un periodo prestabilito senza essere riaperto.
Perché è importante Questo evento segna la conclusione definitiva dell’istanza del processo. Il tempo che intercorre tra «Risolto» e «Chiuso» costituisce il periodo entro il quale il richiedente può confermare la risoluzione. Dove reperirli Deducibile dalla cronologia delle modifiche di stato del ticket. Corrisponde alla data e all’ora in cui lo stato passa a «Chiuso». Acquisizione Registrare la data e l’ora in cui lo stato del ticket passa a «Chiuso». Tipo di evento inferred
	Richiesta di servizio creata	Questa attività segna l’inizio del ciclo di vita della richiesta di servizio, quando una nuova richiesta viene registrata formalmente in Freshservice. L’evento viene acquisito esplicitamente alla creazione di un nuovo ticket, tramite il catalogo dei servizi, un’e-mail o un altro canale, e genera un ID univoco per la richiesta di servizio.
Perché è importante È l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questa attività e le successive è fondamentale per misurare i tempi di ciclo complessivi e individuare i ritardi nelle fasi iniziali. Dove reperirli Questo evento viene registrato esplicitamente in Freshservice. È reperibile nel registro delle attività o nella traccia di audit del ticket e in genere corrisponde alla data e all’ora di creazione. Acquisizione Utilizzi la data e l’ora di creazione del ticket nei dati dei ticket di Freshservice. Tipo di evento explicit
	Richiesta di servizio risolta	Questa tappa fondamentale segna il momento in cui l’agente ha fornito una soluzione e considera concluso il lavoro. Si deduce quando lo stato del ticket passa a «Risolto».
Perché è importante Questa attività segna la fine della fase di lavoro attivo. Il tempo necessario per arrivare a questo punto è una misura chiave dell’efficienza degli agenti e del processo, oltre a costituire la base per il calcolo degli SLA. Dove reperirli Si deduce dalla cronologia delle modifiche allo stato del ticket. Corrisponde alla data e all’ora in cui lo stato è stato impostato per la prima volta su «Risolto». Acquisizione Registri la data e l’ora in cui lo stato del ticket passa per la prima volta a «Risolto». Tipo di evento inferred
	Informazioni fornite da chi ha inviato la richiesta	Si verifica quando chi ha inviato la richiesta fornisce le informazioni necessarie, consentendo all’agente di riprendere il lavoro. In genere, si deduce quando lo stato del ticket passa automaticamente da «In attesa» a «Aperto».
Perché è importante Questa attività conclude il ciclo di richiesta delle informazioni. Il tempo che intercorre tra la richiesta e la ricezione delle informazioni è un’attesa importante da analizzare e ridurre. Dove reperirli Si deduce da una modifica dello stato del ticket da «In attesa» a «Aperto» o «In corso», spesso in seguito a una risposta di chi ha inviato la richiesta. Acquisizione Rilevi quando lo stato del ticket passa da «In attesa» ad «Aperto». Tipo di evento inferred
	Informazioni richieste a chi ha inviato la richiesta	Indica il momento in cui l’agente assegnato richiede ulteriori informazioni a chi ha inviato la richiesta e sospende l’avanzamento. Si deduce da una modifica dello stato del ticket a «In attesa» o «In attesa del cliente».
Perché è importante Questa attività evidenzia una causa frequente di ritardi e rilavorazioni. Analizzarne la frequenza aiuta a individuare opportunità per migliorare i template delle richieste e la raccolta iniziale dei dati. Dove reperirli Si deduce dalla cronologia delle modifiche allo stato del ticket. Individui un passaggio a uno stato come «In attesa di risposta del cliente» o «In attesa di informazioni». Acquisizione Rilevi quando il campo dello stato del ticket cambia a un valore che indica l’attesa di informazioni da parte dell’utente. Tipo di evento inferred
	Nota aggiunta	Rappresenta qualsiasi nota pubblica o privata aggiunta alla richiesta di servizio da un agente o da chi l’ha inviata. È un evento esplicito, registrato nella conversazione o nel registro delle attività del ticket.
Perché è importante Analizzare la frequenza e il momento in cui vengono aggiunte le note può rivelare schemi di comunicazione, l’efficacia della collaborazione e i punti in cui si genera confusione nel processo. Dove reperirli Registrata esplicitamente nella cronologia della conversazione del ticket in Freshservice. Ogni nota riporta la data e l’ora e l’autore. Acquisizione Estragga ogni voce dal registro delle conversazioni o dei commenti del ticket. Tipo di evento explicit
	Priorità della richiesta assegnata	Questa attività si verifica quando alla richiesta di servizio viene assegnato un livello di priorità, ad esempio Bassa, Media o Alta. Si deduce rilevando una modifica del campo «Priorità» nella cronologia del ticket.
Perché è importante L’assegnazione delle priorità è fondamentale per distribuire le risorse e rispettare gli obiettivi SLA. Analizzare questa attività aiuta a verificare che le richieste siano valutate correttamente e tempestivamente. Dove reperirli Si deduce dalla cronologia delle modifiche ai campi del ticket in Freshservice. Individui gli aggiornamenti al campo «Priorità» e registri la data e l’ora della modifica. Acquisizione Rilevi una modifica del campo «Priorità» da un valore nullo o dal valore precedente e registri la data e l’ora. Tipo di evento inferred
	Revisione interna effettuata	Indica che una soluzione proposta o l’evasione di una richiesta richiede una revisione o un’approvazione interna prima di procedere. Si deduce da una modifica dello stato a un valore come «In attesa di approvazione» o «Revisione interna».
Perché è importante Le revisioni interne possono creare colli di bottiglia, soprattutto per le richieste di servizio complesse o ad alto impatto. Misurarne la durata aiuta a semplificare i flussi di lavoro di approvazione. Dove reperirli Si deduce dalla cronologia delle modifiche allo stato del ticket. Nel flusso di lavoro deve essere utilizzato uno stato specifico, come «In attesa di approvazione interna». Acquisizione Rilevi quando il campo dello stato del ticket cambia a un valore che indica una revisione o un’approvazione interna. Tipo di evento inferred
	Richiesta di servizio riaperta	Si verifica quando chi ha inviato la richiesta segnala che il problema persiste dopo che è stato contrassegnato come «Risolto», facendo tornare il ticket allo stato aperto. Si deduce da una modifica dello stato da «Risolto» a «Aperto» o «In corso».
Perché è importante Le richieste riaperte sono un chiaro indicatore di bassi tassi di risoluzione al primo contatto e di insoddisfazione dei clienti. Monitorare questo ciclo di rilavorazione è fondamentale per migliorare la qualità delle soluzioni. Dove reperirli Si deduce dalla cronologia delle modifiche allo stato del ticket nel registro delle attività. Corrisponde al passaggio diretto da «Risolto» ad «Aperto». Acquisizione Rilevi una modifica dello stato da «Risolto» ad «Aperto». Tipo di evento inferred
	Richiesta riassegnata	Questa attività registra ogni modifica dell’agente o del gruppo assegnato dopo l’assegnazione iniziale. Si deduce rilevando gli aggiornamenti successivi ai campi «Agente assegnato» o «Gruppo assegnato».
Perché è importante Le riassegnazioni frequenti possono indicare problemi nello smistamento iniziale, nell’abbinamento tra competenze degli agenti e richieste o nell’equilibrio del carico di lavoro. Questa attività è fondamentale per il KPI sul numero di riassegnazioni agli agenti e per l’analisi delle rilavorazioni. Dove reperirli Si deduce dalla cronologia delle modifiche ai campi del ticket. L’evento viene registrato ogni volta che il campo «Agente assegnato» o «Gruppo assegnato» viene aggiornato dopo l’assegnazione del valore iniziale. Acquisizione Rilevi ogni modifica al campo «Agente assegnato» o «Gruppo assegnato» successiva alla prima assegnazione. Tipo di evento inferred
	Richiesta smistata	Rappresenta la valutazione e la categorizzazione iniziali di una nuova richiesta di servizio. In genere, questa attività viene dedotta dal momento in cui viene assegnata per la prima volta una priorità o la richiesta viene assegnata a un gruppo, segnalando che è stata esaminata e inserita in coda.
Perché è importante Monitorare lo smistamento aiuta a misurare l’efficienza del team che gestisce la prima risposta. I ritardi in questa fase possono incidere sensibilmente sui tempi complessivi di risoluzione e sulla conformità agli SLA. Dove reperirli Dedotta dal registro delle attività. Si individua tramite la data e l’ora del primo evento «Priorità assegnata» o «Gruppo assegnato» successivo alla creazione. Acquisizione Individui la data e l’ora più precoci tra quelle relative a una modifica del campo della priorità e a una modifica del campo del gruppo di assegnazione. Tipo di evento inferred
	Risoluzione confermata da chi ha inviato la richiesta	Questa attività rappresenta la conferma esplicita di chi ha inviato la richiesta che la soluzione fornita è soddisfacente. Si può dedurre da una risposta positiva a un sondaggio o da un commento specifico prima della chiusura del ticket.
Perché è importante La conferma fornisce un riscontro diretto sulla qualità della risoluzione. Un tasso di conferma basso può indicare che le soluzioni non soddisfano pienamente le esigenze degli utenti, anche quando il ticket non viene riaperto. Dove reperirli È difficile acquisire questo dato direttamente e potrebbe essere necessaria una configurazione personalizzata. Si può dedurre dalla risposta a un sondaggio sulla soddisfazione del cliente collegato al ticket o dall’applicazione di un tag specifico. Acquisizione Richiede l’analisi di dati correlati, come i sondaggi sulla soddisfazione o i tag applicati dopo la risoluzione. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Freshservice

Passaggi

Verifichi i prerequisiti: Verifichi che il ruolo utente Freshservice disponga delle autorizzazioni necessarie per accedere al modulo Analytics e creare report. In genere è richiesto un piano Pro o Enterprise.
Configuri le automazioni, se necessario: Per rilevare correttamente gli eventi, verifichi o crei due automazioni specifiche in Freshservice, in Admin -> Workflow Automator. La prima deve aggiungere una nota privata o un tag specifico, ad esempio 'SLA_Breached', a un ticket quando scade il timer SLA di risoluzione. La seconda deve aggiungere un tag specifico, ad esempio 'Resolution_Confirmed', quando viene ricevuto un esito positivo del sondaggio sulla soddisfazione del cliente relativo a un ticket.
Crei il report 'Creation Events': Acceda alla scheda Analytics in Freshservice. Crei un nuovo report e selezioni il modulo 'Tickets' come origine dei dati. Il report rileverà il primo evento di ogni richiesta di assistenza.
Configuri i widget del report 'Creation Events': Aggiunga un widget 'Tabella dati'. Configuri le colonne (metriche) includendo: ID ticket, Data di creazione, Assegnato a, Gruppo, Priorità, Stato e Categoria. Applichi un filtro per l’intervallo di date di creazione desiderato, ad esempio gli ultimi 6 mesi.
Esporti i dati di 'Creation Events': Esegua il report ed esporti il widget della tabella dati in un file CSV. Lo denomini 'creation_events.csv'.
Crei il report 'Update Events': Crei un secondo report, selezionando questa volta il modulo 'Ticket Activities' come origine dei dati. Il report rileva tutte le modifiche e le note successive relative a ciascuna richiesta di assistenza.
Configuri i widget del report 'Update Events': Aggiunga un widget 'Tabella dati'. Configuri le colonne includendo: ID ticket, Data attività, Eseguito da, Tipo di attività e, nella sezione 'Modifiche', Campo, Valore precedente e Nuovo valore. Aggiunga anche gli attributi a livello di ticket, come Gruppo, Assegnato a, Priorità, Stato e Categoria, per fornire il contesto di ogni evento.
Filtri il report 'Update Events': Applichi al campo 'Data attività' lo stesso intervallo di date utilizzato nel report di creazione. Filtri inoltre 'Tipo di attività' per includere solo gli eventi pertinenti, come 'Stato modificato', 'Priorità modificata', 'Gruppo modificato', 'Agente modificato', 'Nota privata aggiunta' e 'Nota pubblica aggiunta'.
Esporti i dati di 'Update Events': Esegua il report ed esporti il widget della tabella dati in un file CSV. Lo denomini 'update_events.csv'.
Combini e trasformi i dati: Apra i due file CSV in un foglio di calcolo oppure utilizzi uno script di preparazione dei dati. Copi tutti i dati da 'update_events.csv' e li incolli sotto i dati di 'creation_events.csv' in un nuovo file denominato 'event_log.csv'.
Mappi le attività e gli attributi: Nel file combinato 'event_log.csv', crei le nuove colonne ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Stato e ServiceType. Compili queste colonne applicando la logica descritta nella sezione Query qui sotto. Il passaggio prevede l’utilizzo di formule o di uno script per trasformare i dati grezzi nel formato finale dell’Event Log.
Esportazione finale: Salvi il file trasformato 'event_log.csv'. Verifichi che le date e ore nei campi EventTime e LastDataUpdate siano in un formato standard, ad esempio ISO 8601. Il file è ora pronto per essere caricato in uno strumento di Process Mining.

Configurazione

Piano Freshservice: È necessario un piano che includa il modulo Analytics, in genere Pro o Enterprise.
Autorizzazioni utente: L’utente che esegue l’esportazione deve poter creare ed eseguire report in Analytics.
Intervallo di date: È consigliabile estrarre i dati di un periodo recente, ad esempio gli ultimi 3-6 mesi, per mantenere gestibile il volume del dataset. Applichi un filtro coerente per intervallo di date basato su 'Created at' nel report di creazione e su 'Activity Date' nel report degli aggiornamenti.
Filtri dei report: Nel report del modulo 'Tickets', imposti il filtro 'Type' = 'Service Request' per isolare il processo corretto. Nel report 'Ticket Activities', filtri 'Activity Type' per includere solo le modifiche pertinenti (stato, priorità, assegnazione e note), così da ridurre i dati superflui nell’esportazione.
Automazioni necessarie: L’estrazione delle attività 'SLA Target Breached' e 'Resolution Confirmed by Requestor' dipende da regole Workflow Automator già configurate, che aggiungono una nota o un tag al ticket quando si verificano questi eventi. Senza tali regole, non è possibile acquisire queste attività con questo metodo.

Query di esempio sql

/*
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

Passaggi

Prerequisiti: Verifichi che sul sistema sia installato Python 3.6 o versione successiva, insieme alle librerie requests e pandas. Le servirà anche una chiave API di Freshservice con autorizzazioni di lettura dei dati dei ticket.
Recupero della chiave API: Acceda alla Sua istanza Freshservice come amministratore. Faccia clic sull’icona del profilo in alto a destra e apra 'Profile Settings': la chiave API si trova nel riquadro a destra. La copi e la conservi in modo sicuro.
Salvataggio dello script: Salvi il codice Python fornito in un file denominato extract_freshservice_srm.py sul computer locale.
Configurazione dei parametri dello script: Apra lo script salvato in un editor di testo. Individui la sezione di configurazione all’inizio del file e sostituisca i valori segnaposto di FRESHSERVICE_DOMAIN, API_KEY, START_DATE e END_DATE. Modifichi il dizionario STATUS_MAPPING se l’istanza utilizza ID numerici diversi per gli stati personalizzati.
Installazione delle librerie: Se le librerie necessarie non sono installate, apra il prompt dei comandi o il terminale ed esegua il comando: pip install requests pandas.
Esecuzione dello script: Dal prompt dei comandi o dal terminale, raggiunga la cartella in cui ha salvato lo script. Lo esegua con il comando: python extract_freshservice_srm.py.
Controllo dell’esecuzione: Lo script mostrerà nella console gli aggiornamenti sullo stato di avanzamento, indicando la pagina dei ticket in elaborazione. A seconda dell’intervallo di date e del volume dei ticket, l’operazione potrebbe richiedere del tempo.
Recupero dell’Event Log: Al termine dell’esecuzione, se tutto è andato a buon fine, nella stessa cartella verrà creato il file freshservice_event_log.csv, che contiene l’Event Log estratto.
Preparazione del caricamento: Il file CSV generato contiene le colonne necessarie (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) ed è pronto per essere caricato in ProcessMind. In genere non sono necessarie altre modifiche di formattazione.

Configurazione

FRESHSERVICE_DOMAIN: L’URL Freshservice dell’organizzazione, ad esempio yourcompany.freshservice.com.
API_KEY: La chiave API personale ottenuta dal profilo utente Freshservice. Deve essere mantenuta riservata.
START_DATE / END_DATE: L’intervallo di date per l’estrazione dei ticket, nel formato 'YYYY-MM-DD'. Per l’analisi iniziale si consiglia un periodo di 3-6 mesi, così da bilanciare il volume dei dati e le informazioni ottenute.
STATUS_MAPPING: Un dizionario Python fondamentale nello script, che associa i nomi degli stati personalizzati utilizzati per dedurre gli eventi (ad esempio, 'External Vendor Engaged') ai rispettivi ID numerici di stato nell’istanza Freshservice. Verifichi e aggiorni questi ID in base alla configurazione del sistema.
Limiti di frequenza dell’API: Tenga presenti i limiti di frequenza dell’API previsti dal piano Freshservice. Lo script elabora i ticket in sequenza per rispettarli; per dataset molto grandi potrebbe essere necessario suddividere l’estrazione in intervalli di date più brevi.
Ambito dei dati: Lo script è configurato per estrarre solo i ticket di tipo 'Service Request'. Il filtro viene applicato durante il recupero iniziale dei ticket.

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()

Passaggi

Verifichi che l’abbonamento Freshservice e le autorizzazioni di amministratore includano l’esportazione pianificata dei dati e la consegna al provider di archiviazione cloud selezionato. I nomi dei menu e le funzionalità di esportazione di Freshservice possono variare in base al piano e al tenant: consulti la documentazione amministrativa aggiornata e utilizzi [Configure based on your system] se nel tenant le etichette sono diverse.
In Freshservice, apra l’area di amministrazione e individui la configurazione dell’esportazione pianificata dei dati. Selezioni l’origine dati delle richieste di servizio o dei ticket che contiene l’ID della richiesta di servizio, lo stato, la priorità, l’assegnazione, il tipo di servizio, i timestamp, i campi SLA, la cronologia delle conversazioni o delle attività e le risposte dei richiedenti. Non presuma che un’esportazione dei ticket nello stato attuale includa la cronologia delle modifiche ai campi.
Configuri l’ambito dell’esportazione. Per la convalida iniziale, selezioni una finestra di estrazione mobile di 3-6 mesi, quindi imposti una pianificazione ricorrente adeguata alle esigenze di reporting. Includa tutti i record delle richieste di servizio e i dati storici delle attività o di audit necessari per individuare modifiche ai campi, note, transizioni di stato, esiti SLA, approvazioni e conferme dei richiedenti. Applichi filtri per azienda o servizio solo se espressamente richiesti, utilizzando [Company or service filter based on your system].
Selezioni CSV come formato di output e configuri la consegna alla posizione di archiviazione cloud approvata, ad esempio Amazon S3. Inserisca [Cloud storage connection details] e [Credentials or role configuration] nella configurazione supportata da Freshservice. Verifichi con il responsabile della piattaforma il bucket, il percorso, la crittografia, la conservazione e le autorizzazioni di accesso. Eviti di inserire le credenziali direttamente negli script o nei file esportati.
Esegua un’esportazione di prova e controlli i file CSV ricevuti. Individui i nomi effettivi delle colonne esportate per l’ID della richiesta di servizio, lo stato, la priorità, l’agente assegnato, il gruppo assegnato, il tipo di servizio, l’ora di creazione, l’ora di aggiornamento, l’ora di risoluzione, l’ora di chiusura, la scadenza SLA, il timestamp della cronologia, il campo modificato, il valore precedente, il nuovo valore, il tipo di nota, l’autore della nota, il timestamp della nota e la risposta o l’esito del sondaggio del richiedente. Se un campo di origine necessario non è disponibile, documenti la limitazione anziché inventare un nome di campo.
Carichi i file CSV in una tabella di staging o in un frame di dati. Nella query seguente, sostituisca i riferimenti alle origini, inclusi [Your ticket table name], [Your ticket history table name], [Your conversation table name], [Your SLA table name] e [Your survey or confirmation table name], con le strutture effettivamente create dall’esportazione. Mappi le colonne di origine ai campi logici utilizzati dalla query. Conservi i timestamp originali e li normalizzi a un unico fuso orario, preferibilmente UTC.
Configuri l’elaborazione incrementale utilizzando [Last successful export timestamp] o il timestamp di consegna del file di esportazione. Mantenga una finestra di sovrapposizione sufficiente, ad esempio di 24-48 ore, per acquisire la cronologia e le correzioni arrivate in ritardo. Elimini i duplicati in base a ServiceRequestId, ActivityName, EventTime e a un identificativo stabile dell’evento di origine, se disponibile. Non elimini i duplicati basandosi solo su ServiceRequestId, perché ogni richiesta deve generare più righe di evento.
Esegua la trasformazione SQL completa. La query crea esplicitamente righe per tutte le 15 attività richieste, incluse attività derivate come il triage, la riassegnazione, la violazione SLA, la conferma del richiedente e la chiusura. Se l’esportazione non contiene prove storiche di un’attività, non è possibile generare tale attività in modo affidabile e la lacuna deve essere segnalata come problema nei dati di origine.
Convalidi il numero di righe, la copertura delle attività, i timestamp, gli identificativi e la compilazione degli attributi utilizzando i controlli riportati di seguito. Verifichi che ogni ServiceRequestId possa avere più eventi ordinati e che EventTime sia valorizzato per ogni riga generata.
Esporti il risultato della query in un file CSV UTF-8 con le colonne richieste ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status e ServiceType. Carichi l’Event Log risultante in ProcessMind e mappi ServiceRequestId come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell’evento. Mantenga SourceSystem e LastDataUpdate come attributi o metadati dell’evento, in base alla configurazione di importazione di ProcessMind.

Configurazione

Origine dell’esportazione: Selezioni il dataset Freshservice delle richieste di servizio o dei ticket e, se disponibili, i dataset relativi alla cronologia, alle conversazioni, agli SLA, alle approvazioni e ai sondaggi. La sola esportazione dei ticket nello stato attuale non è sufficiente per ricostruire tutte le attività richieste.
Pianificazione: Imposti esportazioni ricorrenti in linea con il ciclo di reporting operativo. Per il primo caricamento, utilizzi un intervallo di date di 3-6 mesi. Per i caricamenti incrementali, mantenga una finestra di sovrapposizione per acquisire gli aggiornamenti arrivati in ritardo.
Prove necessarie nei dati di origine: Verifichi che l’esportazione includa un ID stabile della richiesta di servizio, timestamp degli eventi o degli aggiornamenti, cronologia degli stati, delle priorità, delle assegnazioni e dei gruppi, note o conversazioni, informazioni sulle scadenze e sul completamento degli SLA, timestamp di risoluzione e chiusura e, se disponibili, prove della conferma del richiedente.
Filtri: Applichi [Company or service filter based on your system] solo se necessario. Eviti filtri restrittivi sugli stati, perché potrebbero escludere record riaperti, risolti, chiusi, in sospeso, relativi a fornitori o approvazioni, oppure record storici.
Archiviazione cloud: Configuri il bucket o contenitore approvato, il percorso, la crittografia, la conservazione e le autorizzazioni di accesso. Utilizzi un ruolo gestito o un meccanismo per la gestione dei segreti supportato dal tenant, anziché inserire le credenziali nei file SQL o CSV.
Gestione dei file: Conservi i file CSV originali, i timestamp di esportazione, la versione dello schema e i metadati di consegna. Se Freshservice suddivide le esportazioni di grandi dimensioni in più file, elabori tutti i file appartenenti alla stessa esecuzione di esportazione.
Fusi orari: Registri il fuso orario di origine e normalizzi EventTime in UTC. Se necessario per la verificabilità, conservi il timestamp originale.
Prestazioni: Se supportato, suddivida l’elaborazione in base alla data di esportazione, alla data dell’evento o a ServiceRequestId. Prima della trasformazione, carichi i file grezzi in un’area di staging, eviti di eseguire più volte la scansione dell’intera cronologia e utilizzi caricamenti incrementali con una finestra di sovrapposizione controllata.
Autorizzazioni e licenze: Sono prerequisiti l’accesso di amministratore, l’autorizzazione a configurare le esportazioni pianificate, l’autorizzazione a leggere i dati Freshservice selezionati, l’accesso in scrittura all’archiviazione cloud e qualsiasi funzionalità in abbonamento o licenza necessaria per la consegna delle esportazioni pianificate.
Qualità dei dati: Non deduca eventi dal solo valore attuale se non sono disponibili prove storiche. Ad esempio, la priorità corrente può supportare l’attività Request Prioritized solo se è disponibile un timestamp di assegnazione della priorità o un record nella cronologia.
Mappatura delle origini: Sostituisca tutti i riferimenti tra parentesi quadre agli oggetti e alle colonne di origine nella query con i nomi effettivi presenti nei file esportati. I nomi logici delle colonne di output devono rimanere invariati per la mappatura in ProcessMind.

Query di esempio sql

WITH
base_requests AS (
    SELECT
        CAST(r.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(r.[Assigned Agent] AS VARCHAR(255)) AS AssignedAgent,
        CAST(r.[Assigned Team] AS VARCHAR(255)) AS AssignedTeam,
        CAST(r.[Priority] AS VARCHAR(100)) AS Priority,
        CAST(r.[Status] AS VARCHAR(100)) AS Status,
        CAST(r.[Service Type] AS VARCHAR(255)) AS ServiceType,
        CAST(r.[Created Time] AS TIMESTAMP) AS CreatedTime,
        CAST(r.[Resolved Time] AS TIMESTAMP) AS ResolvedTime,
        CAST(r.[Closed Time] AS TIMESTAMP) AS ClosedTime,
        CAST(r.[SLA Due Time] AS TIMESTAMP) AS SLADueTime,
        CAST(r.[Last Updated Time] AS TIMESTAMP) AS LastUpdatedTime
    FROM [Your ticket table name] r
    WHERE CAST(r.[Created Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(r.[Created Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
history AS (
    SELECT
        CAST(h.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(h.[Event Time] AS TIMESTAMP) AS EventTime,
        CAST(h.[Changed Field] AS VARCHAR(255)) AS ChangedField,
        CAST(h.[Old Value] AS VARCHAR(4000)) AS OldValue,
        CAST(h.[New Value] AS VARCHAR(4000)) AS NewValue,
        CAST(h.[Assigned Agent] AS VARCHAR(255)) AS AssignedAgentAtEvent,
        CAST(h.[Assigned Team] AS VARCHAR(255)) AS AssignedTeamAtEvent,
        CAST(h.[Priority] AS VARCHAR(100)) AS PriorityAtEvent,
        CAST(h.[Status] AS VARCHAR(100)) AS StatusAtEvent,
        CAST(h.[Service Type] AS VARCHAR(255)) AS ServiceTypeAtEvent
    FROM [Your ticket history table name] h
    WHERE CAST(h.[Event Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(h.[Event Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
conversations AS (
    SELECT
        CAST(c.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(c.[Created Time] AS TIMESTAMP) AS EventTime,
        CAST(c.[Author Type] AS VARCHAR(100)) AS AuthorType,
        CAST(c.[Visibility] AS VARCHAR(100)) AS Visibility,
        CAST(c.[Message Type] AS VARCHAR(100)) AS MessageType,
        CAST(c.[Message Text] AS VARCHAR(4000)) AS MessageText
    FROM [Your conversation table name] c
    WHERE CAST(c.[Created Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(c.[Created Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
sla_events AS (
    SELECT
        CAST(s.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(s.[SLA Due Time] AS TIMESTAMP) AS SLADueTime,
        CAST(s.[Resolution Time] AS TIMESTAMP) AS ResolutionTime,
        CAST(s.[SLA Breached] AS VARCHAR(20)) AS SLABreached
    FROM [Your SLA table name] s
),
confirmations AS (
    SELECT
        CAST(f.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(f.[Confirmation Time] AS TIMESTAMP) AS EventTime,
        CAST(f.[Confirmation Result] AS VARCHAR(255)) AS ConfirmationResult
    FROM [Your survey or confirmation table name] f
    WHERE CAST(f.[Confirmation Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(f.[Confirmation Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT b.ServiceRequestId, 'Service Request Created' AS ActivityName, b.CreatedTime AS EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM base_requests b WHERE b.CreatedTime IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Triaged', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND (LOWER(h.ChangedField) IN ('priority','assigned agent','owner','assigned group','group') OR LOWER(h.NewValue) IN ('triaged','in queue'))
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Prioritized', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'priority' AND COALESCE(h.OldValue, '') <> COALESCE(h.NewValue, '') AND NULLIF(TRIM(h.NewValue), '') IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Assigned to Agent', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) IN ('assigned agent','owner') AND NULLIF(TRIM(h.NewValue), '') IS NOT NULL AND (h.OldValue IS NULL OR TRIM(h.OldValue) = '')
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Reassigned', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) IN ('assigned agent','owner','assigned group','group') AND COALESCE(h.OldValue, '') <> COALESCE(h.NewValue, '') AND NULLIF(TRIM(h.OldValue), '') IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Information Requested from Requestor', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending','awaiting customer','awaiting requestor')
    UNION ALL
    SELECT h.ServiceRequestId, 'Information Provided by Requestor', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.OldValue) IN ('pending','awaiting customer','awaiting requestor') AND LOWER(h.NewValue) IN ('open','in progress')
    UNION ALL
    SELECT h.ServiceRequestId, 'External Vendor Engaged', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending vendor','awaiting third party','vendor')
    UNION ALL
    SELECT h.ServiceRequestId, 'Internal Review Performed', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending approval','internal review','awaiting approval')
    UNION ALL
    SELECT c.ServiceRequestId, 'Note Added', c.EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM conversations c LEFT JOIN base_requests b ON b.ServiceRequestId = c.ServiceRequestId WHERE c.EventTime IS NOT NULL AND (LOWER(COALESCE(c.MessageType, '')) IN ('note','comment','reply') OR LOWER(COALESCE(c.Visibility, '')) IN ('public','private'))
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Reopened', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.OldValue) = 'resolved' AND LOWER(h.NewValue) IN ('open','in progress')
    UNION ALL
    SELECT s.ServiceRequestId, 'SLA Target Breached', COALESCE(s.ResolutionTime, s.SLADueTime), b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM sla_events s LEFT JOIN base_requests b ON b.ServiceRequestId = s.ServiceRequestId WHERE LOWER(COALESCE(s.SLABreached, '')) IN ('true','yes','1') AND s.SLADueTime IS NOT NULL AND COALESCE(s.ResolutionTime, CURRENT_TIMESTAMP) > s.SLADueTime
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Resolved', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) = 'resolved'
    UNION ALL
    SELECT c.ServiceRequestId, 'Resolution Confirmed by Requestor', c.EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM confirmations c LEFT JOIN base_requests b ON b.ServiceRequestId = c.ServiceRequestId WHERE c.EventTime IS NOT NULL AND LOWER(c.ConfirmationResult) IN ('positive','satisfied','confirmed','yes','resolved')
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Closed', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) = 'closed'
)
SELECT
    e.ServiceRequestId,
    e.ActivityName,
    e.EventTime,
    'Freshservice' AS SourceSystem,
    CAST('[Last data update timestamp]' AS TIMESTAMP) AS LastDataUpdate,
    e.AssignedAgent,
    e.AssignedTeam,
    e.Priority,
    e.Status,
    e.ServiceType
FROM events e
WHERE e.ServiceRequestId IS NOT NULL
  AND e.EventTime IS NOT NULL
ORDER BY e.ServiceRequestId, e.EventTime, e.ActivityName;

È pronto a iniziare?

Prepari i dati per compiere il primo passo verso l’ottimizzazione del processo di gestione delle richieste di servizio. Siamo a Sua disposizione per aiutarLa a migliorare l’erogazione dei servizi.

Torna alla guida al miglioramento

Scarica il template

Migliori subito l’efficienza delle richieste di servizio in Freshservice

Riduca i tempi di evasione e la frustrazione degli utenti, raggiungendo un’automazione del 70%.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.

Il template dei dati per la gestione delle richieste di servizio

Il template dei 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 dei dati dal modulo Analytics di Freshservice

Passaggi

Configurazione

Query di esempio sql

Script Python con l’API REST di Freshservice

Passaggi

Configurazione

Query di esempio python

Esportazione pianificata dei dati di Freshservice nell’archiviazione cloud

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Migliori subito l’efficienza delle richieste di servizio in Freshservice