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

Votre modèle de données pour la gestion des demandes de service

Freshservice

Attributs de gestion des demandes de service (20) Activités de gestion des demandes de service (15) Guides d'extraction (3)

Votre modèle de données pour la gestion des demandes de service

Ce modèle fournit un guide complet pour la collecte des données nécessaires à l'analyse de votre processus de gestion des demandes de service. Il décrit les attributs essentiels, les activités clés à suivre et des conseils pratiques pour extraire ces informations de vos systèmes sources. Utilisez cette ressource pour construire un journal d'événements robuste pour une analyse approfondie des processus.

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

Nouveau dans 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 demandes de service

Ce sont 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 demandes de service.

5 Obligatoire 5 Recommandé 10 Facultatif

	Nom	Description
	Heure de l'événement EventTime	L'horodatage précis auquel l'activité s'est produite.
Description L'heure de l'événement capture la date et l'heure auxquelles une activité spécifique a été enregistrée pour une demande de service. Cet horodatage est fondamental pour séquencer correctement les événements et calculer les durées entre eux. Dans le Process Mining, cet attribut est utilisé pour ordonner les activités de chaque cas et constitue la base de toutes les analyses basées sur le temps. Il est utilisé pour calculer les temps de cycle, les temps d'attente entre les activités et le respect des accords de niveau de service (SLA). Des horodatages précis sont essentiels pour identifier les goulots d'étranglement et comprendre la performance des processus. Pourquoi c'est important Cet horodatage ordonne les événements chronologiquement et constitue la base de toute analyse de performance, y compris le temps de cycle et la détection des goulots d'étranglement. Où obtenir Cela correspond à l'horodatage de création d'une activité ou d'une entrée de journal d'audit dans Freshservice. Exemples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	ID de demande de service ServiceRequestId	L'identifiant unique pour chaque demande de service.
Description L'ID de demande de service est un numéro ou un code unique attribué à chaque nouvelle demande de service enregistrée dans Freshservice. Il sert de clé primaire pour suivre le cycle de vie complet de la demande, de sa création à sa clôture. En Process Mining, cet ID est fondamental car il agit comme l'ID de cas (`Case ID`). Tous les événements connexes, tels que les changements de statut, les attributions d'agents et les notes, sont liés entre eux à l'aide de cet identifiant. L'analyse du parcours de chaque ID de demande de service permet une visualisation complète de bout en bout du processus, l'identification des chemins courants et la détection des déviations ou des goulots d'étranglement affectant les cas individuels. Pourquoi c'est important C'est l'ID de cas (`Case ID`) essentiel qui connecte tous les événements liés, permettant de tracer le parcours de bout en bout d'une seule demande de service. Où obtenir Il s'agit d'un champ principal de l'objet ticket dans Freshservice. Il est visible dans l'interface utilisateur et disponible via l'API Freshservice. Exemples SR-12943SR-13501SR-14011
	Nom de l'activité ActivityName	Le nom de l'événement ou de la tâche qui s'est produit à un moment précis pour une demande de service.
Description Le nom de l'activité décrit une étape ou un événement spécifique au sein du cycle de vie de la demande de service. Ces activités sont extraites des journaux d'audit du système, des changements de statut ou des actions spécifiques effectuées par les utilisateurs, telles que 'Demande attribuée à l'agent', 'Note ajoutée' ou 'Demande de service résolue'. Cet attribut est crucial pour la construction de la cartographie des processus, qui représente visuellement le flux des demandes de service. En analysant la séquence et la fréquence des différentes activités, les organisations peuvent comprendre le processus réel, identifier les goulots d'étranglement entre les étapes, mesurer les durées d'activité et détecter les variantes de processus non conformes ou inefficaces. Pourquoi c'est important Cet attribut définit les étapes de la cartographie des processus, permettant la visualisation et l'analyse du workflow des demandes de service. Où obtenir Généré à partir des 'activités' ou 'audits' associés à un ticket dans Freshservice. Cela nécessite souvent une logique de transformation pour mapper les événements système à des noms d'activités compréhensibles pour le métier. Exemples Demande de service crééeDemande affectée à un agentDemande de service résolueDemande de service fermée
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant quand les données ont été rafraîchies pour la dernière fois depuis le système source.
Description Cet attribut enregistre la date et l'heure de la dernière extraction ou mise à jour du dataset depuis Freshservice. Il fournit un contexte sur la fraîcheur des données analysées. Pour toute analyse de processus, connaître la fraîcheur des données est essentiel. Cet horodatage aide les utilisateurs à comprendre s'ils consultent les informations les plus récentes, ce qui est crucial pour prendre des décisions opérationnelles opportunes et pour se fier aux informations dérivées de l'analyse. Pourquoi c'est important Informe les utilisateurs sur la récence des données, garantissant que les analyses et les décisions sont basées sur des informations à jour. Où obtenir Cette valeur est générée et estampillée sur le dataset pendant le processus d'extraction, de transformation et de chargement (ETL) des données. Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Système source SourceSystem	Identifie le `système` à partir duquel les `données` ont été extraites.
Description Cet attribut spécifie le système d'origine des données de processus, qui est dans ce cas Freshservice. Il est particulièrement utile dans les environnements où les données de plusieurs systèmes sont consolidées pour une vue holistique du processus. Bien qu'il puisse sembler redondant dans une analyse de système unique, c'est une bonne pratique d'inclure cet attribut pour l'évolutivité future et la gouvernance des données. Il assure la clarté sur la provenance des données et aide à gérer les pipelines d'intégration de données. Pourquoi c'est important Assure la provenance et la traçabilité des données, ce qui est crucial lors de la combinaison de données provenant de plusieurs systèmes ou à des fins de gouvernance des données. Où obtenir Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction et de transformation des données (ETL). Exemples FreshserviceFreshservice-API-v2
	Agent assigné AssignedAgent	Le nom de l'agent individuel actuellement assigné à la demande de service.
