> Amélioration Continue des Processusus > Gestion des incidents > Freshservice > Template de données

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

Freshservice

Attributs de gestion des incidents (19) Activités de 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 pour une analyse efficace de la gestion des incidents. Il décrit les attributs essentiels à collecter, les activités critiques à suivre, et fournit des conseils pratiques sur l'extraction de ces informations de votre système source. Utilisez cette ressource pour optimiser votre processus de prélèvement.paration des données.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de gestion des incidents

Voici les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre processus de gestion des incidents.

5 Obligatoire 7 Recommandé 7 Facultatif

	Nom	Descriptionn
	ID d'incident IncidentId	L'identifiant unique de chaque enregistrement d'incident, servant de clé primaire pour le suivi de l'intégralité du cycle de vie de l'incident.
Descriptionn L'Incident ID (ID d'incident) est la base de l'analyse de la gestion des incidents. Il fonctionne comme le ID du cas (ID de cas), reliant toutes les activités, les horodatages et les changements d'attributs associés en un seul parcours cohérent. En Process Mining, chaque entrée de l'journal d'événements est associée à un Incident ID, permettant la reconstruction du flux de processus complet pour chaque incident. Ceci est indispensable pour calculer les temps de cycle, analyser les variantes de processus et identifier les points de blocage spécifiques à chaque cas individuel. Sans identifiant unique, il serait impossible de distinguer les différents incidents et d'analyser leurs chemins, du signalement à la résolution. Pourquoi est-ce important ? : Il identifie de manière unique chaque incident, permettant le suivi complet et l'analyse de son cycle de vie, de la création à la clôture. Source des données : Il s'agit de l'identifiant principal d'un ticket, disponible via l'API Tickets de Freshservice en tant que champ 'id' dans l'objet ticket. Exemples INC-10234INC-10235INC-10236
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation ou extraction des données de ce processus.
Descriptionn Cet attribut fournit un horodatage indiquant la dernière mise à jour de l'ensemble des données à partir du système source. Il s'agit d'un champ de métadonnées qui s'applique à l'ensemble des données plutôt qu'à des événements individuels, mais il est souvent inclus au niveau de l'événement pour des raisons de cohérence. En analyse, cette information permet de mieux comprendre la la réactualisation des données et la fenêtre temporelle couverte par les dashboards et les KPI. Elle donne aux utilisateurs confiance dans l'actualité des informations et aide à gérer les attentes quant à l'inclusion des tout derniers incidents dans l'analyse. Pourquoi est-ce important ? : Il informe les utilisateurs sur la la réactualisation des données, en s'assurant qu'ils comprennent la période couverte par l'analyse. Source des données : Il s'agit d'un horodatage de métadonnées généré pendant le processus d'extraction de données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Horodatage de l'événement EventTimestamp	La date et l'heure exactes auxquelles l'activité ou l'événement s'est produit.
Descriptionn L'Event Horodatage (Horodatage de l'événement), ou Heure de début (Heure de début), marque 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, a un horodatage associé. Cet attribut est indispensable pour toutes les analyses de Process Mining temporelles. Il est utilisé pour ordonner les événements chronologiquement, calculer la durée entre les activités, mesurer le temps de cycle total du cas et analyser les temps d'attente. C'est la base pour construire des dashboards qui suivent la performance des SLA, les délais de handoff et les temps de résolution globaux. Pourquoi est-ce important ? : Elle fournit l'ordre chronologique des événements, ce qui est indispensable pour calculer les durées, analyser les temps de cycle et comprendre la performance des processus. Source des données : Cela est dérivé de divers champs d'horodatage dans Freshservice, tels que 'created_at', 'updated_at', et les horodatages au sein du journal 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	Le nom de l'activité commerciale ou de l'événement spécifique qui s'est produit à un moment donné du cycle de vie de l'incident.
Descriptionn Le Activity Name (Nom de l'activité) décrit une étape ou un événement unique dans le processus de gestion des incidents, tel que 'Incident Assigned to Group' (Incident assigné à un groupe), 'Status Changed to Pending' (Statut changé à En attente) ou 'Incident Resolved' (Incident résolu). Ces activités sont dérivées des changements dans les données de l'incident au fil du temps. Cet attribut est indispensable pour le Process Mining, car il définit les nœuds dans 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, identifier les chemins courants, détecter les écarts par rapport à la procédure standard et repérer les boucles de retraitement (comme les réaffectations fréquentes). Pourquoi est-ce important ? : Il définit les étapes de la cartographie des processus, pour visualiser et l'analyse du flux de résolution des incidents, des points de blocage et des écarts. Source des données : Cet attribut n'est pas un champ direct dans Freshservice, mais est dérivé des changements dans les propriétés du ticket telles que le statut, la priorité, l'assignation à un agent ou à un groupe et l'ajout de notes. Exemples Incident signaléIncident attribué à un groupeNote de résolution ajoutéeIncident résolu
	Système source SourceSystem	Le système dont les données ont été extraites, généralement « Freshservice ».
Descriptionn Cet attribut identifie l'origine des données. Bien que dans ce contexte, il s'agisse systématiquement de « Freshservice », c'est un champ crucial dans les environnements où les données de plusieurs systèmes pourraient être combinées pour une vue d'ensemble complète du processus. Inclure l'attribut Système Source est une bonne pratique pour la gouvernance des données et la traçabilité. Cela clarifie la provenance des données, ce qui est important pour la validation, le débogage et l'expansion future du projet de Process Mining afin d'inclure d'autres systèmes de gestion des services ou opérationnels. Pourquoi est-ce important ? : Il assure la traçabilité et la gouvernance des données en identifiant clairement l'origine des données de gestion des incidents. Source des données : Il s'agit généralement d'une valeur statique ajoutée lors du processus de transformation des données (ETL) pour étiqueter l'ensemble de données. Exemples FreshserviceFreshservice-EUFreshservice-PROD
	Agent assigné AssignedAgent	Le nom ou l'ID de l'agent de support actuellement assigné pour résoudre l'incident.
Descriptionn L'Assigned Agent (Agent assigné) identifie l'employé individuel du Centre de services responsable de l'incident à un moment donné. Les changements apportés à cet attribut représentent un transfert de responsabilité entre les agents. Cet attribut est indispensable pour l'analyse des performances, permettant des dashboards qui suivent la charge de travail des agents, le temps de résolution moyen par agent et les taux de résolution au premier contact. Il est également utilisé pour analyser les passages de relais (handoffs) entre agents, qui peuvent être une source de retard et d'efficience. En suivant les assignations d'agents, les responsables peuvent identifier les besoins en formation et reconnaître les membres de l'équipe les plus performants. Pourquoi est-ce important ? : Il permet l'analyse de la performance des agents, la répartition de la charge de travail et l'impact des transferts entre agents sur les délais de résolution. Source des données : Disponible dans l'API Freshservice Tickets en tant que champ 'responder_id'. Cet ID peut être relié à l'API Agents pour obtenir le nom de l'agent. Exemples John DoeJane SmithSupportBot
	Catégorie d'incident IncidentCategory	La catégorie utilisée pour classer l'incident, comme Matériel, Logiciel ou Réseau.
Descriptionn La Catégorie d'incident permet de classer les incidents en fonction du type de problème signalé. Cette classification hiérarchique facilite l'acheminement de l'incident vers la bonne équipe et est indispensablele pour l'analyse des tendances. Cet attribut est utilisé dans le tableau de bord 'Incident Categorization Accuracy' pour analyser si une mauvaise catégorisation initiale entraîne des délais 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ù la majeure partie de l'effort de support est dépensée et adapter les initiatives d'amélioration. Pourquoi est-ce important ? : Il permet l'analyse des tendances d'incidents et aide à déterminer si une catégorisation incorrecte est à l'origine de retards de résolution. Source des données : Il s'agit d'un champ par défaut mais personnalisable dans Freshservice. Il est accessible via l'API Tickets sous le nom de 'category', avec les champs associés 'sub_category' et 'item_category'. Exemples HardwareLogicielProblème de réseauAccès au compte
	Date/heure cible du SLA de résolution ResolutionSlaTargetTime	L'horodatage de résolution cible de l'incident, conformément à sa politique de SLA.
Descriptionn Cet attribut stocke la date et l'heure spécifiques qui constitue le délai de résolution d'un incident. Cet objectif est déterminé par la politique de l'accord de niveau de service (SLA) appliquée au ticket, qui dépend généralement de facteurs tels que la priorité. Cet objectif de délai est indispensable pour calculer le KPI « Taux de résolutionpect des SLA » et alimenter le tableau de bord « Performance des SLA ». En comparant l'horodatage de résolution réel avec cette cible, nous pouvons déterminer si un incident a été résolu à temps ou n'a pas respecté son SLA. C'est indispensable pour mesurer la conformité des niveaux de service. Pourquoi est-ce important ? : Il fournit la date limite de résolution, ce qui est nécessaire pour calculer la conformité au SLA et identifier les incidents à risque. Source des données : Disponible dans l'API Freshservice Tickets en tant que 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	Le niveau de gravité de l'incident, indiquant son impact commercial.
Descriptionn La Gravité de l'incident mesure l'impact d'un incident sur l'activité, souvent catégorisée comme faible, moyenne, élevée ou critique. Bien que liée à la priorité, la gravité se concentre sur l'impact, tandis que la priorité se concentre sur l'urgence. La combinaison de la gravité et de l'impact détermine souvent la priorité finale. L'analyse par gravité aide à comprendre comment l'organisation gère les incidents ayant des conséquences commerciales significatives. Elle est utilisée dans les tableau de bords pour segmenter les temps de résolution et les performances SLA, garantissant que les problèmes les plus impactants reçoivent le niveau d'attention et de ressources approprié tout au long de leur cycle de vie. Pourquoi est-ce important ? : Il mesure l'impact commercial d'un incident, permettant une analyse axée sur l'atténuation des problèmes les plus préjudiciables. Source des données : Il s'agit d'un champ par défaut dans Freshservice, disponible via l'API Tickets en tant que 'impact'. Les valeurs sont numériques. Exemples FaibleMoyenÉlevé
	Groupe assigné AssignedGroup	Le groupe ou l'équipe de support actuellement en charge de l'incident.
Descriptionn L'Assigned Group (Groupe assigné) indique quelle équipe, telle que 'Level 1 Support' (Support niveau 1), 'Network Team' (Équipe réseau) ou 'Database Admins' (Administrateurs de bases de données), est responsable de l'incident. Les changements apportés à cet attribut signifient une escalade ou un transfert entre différentes équipes fonctionnelles. L'analyse de l'Assigned Group est indispensablele pour comprendre les délais de handoff (transfert) et de transfert. Le Process Mining peut visualiser le flux des incidents entre les groupes, mettant en évidence les chemins d'escalade courants et mesurant le temps passé à attendre que chaque groupe agisse. Cela aide à identifier les points de blocage organisationnels et les opportunités de rationaliser la collaboration inter-équipes. Pourquoi est-ce important ? : Il suit l'équipe responsable, ce qui est impératif pour l'analyse des transferts, des escalades et des retards inter-équipes. Source des données : Disponible dans l'API Freshservice Tickets en tant que champ 'group_id'. Cet ID peut être relié à l'API Groups pour obtenir le nom du groupe. Exemples Centre de servicesOpérations RéseauSupport Infrastructure
	Priorité de l'incident IncidentPriority	Le niveau de priorité de l'incident, qui détermine l'urgence de la réponse et de la résolution.
Descriptionn La Priorité d'incident est un champ clé qui dicte la rapidité et l'attention requises pour la gestion d'un incident. Elle est généralement définie sur une échelle telle que faible, moyenne, élevée et urgente, et influence souvent les objectifs SLA. Dans le Process Mining, la priorité est une dimension majeure pour le filtrage et l'analyse. Elle permet de comparer les processus de résolution pour les incidents de haute priorité par rapport à ceux de faible priorité, garantissant que les problèmes critiques sont traités efficacement. Les tableau de bords segmentent souvent les indicateurs comme le temps de cycle et le respect des SLA par priorité afin de fournir des pistes d'amélioration concrètes aux responsables du support. Pourquoi est-ce important ? : Il aide à prioriser l'analyse sur les incidents les plus critiques et est indispensable pour évaluer la performance du SLA et l'allocation des ressources. Source des données : Disponible dans l'API Freshservice Tickets en tant que champ 'priority'. Les valeurs sont numériques (par exemple, 1 pour Faible, 4 pour Urgent). Exemples FaibleMoyenÉlevéUrgent
	Statut d'incident IncidentStatus	Le statut actuel de l'incident dans son cycle de vie, tel que Ouvert, En attente, Résolu ou Fermé.
Descriptionn L'Incident Status (Statut de l'incident) 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, tels que le passage de 'In Progress' (En cours) à 'Pending' (En attente) ou de 'Resolved' (Résolu) à 'Closed' (Fermé). Cet attribut est indispensable pour comprendre le parcours de l'incident. L'analyse du temps passé dans chaque statut aide à identifier les points de blocage, tels que les incidents qui restent trop longtemps en état 'Pending' en attendant une réponse de l'utilisateur. Il est également essentiel pour définir les points de début et de fin pour les calculs de temps de cycle. Pourquoi est-ce 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. Source des données : Disponible dans l'API Freshservice Tickets en tant que champ 'status'. Les valeurs sont numériques. Exemples OuvertEn coursEn attenteRésoluClôturé
	Canal de signalement ReportingChannel	La méthode ou le canal par lequel l'incident a été signalé, tel que Courriel, Portail ou Téléphone.
