> Amélioration continue des processus > Modèle de données : 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 la gestion des demandes de service(19) 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 vous guide dans la collecte des données nécessaires à l’analyse de votre processus de gestion des demandes de service. Il présente les attributs essentiels, les principales activités à suivre et des conseils pratiques pour extraire ces informations de vos systèmes sources. Utilisez cette ressource pour constituer un journal d’événements adapté à une analyse approfondie du processus.

Attributs recommandés à collecter
Activités clés à suivre
Conseils d’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion des demandes de service

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail votre processus de gestion des demandes de service.

5 Obligatoire 5 Recommandé 9 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage précis de l’activité.
Description L’heure de l’événement indique la date et l’heure auxquelles une activité précise a été enregistrée pour une demande de service. Cet horodatage est essentiel pour remettre les événements dans le bon ordre et calculer les durées qui les séparent. En Process Mining, cet attribut sert à ordonner les activités de chaque cas et constitue la base de toutes les analyses temporelles. Il permet de 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 exacts sont indispensables pour repérer les goulots d’étranglement et comprendre la performance du processus. Pourquoi est-ce important ? Cet horodatage ordonne les événements chronologiquement et sert de base à l’analyse des performances, notamment au calcul du temps de cycle et à la détection des goulots d’étranglement. Où trouver ces données Il correspond à l’horodatage de création d’une activité ou d’une entrée du journal d’audit dans Freshservice. Exemples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Identifiant de la demande de service ServiceRequestId	Identifiant unique de chaque demande de service.
Description L’identifiant de la demande de service est un numéro ou un code unique attribué à chaque nouvelle demande enregistrée dans Freshservice. Il sert de clé principale pour suivre tout le cycle de vie de la demande, de sa création à sa clôture. En Process Mining, cet identifiant est essentiel, car il sert d’ID de cas. Il relie entre eux tous les événements associés, comme les changements de statut, les affectations à des agents et les notes. L’analyse du parcours de chaque demande permet de visualiser le processus de bout en bout, de repérer les chemins les plus fréquents et de détecter les écarts ou les goulots d’étranglement propres à certains cas. Pourquoi est-ce important ? Cet ID de cas essentiel relie tous les événements associés et permet de suivre le parcours complet d’une demande de service. Où trouver ces données Il s’agit d’un champ principal de l’objet ticket dans Freshservice. Il est visible dans l’interface et accessible via l’API Freshservice. Exemples SR-12943SR-13501SR-14011
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche survenu à un moment précis dans le traitement d’une demande de service.
Description Le nom de l’activité décrit une étape ou un événement précis du cycle de vie d’une demande de service. Ces activités sont extraites des journaux d’audit du système, des changements de statut ou d’actions précises effectuées par les utilisateurs, comme « Demande affectée à un agent », « Note ajoutée » ou « Demande de service résolue ». Cet attribut sert à construire la cartographie du processus, qui représente visuellement le flux des demandes de service. En analysant l’ordre et la fréquence des différentes activités, les organisations peuvent comprendre le processus réel, repérer les goulots d’étranglement entre les étapes, mesurer leur durée et détecter les variantes non conformes ou inefficaces. Pourquoi est-ce important ? Cet attribut définit les étapes de la cartographie du processus et permet de visualiser et d’analyser le flux de travail des demandes de service. Où trouver ces données Généré à partir des « activities » ou des « audits » associés à un ticket dans Freshservice. Une logique de transformation est souvent nécessaire pour associer les événements système à des noms d’activité compréhensibles par les équipes métier. Exemples Demande de service crééeDemande affectée à un agentDemande de service résolueDemande de service clôturée
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données depuis le système source.
Description Cet attribut enregistre la date et l’heure de la dernière extraction ou mise à jour du jeu de données depuis Freshservice. Il indique l’ancienneté des données analysées. Pour analyser un processus, il est important de savoir si les données sont à jour. Cet horodatage permet de vérifier que les informations consultées sont les plus récentes, ce qui est essentiel pour prendre des décisions opérationnelles au bon moment et se fier aux résultats de l’analyse. Pourquoi est-ce important ? Indique l’ancienneté des données afin que les analyses et les décisions reposent sur des informations à jour. Où trouver ces données Cette valeur est générée et ajoutée au jeu de données lors du processus d’extraction, de transformation et de chargement (ETL). Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Système source SourceSystem	Indique le système dont les données ont été extraites.
Description Cet attribut indique le système d’origine des données du processus, ici Freshservice. Il est particulièrement utile lorsque les données de plusieurs systèmes sont regroupées pour obtenir une vue d’ensemble du processus. Même s’il peut sembler redondant dans une analyse portant sur un seul système, il est recommandé de l’inclure pour faciliter l’évolution et la gouvernance des données. Il précise leur provenance et aide à gérer les chaînes d’intégration des données. Pourquoi est-ce important ? Garantit la traçabilité et la provenance des données, ce qui est important lorsqu’elles proviennent de plusieurs systèmes ou dans le cadre de leur gouvernance. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) des données. Exemples FreshserviceFreshservice-API-v2
	Agent affecté AssignedAgent	Nom de l’agent actuellement affecté à la demande de service.
Description Cet attribut identifie l’agent d’assistance chargé de traiter la demande de service à un moment donné. L’agent affecté peut changer au cours du cycle de vie de la demande. L’analyse de l’agent affecté permet de comprendre les performances des agents et la répartition de leur charge de travail. Elle sert à calculer des indicateurs clés de performance, comme le temps moyen de résolution par agent, le nombre de demandes en cours et le taux de réaffectation. Ces analyses permettent de repérer les agents les plus performants, ceux qui pourraient avoir besoin d’une formation complémentaire et les déséquilibres dans la répartition du travail. Pourquoi est-ce important ? Permet d’analyser la charge de travail et les performances des agents, ainsi que l’effet des réaffectations sur les délais de résolution. Où trouver ces données Disponible dans le champ « agent » ou « responder » de l’objet ticket dans Freshservice. Exemples Alice JohnsonRobert SmithNon affecté
	Équipe affectée AssignedTeam	Équipe ou groupe d’assistance chargé de traiter la demande de service.