Description Cet attribut identifie l'agent de support spécifique responsable de la gestion de la demande de service à un moment donné. Les attributions d'agents peuvent changer tout au long du cycle de vie d'une demande. L'analyse de l'agent assigné est essentielle pour comprendre la performance des agents et la répartition de la charge de travail. Elle permet le calcul de KPI tels que le temps de résolution moyen par agent, le nombre de demandes actives et les taux de réaffectation. Cela aide à identifier les agents les plus performants, ceux qui pourraient avoir besoin de formation supplémentaire et les déséquilibres dans l'allocation de la charge de travail. Pourquoi c'est important Permet l'analyse de la charge de travail des agents, de leurs performances et de l'impact des réaffectations sur les temps de résolution. Où obtenir Disponible comme champ 'agent' ou 'répondant' sur l'objet ticket dans Freshservice. Exemples Alice JohnsonRobert SmithNon assigné
	Équipe assignée AssignedTeam	L'équipe ou le groupe de support assigné pour gérer la demande de service.
Description Cet attribut indique le groupe ou l'équipe fonctionnel, tel que 'Support IT Niveau 2' ou 'Approvisionnement Matériel', qui est responsable de la demande de service. Une demande peut être attribuée à une équipe avant d'être prise en charge par un agent individuel. L'analyse par équipe assignée aide à comprendre la performance de l'équipe, sa charge de travail et à identifier les goulots d'étranglement spécifiques à certains domaines fonctionnels. C'est crucial pour évaluer l'efficacité avec laquelle différentes équipes traitent les demandes et pour optimiser l'allocation des ressources au sein de l'organisation de support. Pourquoi c'est important Permet l'analyse des performances et de la charge de travail au niveau d'une équipe ou d'un groupe, ce qui est essentiel pour la gestion des ressources et l'identification des goulots d'étranglement fonctionnels. Où obtenir Disponible comme champ 'groupe' sur l'objet ticket dans Freshservice. Exemples Service DeskOpérations RéseauSupport Applicatif
	Priorité Priority	Le niveau de priorité de la demande de service, tel que Basse, Moyenne, Haute ou Urgente.
Description La priorité indique l'importance et l'urgence d'une demande de service, ce qui détermine souvent le temps de résolution cible et les ressources allouées. La priorité peut être définie automatiquement en fonction de règles ou manuellement par les agents. Dans le Process Mining, la Priorité est une dimension critique pour l'analyse. Elle est utilisée pour segmenter les demandes afin de comparer les flux de processus et les performances pour les éléments à haute priorité par rapport à ceux à faible priorité. Ceci est essentiel pour l'analyse de la conformité aux SLA et pour comprendre si la priorisation s'effectue efficacement et rapidement au stade du triage. Pourquoi c'est important Crucial pour l'analyse de la conformité aux SLA et pour comprendre si les demandes sont triées et traitées en fonction de leur impact commercial. Où obtenir Disponible comme champ 'priorité' sur l'objet ticket dans Freshservice. Exemples FaibleMoyenÉlevéUrgent
	Statut Status	Le statut actuel de la demande de service dans son cycle de vie.
Description Le champ Statut représente l'état de la demande de service à un moment donné, par exemple, 'Ouvert', 'En attente', 'Résolu' ou 'Fermé'. Les changements de statut sont souvent la source principale d'activités pour le Process Mining. L'analyse du statut fournit un contexte au flux de processus et aide à comprendre le temps que les demandes passent dans des états particuliers. Par exemple, une longue durée dans le statut 'En attente' pourrait indiquer un goulot d'étranglement en attente d'informations du demandeur ou d'une intervention d'un fournisseur externe. C'est un attribut clé pour définir les points de début et de fin des différentes étapes du processus. Pourquoi c'est important Fournit un contexte essentiel pour chaque événement et aide à mesurer le temps passé dans différents états, tels que 'Ouvert' ou 'En attente', afin d'identifier les retards. Où obtenir Disponible comme champ 'statut' sur l'objet ticket dans Freshservice. Exemples OuvertEn attenteRésoluClôturé
	Type de service ServiceType	Le type ou la catégorie spécifique du service demandé.
Description Le type de service classe la demande en fonction du type de service requis, tel que 'Demande de nouveau matériel', 'Accès logiciel' ou 'Réinitialisation de mot de passe'. Ceci est souvent lié à l'élément du catalogue de services sélectionné par l'utilisateur. Cet attribut permet la segmentation des demandes de service pour comparer les processus et les performances entre différents types de services. Il est essentiel pour calculer des KPI comme le 'Nombre moyen d'activités par type de service', ce qui aide à identifier quels services sont plus complexes ou fortement consommateurs de ressources. Cette analyse peut orienter les efforts de simplification et d'automatisation des processus pour des types de service spécifiques. Pourquoi c'est important Permet la comparaison des flux de processus et de la complexité entre différentes catégories de demandes, aidant à identifier les domaines de standardisation ou d'automatisation. Où obtenir Ceci correspond souvent à la 'catégorie', à l''élément' ou à un champ personnalisé sur l'objet ticket dans Freshservice, selon la configuration. Exemples Intégration de nouveaux employésDemande de licence logicielleAccès VPN
	Canal Channel	La méthode ou le canal par lequel la demande de service a été soumise.
Description Le canal indique comment la demande de service a été créée, par exemple, via le portail self-service, e-mail, appel téléphonique ou chat. Cette information aide à comprendre les préférences des utilisateurs et l'efficacité des canaux. L'analyse du processus par canal peut révéler des informations importantes. Par exemple, les demandes soumises via le portail peuvent être plus complètes et résolues plus rapidement que celles soumises par e-mail, qui pourraient nécessiter plus de communications. Cette analyse peut orienter les efforts visant à promouvoir des canaux plus efficaces. Pourquoi c'est important Aide à analyser si le canal de soumission a un impact sur l'efficacité du processus, le temps de résolution ou la quantité de retravail requise. Où obtenir Disponible comme champ 'source' sur l'objet ticket dans Freshservice. Exemples E-mailPortailTéléphoneChat
	Date d'échéance du `SLA` SlaDueDate	L'horodatage auquel la demande de service devrait être résolue selon son SLA.