Descriptionn Le canal de signalement, également appelé source, indique comment un incident a été enregistré dans le système de support. Les canaux courants incluent le courrier électronique, un portail en libre-service, les appels téléphoniques ou le chat. L'analyse de cet attribut permet d'évaluer l'efficacité des différents canaux de signalement. Le tableau de bord « Efficacité du Canal de Signalement » compare le volume d'incidents et le temps de résolution moyen par canal afin de déterminer les méthodes les plus efficaces et celles qui pourraient nécessiter des améliorations. Par exemple, les incidents signalés via le portail peuvent être résolus plus rapidement s'ils contiennent dès le départ des informations plus structurées. Pourquoi est-ce important ? : Il aide à identifier les canaux de signalement les plus efficaces et révèle des opportunités d'améliorer le processus de réception des incidents. Source des données : Disponible dans l'API Freshservice Tickets en tant que champ 'source'. Les valeurs sont numériques. Exemples E-mailPortailTéléphoneChat
	Cause principale RootCause	La raison sous-jacente ou la cause racine de l'incident, identifiée après enquête.
Descriptionn L'attribut « cause racine » identifie le problème clé qui a mené à l'incident. Cette information est généralement remplie par les agents de support pendant ou après la résolution, dans le cadre d'un processus d'analyse des causes profondes (RCA). Cet attribut est impératif pour le tableau de bord « Incidents récurrents et causes racines » et le KPI « Taux d'achèvement de l'analyse des causes profondes ». En analysant les causes racines courantes, les organisations peuvent passer d'une résolution réactive des incidents à une gestion proactive des problèmes, en mettant en œuvre des solutions permanentes qui préviennent les futurs incidents et réduisent les problèmes récurrents. Pourquoi est-ce important ? : Il permet une gestion proactive des problèmes en aidant à identifier et à éliminer les causes sous-jacentes des incidents récurrents. Source des données : Il s'agit souvent d'un champ personnalisé dans Freshservice, car la fonctionnalité par défaut peut être limitée. Vérifiez la configuration des 'Champs de ticket' pour un champ nommé 'Cause Première' ou similaire. Exemples Bogue logicielErreur de configuration du réseauProblème de Formation UtilisateurPanne Matérielle
	Incident rouvert IsReopened	Un indicateur calculé qui est vrai si un incident a été rouvert après avoir été résolu ou fermé.