Description Cet attribut indique le groupe fonctionnel ou l’équipe, par exemple « Assistance informatique niveau 2 » ou « Approvisionnement en matériel », chargé de la demande de service. Une demande peut être affectée à une équipe avant d’être prise en charge par un agent. L’analyse par équipe affectée permet de comprendre les performances et la charge de travail de chaque équipe, ainsi que de repérer les goulots d’étranglement propres à certaines fonctions. Elle aide à évaluer l’efficacité avec laquelle les différentes équipes traitent les demandes et à mieux répartir les ressources au sein de l’assistance. Pourquoi est-ce important ? Permet d’analyser les performances et la charge de travail par équipe ou par groupe, ce qui est essentiel pour gérer les ressources et repérer les goulots d’étranglement propres à certaines fonctions. Où trouver ces données Disponible dans le champ « group » de l’objet ticket dans Freshservice. Exemples Centre de servicesExploitation du réseauAssistance applicative
	Priorité Priority	Niveau de priorité de la demande de service, par exemple faible, moyenne, élevée ou urgente.
Description La priorité indique l’importance et l’urgence d’une demande de service. Elle détermine souvent le délai de résolution visé et les ressources affectées. Elle peut être définie automatiquement selon des règles ou manuellement par les agents. En Process Mining, la priorité est un axe d’analyse important. Elle permet de segmenter les demandes et de comparer les flux de processus et les performances des demandes prioritaires à celles des demandes moins prioritaires. Cette analyse est essentielle pour vérifier le respect des SLA et déterminer si les demandes sont correctement priorisées dès l’étape de triage. Pourquoi est-ce important ? Essentielle pour vérifier le respect des SLA et déterminer si les demandes sont triées et traitées en fonction de leur impact sur l’activité. Où trouver ces données Disponible dans le champ « priority » de l’objet ticket dans Freshservice. Exemples FaibleMoyenneÉlevéeUrgente
	Statut Status	Statut actuel de la demande de service au cours de son cycle de vie.
Description Le champ Statut indique l’état de la demande de service à un moment donné, par exemple « Ouvert », « En attente », « Résolu » ou « Clos ». Les changements de statut constituent souvent la principale source d’activités pour le Process Mining. L’analyse du statut apporte un contexte au flux du processus et permet de savoir combien de temps les demandes restent dans certains états. Par exemple, une longue période au statut « En attente » peut signaler un goulot d’étranglement dû à l’attente d’informations du demandeur ou d’un fournisseur externe. Cet attribut permet également de définir le début et la fin des différentes étapes du processus. Pourquoi est-ce important ? Apporte un contexte essentiel à chaque événement et permet de mesurer le temps passé dans différents états, comme « Ouvert » ou « En attente », afin de repérer les retards. Où trouver ces données Disponible dans le champ « status » de l’objet ticket dans Freshservice. Exemples OuvertEn attenteRésoluClos
	Type de service ServiceType	Type ou catégorie précise du service demandé.
Description Le type de service classe la demande selon le service nécessaire, par exemple « Demande de nouveau matériel », « Accès à un logiciel » ou « Réinitialisation du mot de passe ». Il est souvent lié à l’élément du catalogue de services sélectionné par l’utilisateur. Cet attribut permet de segmenter les demandes de service afin de comparer les processus et les performances selon le type de service. Il est essentiel pour calculer des indicateurs clés de performance comme le « nombre moyen d’activités par type de service » et repérer les services les plus complexes ou les plus gourmands en ressources. Ces analyses peuvent orienter les efforts de simplification et d’automatisation pour certains types de services. Pourquoi est-ce important ? Permet de comparer les flux de processus et leur complexité selon les catégories de demandes, afin de repérer les possibilités de standardisation ou d’automatisation. Où trouver ces données Selon la configuration, il correspond souvent au champ « category », « item » ou à un champ personnalisé de l’objet ticket dans Freshservice. Exemples Intégration d’un nouvel employéDemande de licence logicielleAccès au VPN
	Canal Channel	Mode ou canal utilisé pour soumettre la demande de service.
Description Le canal indique comment la demande de service a été créée, par exemple via le portail en libre-service, par e-mail, par téléphone ou par messagerie instantanée. Cette information permet de comprendre les préférences des utilisateurs et l’efficacité de chaque canal. L’analyse du processus par canal peut révéler des différences importantes. Par exemple, les demandes soumises via le portail peuvent être plus complètes et résolues plus rapidement que celles envoyées par e-mail, qui nécessitent parfois davantage d’échanges. Ces résultats peuvent orienter les efforts visant à encourager l’utilisation des canaux les plus efficaces. Pourquoi est-ce important ? Permet de déterminer si le canal de soumission a une incidence sur l’efficacité du processus, le délai de résolution ou le nombre de reprises nécessaires. Où trouver ces données Disponible dans le champ « source » de l’objet ticket dans Freshservice. Exemples E-mailPortailTéléphoneMessagerie instantanée
	Date d’échéance du SLA SlaDueDate	Horodatage avant lequel la demande de service doit être résolue selon son SLA.
