> Amélioration continue des processus > Gestion des incidents > Freshservice > Modèle de données

Votre modèle de données de gestion des incidents

Freshservice

Attributs de la Gestion des incidents (19) Activités de la Gestion des incidents (14) Guides d’extraction (3)

Votre modèle de données de gestion des incidents

Ce modèle est conçu pour vous aider à préparer vos données en vue d’une analyse efficace de la gestion des incidents. Il présente les attributs essentiels à recueillir, les activités importantes à suivre et des conseils pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour simplifier la préparation de vos données.

Attributs recommandés à collecter
Activités essentielles à suivre
Guide d’extraction

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la Gestion des incidents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser complètement votre processus de Gestion des incidents.

5 Obligatoire 7 Recommandé 7 Facultatif

	Nom	Description
	ID de l’incident IncidentId	Identifiant unique de chaque enregistrement d’incident, utilisé comme clé primaire pour suivre l’ensemble du cycle de vie de l’incident.
Description L’Incident ID est la pierre angulaire de l’analyse de la Gestion des incidents. Il fait office de Case ID et relie toutes les activités, tous les horodatages et toutes les modifications d’attributs associés au sein d’un même parcours cohérent. Dans le Process Mining, chaque entrée du journal d’événements est associée à un Incident ID, ce qui permet de reconstituer le flux de processus de bout en bout pour chaque incident. Cette association est indispensable pour calculer les temps de cycle, analyser les variantes de processus et identifier les goulots d’étranglement propres à chaque dossier. Sans identifiant unique, il serait impossible de distinguer les différents incidents et d’analyser leur parcours, du signalement à la résolution. Pourquoi c’est important Il identifie chaque incident de manière unique et permet de suivre et d’analyser son cycle de vie de bout en bout, de la création à la clôture. Où les obtenir Il s’agit de l’identifiant principal d’un ticket, disponible dans l’API Freshservice Tickets sous la forme du champ « id » dans l’objet ticket. Exemples INC-10234INC-10235INC-10236
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation ou extraction des données relatives à ce processus.
Description Cet attribut fournit l’horodatage de la dernière mise à jour de l’ensemble du jeu de données depuis le système source. Il s’agit d’un champ de métadonnées qui s’applique à l’ensemble du jeu de données plutôt qu’à des événements individuels, mais il est souvent inclus au niveau des événements pour garantir la cohérence. Dans l’analyse, cette information est essentielle pour comprendre l’actualité des données et la période couverte par les Dashboards et les KPI. Elle permet aux utilisateurs d’évaluer la récence des analyses et de savoir si les incidents les plus récents sont inclus dans l’analyse. Pourquoi c’est important Il informe les utilisateurs de la récence des données et leur permet de comprendre la période couverte par l’analyse. Où les obtenir Il s’agit d’un horodatage de métadonnées généré lors du processus d’extraction des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité ou l’événement s’est produit.
Description L’Event Timestamp, ou Start Time, indique le moment précis où une activité a eu lieu. Chaque activité du cycle de vie de l’incident, de la création à la clôture, possède un horodatage associé. Cet attribut est essentiel pour toutes les analyses de Process Mining fondées sur le temps. Il sert à classer les événements par ordre chronologique, à calculer la durée entre les activités, à mesurer le temps de cycle total d’un dossier et à analyser les temps d’attente. Il constitue la base des Dashboards qui suivent la performance des SLA, les délais de transfert et les temps globaux de résolution. Pourquoi c’est important Il fournit l’ordre chronologique des événements, indispensable pour calculer les durées, analyser les temps de cycle et comprendre la performance du processus. Où les obtenir Il est déduit de différents champs d’horodatage de Freshservice, tels que « created_at », « updated_at » et les horodatages présents dans les journaux de conversation ou d’audit du ticket. Exemples 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Nom de l’activité ActivityName	Nom de l’activité métier ou de l’événement précis survenu à un moment donné du cycle de vie de l’incident.
Description L’Activity Name décrit une étape ou un événement unique du processus de Gestion des incidents, par exemple « Incident Assigned to Group », « Status Changed to Pending » ou « Incident Resolved ». Ces activités sont déduites des modifications des données de l’incident au fil du temps. Cet attribut est fondamental pour le Process Mining, car il définit les nœuds de la carte de processus découverte. En analysant la séquence et la fréquence de ces activités, les organisations peuvent visualiser le processus réel de résolution des incidents, repérer les parcours courants, détecter les écarts par rapport à la procédure standard et identifier les boucles de reprise, comme les réaffectations fréquentes. Pourquoi c’est important Il définit les étapes de la carte de processus et permet de visualiser et d’analyser le flux de résolution des incidents, les goulots d’étranglement et les écarts. Où les obtenir Cet attribut ne correspond pas à un champ direct de Freshservice. Il est déduit des modifications de propriétés du ticket, telles que le statut, la priorité, l’affectation à un agent ou à un groupe, ainsi que l’ajout de notes. Exemples Incident signaléIncident affecté à un groupeNote de résolution ajoutéeIncident résolu
	Système source SourceSystem	Système depuis lequel les données ont été extraites, généralement « Freshservice ».
Description Cet attribut identifie l’origine des données. Dans ce contexte, sa valeur sera toujours « Freshservice », mais il constitue un champ essentiel dans les environnements où des données provenant de plusieurs systèmes peuvent être combinées afin d’obtenir une vue globale du processus. L’inclusion de l’attribut Source System constitue une bonne pratique en matière de gouvernance et de traçabilité des données. Elle garantit la clarté de leur provenance, ce qui est important pour la validation, le débogage et l’extension future du projet de Process Mining à d’autres systèmes de gestion des services ou systèmes opérationnels. Pourquoi c’est important Il garantit la traçabilité et la gouvernance des données en identifiant clairement l’origine des données de Gestion des incidents. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus de transformation des données (ETL) afin d’identifier le jeu de données. Exemples FreshserviceFreshservice-EUFreshservice-PROD
	Agent affecté AssignedAgent	Nom ou identifiant de l’agent de support actuellement chargé de résoudre l’incident.