Descriptionn Cet attribut booléen est un indicateur calculé qui identifie les incidents qui ont été rouverts. Il est défini sur vrai si un incident, après avoir atteint un état « Résolu » ou « Fermé », voit son statut revenir à un état ouvert ou « En cours ». Cet indicateur est indispensable pour calculer le KPI « Taux de réouverture d'incidents » et pour le tableau de bord « Incidents récurrents ». Un taux élevé d'incidents rouverts peut signaler des problèmes liés à la qualité de la résolution initiale, une analyse des causes profondes incomplète ou une clôture prématurée. L'analyse de ces cas aide à améliorer la qualité et la durabilité des corrections. Pourquoi est-ce important ? : Il identifie les défaillances dans le processus de résolution, mettant en évidence les incidents où la solution initiale était inefficace et a conduit à une reprise du travail. Source des données : Ce champ calculé est déterminé par la séquence d'activités dans le journal d'événements. Sa valeur est vraie si une activité telle que 'Incident Réouvert' se produit, ou si une activité en état ouvert succède à une activité en état fermé pour le même ID d'incident. Exemples truefaux
	Nombre de transferts HandoffCount	Le nombre de fois qu'un incident a été transféré entre différents agents ou groupes.
Descriptionn Le Nombre de Transferts est une métrique 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 » incrémente ce compteur. Un nombre élevé de transferts est souvent un indicateur d'inefficacité de processus, d'un routage initial incorrect ou d'un manque d'expertise de l'agent. Cette métrique contribue directement au le KPI « Nombre de Transferts d'Incidents » et le tableau de bord « Analyse des Délais de Transfert », aidant à identifier les incidents ou les chemins de processus avec des transferts excessifs qui entraînent des délais. Pourquoi est-ce important ? : Il quantifie la reprise du travail et les réassignations, aidant à identifier les inefficacités causées par un routage incorrect ou des lacunes de connaissances. Source des données : Cette métrique calculée est obtenue en comptant le nombre de valeurs distinctes ou de modifications dans les champs 'AssignedAgent' ou 'AssignedGroup' sur le cycle de vie d'un même incident. Exemples 0125
	Service du demandeur RequestersDepartment	Le service auquel appartient l'utilisateur qui a signalé l'incident.