Description Cet attribut indique la date limite de résolution de la demande de service, définie par la politique SLA applicable. Cet horodatage calculé dépend de la date de création de la demande, de sa priorité et des heures ouvrées définies dans le SLA. Cette information est essentielle pour suivre les performances en temps réel et analyser après coup le respect des SLA. La comparaison entre l’heure réelle de résolution et SlaDueDate permet de déterminer si le SLA a été respecté ou dépassé. Elle sert de base au calcul de l’indicateur clé de performance du taux de conformité aux SLA. Pourquoi est-ce important ? Il s’agit de la date limite de résolution visée, qui permet de déterminer si la demande de service a respecté ou dépassé son SLA. Où trouver ces données Il s’agit d’un champ calculé dans Freshservice, visible sur le ticket sous « Due by ». Il est accessible via l’API. Exemples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	Demandeur Requestor	Utilisateur ayant soumis la demande de service.
Description Cet attribut identifie la personne, généralement un employé, qui a soumis la demande de service. Il indique qui utilise le centre de services et quels sont ses besoins. Même si le demandeur n’est pas toujours un axe principal d’analyse du flux de processus, l’analyse par demandeur ou par service associé peut révéler des tendances. Par exemple, elle peut montrer qu’un service soumet souvent des demandes incomplètes, ce qui indique un besoin de formation ciblée. Elle est également essentielle pour toute analyse de l’expérience client. Pourquoi est-ce important ? Précise qui a soumis la demande et permet d’analyser les tendances par personne, service ou lieu. Où trouver ces données Disponible dans le champ « requester » de l’objet ticket dans Freshservice. Exemples John DoeJane SmithCompte de service
	Heure de fin EndTime	Horodatage précis de la fin de l’activité.
Description L’heure de fin correspond à l’horodatage auquel une activité s’est achevée. Pour de nombreux événements dans Freshservice, les heures de début et de fin sont identiques : il s’agit alors d’événements ponctuels. En revanche, pour les activités fondées sur un statut, l’heure de fin correspond à l’horodatage du changement de statut suivant. Cet attribut est essentiel pour calculer la durée des activités et les temps d’attente entre elles. La soustraction de StartTime à EndTime permet de déterminer la durée de traitement d’une tâche précise. Ce calcul aide à repérer les activités les plus longues et celles qu’il convient d’optimiser en priorité. Pourquoi est-ce important ? Permet de calculer la durée des activités, ce qui est essentiel pour repérer les goulots d’étranglement et mesurer les temps de traitement de chaque étape. Où trouver ces données Ce champ ne figure pas directement dans les journaux Freshservice. Il doit être calculé à partir de 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	Nom de la politique d’accord de niveau de service (SLA) appliquée à la demande.
Description Cet attribut identifie la politique SLA qui définit les délais de réponse et de résolution visés pour la demande de service. Les politiques reposent généralement sur des facteurs comme la priorité, le type de service ou le groupe du demandeur. Il est essentiel de connaître la politique SLA appliquée pour utiliser le Dashboard d’analyse de la conformité aux SLA et des dépassements. Cela permet de mesurer précisément les performances par rapport aux objectifs définis et de repérer les politiques qui ne sont pas respectées le plus souvent. Les résultats peuvent conduire à revoir les performances du processus ou la faisabilité des objectifs SLA eux-mêmes. Pourquoi est-ce important ? Indique les objectifs de service auxquels la demande est soumise, ce qui est essentiel pour rendre compte avec précision du respect des SLA. Où trouver ces données Cette information fait partie des données SLA associées à un ticket. Il peut être nécessaire d’interroger des points de terminaison ou des champs d’API propres aux SLA. Exemples Incidents hautement prioritaires - 4 hDemandes standard - 3 joursAssistance VIP - 1 h
	Nombre de réaffectations ReassignmentCount	Nombre total de réaffectations de la demande de service à un autre agent ou à une autre équipe.
Description Cet attribut calculé compte, pour chaque demande de service, les occurrences de l’activité « Demande réaffectée » ou d’activités similaires. Un nombre élevé de réaffectations peut signaler un problème de triage initial, un routage inadapté aux compétences ou une charge de travail mal répartie. Cet attribut contribue directement au Dashboard sur les performances des agents et la répartition de leur charge de travail, ainsi qu’à l’indicateur du nombre moyen de réaffectations par demande. Son analyse aide les organisations à repérer les faiblesses du processus qui entraînent des transferts répétés de tickets, allongent les délais de résolution et frustrent les agents comme les demandeurs. Pourquoi est-ce important ? Mesure les inefficacités du routage et les difficultés du processus. Un nombre élevé indique des problèmes de triage initial ou de répartition de la charge de travail des agents, qui entraînent des retards. Où trouver ces données Calculé en comptant les activités de changement d’affectation pour chaque « ServiceRequestId » lors de la transformation des données. Exemples 013
	Reprises ? IsRework	Indicateur booléen précisant si la demande a donné lieu à des reprises.
Description Cet indicateur calculé prend la valeur vrai si certaines activités associées à une demande de service signalent des reprises. Il peut s’agir, par exemple, d’une réouverture après résolution (« Demande de service rouverte »), de réaffectations multiples ou de demandes répétées d’informations à l’utilisateur (« Informations demandées au demandeur »). Cet attribut simplifie l’analyse des inefficacités du processus. Il permet de filtrer facilement les cas avec reprises et de comparer leur cartographie et leur temps de cycle à ceux des cas sans problème. Il contribue directement au Dashboard d’analyse des reprises des demandes de service et aide à mesurer les conséquences des transferts inefficaces ou des informations initiales incomplètes. Pourquoi est-ce important ? Permet de repérer et d’analyser facilement les cas comportant des boucles inefficaces ou des étapes répétées, et de mesurer le coût d’une qualité insuffisante. Où trouver ces données Calculé lors de la transformation des données, en appliquant une logique métier à la séquence d’activités de chaque « ServiceRequestId ». Exemples truefalse
	Service du demandeur RequestorDepartment	Service auquel appartient le demandeur.