Description Cet attribut spécifie la date limite de résolution de la demande de service telle que définie par la politique SLA applicable. Il s'agit d'un horodatage calculé basé sur l'heure de création de la demande, sa priorité et les heures ouvrables définies dans le SLA. Il s'agit d'un point de données critique pour la surveillance des performances en temps réel et pour l'analyse post-mortem de la conformité aux SLA. En comparant le temps de résolution réel avec la `SlaDueDate`, une détermination de 'Respecté' ou 'Violé' peut être faite. C'est la base pour le calcul du KPI de Taux de Conformité SLA. Pourquoi c'est important C'est la date limite cible de résolution, constituant la base de calcul pour savoir si une demande de service a respecté ou violé son SLA. Où obtenir Il s'agit d'un champ calculé au sein de Freshservice, visible sur le ticket sous le nom 'À rendre avant'. Il est disponible via l'API. Exemples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	Demandeur Requestor	L'utilisateur qui a soumis la demande de service.
Description Cet attribut identifie l'individu, généralement un employé, qui a initié la demande de service. Il fournit un contexte sur qui utilise le centre de services et quels sont leurs besoins. Bien que n'étant pas toujours une dimension principale pour l'analyse des flux de processus, l'analyse par demandeur ou leur département associé peut révéler des schémas. Par exemple, cela pourrait montrer qu'un département spécifique soumet fréquemment des demandes incomplètes, indiquant un besoin de formation ciblée. C'est également essentiel pour toute analyse axée sur l'expérience client. Pourquoi c'est important Fournit un contexte sur l'utilisateur à l'origine de la demande, permettant l'analyse des modèles de demande par individu, département ou emplacement. Où obtenir Disponible comme champ 'demandeur' sur l'objet ticket dans Freshservice. Exemples John DoeJane SmithCompte de service
	Département du demandeur RequestorDepartment	Le département auquel appartient le demandeur.
Description Cet attribut spécifie le département organisationnel de l'utilisateur qui a soumis la demande de service, comme 'Ventes', 'Finance' ou 'Ressources Humaines'. Cette information est généralement tirée du profil de l'utilisateur dans le système. L'analyse des performances du processus par département est une exigence courante. Elle peut mettre en évidence si certains départements connaissent des temps de résolution plus longs ou ont des besoins de processus uniques. Cette information peut éclairer l'allocation des ressources, les initiatives de formation ou la création d'offres de services spécifiques à un département. Pourquoi c'est important Permet la segmentation du processus par unité commerciale, aidant à identifier les problèmes spécifiques aux départements ou les variations de performance. Où obtenir Cette information est liée via le profil du demandeur. Elle peut se trouver dans un champ 'département' par défaut ou un champ utilisateur personnalisé dans Freshservice. Exemples FinanceMarketingTechnologies de l'Information
	Est un retravail IsRework	Un indicateur booléen signalant si la demande a impliqué des activités de retravail.
Description Cet indicateur calculé est défini sur vrai si une demande de service subit certaines activités indicatives de retravail. Les exemples incluent la réouverture après résolution ('Demande de service rouverte'), des réaffectations multiples ou des demandes d'informations répétées de la part de l'utilisateur ('Informations demandées au demandeur'). Cet attribut simplifie l'analyse des inefficacités de processus. Il permet un filtrage facile pour isoler les cas de retravail et comparer leurs cartographies de processus et leurs temps de cycle aux cas 'propres'. Cela soutient directement le dashboard 'Analyse du retravail des demandes de service' et aide à quantifier l'impact des transferts inefficaces ou des informations initiales incomplètes. Pourquoi c'est important Offre un moyen simple d'identifier et d'analyser les cas impliquant des boucles inefficaces ou des étapes répétées, aidant à quantifier le coût de la non-qualité. Où obtenir Calculé pendant la transformation des données en appliquant une logique métier à la séquence d'activités pour chaque 'ServiceRequestId'. Exemples truefaux
	Heure de fin EndTime	L'horodatage précis auquel l'activité a été achevée.
Description L'heure de fin (`End Time`) représente l'horodatage d'achèvement d'une activité. Pour de nombreux événements dans Freshservice, l'heure de début et l'heure de fin sont identiques, en faisant des événements ponctuels. Cependant, pour les activités basées sur le statut, l'heure de fin serait l'horodatage du prochain changement de statut. Cet attribut est essentiel pour calculer la durée des activités et les temps d'attente entre elles. En soustrayant l'heure de début (`StartTime`) de l'heure de fin (`EndTime`), le temps de traitement d'une tâche spécifique peut être déterminé. C'est crucial pour identifier les activités les plus chronophages et les principaux candidats à l'optimisation. Pourquoi c'est important Permet le calcul des durées d'activité, ce qui est fondamental pour identifier les goulots d'étranglement et mesurer les temps de traitement pour chaque étape. Où obtenir Ce n'est pas un champ direct dans les logs Freshservice. Il doit être dérivé en prenant l'horodatage de l'événement suivant dans la séquence pour une demande de service donnée. Exemples 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Nom de la politique SLA SlaPolicyName	Le nom de la politique d'accord de niveau de service (SLA) appliquée à la demande.
Description Cet attribut identifie la politique SLA spécifique qui régit les délais de réponse et de résolution cibles pour la demande de service. Les politiques sont généralement basées sur des facteurs comme la priorité, le type de service ou le groupe de demandeurs. Savoir quelle politique SLA est appliquée est essentiel pour le dashboard d'analyse de conformité et de violation des SLA. Cela permet une mesure précise de la performance par rapport aux objectifs définis et aide à analyser quelles politiques sont le plus fréquemment violées. Cela peut conduire à des révisions de la performance du processus ou de la faisabilité des objectifs SLA eux-mêmes. Pourquoi c'est important Identifie les objectifs de service spécifiques par rapport auxquels la demande est mesurée, ce qui est essentiel pour un rapport précis sur la conformité aux SLA. Où obtenir Cette information fait partie des données SLA associées à un ticket. Elle pourrait nécessiter d'interroger des endpoints d'API ou des champs spécifiques liés aux SLA. Exemples Incidents haute priorité - 4hDemandes standard - 3 joursSupport VIP - 1h
	Nombre de Réaffectations ReassignmentCount	Le nombre total de fois qu'une demande de service a été réaffectée à un agent ou une équipe différente.