Description L’Assigned Agent identifie l’employé du service desk responsable de l’incident à un moment donné. Les modifications de cet attribut représentent un transfert de responsabilité entre agents. Cet attribut est essentiel pour analyser la performance. Il permet de créer des Dashboards qui suivent la charge de travail des agents, le temps moyen de résolution par agent et le taux de résolution au premier contact. Il sert également à analyser les transferts entre agents, qui peuvent être une source de retard et d’inefficacité. Le suivi des affectations permet aux responsables d’identifier les besoins de formation et de reconnaître les membres les plus performants de l’équipe. Pourquoi c’est important Il permet d’analyser la performance des agents, la répartition de la charge de travail et l’incidence des transferts entre agents sur les temps de résolution. Où les obtenir Disponible dans l’API Freshservice Tickets sous la forme du champ « responder_id ». Cet identifiant peut être mis en correspondance avec l’API Agents pour obtenir le nom de l’agent. Exemples John DoeJane SmithSupportBot
	Catégorie de l’incident IncidentCategory	Catégorie utilisée pour classer l’incident, par exemple Hardware, Software ou Network.
Description L’Incident Category permet de classer les incidents selon le type de problème signalé. Cette classification hiérarchique facilite l’acheminement de l’incident vers l’équipe appropriée et est essentielle pour l’analyse des tendances. Cet attribut est utilisé dans le Dashboard « Incident Categorization Accuracy » afin de déterminer si une mauvaise catégorisation initiale entraîne des temps de résolution plus longs en raison de réaffectations. En regroupant les incidents par catégorie, les organisations peuvent identifier les problèmes récurrents, comprendre où se concentre l’essentiel de l’effort de support et adapter leurs initiatives d’amélioration. Pourquoi c’est important Elle permet d’analyser les tendances des incidents et de déterminer si une catégorisation incorrecte entraîne des retards de résolution. Où les obtenir Il s’agit d’un champ par défaut et personnalisable de Freshservice. Il est disponible dans l’API Tickets sous la forme de « category », avec les champs associés « sub_category » et « item_category ». Exemples MatérielLogicielProblème réseauAccès au compte
	Échéance du SLA de résolution ResolutionSlaTargetTime	Horodatage avant lequel l’incident est censé être résolu conformément à sa politique de SLA.
Description Cet attribut stocke la date et l’heure précises qui constituent l’échéance de résolution d’un incident. Cette échéance est déterminée par la politique de Service Level Agreement (SLA) appliquée au ticket, qui dépend généralement de facteurs tels que la priorité. Cette échéance est essentielle pour calculer le KPI « SLA Adherence Rate » et alimenter le « SLA Performance Dashboard ». En comparant l’horodatage réel de résolution à cette échéance, il est possible de déterminer si l’incident a été résolu dans les délais ou si son SLA n’a pas été respecté. Cette comparaison est fondamentale pour mesurer la conformité aux niveaux de service. Pourquoi c’est important Elle fournit l’échéance de résolution, nécessaire pour calculer la conformité aux SLA et identifier les incidents à risque. Où les obtenir Disponible dans l’API Freshservice Tickets sous la forme des champs « fr_due_by » (première réponse) et « due_by » (résolution). Exemples 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Gravité de l’incident IncidentSeverity	Niveau de gravité de l’incident, indiquant son impact sur l’activité.
Description L’Incident Severity mesure l’impact d’un incident sur l’activité. Elle est souvent classée comme Low, Medium, High ou Critical. Bien que la gravité soit liée à la priorité, elle porte sur l’impact, tandis que la priorité concerne l’urgence. La combinaison de la gravité et de l’impact détermine souvent la priorité finale. L’analyse par niveau de gravité permet de comprendre dans quelle mesure l’organisation traite les incidents ayant des conséquences importantes pour l’activité. Elle est utilisée dans les Dashboards pour segmenter les temps de résolution et la performance des SLA, afin de garantir que les problèmes les plus lourds de conséquences bénéficient du niveau d’attention et de ressources approprié tout au long de leur cycle de vie. Pourquoi c’est important Elle mesure l’impact d’un incident sur l’activité et permet de concentrer l’analyse sur les problèmes les plus dommageables. Où les obtenir Il s’agit d’un champ par défaut de Freshservice, disponible dans l’API Tickets sous la forme de « impact ». Les valeurs sont numériques. Exemples FaibleMoyenneÉlevée
	Groupe affecté AssignedGroup	Groupe ou équipe de support actuellement chargé de l’incident.
Description L’Assigned Group indique quelle équipe, par exemple « Level 1 Support », « Network Team » ou « Database Admins », est responsable de l’incident. Les modifications de cet attribut signalent une escalade ou un transfert entre différentes équipes fonctionnelles. L’analyse de l’Assigned Group est essentielle pour comprendre les délais liés aux transferts et aux prises en charge. Le Process Mining peut visualiser le flux des incidents entre les groupes, mettre en évidence les parcours d’escalade courants et mesurer le temps d’attente avant l’intervention de chaque groupe. Cette analyse aide à identifier les goulots d’étranglement organisationnels et les possibilités d’améliorer la collaboration entre équipes. Pourquoi c’est important Il indique quelle équipe est responsable et permet d’analyser les transferts, les escalades et les délais entre équipes. Où les obtenir Disponible dans l’API Freshservice Tickets sous la forme du champ « group_id ». Cet identifiant peut être mis en correspondance avec l’API Groups pour obtenir le nom du groupe. Exemples Centre de servicesOpérations réseauSupport de l'infrastructure
	Priorité de l’incident IncidentPriority	Niveau de priorité de l’incident, qui détermine l’urgence de la réponse et de la résolution.
Description L’Incident Priority est un champ essentiel qui détermine la rapidité et le niveau d’attention requis pour traiter un incident. Elle est généralement définie selon une échelle telle que Low, Medium, High et Urgent, et détermine souvent les objectifs de SLA. Dans le Process Mining, la priorité constitue une dimension importante pour le filtrage et l’analyse. Elle permet de comparer les processus de résolution des incidents hautement prioritaires et des incidents moins prioritaires, afin de vérifier que les problèmes critiques sont traités efficacement. Les Dashboards segmentent souvent des indicateurs tels que le temps de cycle et le respect des SLA par niveau de priorité, afin de fournir aux responsables du support des analyses concrètes. Pourquoi c’est important Elle permet de concentrer l’analyse sur les incidents les plus critiques et est essentielle pour évaluer la performance des SLA et l’affectation des ressources. Où les obtenir Disponible dans l’API Freshservice Tickets sous la forme du champ « priority ». Les valeurs sont numériques, par exemple 1 pour Low et 4 pour Urgent. Exemples FaibleMoyenneÉlevéeUrgente
	Statut de l’incident IncidentStatus	Statut actuel de l’incident dans son cycle de vie, par exemple Open, Pending, Resolved ou Closed.