Description Cet attribut indique le service de l’organisation auquel appartient l’utilisateur qui a soumis la demande de service, par exemple « Ventes », « Finance » ou « Ressources humaines ». Cette information provient généralement du profil de l’utilisateur dans le système. L’analyse des performances du processus par service est courante. Elle peut révéler que certains services connaissent des délais de résolution plus longs ou ont des besoins particuliers. Ces résultats peuvent guider la répartition des ressources, les formations ou la création de services adaptés à certains services. Pourquoi est-ce important ? Permet de segmenter le processus par unité opérationnelle afin de repérer les problèmes ou les écarts de performance propres à certains services. Où trouver ces données Cette information est associée au profil du demandeur. Elle peut figurer dans le champ « department » par défaut ou dans un champ utilisateur personnalisé de Freshservice. Exemples FinanceMarketingTechnologies de l’information
	SLA dépassé ? IsSlaBreached	Indicateur booléen précisant si la demande de service a dépassé le délai de résolution prévu par son SLA.
Description Cet attribut calculé prend la valeur vrai ou faux et indique si le ticket a été clôturé après la date d’échéance de son SLA. Il est calculé en comparant l’horodatage de clôture ou de résolution de la demande de service à SlaDueDate. Cet attribut simplifie l’analyse et la visualisation dans le Dashboard de conformité aux SLA. Il permet de filtrer et d’agréger facilement les demandes pour calculer le taux global de conformité aux SLA. La segmentation selon cet indicateur permet d’isoler rapidement les demandes dont le SLA a été dépassé et de comparer leurs caractéristiques de processus à celles des demandes résolues dans les délais. Pourquoi est-ce important ? Simplifie l’analyse de la conformité aux SLA grâce à un indicateur clair qui permet de filtrer et d’agréger les demandes n’ayant pas respecté les délais visés. Où trouver ces données Il s’agit d’un champ calculé lors de la transformation des données, en comparant l’horodatage de résolution final au champ « SlaDueDate ». Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les étapes et les jalons essentiels à consigner dans votre journal d’événements pour découvrir et analyser avec précision les flux de travail de gestion des demandes de service.

6 Recommandé 9 Facultatif

	Activité	Description
	Demande affectée à un agent	Cette activité marque le moment où une demande de service est affectée à un agent précis. Il s’agit d’une étape importante, déduite du suivi des modifications apportées au champ « Agent affecté » ou « Responsable » du ticket.
Pourquoi est-ce important ? Cette activité est essentielle pour analyser la charge de travail des agents et repérer les goulots d’étranglement dans le processus d’affectation. Le temps écoulé entre la création et l’affectation est un indicateur clé de performance. Où trouver ces données Cette activité est déduite du journal d’activité ou de la piste d’audit des champs du ticket, en surveillant les modifications du champ « Agent » ou « Agent responsable ». Données à recueillir Consignez l’horodatage auquel le champ « Agent affecté » est renseigné ou change de valeur. Type d’événement inferred
	Demande de service clôturée	Il s’agit de l’activité finale, qui marque la fin du cycle de vie de la demande de service. Elle a généralement lieu automatiquement après une période définie au statut « Résolu », si le ticket n’a pas été rouvert.
Pourquoi est-ce important ? Cet événement marque la fin définitive de l’instance du processus. Le délai entre « Résolu » et « Clos » correspond à la période pendant laquelle le demandeur peut confirmer la résolution. Où trouver ces données Déduit de l’historique des changements de statut du ticket. Il correspond à l’horodatage du passage au statut « Clos ». Données à recueillir Enregistrer l’horodatage du passage du ticket au statut « Clos ». Type d’événement inferred
	Demande de service créée	Cette activité marque le début du cycle de vie d’une demande de service, lorsqu’une nouvelle demande est officiellement enregistrée dans Freshservice. L’événement est explicitement consigné à la création d’un nouveau ticket, depuis le catalogue de services, par courriel ou par un autre canal. Un identifiant unique de demande de service est alors créé.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Mesurer le temps écoulé entre cette activité et les suivantes est essentiel pour calculer les temps de cycle globaux et repérer les premiers retards de traitement. Où trouver ces données Cet événement est explicitement enregistré dans Freshservice. Vous le trouverez dans le journal d’activité ou la piste d’audit du ticket. Il correspond généralement à l’horodatage de création du ticket. Données à recueillir Utilisez l’horodatage de création du ticket dans les données des tickets Freshservice. Type d’événement explicit
	Demande de service résolue	Cette étape importante marque le moment où l’agent a fourni une solution et considère le travail terminé. Elle est déduite du passage du statut du ticket à « Résolu ».
Pourquoi est-ce important ? Cette activité marque la fin de la phase de travail actif. Le temps écoulé jusqu’à ce moment est un indicateur clé de l’efficacité des agents et du processus, et sert de base au calcul des SLA. Où trouver ces données Cette activité est déduite de l’historique des changements de statut du ticket. Elle correspond à l’horodatage de la première définition du statut « Résolu ». Données à recueillir Consignez l’horodatage du premier passage du statut du ticket à « Résolu ». Type d’événement inferred
	Objectif SLA dépassé	Cet événement calculé a lieu lorsque le délai de résolution d’une demande de service dépasse l’objectif défini dans l’accord de niveau de service (SLA). Il ne s’agit pas d’un événement directement enregistré par le système : il est déduit de la comparaison entre le délai de résolution et la date d’échéance du SLA.
Pourquoi est-ce important ? Cet indicateur mesure directement les performances du service au regard de ses engagements et constitue un KPI important pour la direction. Il aide à repérer les types de demandes ou les niveaux de priorité les plus susceptibles de ne pas respecter les délais. Où trouver ces données Cet événement est calculé en comparant l’horodatage « Résolu » à l’horodatage « Échéance du SLA ». Il est déclenché si la résolution intervient après l’échéance. Données à recueillir 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
	Prestataire externe sollicité	Cette activité marque le transfert d’un ticket à un prestataire externe ou à un tiers chargé de le résoudre. Elle est déduite du passage à un statut précis, comme « En attente du prestataire » ou « En attente d’un tiers ».