Description Cet attribut calculé compte les occurrences de 'Demande réaffectée' ou d'activités similaires pour chaque demande de service. Un nombre élevé de réaffectations pointe souvent vers des problèmes de triage initial, un routage basé sur les compétences incorrect ou des déséquilibres de la charge de travail. Cet attribut soutient directement le dashboard 'Performance des agents et répartition de la charge de travail' et le KPI 'Nb moyen de réaffectations d'agents/demande'. L'analyse de cette métrique aide les organisations à identifier les faiblesses des processus qui entraînent le passage des tickets d'un agent à l'autre, ce qui augmente le temps de résolution et frustre à la fois les agents et les demandeurs. Pourquoi c'est important Mesure l'inefficacité du routage et les frictions du processus. Un nombre élevé indique des problèmes avec le triage initial ou la charge de travail des agents, entraînant des retards. Où obtenir Ceci est calculé en comptant les activités spécifiques de changement d'attribution pour chaque 'ServiceRequestId' pendant la transformation des données. Exemples 013
	SLA est enfreint IsSlaBreached	Un indicateur booléen signalant si la demande de service a dépassé son objectif de SLA de résolution.
Description Cet attribut calculé est un simple indicateur vrai ou faux qui indique si la demande de service a été clôturée après sa date d'échéance SLA. Il est dérivé en comparant l'horodatage de 'Demande de service fermée' ou 'Demande de service résolue' avec la 'SlaDueDate'. Cet attribut simplifie l'analyse et la visualisation pour le dashboard de conformité aux SLA. Il permet un filtrage et une agrégation faciles pour calculer le KPI du taux de conformité SLA global. La segmentation par cet indicateur aide à isoler et à analyser rapidement les caractéristiques de processus des demandes non conformes par rapport à celles qui ont été résolues à temps. Pourquoi c'est important Simplifie l'analyse de la conformité aux SLA en fournissant un indicateur clair pour filtrer et agréger les demandes qui n'ont pas atteint leurs objectifs. Où obtenir Il s'agit d'un champ calculé, dérivé lors de la transformation des données en comparant l'horodatage de résolution finale au champ 'SlaDueDate'. Exemples truefaux
	Temps de traitement ProcessingTime	Le temps passé à travailler activement sur une activité.
Description Le temps de traitement est une métrique calculée qui représente la durée d'une activité unique. Il est obtenu en soustrayant l'heure de début (`StartTime`) de l'activité de son heure de fin (`EndTime`). Cette métrique est fondamentale pour l'analyse des goulots d'étranglement. En agrégeant les temps de traitement pour chaque type d'activité, une image claire émerge des étapes où le plus de temps est consacré dans le processus. Cela permet aux analystes de concentrer les efforts d'amélioration sur les étapes les plus chronophages, telles que 'Examen interne effectué' ou 'Fournisseur externe engagé'. Pourquoi c'est important Quantifie la durée des étapes individuelles du processus, mettant directement en évidence les activités les plus chronophages et les goulots d'étranglement. Où obtenir Calculé lors de la préparation des données en soustrayant le 'EventTime' (Heure de début) d'un événement de la 'EndTime' (l'horodatage de l'événement suivant). Exemples 360086400300

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Ce sont les étapes et jalons clés du processus à capturer dans votre journal d'événements pour une découverte et une analyse précises de vos workflows de demandes de service.

6 Recommandé 9 Facultatif

	Activité	Description
	Demande affectée à un agent	Marque le moment où une demande de service est affectée à un agent spécifique pour traitement. Il s'agit d'une étape clé, déduite en suivant les modifications apportées au champ 'Agent assigné' ou 'Propriétaire' du ticket.
Pourquoi c'est important Cette activité est cruciale pour l'analyse de la charge de travail des agents et l'identification des goulots d'étranglement dans le processus d'affectation. Le temps entre la création et l'affectation est un indicateur clé de performance. Où obtenir Déduit du journal d'activités du ticket ou de la piste d'audit des champs en surveillant les modifications du champ 'Agent' ou 'Assigné'. Capture Capture l'horodatage lorsque le champ 'Agent assigné' est rempli ou que sa valeur change. Type d'événement inferred
	Demande de service créée	Cette activité marque le début du cycle de vie de la demande de service lorsqu'une nouvelle demande est formellement enregistrée dans Freshservice. Cet événement est capturé explicitement lorsqu'un nouvel enregistrement de ticket est généré, que ce soit via le catalogue de services, l'e-mail ou un autre canal, créant un ID de demande de service unique.
Pourquoi c'est important Il s'agit de l'événement de départ principal du processus. L'analyse du temps écoulé entre cette activité et les autres est fondamentale pour mesurer les temps de cycle globaux et identifier les retards de traitement initiaux. Où obtenir Cet événement est enregistré explicitement dans Freshservice. Il peut être trouvé dans le journal d'activités ou la piste d'audit du ticket, correspondant généralement à l'horodatage de création du ticket. Capture Utilisez l'horodatage de création du ticket à partir des données des tickets Freshservice. Type d'événement explicit
	Demande de service fermée	C'est l'activité finale, signifiant la fin du cycle de vie de la demande de service. Elle se produit généralement automatiquement après une période de temps définie dans l'état 'Résolu' sans être rouverte.