Descriptionn Cet attribut identifie le département métier du demandeur, tel que « Ventes », « Finance » ou « IT ». Cette information est généralement extraite du profil de l'utilisateur dans Freshservice. L'analyse des incidents par département du demandeur peut révéler si certaines unités commerciales sont affectées de manière disproportionnée par des problèmes ou s'il existe des problèmes spécifiques à un département. Elle fournit un contexte précieux pour comprendre l'impact commercial des incidents et peut aider à prioriser les corrections qui affectent les départements critiques. Pourquoi est-ce important ? : Il fournit un contexte métier, permettant l'analyse des tendances d'incidents et de leurs impacts sur des départements spécifiques. Source des données : Ces informationsns sont liées au demandeur du ticket. Elles peuvent être récupérées à partir du point de terminaison API « Requesters » en utilisant le requester_id du ticket, puis en accédant au department_id et au nom. Exemples VentesMarketingFinanceRessources Humaines
	SLA dépassé IsSlaBreached	Un indicateur calculé qui est vrai si l'incident n'a pas été résolu dans le délai cible de son SLA.
Descriptionn Cet attribut booléen est une métrique calculée qui indique si le temps de résolution d'un incident a dépassé son objectif de SLA. Il est dérivé en comparant l'horodatage de résolution réel au ResolutionSlaTargetTime. Cet indicateur est une entrée directe pour le KPI « Taux de résolutionpect des SLA » et le tableau de bord « Performance des SLA ». Il simplifie l'analyse en fournissant un résultat clair et binaire pour la performance SLA de chaque incident, facilitant l'agrégation et l'analyse des tendances. Il aide à identifier rapidement le volume et le pourcentage d'incidents qui ne respectent pas les engagements de service. Pourquoi est-ce important ? : Il mesure directement la conformité au SLA pour chaque incident, facilitant le calcul des taux d'adhérence globaux et l'identification des zones problématiques. Source des données : Il s'agit d'un champ calculé, généré lors de la transformation des données en comparant l'horodatage de l'activité 'Incident Résolu' avec le champ ResolutionSlaTargetTime. Exemples truefaux
	Solution de contournement fournie WorkaroundProvided	Un indicateur signalant si une solution de contournement temporaire a été fournie à l'utilisateur avant la résolution finale.
Descriptionn Cet attribut booléen indique si une solution temporaire ou une solution de contournement a été mise en œuvre pour atténuer l'impact de l'incident pendant qu'une solution permanente était en cours de développement. Cela est souvent suivi via une case à cocher ou un statut spécifique. En Process Mining, cet attribut prend en charge le tableau de bord « Mesures d'efficacité des solutions de contournement ». Il permet de comparer les temps de résolution des incidents avec et sans solutions de contournement, aidant à déterminer si la fourniture de solutions temporaires réduit efficacement les perturbations commerciales et contribue à une résolution globale plus rapide du point de vue de l'utilisateur. Pourquoi est-ce important ? : Il aide à mesurer l'efficacité des solutions de contournement temporaires pour réduire l'impact des incidents et accélérer la perception de la résolution. Source des données : Il s'agit généralement d'un champ booléen (case à cocher) personnalisé. Son existence doit être vérifiée dans la configuration des 'Champs de ticket' de Freshservice. Exemples truefaux

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Ce sont les étapes clés du processus et les jalons à enregistrer dans votre journal d'événements pour une découverte précise des processus et l'identification des points de blocage.

7 Recommandé 7 Facultatif

	Activité	Descriptionn
	Incident attribué à un groupe	Représente l’attribution initiale d’un incident à un groupe de support. Elle peut être automatique via des règles de routage ou manuelle par un opérateur. Cette activité est identifiée en suivant la première saisie du champ 'Group' dans le journal d’audit de l’incident.