Description L’Incident Status indique l’état actuel de l’incident. Les changements de statut sont des événements clés qui constituent la base de la carte de processus découverte, par exemple le passage de « In Progress » à « Pending » ou de « Resolved » à « Closed ». Cet attribut est fondamental pour comprendre le parcours de l’incident. L’analyse du temps passé dans chaque statut permet d’identifier les goulots d’étranglement, notamment les incidents qui restent trop longtemps à l’état « Pending » dans l’attente d’une réponse de l’utilisateur. Il est également essentiel pour définir les points de début et de fin utilisés dans les calculs du temps de cycle. Pourquoi c’est important Il suit la progression de l’incident tout au long de son cycle de vie et aide à identifier les étapes où les retards sont fréquents. Où les obtenir Disponible dans l’API Freshservice Tickets sous la forme du champ « status ». Les valeurs sont numériques. Exemples OuvertEn coursEn attenteRésoluFermé
	Canal de signalement ReportingChannel	Méthode ou canal par lequel l’incident a été signalé, par exemple Email, Portal ou Phone.
Description Le Reporting Channel, également appelé source, indique comment un incident est entré dans le système de support. Les canaux courants comprennent l’e-mail, un portail en libre-service, les appels téléphoniques et le chat. L’analyse de cet attribut permet d’évaluer l’efficacité des différents canaux de signalement. Le Dashboard « Reporting Channel Efficiency » compare le volume d’incidents et le temps moyen de résolution par canal afin de déterminer quelles méthodes sont les plus efficaces et lesquelles nécessitent des améliorations. Par exemple, les incidents signalés via le portail peuvent être résolus plus rapidement lorsqu’ils contiennent dès le départ des informations mieux structurées. Pourquoi c’est important Il permet d’identifier les canaux de signalement les plus efficaces et de repérer les possibilités d’amélioration du processus de prise en charge des incidents. Où les obtenir Disponible dans l’API Freshservice Tickets sous la forme du champ « source ». Les valeurs sont numériques. Exemples E-mailPortailTéléphoneChat
	Cause racine RootCause	Raison sous-jacente ou cause racine identifiée pour l’incident après investigation.
Description L’attribut Root Cause décrit le problème fondamental à l’origine de l’incident. Ces informations sont généralement renseignées par les agents de support pendant ou après la résolution, dans le cadre d’une analyse de la cause racine (RCA). Cet attribut est essentiel pour le Dashboard « Recurring Incidents And Root Causes » et le KPI « Root Cause Analysis Completion Rate ». En analysant les causes racines courantes, les organisations peuvent passer d’une correction réactive des incidents à une Gestion des problèmes proactive, mettre en œuvre des solutions permanentes et réduire les incidents récurrents. Pourquoi c’est important Il permet une Gestion des problèmes proactive en aidant à identifier et à éliminer les causes sous-jacentes des incidents récurrents. Où les obtenir Il s’agit souvent d’un champ personnalisé dans Freshservice, car les fonctionnalités par défaut peuvent être limitées. Vérifiez la configuration « Ticket Fields » pour rechercher un champ nommé « Root Cause » ou un intitulé similaire. Exemples Bug logicielErreur de configuration réseauProblème de formation utilisateurDéfaillance matérielle
	Nombre de transferts HandoffCount	Nombre de fois où un incident a été transféré entre différents agents ou groupes.
Description Le Handoff Count est une mesure calculée qui quantifie le nombre de réaffectations subies par un incident au cours de son cycle de vie. Chaque modification de l’attribut « AssignedAgent » ou « AssignedGroup » augmente ce nombre. Un nombre élevé de transferts indique souvent une inefficacité du processus, un mauvais acheminement initial ou un manque d’expertise des agents. Cette mesure alimente directement le KPI « Incident Handoff Count » et le Dashboard « Handoff And Transfer Delay Analysis », qui aident à identifier les incidents ou les parcours comportant trop de transferts et entraînant des retards. Pourquoi c’est important Il quantifie les reprises et les réaffectations et aide à identifier les inefficacités dues à un mauvais acheminement ou à des lacunes de connaissances. Où les obtenir Il s’agit d’une mesure calculée obtenue en comptant le nombre de valeurs distinctes ou de modifications des champs « AssignedAgent » ou « AssignedGroup » au cours du cycle de vie d’un même incident. Exemples 0125
	Rouverte IsReopened	Indicateur calculé dont la valeur est vraie si un incident a été rouvert après avoir été résolu ou fermé.
Description Cet attribut booléen est un indicateur calculé qui identifie les incidents ayant été rouverts. Sa valeur devient vraie si, après avoir atteint l’état « Resolved » ou « Closed », le statut d’un incident repasse à un état ouvert ou en cours. Cet indicateur est essentiel pour calculer le KPI « Incident Reopening Rate » et alimenter le Dashboard « Recurring Incidents ». Un taux élevé de réouverture peut signaler des problèmes liés à la qualité de la résolution initiale, à une analyse incomplète de la cause racine ou à une clôture prématurée. L’analyse de ces cas contribue à améliorer la qualité et la pérennité des corrections. Pourquoi c’est important Il identifie les défaillances du processus de résolution, en mettant en évidence les incidents pour lesquels la correction initiale était inefficace et a entraîné une reprise du traitement. Où les obtenir Il s’agit d’un champ calculé déduit de la séquence des activités du journal d’événements. Sa valeur est vraie si une activité telle que « Incident Reopened » apparaît ou si une activité correspondant à un état ouvert suit une activité correspondant à un état fermé pour le même Incident ID. Exemples truefalse
	Service du demandeur RequestersDepartment	Service auquel appartient l’utilisateur ayant signalé l’incident.