Pourquoi c'est important Cet événement marque la fin définitive de l'instance de processus. Le temps entre 'Résolu' et 'Fermé' représente la fenêtre de confirmation pour le demandeur. Où obtenir Déduit de l'historique des changements de statut du ticket. Il correspond à l'horodatage lorsque le statut passe à 'Clôturé'. Capture Capture l'horodatage lorsque le statut du ticket passe à 'Clôturé'. Type d'événement inferred
	Demande de service résolue	Ce jalon critique marque le moment où l'agent a fourni une solution et considère le travail achevé. Cela est déduit du changement de statut du ticket à 'Résolu'.
Pourquoi c'est important Cette activité marque la fin de la phase de travail active. La durée jusqu'à ce point est une mesure clé de l'efficacité de l'agent et du processus, et elle constitue la base des calculs de SLA. Où obtenir Déduit de l'historique des changements de statut du ticket. Cela correspond à l'horodatage lorsque le statut a été défini pour la première fois sur 'Résolu'. Capture Capture l'horodatage lorsque le statut du ticket passe pour la première fois à 'Résolu'. Type d'événement inferred
	Fournisseur externe engagé	Cette activité marque le moment où un ticket est transféré à un fournisseur externe ou à un tiers pour résolution. Elle est déduite d'un changement de statut vers un état spécifique comme 'En attente fournisseur' ou 'En attente tiers'.
Pourquoi c'est important L'engagement des fournisseurs peut introduire des retards significatifs. Le suivi de cette activité est essentiel pour mesurer la performance des fournisseurs et son impact sur le temps de cycle global des demandes de service. Où obtenir Déduit de l'historique des changements de statut du ticket. Recherchez un statut spécifiquement configuré pour suivre la dépendance vis-à-vis des fournisseurs externes. Capture Détecter quand le champ de statut du ticket change pour une valeur indiquant une attente d'un tiers. Type d'événement inferred
	Objectif SLA non respecté	Un événement calculé qui se produit lorsque le temps de résolution d'une demande de service dépasse son objectif d'accord de niveau de service (SLA) défini. Ce n'est pas un événement système direct mais est dérivé en comparant le temps de résolution à la date d'échéance du SLA.
Pourquoi c'est important Ceci mesure directement la performance du service par rapport aux engagements et constitue un KPI clé pour la direction. Cela aide à identifier quels types de demandes ou priorités sont les plus à risque d'échouer. Où obtenir Calculé en comparant l'horodatage 'Résolu' avec l'horodatage 'SLA dû le'. Si le temps de résolution est postérieur, cet événement est déclenché. Capture Comparez l'horodatage de résolution à l'horodatage d'échéance du SLA. Si resolved_at > sla_due_by, créez cet événement. Type d'événement calculated
	Demande de service rouverte	Se produit lorsqu'un demandeur indique qu'un problème persiste après qu'il ait été marqué comme 'Résolu', ce qui fait que le ticket retourne à un état ouvert. Ceci est déduit d'un changement de statut de 'Résolu' à 'Ouvert' ou 'En cours'.
Pourquoi c'est important Les demandes rouvertes sont un indicateur fort de faibles taux de résolution au premier contact et d'insatisfaction client. Le suivi de cette boucle de retravail est essentiel pour améliorer la qualité des solutions. Où obtenir Déduit de l'historique des changements de statut du ticket dans le journal d'activités. Il s'agit d'une transition de statut directe de 'Résolu' à 'Ouvert'. Capture Détecter un changement de statut d'un état résolu à un état ouvert. Type d'événement inferred
	Demande priorisée	Cette activité se produit lorsqu'un niveau de priorité, tel que Basse, Moyenne ou Haute, est assigné à la demande de service. Elle est déduite en détectant un changement dans le champ 'Priorité' au sein de l'historique du ticket.
Pourquoi c'est important La priorisation est essentielle pour l'allocation des ressources et pour garantir que les objectifs de SLA sont atteints. L'analyse de cette activité aide à vérifier que les demandes sont évaluées correctement et en temps voulu. Où obtenir Déduit de l'historique des modifications de champ du ticket dans Freshservice. Recherchez les mises à jour du champ 'Priorité' et capturez l'horodatage du changement. Capture Détecter un changement dans le champ 'Priorité' de null ou de sa valeur précédente et enregistrer l'horodatage. Type d'événement inferred
	Demande réassignée	Cette activité saisit tout changement dans l'agent ou le groupe assigné après l'attribution initiale. Elle est déduite en détectant les mises à jour ultérieures des champs 'Agent assigné' ou 'Groupe assigné'.
Pourquoi c'est important Les réaffectations fréquentes indiquent des problèmes potentiels avec le triage initial, l'adéquation des compétences des agents ou l'équilibrage de la charge de travail. Cette activité est vitale pour l'indicateur clé de performance (KPI) du nombre de réaffectations d'agents et l'analyse du retravail. Où obtenir Déduit de l'historique des modifications de champ du ticket. Cet événement est enregistré chaque fois que le champ 'Agent assigné' ou 'Groupe assigné' est mis à jour après que sa valeur initiale a été définie. Capture Détecter toute modification du champ 'Agent assigné' ou 'Groupe assigné' après la première affectation. Type d'événement inferred
	Demande triée	Représente l'évaluation initiale et la catégorisation d'une nouvelle demande de service. Cette activité est généralement déduite de la première fois qu'une priorité est définie ou que la demande est assignée à un groupe, indiquant qu'elle a été examinée et qu'elle entre dans la file d'attente.
Pourquoi c'est important Le suivi du triage aide à mesurer l'efficacité de l'équipe de première intervention. Des retards à ce stade peuvent impacter significativement les temps de résolution globaux et la conformité aux SLA. Où obtenir Déduit du journal d'activités. Il peut être identifié par l'horodatage du premier événement 'Priorité définie' ou 'Groupe assigné' qui se produit après la création. Capture Identifier l'horodatage le plus ancien d'une modification du champ de priorité ou d'une modification du champ de groupe d'affectation. Type d'événement inferred
	Information demandée au demandeur	Représente le moment où l'agent assigné demande plus d'informations au demandeur et met en pause l'avancement. Ceci est déduit d'un changement de statut du ticket vers un état 'En attente' ou 'En attente du client'.