Pourquoi est-ce important ? L’intervention d’un prestataire peut entraîner des retards importants. Suivre cette activité est essentiel pour mesurer les performances du prestataire et son incidence sur le temps de cycle global des demandes de service. Où trouver ces données Cette activité est déduite de l’historique des changements de statut du ticket. Repérez le statut configuré spécifiquement pour suivre la dépendance à l’égard de prestataires externes. Données à recueillir Détectez le passage du champ de statut du ticket à une valeur indiquant qu’une réponse d’un tiers est attendue. Type d’événement inferred
	Demande de service rouverte	Cette activité a lieu lorsque le demandeur signale que le problème persiste après que le ticket a été marqué comme « Résolu ». Le ticket repasse alors à l’état ouvert. Elle est déduite du passage du statut « Résolu » à « Ouvert » ou « En cours ».
Pourquoi est-ce important ? La réouverture des demandes indique souvent un faible taux de résolution dès le premier contact et une insatisfaction des clients. Suivre cette boucle de reprise est essentiel pour améliorer la qualité des solutions. Où trouver ces données Cette activité est déduite de l’historique des changements de statut du ticket dans le journal d’activité. Elle correspond au passage direct du statut « Résolu » à « Ouvert ». Données à recueillir Détectez le passage d’un statut de résolution à un statut ouvert. Type d’événement inferred
	Demande priorisée	Cette activité a lieu lorsqu’un niveau de priorité, par exemple faible, moyen ou élevé, est attribué à la demande de service. Elle est déduite de la détection d’une modification du champ « Priorité » dans l’historique du ticket.
Pourquoi est-ce important ? La priorisation est essentielle pour répartir les ressources et respecter les objectifs SLA. L’analyse de cette activité permet de vérifier que les demandes sont évaluées correctement et dans les délais. Où trouver ces données Cette activité est déduite de l’historique des modifications de champs du ticket dans Freshservice. Repérez les mises à jour du champ « Priorité » et consignez l’horodatage de la modification. Données à recueillir Détectez toute modification du champ « Priorité », qu’il passe d’une valeur nulle ou de sa valeur précédente, et consignez l’horodatage. Type d’événement inferred
	Demande réaffectée	Cette activité consigne tout changement d’agent ou de groupe affecté après l’affectation initiale. Elle est déduite de la détection de mises à jour ultérieures des champs « Agent affecté » ou « Groupe affecté ».
Pourquoi est-ce important ? Des réaffectations fréquentes peuvent révéler des problèmes de tri initial, d’adéquation entre les compétences des agents et les demandes, ou de répartition de la charge de travail. Cette activité est essentielle au KPI du nombre de réaffectations d’agents et à l’analyse des reprises. Où trouver ces données Cette activité est déduite de l’historique des modifications de champs du ticket. L’événement est consigné chaque fois que le champ « Agent affecté » ou « Groupe affecté » est mis à jour après sa première définition. Données à recueillir Détectez toute modification du champ « Agent affecté » ou « Groupe affecté » après la première affectation. Type d’événement inferred
	Demande triée	Cette activité correspond à l’évaluation et à la catégorisation initiales d’une nouvelle demande de service. Elle est généralement déduite de la première définition d’une priorité ou de l’affectation de la demande à un groupe, ce qui indique qu’elle a été examinée et ajoutée à la file d’attente.
Pourquoi est-ce important ? Le suivi du tri permet de mesurer l’efficacité de l’équipe chargée de la première réponse. Un retard à cette étape peut allonger considérablement le délai global de résolution et compromettre le respect des SLA. Où trouver ces données Cette activité est déduite du journal d’activité. Elle peut être repérée à l’horodatage du premier événement « Priorité définie » ou « Groupe affecté » après la création. Données à recueillir Repérez l’horodatage le plus ancien entre une modification du champ de priorité et une modification du champ du groupe d’affectation. Type d’événement inferred
	Informations demandées au demandeur	Cette activité correspond au moment où l’agent affecté a besoin d’informations supplémentaires de la part du demandeur et met le traitement en pause. Elle est déduite du passage du ticket au statut « En attente » ou « En attente du client ».
Pourquoi est-ce important ? Cette activité met en évidence une cause fréquente de retard et de reprise. En analyser la fréquence permet de repérer les possibilités d’améliorer les modèles de demande et la collecte initiale des informations. Où trouver ces données Cette activité est déduite de l’historique des changements de statut du ticket. Repérez les changements vers un statut tel que « En attente d’une réponse du client » ou « En attente d’informations ». Données à recueillir Détectez le passage du champ de statut du ticket à une valeur indiquant que des informations sont attendues de l’utilisateur. Type d’événement inferred
	Informations fournies par le demandeur	Cette activité a lieu lorsque le demandeur fournit les informations nécessaires et que l’agent peut reprendre le traitement. Elle est généralement déduite du passage automatique du statut du ticket de « En attente » à « Ouvert ».
Pourquoi est-ce important ? Cette activité clôt la demande d’informations. Le temps écoulé entre la demande et la réception des informations est un délai d’attente important à analyser et à réduire. Où trouver ces données Cette activité est déduite du passage du statut « En attente » à « Ouvert » ou « En cours », souvent après une réponse du demandeur. Données à recueillir Détectez le passage du statut du ticket d’un état d’attente à un état ouvert. Type d’événement inferred
	Note ajoutée	Cette activité correspond à 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, consigné dans la conversation ou le journal d’activité du ticket.
Pourquoi est-ce important ? L’analyse de la fréquence et du moment où les notes sont ajoutées peut révéler les habitudes de communication, l’efficacité de la collaboration et les points de confusion dans le processus. Où trouver ces données Chaque note est explicitement consignée dans l’historique de conversation du ticket dans Freshservice, avec son horodatage et son auteur. Données à recueillir Extrayez chaque entrée du journal de conversation ou de commentaires du ticket. Type d’événement explicit
	Résolution confirmée par le demandeur	Cette activité correspond à la confirmation explicite du demandeur que la solution fournie lui convient. Elle peut être déduite d’une réponse positive à une enquête ou d’un commentaire précis avant la clôture du ticket.