Pourquoi est-ce important ? : Le suivi des affectations est indispensable pour mesurer les délais de première réponse et identifier les points de blocage dans le processus de répartition. Il aide à analyser l'efficacité de l'acheminement des incidents vers la bonne équipe. Source des données : Déduit de la première entrée dans le journal d'activités de l'incident qui remplit ou modifie le champ 'Group'. Capture Identifier le premier horodatage où le champ « Group » est rempli pour un incident. Type d'événement inferred
	Incident fermé	Représente la clôture finale et formelle de l’incident. Cela intervient généralement automatiquement après une période définie au statut 'Resolved', ou peut être effectué manuellement par un agent. Cet événement marque la fin du cycle de vie de l’incident.
Pourquoi est-ce important ? : Cette activité est 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 toute période de confirmation par l'utilisateur. Source des données : Déduit du journal d'activités de l'incident en identifiant quand le champ 'Statut' est mis à jour à 'Fermé'. Capture Utilisez l'horodatage de l'entrée du journal d'activités pour le changement de statut à 'Fermé'. 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 de SLA pour la résolution. Cet événement est détecté en suivant les modifications du champ 'Priority' dans l’historique de l’incident.
Pourquoi est-ce important ? : Une priorisation incorrecte ou tardive peut entraîner des violations de SLA et une allocation inefficace des ressources. L'analyse de cette activité permet de garantir que les incidents critiques reçoivent une attention immédiate. Source des données : Déduit du journal d'activités de l'incident, qui suit toutes les mises à jour du champ 'Priorité'. Capture Utilisez les horodatages du journal d'audit où la valeur du champ 'Priorité' a été définie ou modifiée. Type d'événement inferred
	Incident résolu	Marque le moment où l'agent a implémenté une correction et considère l'incident résolu. Ceci est enregistré lorsque le statut de l'incident passe à 'Résolu'. Dans Freshservice, c'est une étape clé qui arrête le compteur SLA.
Pourquoi est-ce important ? : Ce jalon est indispensable pour mesurer le Délai de Résolution (TTR). La période entre les statuts 'Résolu' et 'Fermé' est indispensablele pour analyser les délais de confirmation utilisateur et les politiques de fermeture automatique. Source des données : Déduit du journal d'activités de l'incident en identifiant quand le champ 'Statut' est mis à jour à 'Résolu'. Capture Utilisez l'horodatage de l'entrée du journal d'activités pour le changement de statut à 'Résolu'. Type d'événement inferred
	Incident signalé	Marque la création d'un nouvel enregistrement d'incident dans Freshservice. C'est le point de départ du cycle de vie de l'incident, généralement déclenchée par un utilisateur final via un portail, un e-mail ou un agent du service d'assistance créant un ticket en son nom. Cet événement est explicitement enregistré avec un horodatage de création.
Pourquoi est-ce important ? : Cette activité est l'événement de début principal pour l'ensemble du processus. L'analyse du temps écoulé entre cet événement et la résolution est clée pour mesurer les temps de cycle globaux et le respect des SLA. Source des données : Capturé à partir de l'horodatage de création de la table d'incidents. Freshservice l'enregistre explicitement pour chaque nouveau ticket. Capture Utilisez l'horodatage 'Créé le' de l'enregistrement d'incident principal. Type d'événement explicit
	Note de résolution ajoutée	Se produit lorsqu’un agent consigne la solution de l’incident en ajoutant une note de résolution. Dans Freshservice, c’est une action distincte avant de passer le statut à 'Resolved'. Cette action et son contenu sont consignés explicitement.
Pourquoi est-ce important ? : Cela marque l'identification d'une solution. Le temps entre cette étape et le statut 'Incident Résolu' peut indiquer un examen interne ou une charge de documentation. Source des données : Capturé à partir de l'horodatage lorsqu'une note de résolution est ajoutée à l'incident, qui est enregistrée dans l'historique des conversations. Capture Identifier l'horodatage de l'entrée « Note de Résolution » dans le journal de conversation de l'incident. Type d'événement explicit
	Statut changé à En cours	Cette activité marque le début officiel de l'enquête active et du travail sur l'incident. Elle est enregistrée lorsqu'un agent change le statut de l'incident à « En cours ». Il s'agit d'un changement de statut standard enregistré dans l'historique d'activité du ticket.
Pourquoi est-ce important ? : Ce jalon permet de différencier le temps d'attente du temps de travail actif. Analyser la durée pendant laquelle un incident reste 'En Cours' est indispensable pour comprendre l'effort de résolution. Source des données : Déduit du journal d'activités de l'incident en identifiant quand le champ 'Statut' est mis à jour à 'En cours'. Capture Filtrez le journal d'activité pour un changement de statut à « En Cours » et utilisez son horodatage. Type d'événement inferred
	Agent assigné à l'incident	Cette activité marque le moment où un agent spécifique est assigné pour gérer l'incident. Elle signifie une prise en charge individuelle du ticket. L'assignation est enregistrée dans l'historique d'activité du ticket, indiquant quel agent a été assigné et à quel moment.