Pourquoi c'est important Cette activité met en évidence une source courante de retard et de retravail. L'analyse de sa fréquence aide à identifier les opportunités d'améliorer les modèles de demande et la collecte initiale des données. Où obtenir Déduit de l'historique des changements de statut du ticket. Recherchez un changement vers un statut comme 'En attente de réponse client' ou 'En attente d'informations'. Capture Détecter quand le champ de statut du ticket change pour une valeur indiquant une attente d'une saisie utilisateur. Type d'événement inferred
	Information fournie par le demandeur	Se produit lorsque le demandeur répond avec les informations nécessaires, permettant à l'agent de reprendre le travail. Ceci est généralement déduit lorsque le statut du ticket passe automatiquement d'un état 'En attente' à 'Ouvert'.
Pourquoi c'est important Cette activité boucle les demandes d'information. La durée entre la demande et la fourniture d'informations est un temps d'attente critique à analyser et à optimiser. Où obtenir Déduit d'un changement de statut d'un état 'En attente' vers un état 'Ouvert' ou 'En cours', souvent déclenché par une réponse du demandeur. Capture Détecter quand le statut du ticket passe d'un état en attente à un état ouvert. Type d'événement inferred
	Note ajoutée	Représente toute note publique ou privée ajoutée à la demande de service par un agent ou le demandeur. Il s'agit d'un événement explicite capturé dans la conversation ou le journal d'activités du ticket.
Pourquoi c'est important L'analyse de la fréquence et du calendrier des notes peut révéler les modèles de communication, l'efficacité de la collaboration et les points de confusion dans le processus. Où obtenir Explicitement enregistré dans l'historique des conversations du ticket dans Freshservice. Chaque note a un horodatage et un auteur. Capture Extrayez chaque entrée de l'historique des conversations ou des commentaires du ticket. Type d'événement explicit
	Résolution confirmée par le demandeur	Cette activité représente une confirmation explicite du demandeur que la solution fournie est satisfaisante. Cela peut être déduit d'une réponse positive à une enquête ou d'un commentaire spécifique avant la clôture du ticket.
Pourquoi c'est important La confirmation fournit un feedback direct sur la qualité de la résolution. Un faible taux de confirmation peut indiquer que les solutions ne répondent pas entièrement aux besoins des utilisateurs, même si elles ne sont pas rouvertes. Où obtenir Ceci est difficile à capturer directement et peut nécessiter une configuration personnalisée. Cela pourrait être déduit d'une réponse à une enquête de satisfaction client liée au ticket, ou de l'application d'un tag spécifique. Capture Nécessite l'analyse de données connexes comme les enquêtes de satisfaction ou les tags appliqués après résolution. Type d'événement inferred
	Révision interne effectuée	Indique qu'une solution proposée ou l'exécution d'une demande nécessite un examen ou une approbation interne avant de procéder. Ceci est déduit d'un changement de statut vers un état tel que 'En attente d'approbation' ou 'Examen interne'.
Pourquoi c'est important Les révisions internes peuvent être une source de goulots d'étranglement, en particulier pour les demandes de service complexes ou à fort impact. Mesurer cette durée aide à rationaliser les flux de travail d'approbation. Où obtenir Déduit de l'historique des changements de statut du ticket. Cela nécessite l'utilisation d'un statut spécifique comme 'En attente d'approbation interne' dans le flux de travail. Capture Détecter quand le champ de statut du ticket change pour une valeur indiquant un examen ou une approbation interne. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

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

Étapes

Vérification des prérequis : Assurez-vous de disposer d'un rôle d'utilisateur Freshservice avec les autorisations d'accès et de création de rapports dans le module Analytics. Cela nécessite généralement un plan Pro ou Enterprise.
Configurer les automatisations (si nécessaire) : Pour une capture d'événements précise, vérifiez ou créez deux automatisations spécifiques dans Freshservice sous Admin -> Workflow Automator. Premièrement, une automatisation qui ajoute une note privée ou une balise spécifique (par exemple, 'SLA_Breached') à un ticket lorsque son délai de résolution SLA expire. Deuxièmement, une automatisation qui ajoute une balise spécifique (par exemple, 'Resolution_Confirmed') lorsqu'une enquête de satisfaction client positive est reçue pour un ticket.
Créer le rapport 'Événements de création' : Accédez à l'onglet Analytics dans Freshservice. Créez un nouveau rapport et sélectionnez le module 'Tickets' comme source de données. Ce rapport capturera le premier événement pour chaque demande de service.
Configurer les widgets du rapport 'Événements de création' : Ajoutez un widget 'Tableau de données'. Configurez les colonnes (métriques) pour inclure : ID du ticket, Créé le, Assigné à, Groupe, Priorité, Statut et Catégorie. Appliquez un filtre pour la plage de dates de création souhaitée, par exemple, les 6 derniers mois.
Exporter les données 'Événements de création' : Exécutez le rapport et exportez le widget de tableau de données vers un fichier CSV. Nommez-le 'creation_events.csv'.
Créer le rapport 'Événements de mise à jour' : Créez un deuxième rapport, cette fois en sélectionnant le module 'Activités des tickets' comme source de données. Ce rapport capture toutes les modifications et notes ultérieures pour chaque demande de service.
Configurer les widgets du rapport 'Événements de mise à jour' : Ajoutez un widget 'Tableau de données'. Configurez les colonnes pour inclure : ID du ticket, Date d'activité, Effectué par, Type d'activité, et sous 'Changements', incluez Champ, Ancienne valeur et Nouvelle valeur. Vous devriez également ajouter des attributs de niveau ticket comme Groupe, Assigné à, Priorité, Statut et Catégorie pour fournir un contexte à chaque événement.
Filtrer le rapport 'Événements de mise à jour' : Appliquez un filtre pour la 'Date d'activité' afin qu'elle corresponde à la même plage de dates utilisée dans le rapport de création. Filtrez davantage le 'Type d'activité' pour inclure uniquement les événements pertinents tels que 'Statut changé', 'Priorité changée', 'Groupe changé', 'Agent changé', 'Note privée ajoutée' et 'Note publique ajoutée'.
Exporter les données 'Événements de mise à jour' : Exécutez le rapport et exportez le widget de tableau de données vers un fichier CSV. Nommez-le 'update_events.csv'.
Combiner et transformer les données : Ouvrez les deux fichiers CSV dans un programme de feuille de calcul ou utilisez un script de préparation de données. Copiez toutes les données de 'update_events.csv' et collez-les sous les données de 'creation_events.csv' dans un nouveau fichier nommé 'event_log.csv'.
Mapper les activités et les attributs : Dans le fichier 'event_log.csv' combiné, créez de nouvelles colonnes : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status et ServiceType. Remplissez ces colonnes en utilisant la logique définie dans la section Requête ci-dessous. Cette étape implique l'utilisation de formules ou d'un script pour traduire les données brutes dans le format de journal d'événements final.
Exportation finale : Enregistrez le fichier 'event_log.csv' transformé. Assurez-vous que le format de date pour EventTime et LastDataUpdate est dans un format standard comme ISO 8601. Ce fichier est maintenant prêt à être téléchargé dans un outil de Process Mining.