Pourquoi est-ce important ? La confirmation fournit un retour direct sur la qualité de la résolution. Un faible taux de confirmation peut indiquer que les solutions ne répondent pas pleinement aux besoins des utilisateurs, même si les tickets ne sont pas rouverts. Où trouver ces données Cette activité est difficile à enregistrer directement et peut nécessiter une configuration personnalisée. Elle peut être déduite d’une réponse à une enquête de satisfaction liée au ticket ou de l’ajout d’une étiquette spécifique. Données à recueillir Cette activité nécessite d’analyser des données connexes, comme les enquêtes de satisfaction ou les étiquettes ajoutées après la résolution. Type d’événement inferred
	Revue interne effectuée	Cette activité indique qu’une solution proposée ou le traitement d’une demande nécessite une revue ou une approbation interne avant de se poursuivre. Elle est déduite du passage à un statut tel que « En attente d’approbation » ou « Revue interne ».
Pourquoi est-ce important ? Les revues internes peuvent créer des goulots d’étranglement, notamment pour les demandes de service complexes ou à fort impact. Mesurer leur durée permet de simplifier les flux d’approbation. Où trouver ces données Cette activité est déduite de l’historique des changements de statut du ticket. Le flux de travail doit utiliser un statut spécifique, tel que « En attente d’approbation interne ». Données à recueillir Détectez le passage du champ de statut du ticket à une valeur indiquant une revue ou une approbation interne. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Freshservice

Étapes

Vérifiez les prérequis : Assurez-vous que votre rôle utilisateur Freshservice vous autorise à accéder au module Analytics et à y créer des rapports. Un forfait Pro ou Enterprise est généralement nécessaire.
Configurez les automatisations si nécessaire : Pour consigner correctement les événements, vérifiez ou créez deux automatisations dans Freshservice, sous Admin -> Workflow Automator. La première ajoute une note privée ou une étiquette spécifique (par exemple, ’SLA_Breached’) à un ticket lorsque le délai de résolution prévu par le SLA expire. La seconde ajoute une étiquette spécifique (par exemple, ’Resolution_Confirmed’) lorsqu’une enquête de satisfaction reçoit une réponse positive pour un ticket.
Créez le rapport « Creation Events » : Dans Freshservice, ouvrez l’onglet Analytics. Créez un rapport et sélectionnez le module « Tickets » comme source de données. Ce rapport consigne le premier événement de chaque demande de service.
Configurez les widgets du rapport « Creation Events » : Ajoutez un widget « Data Table ». Configurez les colonnes (métriques) à inclure : Ticket ID, Created at, Assigned to, Group, Priority, État et Category. Appliquez un filtre sur la période de création souhaitée, par exemple les six derniers mois.
Exportez les données « Creation Events » : Exécutez le rapport et exportez le widget Data Table au format CSV. Nommez le fichier ’creation_events.csv’.
Créez le rapport « Update Events » : Créez un deuxième rapport en sélectionnant cette fois le module « Ticket Activities » comme source de données. Ce rapport consigne les modifications et les notes ultérieures associées à chaque demande de service.
Configurez les widgets du rapport « Update Events » : Ajoutez un widget « Data Table ». Configurez les colonnes à inclure : Ticket ID, Activity Date, Performed by, Activity Type et, sous « Changes », Field, Old Value et New Value. Ajoutez également des attributs au niveau du ticket, comme Group, Assigned to, Priority, État et Category, pour apporter du contexte à chaque événement.
Filtrez le rapport « Update Events » : Appliquez à « Activity Date » le même filtre de période que pour le rapport de création. Filtrez ensuite « Activity Type » pour ne conserver que les événements pertinents, par exemple « Status changed », « Priority changed », « Group changed », « Agent changed », « Private Note added » et « Public Note added ».
Exportez les données « Update Events » : Exécutez le rapport et exportez le widget Data Table au format CSV. Nommez le fichier ’update_events.csv’.
Combinez et transformez les données : Ouvrez les deux fichiers CSV dans un tableur ou utilisez un script de préparation des données. Copiez toutes les données de ’update_events.csv’ et collez-les sous celles de ’creation_events.csv’ dans un nouveau fichier nommé ’event_log.csv’.
Associez les activités et les attributs : Dans le fichier ’event_log.csv’ combiné, créez les colonnes suivantes : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status et ServiceType. Renseignez-les en appliquant la logique définie dans la section Query ci-dessous. Cette étape consiste à utiliser des formules ou un script pour convertir les données brutes au format final du journal d’événements.
Exportez le fichier final : Enregistrez le fichier ’event_log.csv’ transformé. Vérifiez que les dates des colonnes EventTime et LastDataUpdate suivent un format standard, comme ISO 8601. Le fichier est alors prêt à être importé dans un outil de Process Mining.

Configuration

Forfait Freshservice : Vous devez disposer d’un forfait incluant le module Analytics, généralement Pro ou Enterprise.
Autorisations utilisateur : La personne qui effectue l’export doit pouvoir créer et exécuter des rapports dans Analytics.
Période : Il est recommandé d’extraire les données d’une période récente, par exemple les trois à six derniers mois, afin de conserver un jeu de données facile à gérer. Appliquez un filtre de période cohérent, basé sur « Created at » pour le rapport de création et sur « Activity Date » pour le rapport des mises à jour.
Filtres des rapports : Dans le rapport du module « Tickets », filtrez « Type » sur « Service Request » pour isoler le processus concerné. Dans le rapport « Ticket Activities », filtrez « Activity Type » afin de ne conserver que les modifications pertinentes (état, priorité, affectation, notes) et 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 Workflow Automator préexistantes qui ajoutent une note ou une étiquette au ticket lorsque ces événements se produisent. Sans ces règles, cette méthode ne permet pas de consigner ces activités.

Exemple de requête sql

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

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

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

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

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

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

Étapes