Description Cet attribut identifie le service métier du demandeur, par exemple « Sales », « Finance » ou « IT ». Ces informations proviennent généralement du profil de l’utilisateur dans Freshservice. L’analyse des incidents par service du demandeur peut révéler si certaines unités opérationnelles sont touchées de manière disproportionnée par des problèmes ou si des difficultés sont propres à certains services. Elle fournit un contexte utile pour comprendre l’impact des incidents sur l’activité et peut aider à prioriser les corrections qui concernent les services essentiels. Pourquoi c’est important Il fournit un contexte métier et permet d’analyser les tendances des incidents ainsi que leur impact sur des services précis. Où les obtenir Ces informations sont liées au demandeur du ticket. Elles peuvent être récupérées via le point de terminaison de l’API « Requesters » en utilisant le « requester_id » du ticket, puis en consultant le « department_id » et le nom du service. Exemples VentesMarketingFinanceRessources humaines
	SLA non respecté IsSlaBreached	Indicateur calculé dont la valeur est vraie si l’incident n’a pas été résolu dans le délai cible défini par son SLA.
Description Cet attribut booléen est un indicateur calculé qui précise si le temps de résolution d’un incident a dépassé son objectif de SLA. Il est obtenu en comparant l’horodatage réel de résolution au champ « ResolutionSlaTargetTime ». Cet indicateur alimente directement le KPI « SLA Adherence Rate » et le « SLA Performance Dashboard ». Il simplifie l’analyse en fournissant un résultat binaire clair pour la performance SLA de chaque incident, ce qui facilite l’agrégation et l’analyse des tendances. Il permet d’identifier rapidement le volume et le pourcentage d’incidents qui ne respectent pas les engagements de service. Pourquoi c’est important Il mesure directement la conformité au SLA pour chaque incident et facilite le calcul du taux global de respect des SLA ainsi que l’identification des problèmes. Où les obtenir Il s’agit d’un champ calculé, obtenu lors de la transformation des données en comparant l’horodatage « Incident Resolved » au champ « ResolutionSlaTargetTime ». Exemples truefalse
	Solution de contournement fournie WorkaroundProvided	Indicateur précisant si une solution de contournement temporaire a été fournie à l’utilisateur avant la résolution finale.
Description Cet attribut booléen indique si une correction temporaire ou une solution de contournement a été mise en œuvre pour limiter l’impact de l’incident pendant l’élaboration d’une solution permanente. Il est souvent suivi au moyen d’une case à cocher ou d’un statut spécifique. Dans le Process Mining, cet attribut alimente le Dashboard « Workaround Effectiveness Metrics ». Il permet de comparer les temps de résolution des incidents avec et sans solution de contournement, afin de déterminer si les corrections temporaires réduisent effectivement les perturbations de l’activité et contribuent à accélérer la résolution perçue par l’utilisateur. Pourquoi c’est important Il aide à mesurer l’efficacité des solutions de contournement temporaires pour réduire l’impact des incidents et accélérer la résolution perçue. Où les obtenir Il s’agit généralement d’un champ booléen personnalisé, sous la forme d’une case à cocher. Sa présence doit être vérifiée dans la configuration « Ticket Fields » de Freshservice. Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de la Gestion des incidents

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour permettre une découverte précise du processus et identifier les goulots d’étranglement.

7 Recommandé 7 Facultatif

	Activité	Description
	Incident affecté à un groupe	Représente l'affectation initiale d'un incident à un groupe de support. Cette affectation peut être effectuée automatiquement par des règles de routage ou manuellement par un répartiteur. L'activité est capturée en suivant le premier renseignement du champ « Group » dans le journal d'audit de l'incident.
Pourquoi c’est important Le suivi des affectations est essentiel pour mesurer les délais de première réponse et identifier les goulots d'étranglement du processus de répartition. Il permet d'analyser l'efficacité avec laquelle les incidents sont orientés vers l'équipe appropriée. Où les obtenir Déduit de la première entrée du journal d'activité de l'incident qui renseigne ou modifie le champ « Group ». Collecte Identifiez le premier horodatage auquel le champ « Group » est renseigné pour un incident. Type d’événement inferred
	Incident fermé	Représente la clôture finale et officielle de l’enregistrement de l’incident. Elle intervient généralement automatiquement après une période définie dans l’état « Resolved », mais peut également être effectuée manuellement par un agent. Cet événement marque la fin du cycle de vie de l’incident.
Pourquoi c’est important Cette activité constitue le point final définitif du processus. Le temps total jusqu’à cet événement représente la durée complète du cycle de vie de l’incident, y compris les éventuelles périodes d’attente d’une confirmation de l’utilisateur. Où les obtenir Déduit du journal d’activité de l’incident en identifiant le moment où le champ « Status » est mis à jour sur « Closed ». Collecte Utiliser l’horodatage de l’entrée du journal d’activité correspondant au changement de statut vers « Closed ». Type d’événement inferred
	Incident priorisé	Se produit lorsque la priorité de l'incident est définie ou mise à jour. Le niveau de priorité détermine l'urgence et les objectifs SLA de résolution. Cette activité est capturée en surveillant les modifications du champ « Priority » dans l'historique de l'incident.
Pourquoi c’est important Une priorisation incorrecte ou tardive peut entraîner des dépassements de SLA et une affectation inefficace des ressources. L'analyse de cette activité permet de garantir que les incidents critiques reçoivent une attention immédiate. Où les obtenir Déduit du journal d'activité de l'incident, qui enregistre toutes les mises à jour du champ « Priority ». Collecte Utilisez les horodatages du journal d'audit auxquels la valeur du champ « Priority » a été définie ou modifiée. Type d’événement inferred
	Incident résolu	Marque le moment où l'agent a mis en œuvre une correction et considère l'incident comme résolu. Cette activité est capturée lorsque le statut de l'incident passe à « Resolved ». Dans Freshservice, il s'agit d'une étape importante qui arrête le compteur SLA.
Pourquoi c’est important Cette étape est essentielle pour mesurer le délai de résolution, ou TTR. La période entre « Resolved » et « Closed » est importante pour analyser les retards de confirmation par l'utilisateur et les règles de clôture automatique. Où les obtenir Déduit du journal d'activité de l'incident en identifiant le moment où le champ « Status » est mis à jour avec la valeur « Resolved ». Collecte Utilisez l'horodatage de l'entrée du journal d'activité correspondant au passage du statut à « Resolved ». Type d’événement inferred
	Incident signalé	Indique la création d'un nouvel enregistrement d'incident dans Freshservice. Il s'agit du point de départ du cycle de vie de l'incident, généralement déclenché par un utilisateur final via un portail ou un e-mail, ou par un agent du centre de services qui crée un ticket pour son compte. Cet événement est enregistré explicitement avec un horodatage de création.