Configuration

Plan Freshservice: Un plan incluant le module Analytics (généralement Pro ou Enterprise) est requis.
Autorisations de l'utilisateur: L'utilisateur effectuant l'exportation doit disposer des autorisations nécessaires pour créer et exécuter des rapports dans Analytics.
Plage de dates: Il est recommandé d'extraire des données pour une période récente, par exemple les 3 à 6 derniers mois, afin de maintenir l'ensemble de données gérable. Appliquez un filtre de plage de dates cohérent basé sur 'Créé le' pour le rapport de création et sur 'Date d'activité' pour le rapport de mises à jour.
Filtres de rapport: Dans le rapport du module 'Tickets', filtrez par 'Type' = 'Service Request' pour isoler le processus correct. Pour le rapport 'Activités des tickets', filtrez le 'Type d'activité' pour inclure uniquement les changements pertinents (Statut, Priorité, Affectation, Notes) afin de réduire le bruit dans les données exportées.
Automatisations requises: L'extraction des activités 'SLA Target Breached' et 'Resolution Confirmed by Requestor' dépend de règles d'automatisation de flux de travail préexistantes qui ajoutent une note ou une balise au ticket lors de ces événements. Sans celles-ci, les activités ne peuvent pas être capturées par cette méthode.

a Exemple de requête config

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

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

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

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

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

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

Étapes

Prérequis : Assurez-vous d'avoir Python 3.6 ou plus récent installé sur votre système, ainsi que les bibliothèques requests et pandas. Vous aurez également besoin d'une clé API Freshservice avec les autorisations de lecture des données de ticket.
Obtenir la clé API : Connectez-vous à votre instance Freshservice en tant qu'administrateur. Cliquez sur l'icône de votre profil dans le coin supérieur droit, allez dans 'Paramètres du profil', et vous trouverez votre clé API dans le volet de droite. Copiez cette clé en toute sécurité.
Enregistrer le script : Enregistrez le code Python fourni dans un fichier nommé extract_freshservice_srm.py sur votre machine locale.
Configurer les paramètres du script : Ouvrez le script enregistré dans un éditeur de texte. Localisez la section de configuration en haut et remplacez les valeurs de remplacement pour FRESHSERVICE_DOMAIN, API_KEY, START_DATE et END_DATE. Ajustez le dictionnaire STATUS_MAPPING si votre instance utilise des ID numériques différents pour les statuts personnalisés.
Installer les bibliothèques : Si vous n'avez pas les bibliothèques requises installées, ouvrez votre ligne de commande ou terminal et exécutez la commande : pip install requests pandas.
Exécuter le script : Naviguez jusqu'au répertoire où vous avez enregistré le script en utilisant votre ligne de commande ou terminal. Exécutez le script en exécutant la commande : python extract_freshservice_srm.py.
Surveiller l'exécution : Le script affichera les mises à jour de progression dans la console, indiquant quelle page de tickets il est en train de traiter. Selon la plage de dates et le volume de tickets, cela peut prendre un certain temps.
Récupérer le journal d'événements : Une fois le script terminé avec succès, il créera un fichier nommé freshservice_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements extrait.
Préparer le téléchargement : Le fichier CSV généré est structuré avec les colonnes requises (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) et est prêt à être téléchargé dans ProcessMind. Aucune autre mise en forme n'est généralement nécessaire.

Configuration

FRESHSERVICE_DOMAIN: L'URL Freshservice de votre organisation, par exemple, yourcompany.freshservice.com.
API_KEY: La clé API personnelle obtenue à partir de votre profil utilisateur Freshservice. Celle-ci doit rester confidentielle.
START_DATE / END_DATE: La plage de dates pour l'extraction des tickets, formatée comme 'AAAA-MM-JJ'. Pour une analyse initiale, une période de 3 à 6 mois est recommandée afin d'équilibrer le volume de données et la pertinence des informations.
STATUS_MAPPING: Un dictionnaire Python essentiel dans le script qui associe les noms de statuts personnalisés utilisés pour inférer des événements (comme 'External Vendor Engaged') à leurs identifiants de statut numériques correspondants dans votre instance Freshservice. Vous devez vérifier et mettre à jour ces identifiants pour qu'ils correspondent à la configuration de votre système.
API Rate Limiting: Soyez conscient des limites de débit de l'API de votre plan Freshservice. Le script traite les tickets séquentiellement pour respecter ces limites, mais pour des ensembles de données extrêmement volumineux, vous devrez peut-être exécuter l'extraction par lots de plages de dates plus petites.
Data Scope: Le script est configuré pour extraire uniquement les tickets de type 'Service Request'. Ce filtre est appliqué lors de la récupération initiale des tickets.