Pourquoi est-ce important ? : Cela permet d'analyser la charge de travail des agents, leur performance et le temps nécessaire pour qu'un incident soit pris en charge par un individu après l'assignation à un groupe. C'est impératif pour les dashboards de performance des agents. Source des données : Suivi via les modifications apportées au champ 'Agent' dans le journal d'activités de l'incident ou la piste d'audit. Capture Identifier les horodatages correspondant aux changements dans le 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 marque un transfert dans le processus de résolution. Cet événement est déduit en détectant les modifications ultérieures aux champs 'Agent' ou 'Group' après l'assignation initiale.
Pourquoi est-ce important ? : Des réaffectations fréquentes, ou « transferts », indiquent 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 délais. Source des données : Déduit du journal d'activités de l'incident en suivant toute modification aux champs 'Agent' ou 'Group' après la première assignation. Capture Détecter 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. Cela se déduit d’un changement d’état de 'Resolved' vers un état tel que 'Open' ou 'In Progress'.
Pourquoi est-ce important ? : Un taux de réouverture élevé signale des problèmes de qualité de résolution ou des correctifs incomplets. Il s'agit d'une métrique clé pour analyser les reprises et la performance des agents. Source des données : Déduit du journal d'activités de l'incident en détectant un changement de statut de 'Résolu' à un statut actif. Capture Filtrez le journal d'activité pour un changement de « Statut » de « Résolu » à « Ouvert » ou « En Cours ». Type d'événement inferred
	Objectif SLA non respecté	C'est un événement calculé qui se produit lorsque le temps écoulé sur un incident dépasse l'objectif de SLA fixé pour la réponse ou la résolution. Freshservice suit l'état du SLA en interne et cet événement peut être dérivé en comparant les horodatages aux politiques de SLA.
Pourquoi est-ce important ? : Mesure directement la conformité aux engagements de niveau de service. Identifier quand et pourquoi les violations se produisent est indispensable pour le Tableau de bord de Performance SLA et l'amélioration continue. Source des données : Calculé en comparant l'horodatage de la résolution ou de la réponse avec l'heure d'échéance cible du SLA. Freshservice signale souvent les tickets comme 'SLA Violated'. Capture Déterminé 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 avec 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 des horodatages.
Pourquoi est-ce important ? : Respecter le SLA de première réponse est un KPI essentiel pour la satisfaction client. Cette activité permet de mesurer et d’analyser la rapidité avec laquelle les agents prennent en charge les nouveaux incidents. Source des données : Identifié en trouvant l'horodatage de la première note publique ou réponse ajoutée par un agent dans le journal de conversation de l'incident. Capture Filtrez l'historique des conversations de l'incident pour la première entrée effectuée par un agent. Type d'événement explicit
	Solution de contournement fournie	Cette activité signifie qu'une solution temporaire ou une solution de contournement a été communiquée à l'utilisateur pour atténuer l'impact de l'incident. La saisie de cette information nécessite souvent une configuration du système spécifique, telle qu'une case à cocher dédiée, un type de note spécifique ou une analyse par mots-clés dans les notes de l'agent.
Pourquoi est-ce important ? : Cela aide à analyser l'efficacité des solutions de contournement pour réduire l'impact commercial et leur relation avec le temps de résolution final. Cela soutient le tableau de bord « Mesures d'efficacité des solutions de contournement ». Source des données : Il ne s'agit probablement pas d'un événement explicite. Cela peut être inféré en marquant des notes contenant des mots-clés comme 'solution de contournement', ou si un champ personnalisé de type case à cocher 'Solution de contournement fournie' est utilisé et que son changement est enregistré. Capture Déduit d'un changement de champ personnalisé ou d'une analyse des mots-clés des notes de l'agent. Type d'événement inferred
	Statut changé à En attente	Représente un moment où le processus de résolution est mis en pause, généralement en attente d’informations de l’utilisateur ou d’un tiers. Cela se déduit d’un changement d’état vers un statut 'Pending'. Le temps passé dans cet état est souvent exclu des calculs de SLA.
Pourquoi est-ce important ? : Identifier le temps passé dans les états en attente est impératif pour comprendre les dépendances externes et les délais. Cela aide à isoler le temps de travail de l'agent du temps d'attente. Source des données : Déduit du journal d'activités de l'incident lorsque le champ 'Statut' est mis à jour à une valeur telle que 'En attente' ou 'En attente de réponse utilisateur'. Capture Filtrez le journal d'activité pour les changements de statut vers tout état en attente et utilisez l'horodatage associé. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos `données` de `Freshservice`

Étapes

Accéder à Freshservice Analytics : Connectez-vous à votre instance Freshservice avec un compte disposant des permissions pour accéder et créer des rapports. Naviguez vers le module Analytics depuis le menu principal.
Créer un Nouveau Rapport : Cliquez sur le bouton Nouveau rapport. Donnez un nom descriptif, tel que « Journal d'événements de gestion des incidents ». Sélectionnez le module Incident Management lorsque vous êtes invité à choisir une source de données.
Sélectionner le Widget de Rapport : Dans l'éditeur de rapport, ajoutez un nouveau widget et sélectionnez le type Table. Cela constituera la base de vos données de Journal d'événements.
Ajouter les colonnes de données principales : Depuis le panneau de source de données sur la droite, faites glisser et déposez les champs nécessaires dans la configuration des colonnes de la table. Commencez par Incident ID, Created at, Agent, Group, Priority, Severity, Status et Category.
Intégrer les données d'activité : Pour capturer les événements individuels, vous devez joindre ou inclure les données des activités de ticket. Ajoutez la source de données Activités (Activities) à votre widget. À partir de cette source, ajoutez Performed at (pour l'horodatage de l'événement) et Activity description ou des champs similaires qui décrivent le changement survenu.
Créer une colonne (ActivityName) calculée : C'est l'étape la plus critique. Créez une nouvelle colonne calculée ou un champ de formule. Utilisez des instructions IF imbriquées ou une fonction CASE pour traduire les données d'activité brutes en valeurs (ActivityName) requises. Consultez la section Requête pour la logique détaillée de chacune des 14 activités.
Configurer l' EventHorodatage : Créez une autre colonne calculée pour l' EventHorodatage. La logique de cette colonne doit sélectionner l'horodatage Created at pour l'activité 'Incident Reported' et l'horodatage Performed at de l'activité pour tous les autres événements.
Appliquer les filtres de rapport : Configurez les filtres de rapport pour affiner les données. Au minimum, définissez un filtre de plage de dates sur le champ 'Created at'. Une plage des 3 à 6 derniers mois est recommandée. Vous devez également ajouter un filtre pour inclure uniquement les tickets où le 'Type de Ticket' est 'Incident'.
Exécuter et affiner le rapport : Exécutez le rapport pour générer un aperçu des données. Vérifiez la sortie pour vous assurer que les colonnes (ActivityName) et EventHorodatage sont correctement renseignées. Ajustez les formules et les filtres si nécessaire.
Enregistrer et exporter le rapport : Une fois que vous êtes satisfait du résultat du rapport, enregistrez-le. Utilisez l'option Exporter et sélectionnez CSV comme format.
Planifier l'exportation (Facultatif) : Pour une analyse continue, vous pouvez planifier l'exécution et l'exportation automatiques du rapport. Configurez une planification (par exemple, quotidienne ou hebdomadaire) pour que le fichier CSV soit livré à votre e-mail ou à une autre destination.
Préparer les données pour le téléchargement : Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonne pour qu'ils correspondent au schéma requis pour ProcessMind : IncidentId, (ActivityName), EventHorodatage, 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 téléchargé.