Pourquoi c’est important Cette activité constitue l'événement de début principal de l'ensemble du processus. L'analyse du délai entre cet événement et la résolution est fondamentale pour mesurer les temps de cycle globaux et le respect des SLA. Où les obtenir Capturé à partir de l'horodatage de création de la table des incidents. Freshservice l'enregistre explicitement pour chaque nouveau ticket. Collecte Utilisez l'horodatage « Created at » de l'enregistrement principal de l'incident. Type d’événement explicit
	Note de résolution ajoutée	Se produit lorsqu'un agent documente la solution apportée à l'incident en ajoutant une note de résolution. Il s'agit d'une action distincte dans Freshservice, effectuée avant le passage du statut à « Resolved ». Cette action et son contenu sont enregistrés explicitement.
Pourquoi c’est important Cette activité marque l'identification d'une solution. Le délai entre cette étape et le statut « Incident Resolved » peut révéler le temps consacré à la revue interne ou à la documentation. Où les obtenir Capturé à partir de l'horodatage d'ajout d'une note de résolution à l'incident, enregistré dans l'historique des conversations. Collecte Identifiez l'horodatage de l'entrée « Resolution Note » dans le journal des conversations de l'incident. Type d’événement explicit
	Statut modifié en In Progress	Cette activité marque le début officiel de l'investigation et du traitement actifs de l'incident. Elle est capturée lorsqu'un agent modifie le statut de l'incident en « In Progress ». Il s'agit d'une modification de statut standard enregistrée dans l'historique d'activité du ticket.
Pourquoi c’est important Cette étape permet de distinguer le temps d'attente du temps de traitement actif. L'analyse de la durée pendant laquelle un incident reste « In Progress » est essentielle pour comprendre l'effort nécessaire à sa résolution. Où les obtenir Déduit du journal d'activité de l'incident en identifiant le moment où le champ « Status » est mis à jour avec la valeur « In Progress ». Collecte Filtrez le journal d'activité pour trouver une modification du statut vers « In Progress » et utilisez son horodatage. Type d’événement inferred
	Agent affecté à l'incident	Cette activité indique le moment où un agent précis est affecté au traitement de l'incident. Elle marque la prise en charge individuelle du ticket. L'affectation est enregistrée dans l'historique d'activité du ticket, avec l'identité de l'agent et l'heure de l'affectation.
Pourquoi c’est important Cela permet d'analyser la charge de travail et les performances des agents, ainsi que le délai nécessaire pour qu'un incident soit pris en charge par une personne après son affectation à un groupe. Cette information est essentielle pour les Dashboards de performance des agents. Où les obtenir Suivi au moyen des modifications du champ « Agent » dans le journal d'activité ou la piste d'audit de l'incident. Collecte Identifiez les horodatages correspondant aux modifications du champ « Agent ». Type d’événement inferred
	Incident réaffecté	Indique que l'incident a été transféré d'un agent ou d'un groupe à un autre. Cela correspond à un transfert dans le processus de résolution. L'événement est déduit de la détection des modifications ultérieures des champs « Agent » ou « Group » après l'affectation initiale.
Pourquoi c’est important Les réaffectations fréquentes, ou transferts, signalent souvent des inefficacités de processus, des lacunes de connaissances ou un routage initial incorrect. L'analyse de ces événements aide à identifier et à réduire les retards. Où les obtenir Déduit du journal d'activité de l'incident en suivant toute modification des champs « Agent » ou « Group » après la première affectation. Collecte Détectez les modifications des champs « Agent » ou « Group » dans l'historique d'audit du ticket. Type d’événement inferred
	Incident rouvert	Se produit lorsqu'un incident précédemment marqué comme « Resolved » repasse à un statut ouvert, généralement parce que l'utilisateur conteste la résolution. Cet événement est déduit d'une modification du statut de « Resolved » vers un état tel que « Open » ou « In Progress ».
Pourquoi c’est important Un taux de réouverture élevé indique des problèmes de qualité de résolution ou des corrections incomplètes. Il s'agit d'un indicateur important pour analyser les reprises et les performances des agents. Où les obtenir Déduit du journal d’activité de l’incident en détectant un changement de statut de « Resolved » vers un statut actif. Collecte Filtrer le journal d’activité pour repérer un changement de « Status » de « Resolved » vers « Open » ou « In Progress ». Type d’événement inferred
	Objectif SLA dépassé	Il s'agit d'un événement calculé qui se produit lorsque le temps écoulé pour un incident dépasse l'objectif SLA défini pour la réponse ou la résolution. Freshservice suit l'état des SLA en interne et cet événement peut être déduit en comparant les horodatages aux règles SLA.
Pourquoi c’est important Mesure directement le respect des engagements de niveau de service. Identifier quand et pourquoi les dépassements surviennent est essentiel pour le Dashboard de performance des SLA et l'amélioration continue. Où les obtenir Calculé en comparant l'horodatage de résolution ou de réponse à l'échéance prévue par le SLA. Freshservice signale souvent les tickets comme « SLA Violated ». Collecte Déduisez-le en comparant l'horodatage « Resolved at » à l'horodatage « Due by », ou lorsque le champ « SLA Status » passe à « Violated ». Type d’événement calculated
	Première réponse envoyée	Cette activité représente la première communication d'un agent à l'utilisateur après le signalement de l'incident. Il peut s'agir d'une note publique ou d'une réponse directe. Freshservice enregistre toutes les communications des agents avec leur horodatage.
Pourquoi c’est important Le respect du SLA de première réponse est un KPI essentiel pour la satisfaction des clients. Cette activité permet de mesurer et d'analyser la rapidité avec laquelle les agents prennent en charge les nouveaux incidents. Où les obtenir Identifiée en recherchant l'horodatage de la première note publique ou réponse ajoutée par un agent dans le journal des conversations de l'incident. Collecte Filtrez l'historique des conversations de l'incident pour trouver la première entrée créée par un agent. Type d’événement explicit
	Solution de contournement fournie	Cette activité indique qu'une solution temporaire ou une solution de contournement a été communiquée à l'utilisateur afin de réduire l'impact de l'incident. Sa capture nécessite souvent une configuration spécifique du système, comme une case à cocher dédiée, un type de note particulier ou une analyse des mots-clés présents dans les notes des agents.