Prérequis : Vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système, ainsi que les bibliothèques requests et pandas. Vous aurez également besoin d’une clé API Freshservice autorisée à lire les données des tickets.
Obtenez une clé API : Connectez-vous à votre instance Freshservice en tant qu’administrateur. Cliquez sur l’icône de votre profil en haut à droite, ouvrez « Profile Settings » et repérez votre clé API dans le panneau de droite. Copiez-la et conservez-la en lieu sûr.
Enregistrez le script : Enregistrez le code Python fourni dans un fichier nommé extract_freshservice_srm.py sur votre ordinateur.
Configurez les paramètres du script : Ouvrez le script enregistré dans un éditeur de texte. Repérez la section de configuration en haut du fichier et remplacez les valeurs fictives de FRESHSERVICE_DOMAIN, API_KEY, START_DATE et END_DATE. Modifiez le dictionnaire STATUS_MAPPING si votre instance utilise des identifiants numériques différents pour les états personnalisés.
Installez les bibliothèques : Si les bibliothèques requises ne sont pas installées, ouvrez la ligne de commande ou le terminal et exécutez : pip install requests pandas.
Exécutez le script : À l’aide de la ligne de commande ou du terminal, accédez au répertoire où vous avez enregistré le script. Lancez-le avec la commande : python extract_freshservice_srm.py.
Suivez l’exécution : Le script affiche sa progression dans la console et indique la page de tickets en cours de traitement. Selon la période et le volume de tickets, l’opération peut prendre un certain temps.
Récupérez le journal d’événements : Une fois l’exécution terminée, le script crée dans le même répertoire un fichier nommé freshservice_event_log.csv, qui contient le journal d’événements extrait.
Préparez l’importation : Le fichier CSV généré comporte les colonnes requises (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) et peut être importé dans ProcessMind. En général, aucune autre mise en forme n’est nécessaire.

Configuration

FRESHSERVICE_DOMAIN : L’URL Freshservice de votre organisation, par exemple yourcompany.freshservice.com.
API_KEY : La clé API personnelle associée à votre profil utilisateur Freshservice. Elle doit rester confidentielle.
START_DATE / END_DATE : La période d’extraction des tickets, au format ’YYYY-MM-DD’. Pour une première analyse, une période de trois à six mois est recommandée afin de trouver un équilibre entre le volume de données et la richesse de l’analyse.
STATUS_MAPPING : Dictionnaire Python essentiel du script, qui associe les noms d’états personnalisés utilisés pour déduire des événements (par exemple, ’External Vendor Engaged’) aux identifiants numériques correspondants dans votre instance Freshservice. Vérifiez ces identifiants et mettez-les à jour pour qu’ils correspondent à la configuration de votre système.
Limitation du débit de l’API : Tenez compte des limites d’appels API de votre forfait Freshservice. Le script traite les tickets l’un après l’autre pour les respecter. Pour les jeux de données très volumineux, vous devrez peut-être répartir l’extraction en plusieurs périodes plus courtes.
Périmètre des données : 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.

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érifiez que votre abonnement Freshservice et vos autorisations d’administrateur incluent l’export planifié des données et leur transfert vers le fournisseur de stockage cloud choisi. Les noms des menus et les possibilités d’export de Freshservice peuvent varier selon le forfait et l’environnement. Consultez la documentation d’administration à jour et utilisez [Configure based on your system] si les libellés diffèrent dans votre environnement.
Dans Freshservice, ouvrez l’espace d’administration et repérez la configuration de l’export planifié des données. Sélectionnez la source de données des demandes de service ou des tickets qui contient l’identifiant de demande de service, l’état, la priorité, l’affectation, le type de service, les horodatages, les champs SLA, l’historique des conversations ou des activités et les réponses du demandeur. Ne partez pas du principe qu’un export des tickets dans leur état actuel contient l’historique des modifications de champs.
Définissez le périmètre de l’export. Pour la validation initiale, sélectionnez une période glissante de trois à six mois, puis choisissez une fréquence adaptée aux besoins de reporting. Incluez tous les enregistrements de demandes de service ainsi que les données historiques d’activité ou d’audit nécessaires pour repérer les changements de champs, les notes, les transitions d’état, les résultats SLA, les approbations et les confirmations des demandeurs. N’appliquez des filtres par entreprise ou par service que si cela est explicitement nécessaire, en utilisant [Company or service filter based on your system].
Sélectionnez le format CSV et configurez le transfert vers l’emplacement de stockage cloud approuvé, par exemple Amazon S3. Saisissez [Cloud storage connection details] et [Credentials or role configuration] dans la configuration Freshservice prévue à cet effet. Vérifiez le compartiment, le chemin, le chiffrement, la durée de conservation et les règles d’accès avec le responsable de la plateforme. Ne placez pas directement les identifiants dans des scripts ou des fichiers exportés.
Lancez un export de test et examinez les fichiers CSV reçus. Repérez les noms réels des colonnes exportées pour l’identifiant de demande de service, l’état, la priorité, l’agent affecté, le groupe affecté, le type de service, les heures de création, de mise à jour, de résolution et de clôture, l’échéance SLA, l’horodatage de l’historique, le champ modifié, l’ancienne valeur, la nouvelle valeur, le type de note, son auteur et son horodatage, ainsi que la réponse du demandeur ou le résultat de l’enquête. Si un champ source requis n’est pas disponible, consignez cette limite au lieu d’inventer un nom de champ.
Chargez les fichiers CSV dans une table de préparation ou une structure de données. Dans la requête ci-dessous, remplacez les références aux sources, notamment [Your ticket table name], [Your ticket history table name], [Your conversation table name], [Your SLA table name] et [Your survey or confirmation table name], par les structures réelles créées à partir de l’export. Associez les colonnes sources aux champs logiques utilisés par la requête. Conservez les horodatages sources et normalisez-les dans un même fuseau horaire, de préférence UTC.
Configurez le traitement incrémentiel à l’aide de [Last successful export timestamp] ou de l’horodatage de livraison du fichier exporté. Prévoyez une période de chevauchement suffisante, par exemple de 24 à 48 heures, pour inclure les historiques reçus tardivement et les corrections. Éliminez les doublons à l’aide de ServiceRequestId, ActivityName, EventTime et d’un identifiant d’événement source stable, s’il existe. Ne dédupliquez pas uniquement par ServiceRequestId, car une demande doit produire plusieurs lignes d’événement.
Exécutez la transformation SQL complète. La requête crée explicitement des lignes pour les 15 activités requises, y compris les activités déduites telles que le triage, la réaffectation, le dépassement SLA, la confirmation du demandeur et la clôture. Si l’export ne fournit pas de preuve historique pour une activité, celle-ci ne peut pas être produite de manière fiable et doit être signalée comme une lacune des données sources.
Vérifiez le nombre de lignes, la couverture des activités, les horodatages, les identifiants et le renseignement des attributs à l’aide des contrôles ci-dessous. Confirmez que chaque ServiceRequestId peut comporter plusieurs événements ordonnés et que EventTime est renseigné pour chaque ligne produite.
Exportez le résultat de la requête dans un fichier CSV UTF-8 contenant les colonnes requises : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status et ServiceType. Importez le journal d’événements obtenu dans ProcessMind, puis associez ServiceRequestId à l’identifiant du cas, ActivityName à l’activité et EventTime à l’horodatage de l’événement. Selon la configuration d’importation de ProcessMind, conservez SourceSystem et LastDataUpdate comme attributs d’événement ou métadonnées.