Configuration

Module Analytics : Cette extraction nécessite l'accès au module Analytics de Freshservice, disponible dans les plans de niveau supérieur (ex. : Pro, Grande entreprise).
Permissions requises : Votre compte utilisateur doit avoir un rôle disposant des permissions pour créer, éditer et exécuter des rapports dans le module Analytics.
Plage de dates : Il est impératif de définir un filtre de plage de dates sur la date de création de l'incident pour gérer le volume de données. Une période glissante de 3 à 6 mois est recommandée pour un équilibre entre le contexte historique et la performance.
Filtres de rapport : Il est impératif de toujours filtrer par 'Type de Ticket' égal à 'Incident' pour exclure les demandes de service ou d'autres types de tickets de votre analyse de processus.
Champs calculés : La méthode repose fortement sur l'utilisation de champs calculés (formules) pour dériver les (ActivityName) et EventHorodatage pour chaque événement. Une familiarité avec l'éditeur de formules Freshservice est bénéfique.
Volume de données : Sachez que pour chaque incident, cette extraction génère plusieurs lignes (une pour chaque activité). Pour les grandes instances Freshservice, le fichier CSV résultant peut devenir très volumineux et peut impacter le temps de génération du rapport et la vitesse d'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 : Assurez-vous d'avoir installé Python 3.6+ ainsi que les bibliothèques requests et pandas. Vous pouvez les installer via pip : pip install requests pandas.
Générez votre clé API : Connectez-vous à votre instance Freshservice en tant qu'administrateur. Accédez à vos paramètres de profil en cliquant sur votre photo de profil dans le coin supérieur droit. Rendez-vous dans la section 'Clé API' et copiez votre clé API personnelle. Traitez cette clé comme un mot de passe.
Configurez le script : Enregistrez le code Python fourni dans un fichier nommé extract_freshservice_incidents.py sur votre machine locale.
Configurez les paramètres : Ouvrez le script dans un éditeur de texte. Mettez à jour les valeurs des espaces réservés pour FRESHSERVICE_DOMAIN (par exemple, 'votreentreprise.freshservice.com'), API_KEY (la clé que vous venez de copier) et START_DATE_STR (le début de votre période d'extraction souhaitée au format 'AAAA-MM-JJ').
Comprenez 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 spécifiée. Il parcourt chaque page de résultats renvoyés par l'API. Pour chaque ticket, il effectue un deuxième appel API pour récupérer son historique d'activités détaillé.
Génération du journal d'événements : Le script traite les données centrales du ticket et son journal d'activités pour identifier et créer des enregistrements pour chacune des 14 activités métiers 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érivé d'une entrée spécifique dans le journal d'activités.
Dérivez les événements complexes : Les événements tels que 'SLA Target Breached' sont dérivés. Le script vérifie si le SLA de résolution d'un ticket a été violé. Si tel est le cas, il crée un événement horodaté avec la date due_by, marquant le moment où la violation s'est produite.
Exécutez le script : Ouvrez un terminal ou une invite de commande, naviguez jusqu'au répertoire où vous avez enregistré le script, et exécutez-le à l'aide de la commande : python extract_freshservice_incidents.py.
Surveillez l'exécution : Le script affichera les mises à jour de progression dans la console, indiquant le nombre de tickets traités. Selon le nombre de tickets et les limites de débit de l'API, cela peut prendre un certain temps.
Examinez la sortie : Une fois le script terminé, il générera un fichier CSV nommé freshservice_incident_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements complet.
Préparez-vous au téléversement : Ouvrez le fichier CSV dans un tableur pour vous assurer que les colonnes (IncidentId, (ActivityName), EventHorodatage, etc.) sont remplies comme prévu. Le fichier est maintenant prêt à être téléversé dans ProcessMind ou un autre outil de Process Mining.

Configuration

FRESHSERVICE_DOMAIN : L'URL spécifique de votre entreprise pour Freshservice, par exemple, mycompany.freshservice.com. C'est un paramètre requis dans le script.
API_KEY : La clé API personnelle d'un utilisateur disposant des permissions suffisantes pour lire toutes les données d'incident. C'est un paramètre requis.
START_DATE_STR : La date de début de l'extraction des données au format 'YYYY-MM-DD'. Il est recommandé d'extraire une période initiale de 3 à 6 mois de données pour une analyse significative.
PAGE_SIZE : Définie à 100, le maximum autorisé par l'API Freshservice, pour minimiser le nombre d'appels API et améliorer les performances. Il n'est généralement pas recommandé de modifier cette valeur.
API Rate Limiting : Le script inclut un appel time.sleep(1) de base après le traitement de chaque ticket pour respecter les limites de débit de l'API Freshservice. Pour les déploiements à fort volume, cela peut nécessiter un ajustement pour éviter les erreurs.
Required Permissions : La clé API utilisée doit appartenir à un compte utilisateur (par exemple, un compte de service dédié) avec au moins les permissions du rôle 'Agent SD' pour garantir l'accès à tous les champs de ticket nécessaires et aux journaux d'activités danss différents groupes du service d'assistance.

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

Accéder à Freshservice Analytics : Connectez-vous à votre instance Freshservice avec un compte disposant des permissions pour accéder et créer des rapports. Naviguez vers le module Analytics depuis le menu principal.
Créer un Nouveau Rapport : Cliquez sur le bouton Nouveau rapport. Donnez un nom descriptif, tel que « Journal d'événements de gestion des incidents ». Sélectionnez le module Incident Management lorsque vous êtes invité à choisir une source de données.
Sélectionner le Widget de Rapport : Dans l'éditeur de rapport, ajoutez un nouveau widget et sélectionnez le type Table. Cela constituera la base de vos données de Journal d'événements.
Ajouter les colonnes de données principales : Depuis le panneau de source de données sur la droite, faites glisser et déposez les champs nécessaires dans la configuration des colonnes de la table. Commencez par Incident ID, Created at, Agent, Group, Priority, Severity, Status et Category.
Intégrer les données d'activité : Pour capturer les événements individuels, vous devez joindre ou inclure les données des activités de ticket. Ajoutez la source de données Activités (Activities) à votre widget. À partir de cette source, ajoutez Performed at (pour l'horodatage de l'événement) et Activity description ou des champs similaires qui décrivent le changement survenu.
Créer une colonne (ActivityName) calculée : C'est l'étape la plus critique. Créez une nouvelle colonne calculée ou un champ de formule. Utilisez des instructions IF imbriquées ou une fonction CASE pour traduire les données d'activité brutes en valeurs (ActivityName) requises. Consultez la section Requête pour la logique détaillée de chacune des 14 activités.
Configurer l' EventHorodatage : Créez une autre colonne calculée pour l' EventHorodatage. La logique de cette colonne doit sélectionner l'horodatage Created at pour l'activité 'Incident Reported' et l'horodatage Performed at de l'activité pour tous les autres événements.
Appliquer les filtres de rapport : Configurez les filtres de rapport pour affiner les données. Au minimum, définissez un filtre de plage de dates sur le champ 'Created at'. Une plage des 3 à 6 derniers mois est recommandée. Vous devez également ajouter un filtre pour inclure uniquement les tickets où le 'Type de Ticket' est 'Incident'.
Exécuter et affiner le rapport : Exécutez le rapport pour générer un aperçu des données. Vérifiez la sortie pour vous assurer que les colonnes (ActivityName) et EventHorodatage sont correctement renseignées. Ajustez les formules et les filtres si nécessaire.
Enregistrer et exporter le rapport : Une fois que vous êtes satisfait du résultat du rapport, enregistrez-le. Utilisez l'option Exporter et sélectionnez CSV comme format.
Planifier l'exportation (Facultatif) : Pour une analyse continue, vous pouvez planifier l'exécution et l'exportation automatiques du rapport. Configurez une planification (par exemple, quotidienne ou hebdomadaire) pour que le fichier CSV soit livré à votre e-mail ou à une autre destination.
Préparer les données pour le téléchargement : Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonne pour qu'ils correspondent au schéma requis pour ProcessMind : IncidentId, (ActivityName), EventHorodatage, 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 téléchargé.

Configuration

Module Analytics : Cette extraction nécessite l'accès au module Analytics de Freshservice, disponible dans les plans de niveau supérieur (ex. : Pro, Grande entreprise).
Permissions requises : Votre compte utilisateur doit avoir un rôle disposant des permissions pour créer, éditer et exécuter des rapports dans le module Analytics.
Plage de dates : Il est impératif de définir un filtre de plage de dates sur la date de création de l'incident pour gérer le volume de données. Une période glissante de 3 à 6 mois est recommandée pour un équilibre entre le contexte historique et la performance.
Filtres de rapport : Il est impératif de toujours filtrer par 'Type de Ticket' égal à 'Incident' pour exclure les demandes de service ou d'autres types de tickets de votre analyse de processus.
Champs calculés : La méthode repose fortement sur l'utilisation de champs calculés (formules) pour dériver les (ActivityName) et EventHorodatage pour chaque événement. Une familiarité avec l'éditeur de formules Freshservice est bénéfique.
Volume de données : Sachez que pour chaque incident, cette extraction génère plusieurs lignes (une pour chaque activité). Pour les grandes instances Freshservice, le fichier CSV résultant peut devenir très volumineux et peut impacter le temps de génération du rapport et la vitesse d'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'

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Freshservice Analytics Module Export de Données vers CSV

Étapes

Configuration

a Exemple de requête config

Extraction via script Python avec l’API REST de Freshservice

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Évitez les manquements aux 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 gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Freshservice Analytics Module Export de Données vers CSV

Étapes

Configuration

a Exemple de requête config

Extraction via script Python avec l’API REST de Freshservice

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Évitez les manquements aux SLA : Optimisez la gestion des incidents dès aujourd'hui