Pourquoi c’est important Cela permet d'analyser l'efficacité des solutions de contournement pour réduire l'impact sur l'activité et leur relation avec le délai de résolution définitive. Cette analyse alimente le Dashboard des indicateurs d'efficacité des solutions de contournement. Où les obtenir Il ne s'agit probablement pas d'un événement explicite. Il peut être déduit en repérant les notes contenant des mots-clés tels que « workaround », ou lorsqu'un champ personnalisé « Workaround Provided » est utilisé et que sa modification est enregistrée. Collecte Déduit d'une modification d'un champ personnalisé ou d'une analyse des mots-clés présents dans les notes des agents. Type d’événement inferred
	Statut modifié en Pending	Représente le moment où le processus de résolution est suspendu, généralement dans l'attente d'informations de l'utilisateur ou d'un tiers. Cet événement est déduit d'une modification du statut vers un état « Pending ». Le temps passé dans cet état est souvent exclu des calculs de SLA.
Pourquoi c’est important L'identification du temps passé dans les états d'attente est essentielle pour comprendre les dépendances externes et les retards. Elle permet de distinguer le temps de travail des agents du temps d'attente. Où les obtenir Déduit du journal d'activité de l'incident lorsque le champ « Status » est mis à jour avec une valeur telle que « Pending » ou « Awaiting User Response ». Collecte Filtrez le journal d'activité pour trouver les modifications vers un état d'attente et utilisez l'horodatage associé. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Freshservice

Étapes

Accédez aux analyses de Freshservice : Connectez-vous à votre instance Freshservice avec un compte disposant des autorisations nécessaires pour accéder aux rapports et en créer. Dans le menu principal, accédez au module Analyses.
Créez un rapport : Cliquez sur le bouton Nouveau rapport. Saisissez un nom explicite, par exemple « Journal d’événements de la gestion des incidents ». Lorsque vous devez choisir une source de données, sélectionnez le module Gestion des incidents.
Sélectionnez le widget du rapport : Dans l’éditeur de rapports, ajoutez un widget, puis sélectionnez le type Tableau. Il servira de base à vos données de journal d’événements.
Ajoutez les colonnes de données principales : Dans le panneau de la source de données à droite, faites glisser les champs nécessaires vers la configuration des colonnes du tableau. Commencez par Incident ID, Created at, Agent, Group, Priority, Severity, Status et Category.
Intégrez les données d’activité : Pour enregistrer les événements individuels, vous devez joindre ou inclure les données des activités des tickets. Ajoutez la source de données Activities à votre widget. Dans cette source, ajoutez Performed at, qui correspond à l’horodatage de l’événement, ainsi que Activity description ou des champs similaires décrivant la modification effectuée.
Créez une colonne calculée « ActivityName » : Il s’agit de l’étape la plus importante. Créez une colonne calculée ou un champ de formule. Utilisez des instructions IF imbriquées ou une fonction CASE pour convertir les données d’activité brutes en valeurs ActivityName attendues. Consultez la section Query pour connaître la logique détaillée des 14 activités.
Configurez « EventTimestamp » : Créez une autre colonne calculée pour EventTimestamp. Cette colonne doit sélectionner l’horodatage Created at pour l’activité « Incident Reported », puis l’horodatage Performed at de l’activité pour tous les autres événements.
Appliquez les filtres du rapport : Configurez les filtres afin de limiter les données. Définissez au minimum un filtre de période sur le champ Created at. Une période couvrant les 3 à 6 derniers mois est recommandée. Ajoutez également un filtre pour inclure uniquement les tickets dont Ticket Type est « Incident ».
Exécutez et affinez le rapport : Exécutez le rapport pour générer un aperçu des données. Vérifiez que les colonnes ActivityName et EventTimestamp sont correctement renseignées. Ajustez les formules et les filtres si nécessaire.
Enregistrez et exportez le rapport : Lorsque le résultat vous convient, enregistrez le rapport. Utilisez l’option Export et sélectionnez CSV comme format.
Planifiez l’exportation (facultatif) : Pour assurer un suivi continu, vous pouvez planifier l’exécution et l’exportation automatiques du rapport. Définissez une fréquence, par exemple quotidienne ou hebdomadaire, afin que le fichier CSV soit envoyé à votre adresse e-mail ou à une autre destination.
Préparez les données à importer : Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonnes pour respecter le schéma requis par ProcessMind : IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Ajoutez les colonnes statiques SourceSystem, avec la valeur « Freshservice », et LastDataUpdate, avec l’horodatage actuel. Le fichier est maintenant prêt à être importé.

Configuration

Module Analytics : cette extraction nécessite l’accès au module Analytics de Freshservice, disponible dans les offres supérieures, par exemple Pro ou Enterprise.
Autorisations requises : votre compte utilisateur doit disposer d’un rôle autorisant la création, la modification et l’exécution de rapports dans le module Analytics.
Période : il est essentiel de définir un filtre sur la date de création des incidents afin de maîtriser le volume de données. Une période glissante de 3 à 6 mois est recommandée pour équilibrer contexte historique et performances.
Filtres du rapport : filtrez toujours Ticket Type sur « Incident » afin d’exclure les demandes de service et les autres types de tickets de votre analyse de processus.
Champs calculés : cette méthode repose largement sur des champs calculés, ou formules, pour déterminer ActivityName et EventTimestamp pour chaque événement. Une bonne connaissance de l’éditeur de formules Freshservice est utile.
Volume de données : pour chaque incident, cette extraction génère plusieurs lignes, une par activité. Dans les grandes instances Freshservice, le fichier CSV obtenu peut devenir très volumineux, ce qui allonge la génération du rapport et l’exportation.

a Exemple de requête config

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

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

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

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

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

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

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

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

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

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

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

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

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

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

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

Étapes