a Exemple de requête python

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

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

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

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

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

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

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

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

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

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

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

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

        data = get_api_data(url)

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

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

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

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

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

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

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

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

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

        page += 1

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

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

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

Étapes

Vérification des prérequis : Assurez-vous de disposer d'un rôle d'utilisateur Freshservice avec les autorisations d'accès et de création de rapports dans le module Analytics. Cela nécessite généralement un plan Pro ou Enterprise.
Configurer les automatisations (si nécessaire) : Pour une capture d'événements précise, vérifiez ou créez deux automatisations spécifiques dans Freshservice sous Admin -> Workflow Automator. Premièrement, une automatisation qui ajoute une note privée ou une balise spécifique (par exemple, 'SLA_Breached') à un ticket lorsque son délai de résolution SLA expire. Deuxièmement, une automatisation qui ajoute une balise spécifique (par exemple, 'Resolution_Confirmed') lorsqu'une enquête de satisfaction client positive est reçue pour un ticket.
Créer le rapport 'Événements de création' : Accédez à l'onglet Analytics dans Freshservice. Créez un nouveau rapport et sélectionnez le module 'Tickets' comme source de données. Ce rapport capturera le premier événement pour chaque demande de service.
Configurer les widgets du rapport 'Événements de création' : Ajoutez un widget 'Tableau de données'. Configurez les colonnes (métriques) pour inclure : ID du ticket, Créé le, Assigné à, Groupe, Priorité, Statut et Catégorie. Appliquez un filtre pour la plage de dates de création souhaitée, par exemple, les 6 derniers mois.
Exporter les données 'Événements de création' : Exécutez le rapport et exportez le widget de tableau de données vers un fichier CSV. Nommez-le 'creation_events.csv'.
Créer le rapport 'Événements de mise à jour' : Créez un deuxième rapport, cette fois en sélectionnant le module 'Activités des tickets' comme source de données. Ce rapport capture toutes les modifications et notes ultérieures pour chaque demande de service.
Configurer les widgets du rapport 'Événements de mise à jour' : Ajoutez un widget 'Tableau de données'. Configurez les colonnes pour inclure : ID du ticket, Date d'activité, Effectué par, Type d'activité, et sous 'Changements', incluez Champ, Ancienne valeur et Nouvelle valeur. Vous devriez également ajouter des attributs de niveau ticket comme Groupe, Assigné à, Priorité, Statut et Catégorie pour fournir un contexte à chaque événement.
Filtrer le rapport 'Événements de mise à jour' : Appliquez un filtre pour la 'Date d'activité' afin qu'elle corresponde à la même plage de dates utilisée dans le rapport de création. Filtrez davantage le 'Type d'activité' pour inclure uniquement les événements pertinents tels que 'Statut changé', 'Priorité changée', 'Groupe changé', 'Agent changé', 'Note privée ajoutée' et 'Note publique ajoutée'.
Exporter les données 'Événements de mise à jour' : Exécutez le rapport et exportez le widget de tableau de données vers un fichier CSV. Nommez-le 'update_events.csv'.
Combiner et transformer les données : Ouvrez les deux fichiers CSV dans un programme de feuille de calcul ou utilisez un script de préparation de données. Copiez toutes les données de 'update_events.csv' et collez-les sous les données de 'creation_events.csv' dans un nouveau fichier nommé 'event_log.csv'.
Mapper les activités et les attributs : Dans le fichier 'event_log.csv' combiné, créez de nouvelles colonnes : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status et ServiceType. Remplissez ces colonnes en utilisant la logique définie dans la section Requête ci-dessous. Cette étape implique l'utilisation de formules ou d'un script pour traduire les données brutes dans le format de journal d'événements final.
Exportation finale : Enregistrez le fichier 'event_log.csv' transformé. Assurez-vous que le format de date pour EventTime et LastDataUpdate est dans un format standard comme ISO 8601. Ce fichier est maintenant prêt à être téléchargé dans un outil de Process Mining.

Configuration

Plan Freshservice: Un plan incluant le module Analytics (généralement Pro ou Enterprise) est requis.
Autorisations de l'utilisateur: L'utilisateur effectuant l'exportation doit disposer des autorisations nécessaires pour créer et exécuter des rapports dans Analytics.
Plage de dates: Il est recommandé d'extraire des données pour une période récente, par exemple les 3 à 6 derniers mois, afin de maintenir l'ensemble de données gérable. Appliquez un filtre de plage de dates cohérent basé sur 'Créé le' pour le rapport de création et sur 'Date d'activité' pour le rapport de mises à jour.
Filtres de rapport: Dans le rapport du module 'Tickets', filtrez par 'Type' = 'Service Request' pour isoler le processus correct. Pour le rapport 'Activités des tickets', filtrez le 'Type d'activité' pour inclure uniquement les changements pertinents (Statut, Priorité, Affectation, Notes) afin de réduire le bruit dans les données exportées.
Automatisations requises: L'extraction des activités 'SLA Target Breached' et 'Resolution Confirmed by Requestor' dépend de règles d'automatisation de flux de travail préexistantes qui ajoutent une note ou une balise au ticket lors de ces événements. Sans celles-ci, les activités ne peuvent pas être capturées par cette méthode.

a Exemple de requête config

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

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

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

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

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

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

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Exportation de données du module Freshservice Analytics

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Freshservice

Étapes

Configuration

a Exemple de requête python

Exportation de données Freshservice planifiée vers le stockage cloud

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Optimisez l'efficacité de la gestion des demandes de service dans Freshservice dès aujourd'hui

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Exportation de données du module Freshservice Analytics

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Freshservice

Étapes

Configuration

a Exemple de requête python

Exportation de données Freshservice planifiée vers le stockage cloud

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez l'efficacité de la gestion des demandes de service dans Freshservice dès aujourd'hui