Configuration

Source de l’export : sélectionnez le jeu de données Freshservice des demandes de service ou des tickets et, si disponibles, les jeux de données associés à l’historique, aux conversations, aux SLA, aux approbations et aux enquêtes. Un export des tickets dans leur seul état actuel ne suffit pas à reconstituer toutes les activités demandées.
Planification : programmez des exports récurrents selon le cycle de reporting opérationnel. Pour le premier chargement, utilisez une période de trois à six mois. Pour les chargements incrémentiels, prévoyez un chevauchement afin de récupérer les mises à jour reçues tardivement.
Preuves requises dans les données sources : vérifiez que l’export contient un identifiant de demande de service stable, les horodatages des événements ou des mises à jour, l’historique des états, des priorités et des affectations, l’historique des groupes, les notes ou conversations, les échéances et les informations de réalisation des SLA, les horodatages de résolution et de clôture, ainsi que, si disponibles, les preuves de confirmation du demandeur.
Filtres : n’appliquez [Company or service filter based on your system] que si nécessaire. Évitez les filtres d’état trop restrictifs, car ils peuvent exclure les enregistrements rouverts, résolus, clôturés, en attente, transmis à un fournisseur, soumis à approbation ou historiques.
Stockage cloud : configurez le compartiment ou le conteneur approuvé, le chemin, le chiffrement, la durée de conservation et les règles d’accès. Utilisez un rôle géré ou un mécanisme de gestion des secrets pris en charge par l’environnement, plutôt que d’inscrire les identifiants dans des fichiers SQL ou CSV.
Gestion des fichiers : conservez les fichiers CSV d’origine, les horodatages des exports, la version du schéma et les métadonnées de livraison. Si Freshservice répartit les exports volumineux dans plusieurs fichiers, traitez tous les fichiers d’une même exécution.
Fuseaux horaires : consignez le fuseau horaire source et normalisez EventTime en UTC. Conservez l’horodatage d’origine si la traçabilité est nécessaire.
Performances : répartissez le traitement par date d’export, date d’événement ou ServiceRequestId lorsque cela est possible. Préparez les fichiers bruts avant leur transformation, évitez de parcourir plusieurs fois l’historique complet et utilisez des chargements incrémentiels avec une période de chevauchement maîtrisée.
Autorisations et licences : l’accès administrateur, l’autorisation de configurer les exports planifiés, l’autorisation de lire les données Freshservice sélectionnées, l’accès en écriture au stockage cloud et toute fonctionnalité ou licence d’abonnement nécessaire à la livraison des exports planifiés sont des prérequis.
Qualité des données : ne déduisez pas d’événements à partir de la seule valeur actuelle lorsqu’aucune preuve historique n’est disponible. Par exemple, une priorité actuelle ne permet de produire l’activité Request Prioritized que si un horodatage d’affectation de priorité ou un enregistrement historique existe.
Association des sources : remplacez chaque référence entre crochets aux objets et aux colonnes sources dans la requête par les noms réels figurant dans l’export reçu. Les noms des colonnes logiques de sortie doivent rester inchangés pour l’association dans ProcessMind.

Exemple de requête sql

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

Prêt à commencer ?

Préparez vos données pour faire le premier pas vers l’optimisation de votre processus de gestion des demandes de service. Nous sommes là pour vous aider à améliorer la prestation de vos services.

Retour au guide d’amélioration

Télécharger le modèle

Améliorez dès aujourd’hui l’efficacité de la gestion des demandes de service dans Freshservice

Réduisez les délais de traitement et la frustration des utilisateurs, et atteignez 70 % d’automatisation.

Démarrez votre essai gratuit

Aucune carte bancaire n’est requise. La configuration ne prend que quelques minutes.

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 la gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Export des données du module Analytics de Freshservice

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST de Freshservice

Étapes

Configuration

Exemple de requête python

Export planifié des données Freshservice vers un stockage cloud

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Améliorez dès aujourd’hui l’efficacité de la gestion des demandes de service dans Freshservice

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 la gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Export des données du module Analytics de Freshservice

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST de Freshservice

Étapes

Configuration

Exemple de requête python

Export planifié des données Freshservice vers un stockage cloud

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Améliorez dès aujourd’hui l’efficacité de la gestion des demandes de service dans Freshservice

Prêt à commencer ?