Prérequis : vérifiez que Python 3.6 ou une version ultérieure est installé, ainsi que les bibliothèques requests et pandas. Vous pouvez les installer avec pip : pip install requests pandas.
Générer une clé API : connectez-vous à votre instance Freshservice en tant qu’administrateur. Ouvrez les paramètres de votre profil en cliquant sur votre photo de profil, en haut à droite. Accédez à la section « API Key » et copiez votre clé API personnelle. Traitez cette clé comme un mot de passe.
Configurer le script : enregistrez le code Python fourni dans un fichier nommé extract_freshservice_incidents.py sur votre ordinateur.
Configurer les paramètres : ouvrez le fichier du script dans un éditeur de texte. Remplacez les valeurs d’exemple de FRESHSERVICE_DOMAIN, par exemple « yourcompany.freshservice.com », API_KEY, avec la clé que vous venez de copier, et START_DATE_STR, avec le début de la période d’extraction souhaitée au format « YYYY-MM-DD ».
Comprendre la logique du script : le script récupère d’abord tous les tickets d’incident créés après la date de début indiquée. Il parcourt chaque page de résultats renvoyée par l’API. Pour chaque ticket, il effectue un second appel API afin de récupérer l’historique détaillé des activités.
Générer l’Event Log : le script traite les données principales du ticket et son journal d’activités afin d’identifier et de créer les enregistrements correspondant aux 14 activités métier requises. Par exemple, « Incident Reported » est créé à partir de la date de création du ticket, tandis que « Status Changed to In Progress » est déduit d’une entrée précise du journal d’activités.
Déduire les événements complexes : certains événements, comme « SLA Target Breached », sont calculés. Le script vérifie si le SLA de résolution d’un ticket a été violé. Si c’est le cas, il crée un événement horodaté avec la date due_by, qui marque le moment de la violation.
Exécuter le script : ouvrez un terminal ou une invite de commandes, accédez au répertoire dans lequel vous avez enregistré le script, puis exécutez-le avec la commande : python extract_freshservice_incidents.py.
Suivre l’exécution : le script affiche dans la console l’avancement du traitement, notamment le nombre de tickets traités. Selon le nombre de tickets et les limites de débit de l’API, l’opération peut prendre un certain temps.
Vérifier le résultat : à la fin de l’exécution, un fichier CSV nommé freshservice_incident_event_log.csv est créé dans le même répertoire. Il contient l’Event Log complet.
Préparer le chargement : ouvrez le fichier CSV dans un tableur afin de vérifier que les colonnes IncidentId, ActivityName, EventTimestamp, etc. sont correctement renseignées. Le fichier est prêt à être chargé dans ProcessMind ou un autre outil de Process Mining.

Configuration

FRESHSERVICE_DOMAIN : l’URL Freshservice propre à votre entreprise, par exemple mycompany.freshservice.com. Ce paramètre est obligatoire dans le script.
API_KEY : la clé API personnelle d’un utilisateur disposant des autorisations suffisantes pour lire toutes les données d’incident. Ce paramètre est obligatoire.
START_DATE_STR : la date de début de l’extraction au format « YYYY-MM-DD ». Il est recommandé d’extraire initialement une période de 3 à 6 mois afin d’obtenir une analyse pertinente.
PAGE_SIZE : définissez cette valeur sur 100, le maximum autorisé par l’API Freshservice, afin de réduire le nombre d’appels API et d’améliorer les performances. Il est généralement déconseillé de la modifier.
Limitation du débit de l’API : le script inclut un appel time.sleep(1) après le traitement de chaque ticket afin de respecter les limites de débit de l’API Freshservice. Pour les instances à fort volume, cette valeur devra peut-être être ajustée afin d’éviter les erreurs.
Autorisations requises : la clé API utilisée doit appartenir à un compte utilisateur, par exemple un compte de service dédié, disposant au minimum des autorisations du rôle « SD Agent », afin d’accéder à tous les champs de ticket et journaux d’activités nécessaires dans les différents groupes du centre de services.

a Exemple de requête python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Étapes

Vérifiez que votre offre Freshservice et vos autorisations d’administrateur permettent d’utiliser les règles du flux de travail Automator, les actions de webhook, l’accès aux incidents et l’historique des activités des tickets. Confirmez avec l’équipe destinataire le point de terminaison, la méthode d’authentification, les exigences TLS et la politique de conservation.
Définissez le contrat d’événement avant de configurer l’automatisation. Utilisez un objet JSON par livraison de webhook avec IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory et ResolutionSlaTargetTime. Configurez le récepteur pour conserver la charge utile originale du webhook ainsi que son horodatage de livraison.
Créez une règle du flux de travail Automator pour la création des incidents. Configurez son déclenchement à la création d’un incident, puis ajoutez une action de webhook qui envoie l’activité Incident Reported. Définissez EventTimestamp sur l’horodatage de création de l’incident et ActivityName sur Incident Reported.
Créez des règles de mise à jour pour les changements d’affectation, de priorité, de statut, de communication, de notes, de SLA et de clôture. Configurez les conditions à partir des champs d’incident et de l’historique des activités disponibles dans votre compte Freshservice. Chaque règle doit envoyer un événement de webhook distinct lorsque l’activité correspondante se produit. Ne demandez pas à ProcessMind de déduire les activités à partir d’un instantané final de l’incident.
Configurez une association explicite des activités. Envoyez Incident Assigned to Group lorsque le champ Group reçoit sa valeur initiale, Agent Assigned to Incident lorsque le champ Agent reçoit sa valeur initiale, Incident Prioritized lorsque Priority est défini ou modifié, First Response Sent lorsqu’une première réponse ou note publique admissible d’un agent est enregistrée, Incident Reassigned lorsque Agent ou Group change après l’affectation initiale, Status Changed to In Progress et Status Changed to Pending pour les transitions de statut correspondantes, Workaround Provided uniquement lorsqu’un indicateur de solution de contournement configuré est présent, Resolution Note Added lorsqu’une note de résolution est ajoutée, Incident Resolved lorsque le statut passe à Resolved, SLA Target Breached lorsque la condition de dépassement du SLA configurée est remplie, Incident Reopened lorsque le statut passe de Resolved à un statut ouvert, et Incident Closed lorsque le statut passe à Closed.
Configurez le corps de la requête webhook au format JSON et incluez l’identifiant de l’incident, le nom de l’activité, l’horodatage de l’événement, le système source, la dernière mise à jour des données et les attributs contextuels recommandés. Utilisez les variables de webhook Freshservice mises à disposition par votre compte. Si une variable obligatoire n’est pas disponible dans l’éditeur de webhook, renseignez-la dans le service destinataire en appelant une interface Freshservice approuvée, ou laissez sa valeur vide plutôt que d’en inventer une.
Configurez l’idempotence et la gestion des livraisons au niveau du point de terminaison. Utilisez un identifiant d’événement stable si Freshservice en fournit un. Dans le cas contraire, construisez une clé de déduplication à partir de IncidentId, ActivityName, EventTimestamp et de l’identifiant de livraison source. Ne renvoyez une réponse HTTP de succès qu’après l’acceptation durable de la charge utile.
Testez chaque règle avec des incidents contrôlés. Créez un incident, affectez-lui un groupe et un agent, modifiez la priorité et le statut, envoyez une réponse admissible, ajoutez une solution de contournement et une note de résolution si elles sont configurées, puis résolvez, rouvrez et fermez l’incident. Testez séparément un dépassement de SLA à l’aide d’une politique ou d’une file de test contrôlée. Vérifiez que chaque activité attendue arrive dans une charge utile de webhook distincte.
Déposez les charges utiles des webhooks dans une zone de préparation durable, normalisez les horodatages dans un même fuseau horaire et aplatissez chaque charge utile en une ligne du journal d’événements. Conservez une ligne par activité de webhook explicite. Renseignez LastDataUpdate avec l’horodatage d’actualisation de l’extraction ou de l’ingestion, et non avec l’horodatage de l’événement métier.
Validez le journal d’événements préparé, supprimez uniquement les livraisons strictement dupliquées et conservez les répétitions légitimes, comme plusieurs changements de priorité ou transitions de statut. Vérifiez que IncidentId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate sont présents sur chaque ligne.
Exportez le journal d’événements normalisé au format CSV ou dans un autre format pris en charge par ProcessMind. Utilisez exactement les noms de colonnes IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory et ResolutionSlaTargetTime. Importez le fichier ou connectez la source d’événements préparée à ProcessMind, en associant IncidentId à l’identifiant du cas et ActivityName au champ d’activité.

Configuration

Périmètre des déclencheurs : Configurez des règles distinctes du flux de travail Automator pour la création des incidents et pour chaque condition de mise à jour. Une règle générale de mise à jour peut créer des événements en double ou ambigus, sauf si le récepteur applique une association stricte des activités.
Charge utile du webhook : Incluez tous les attributs obligatoires dans chaque charge utile. Ajoutez les attributs recommandés lorsqu’ils sont disponibles au moment de l’événement. Conservez la charge utile brute à des fins d’audit et de rejeu.
Sémantique des activités : Distinguez les affectations initiales du groupe et de l’agent des changements ultérieurs. Les changements ultérieurs produisent Incident Reassigned, tandis que la première attribution produit l’activité d’affectation initiale correspondante.
Gestion des statuts : Associez les valeurs de statut exactes configurées dans le compte Freshservice. Si le compte utilise des statuts personnalisés pour les incidents en attente ou ouverts, configurez des associations explicites pour ces valeurs.
Première réponse : Définissez si une réponse publique, une note publique ou un autre type de communication est admissible. Appliquez cette définition de manière uniforme et émettez l’événement uniquement pour la première communication admissible par incident.
Détection des solutions de contournement : Configurez un champ dédié, une case à cocher, un type de note ou une règle de mots-clés approuvée. Sans cette configuration, Workaround Provided ne peut pas être identifié de manière fiable.
Dépassement du SLA : Configurez un déclencheur explicite de dépassement du SLA ou un processus planifié distinct qui compare l’heure actuelle à ResolutionSlaTargetTime. Un instantané final de l’incident ne suffit pas à reconstituer l’horodatage du dépassement.
Période : Pour la validation initiale, utilisez environ 3 à 6 mois d’incidents. En fonctionnement temps réel, commencez l’ingestion avant la période d’analyse cible et conservez l’historique des webhooks pour permettre un rejeu.
Filtres : Appliquez uniquement les filtres approuvés concernant l’entreprise, l’espace de travail, le service, la catégorie ou la période. Ne présumez pas des noms de champs Freshservice ni de la syntaxe des filtres qui ne sont pas exposés dans la configuration du compte.
Performances : Utilisez un traitement asynchrone des webhooks, placez les requêtes entrantes en file d’attente, regroupez les écritures en aval et indexez IncidentId et EventTimestamp. Évitez les appels d’enrichissement synchrones lors de la réception des webhooks.
Fiabilité : Configurez les nouvelles tentatives, la gestion des files d’attente de rejet, la supervision et la suppression des doublons. Enregistrez les livraisons échouées et rejouez-les après correction.
Prérequis : Accès administrateur, disponibilité du flux de travail Automator, autorisations de webhook, point de terminaison HTTPS, configuration de l’authentification, fonctionnalités suffisantes de l’offre Freshservice et processus de dépôt ou d’importation compatible avec ProcessMind.
Sécurité : Utilisez HTTPS, limitez si possible les accès entrants, renouvelez les identifiants, réduisez les champs sensibles au minimum et protégez les descriptions et notes des incidents lorsqu’elles sont incluses dans les charges utiles.

a Exemple de requête config

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

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

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

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

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

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

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

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

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

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

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

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

Prêt à commencer ?

Utilisez ce modèle pour configurer correctement vos données et obtenir des analyses utiles de vos flux de travail de gestion des incidents. Commencez dès aujourd’hui à réduire vos délais de résolution.

Retour au guide d’amélioration Télécharger le modèle

Mettez fin aux violations de SLA : optimisez la Gestion des incidents dès aujourd’hui

Rejoignez les entreprises qui réduisent leur MTTR de 35 % et évitent les violations de SLA coûteuses.

Démarrer l’essai gratuit

Essai gratuit de 14 jours, sans carte bancaire.

Votre modèle de données de gestion des incidents

Votre modèle de données de gestion des incidents

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Exportation des données du module Analytics de Freshservice au format CSV

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l’API REST Freshservice

Étapes

Configuration

a Exemple de requête python

Envoi de données en temps réel via les webhooks du flux de travail Automator

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Mettez fin aux violations de SLA : optimisez la Gestion des incidents dès aujourd’hui

Votre modèle de données de gestion des incidents

Votre modèle de données de gestion des incidents

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Exportation des données du module Analytics de Freshservice au format CSV

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l’API REST Freshservice

Étapes

Configuration

a Exemple de requête python

Envoi de données en temps réel via les webhooks du flux de travail Automator

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Mettez fin aux violations de SLA : optimisez la Gestion des incidents dès aujourd’hui

Nous attachons de l’importance à votre confidentialité