> 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 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 fournit un guide complet pour collecter les données nécessaires à l’analyse de votre processus de gestion des demandes de service. Il présente 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 constituer un journal d’événements fiable et réaliser une analyse approfondie du processus.

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

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

Télécharger le modèle

Attributs de la gestion des demandes de service

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète 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 auquel l'activité s'est produite.
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 fondamental pour ordonner correctement les événements et calculer les durées qui les séparent. Dans le Process Mining, cet attribut sert à ordonner les activités de chaque dossier 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 précis sont essentiels pour identifier les goulots d'étranglement et comprendre la performance du processus. Pourquoi c’est important Cet horodatage ordonne les événements chronologiquement et constitue la base de toute analyse de performance, notamment du temps de cycle et de la détection des goulots d'étranglement. Où les obtenir 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 demande de service ServiceRequestId	Identifiant unique de chaque demande de service.
Description L'identifiant 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 l'ensemble du cycle de vie de la demande, de sa création à sa clôture. Dans le Process Mining, cet identifiant constitue le Case ID. Tous les événements associés, tels que les changements de statut, les affectations d'agents et les notes, sont reliés au moyen de cet identifiant. L'analyse du parcours de chaque identifiant de demande de service permet de visualiser le processus de bout en bout, d'identifier les chemins fréquents et de détecter les écarts ou les goulots d'étranglement qui affectent certains dossiers. Pourquoi c’est important Il s'agit du Case ID essentiel qui relie tous les événements associés et permet de retracer le parcours de bout en bout d'une seule demande de service. Où les obtenir Il s'agit d'un champ principal de l'objet ticket dans Freshservice. Il est visible dans l'interface utilisateur 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 pour 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 système, des changements de statut ou d'actions précises effectuées par les utilisateurs, telles que « Request Assigned to Agent », « Note Added » ou « Service Request Resolved ». Cet attribut est essentiel à la construction de la cartographie du 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 la durée des activités et détecter les variantes de processus non conformes ou inefficaces. Pourquoi c’est important Cet attribut définit les étapes de la carte de processus et permet de visualiser et d’analyser le flux de travail des demandes de service. Où les obtenir Généré à partir des « activities » ou des « audits » associés à un ticket dans Freshservice. Cela nécessite souvent une logique de transformation pour faire correspondre les événements système à des noms d'activités compréhensibles pour 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 auxquelles le jeu de données a été extrait ou mis à jour pour la dernière fois depuis Freshservice. Il renseigne sur l'actualité des données analysées. Pour toute analyse de processus, il est essentiel de connaître la fraîcheur des données. Cet horodatage aide les utilisateurs à déterminer s'ils consultent les informations les plus récentes, ce qui est indispensable pour prendre des décisions opérationnelles en temps utile et faire confiance aux résultats de l'analyse. Pourquoi c’est important Informe les utilisateurs de l'actualité des données et garantit que les analyses et les décisions reposent sur des informations à jour. Où les obtenir Cette valeur est générée et apposée sur le jeu de données lors du processus d'extraction et de transformation des données (ETL). 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 précise le système d'origine des données du processus, qui est ici Freshservice. Il est particulièrement utile lorsque les données de plusieurs systèmes sont regroupées afin d'obtenir une vue globale du processus. Même s'il peut sembler redondant dans le cadre d'une analyse portant sur un seul système, il est recommandé d'inclure cet attribut pour faciliter l'évolution future et la gouvernance des données. Il garantit la traçabilité de l'origine des données et contribue à la gestion des pipelines d'intégration. Pourquoi c’est important Garantit la traçabilité et la provenance des données, ce qui est essentiel lorsque des données provenant de plusieurs systèmes sont combinées ou dans le cadre de la gouvernance des données. Où les 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 affecté AssignedAgent	Nom de l'agent actuellement affecté à la demande de service.
Description Cet attribut identifie l'agent de support chargé de traiter la demande de service à un moment donné. Les affectations d'agents peuvent évoluer au cours du cycle de vie d'une demande. L'analyse de l'agent affecté est essentielle pour comprendre la performance des agents et la répartition de la charge de travail. Elle permet de calculer des KPI tels que le temps moyen de résolution par agent, le nombre de demandes actives et le taux de réaffectation. Elle aide à identifier les agents les plus performants, ceux qui pourraient avoir besoin d'une formation complémentaire et les déséquilibres dans la répartition de la charge. Pourquoi c’est important Permet d'analyser la charge de travail et la performance des agents, ainsi que l'incidence des réaffectations sur les délais de résolution. Où les obtenir Disponible dans le champ « agent » ou « responder » de l'objet ticket dans Freshservice. Exemples Alice JohnsonRobert SmithNon attribué
	Équipe affectée AssignedTeam	Équipe ou groupe de support chargé de traiter la demande de service.
Description Cet attribut indique le groupe fonctionnel ou l'équipe, par exemple « IT Support Level 2 » ou « Hardware Procurement », responsable 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 aide à comprendre la performance et la charge de travail au niveau de l'équipe, ainsi qu'à identifier les goulots d'étranglement propres à certaines fonctions. Elle est essentielle pour évaluer l'efficacité avec laquelle les différentes équipes traitent les demandes et optimiser l'affectation des ressources au sein de l'organisation de support. Pourquoi c’est important Permet d'analyser la performance et la charge de travail au niveau d'une équipe ou d'un groupe, ce qui est essentiel à la gestion des ressources et à l'identification des goulots d'étranglement fonctionnels. Où les obtenir Disponible dans le champ « group » de l'objet ticket dans Freshservice. Exemples Centre de servicesOpérations réseauSupport applicatif
	Priorité Priority	Niveau de priorité de la demande de service, par exemple Low, Medium, High ou Urgent.
Description La priorité indique l'importance et l'urgence d'une demande de service. Elle détermine souvent le délai de résolution cible et les ressources affectées. Elle peut être définie automatiquement selon des règles ou manuellement par les agents. Dans le Process Mining, la priorité constitue une dimension importante de l'analyse. Elle sert à segmenter les demandes afin de comparer les flux et la performance des processus pour les éléments hautement prioritaires et ceux qui le sont moins. Cette analyse est essentielle pour évaluer le respect des SLA et déterminer si la priorisation intervient efficacement et rapidement au stade du triage. Pourquoi c’est important Essentiel à l'analyse du respect des SLA et à la compréhension de la manière dont les demandes sont triées et traitées en fonction de leur impact métier. Où les obtenir Disponible dans le champ « priority » de l'objet ticket dans Freshservice. Exemples FaibleMoyenneÉlevéeUrgente
	Statut Status	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 « Open », « Pending », « Resolved » ou « Closed ». Les changements de statut constituent souvent la principale source d'activités pour le Process Mining. L'analyse du statut fournit le contexte du flux du processus et aide à comprendre le temps passé par les demandes dans certains états. Par exemple, une longue durée au statut « Pending » peut indiquer un goulot d'étranglement lié à l'attente d'informations du demandeur ou d'un fournisseur externe. Il s'agit d'un attribut essentiel pour définir les points de début et de fin des différentes étapes du processus. Pourquoi c’est important Fournit un contexte important pour chaque événement et aide à mesurer le temps passé dans différents états, tels que « Open » ou « Pending », afin d'identifier les retards. Où les obtenir Disponible dans le champ « status » de l'objet ticket dans Freshservice. Exemples OuvertEn attenteRésoluClôturé
	Type de service ServiceType	Type ou catégorie précise du service demandé.
Description Le type de service catégorise la demande selon la nature du service nécessaire, par exemple « New Hardware Request », « Software Access » ou « Password Reset ». Il est souvent associé à 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 la performance selon les différents types de services. Il est essentiel au calcul de KPI tels que « Average Activity Count per Service Type », qui aide à identifier les services les plus complexes ou les plus consommateurs de ressources. Cette analyse peut orienter les efforts de simplification et d'automatisation pour certains types de services. Pourquoi c’est important Permet de comparer les flux et la complexité des processus entre différentes catégories de demandes, afin d'identifier les possibilités de standardisation ou d'automatisation. Où les obtenir Correspond souvent au champ « category », « item » ou à un champ personnalisé de l'objet ticket dans Freshservice, selon la configuration. Exemples Intégration d'un nouvel employéDemande de licence logicielleAccès VPN
	Canal Channel	Méthode ou canal par lequel la demande de service a été envoyée.
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 chat. Ces informations permettent de comprendre les préférences des utilisateurs et l'efficacité des canaux. L'analyse du processus par canal peut révéler des éléments importants. Par exemple, les demandes envoyées via le portail peuvent être plus complètes et résolues plus rapidement que celles envoyées par e-mail, qui peuvent nécessiter davantage d'échanges. Cette analyse peut guider les initiatives visant à promouvoir les canaux les plus efficaces. Pourquoi c’est important Aide à déterminer si le canal d'envoi a une incidence sur l'efficacité du processus, le délai de résolution ou le volume de reprises nécessaires. Où les obtenir Disponible dans le champ « source » de l'objet ticket dans Freshservice. Exemples E-mailPortailTéléphoneChat
	Date d’échéance du SLA SlaDueDate	Horodatage avant lequel la demande de service doit être résolue conformément à son SLA.
Description Cet attribut indique la date limite de résolution de la demande de service, telle qu’elle est définie par la politique de SLA applicable. Il s’agit d’un horodatage calculé à partir de l’heure de création de la demande, de sa priorité et des heures ouvrées définies dans le SLA. Cette donnée est essentielle pour suivre les performances en temps réel et analyser a posteriori la conformité aux SLA. En comparant l’heure réelle de résolution à SlaDueDate, il est possible de déterminer si le SLA a été « respecté » ou « dépassé ». Elle constitue la base du calcul du KPI de taux de conformité aux SLA. Pourquoi c’est important Il s’agit de la date limite cible de résolution, qui sert de base pour déterminer si une demande de service a respecté ou dépassé son SLA. Où les obtenir Il s’agit d’un champ calculé dans Freshservice, visible sur le ticket sous l’intitulé « Due by ». Il est accessible via l’API. Exemples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	Demandeur Requestor	Utilisateur qui a envoyé la demande de service.
Description Cet attribut identifie la personne, généralement un salarié, à l'origine de la demande de service. Il fournit un contexte sur les utilisateurs du centre de services et sur leurs besoins. Même s'il ne constitue pas toujours une dimension principale de l'analyse des flux de processus, l'analyse par demandeur ou par service associé peut révéler certains schémas. Elle peut par exemple montrer qu'un service donné envoie fréquemment des demandes incomplètes, ce qui indique un besoin de formation ciblée. Elle est également essentielle à toute analyse centrée sur l'expérience client. Pourquoi c’est important Fournit un contexte sur l'utilisateur à l'origine de la demande et permet d'analyser les tendances par personne, service ou emplacement. Où les obtenir Disponible dans le champ « requester » de l'objet ticket dans Freshservice. Exemples John DoeJane SmithCompte de service
	Heure de fin EndTime	Horodatage précis auquel l’activité a été terminée.
Description L’heure de fin correspond à l’horodatage d’achèvement d’une activité. Pour de nombreux événements dans Freshservice, les heures de début et de fin sont identiques, car il s’agit 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 indispensable pour calculer la durée des activités et les temps d’attente entre celles-ci. En soustrayant StartTime de EndTime, il est possible de déterminer le temps de traitement d’une tâche donnée. Cette information permet d’identifier les activités les plus chronophages et celles qui doivent être optimisées en priorité. Pourquoi c’est important Permet de calculer la durée des activités, une mesure fondamentale pour identifier les goulots d’étranglement et évaluer les temps de traitement de chaque étape. Où les obtenir Ce champ n’est pas directement présent dans les journaux Freshservice. Il doit être calculé à partir de l’horodatage de l’événement suivant dans la séquence d’une demande de service donnée. Exemples 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Nom de la politique de SLA SlaPolicyName	Nom de la politique d'accord de niveau de service (SLA) appliquée à la demande.
Description Cet attribut identifie la politique de SLA qui régit les délais cibles de réponse et de résolution de la demande de service. Les politiques reposent généralement sur des facteurs tels que la priorité, le type de service ou le groupe de demandeurs. Il est essentiel de connaître la politique de SLA appliquée pour le Dashboard SLA Compliance & Breach Analysis. Cela permet de mesurer précisément la performance par rapport aux objectifs définis et d'analyser les politiques qui font le plus souvent l'objet d'un dépassement. Ces résultats peuvent conduire à réexaminer la performance du processus ou la faisabilité des objectifs de SLA eux-mêmes. Pourquoi c’est important Identifie les objectifs de service précis auxquels la demande est comparée, ce qui est essentiel pour produire des rapports fiables sur le respect des SLA. Où les obtenir Ces informations font partie des données de SLA associées à un ticket. Leur récupération peut nécessiter l'interrogation de points de terminaison ou de champs d'API spécifiques liés aux SLA. Exemples Incidents hautement prioritaires, 4 hDemandes standard, 3 joursSupport VIP, 1 h
	Nombre de réaffectations ReassignmentCount	Nombre total de fois où une demande de service a été réaffectée à un autre agent ou à une autre équipe.
Description Cet attribut calculé compte les occurrences de « Request Reassigned » ou d’activités similaires pour chaque demande de service. Un nombre élevé de réaffectations révèle souvent des problèmes lors du triage initial, un routage fondé sur les compétences inadapté ou un déséquilibre de la charge de travail. Cet attribut alimente directement le Dashboard « Performance des agents et répartition de la charge » ainsi que le KPI « Nombre moyen de réaffectations par demande et par agent ». L’analyse de cette mesure aide les organisations à repérer les faiblesses du processus qui entraînent la circulation répétée des tickets, allongeant ainsi le délai de résolution et suscitant la frustration des agents comme des demandeurs. Pourquoi c’est important Mesure les inefficacités du routage et les points de friction du processus. Un nombre élevé indique des problèmes lors du triage initial ou dans la répartition de la charge entre les agents, ce qui entraîne des retards. Où les obtenir Ce champ est calculé en comptant les activités correspondant à des changements d’affectation pour chaque « ServiceRequestId » lors de la transformation des données. Exemples 013
	Retraitement IsRework	Indicateur booléen précisant si la demande comporte des activités de retraitement.
Description Cet indicateur calculé prend la valeur true lorsqu’une demande de service comporte certaines activités révélatrices d’un retraitement. Il peut notamment s’agir de la réouverture après résolution (« Service Request Reopened »), de réaffectations multiples ou de demandes répétées d’informations auprès de l’utilisateur (« Information Requested from Requestor »). Cet attribut simplifie l’analyse des inefficacités du processus. Il permet de filtrer facilement les cas comportant un retraitement et de comparer leur cartographie des processus et leur durée de cycle à celles des cas « propres ». Il alimente directement le Dashboard « Analyse des retraitements des demandes de service » et aide à mesurer l’impact des transferts inefficaces ou d’informations initiales incomplètes. Pourquoi c’est important Permet de repérer et d’analyser simplement les cas comportant des boucles inefficaces ou des étapes répétées, afin de mesurer le coût de la non-qualité. Où les obtenir Calculé lors de la transformation des données en appliquant des règles métier à la séquence des activités de chaque « ServiceRequestId ». Exemples truefalse
	Service du demandeur RequestorDepartment	Service auquel appartient le demandeur.
Description Cet attribut précise le service de l'organisation auquel appartient l'utilisateur ayant envoyé la demande de service, par exemple « Sales », « Finance » ou « Human Resources ». Ces informations proviennent généralement du profil de l'utilisateur dans le système. L'analyse de la performance du processus par service est une exigence courante. Elle peut mettre en évidence des délais de résolution plus longs ou des besoins spécifiques dans certains services. Ces résultats peuvent orienter l'affectation des ressources, les initiatives de formation ou la création d'offres de services adaptées à chaque service. Pourquoi c’est important Permet de segmenter le processus par unité opérationnelle et d'identifier les problèmes ou les écarts de performance propres à chaque service. Où les obtenir Ces informations sont associées au profil du demandeur. Elles peuvent figurer dans un 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é est un indicateur simple, vrai ou faux, qui précise si la demande de service a été clôturée après la date d’échéance de son SLA. Il est obtenu en comparant l’horodatage « Service Request Closed » ou « Service Request Resolved » à « 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 afin de calculer le KPI global de taux de conformité aux SLA. Le regroupement selon cet indicateur permet d’isoler rapidement les demandes ayant dépassé leur SLA et de comparer leurs caractéristiques de processus à celles des demandes résolues dans les délais. 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 respecté leurs objectifs. Où les obtenir Il s’agit d’un champ calculé lors de la transformation des données, en comparant l’horodatage final de résolution au champ « SlaDueDate ». Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir et analyser correctement vos flux de travail 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 précis pour traitement. Il s'agit d'une étape importante, déduite du suivi des modifications des champs « Assigned Agent » ou « Owner » du ticket.
Pourquoi c’est important Cette activité est essentielle pour analyser la charge de travail des agents et identifier les goulots d'étranglement du processus d'affectation. Le temps écoulé entre la création et l'affectation constitue un indicateur clé de performance. Où les obtenir Déduit du journal d'activité ou de la piste d'audit des champs du ticket, en surveillant les modifications des champs « Agent » ou « Assignee ». Collecte Capturez l'horodatage auquel le champ « Assigned Agent » est renseigné ou auquel sa valeur est modifiée. 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 intervient généralement automatiquement après une durée définie à l'état « Resolved », si la demande n'est pas rouverte.
Pourquoi c’est important Cet événement marque la fin définitive de l'instance du processus. Le temps écoulé entre « Resolved » et « Closed » représente la période de confirmation accordée au demandeur. Où les obtenir Déduit de l'historique des changements de statut du ticket. Il correspond à l'horodatage auquel le statut passe à « Closed ». Collecte Capturez l'horodatage auquel le statut du ticket passe à « Closed ». 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. Cet événement est explicitement capturé lorsqu'un nouvel enregistrement de ticket est créé, via le catalogue de services, un e-mail ou un autre canal, et qu'un identifiant unique de demande de service est attribué.
Pourquoi c’est important Il s'agit de l'événement de début principal du processus. L'analyse du temps écoulé entre cette activité et les suivantes est fondamentale pour mesurer les temps de cycle globaux et identifier les premiers retards de traitement. Où les obtenir Cet événement est explicitement enregistré dans Freshservice. Il figure dans le journal d'activité ou la piste d'audit du ticket et correspond généralement à l'horodatage de création du ticket. Collecte 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 traitement comme terminé. Elle est déduite du changement de statut du ticket vers « Resolved ».
Pourquoi c’est important Cette activité marque la fin de la phase de traitement actif. La durée jusqu'à ce moment constitue une mesure importante de l'efficacité de l'agent et du processus, et sert de base aux calculs de SLA. Où les obtenir Déduit de l'historique des changements de statut du ticket. Il correspond à l'horodatage auquel le statut a été défini pour la première fois sur « Resolved ». Collecte Capturez l'horodatage auquel le statut du ticket passe pour la première fois à « Resolved ». Type d’événement inferred
	Fournisseur externe sollicité	Cette activité marque le transfert d'un ticket à un fournisseur externe ou à un tiers pour résolution. Elle est déduite d'un changement de statut vers un état précis tel que « Pending Vendor » ou « Awaiting Third Party ».
Pourquoi c’est important Le recours à un fournisseur peut entraîner des retards importants. Le suivi de cette activité est essentiel pour mesurer la performance du fournisseur et son incidence sur le temps de cycle global des demandes de service. Où les obtenir Déduit de l'historique des changements de statut du ticket. Recherchez un statut spécifiquement configuré pour suivre la dépendance à l'égard de fournisseurs externes. Collecte Détectez le moment où le champ de statut du ticket prend une valeur indiquant l'attente d'un tiers. Type d’événement inferred
	Objectif de SLA dépassé	Événement calculé qui se produit lorsque le délai de résolution d'une demande de service dépasse l'objectif défini dans son accord de niveau de service (SLA). Il ne s'agit pas d'un événement système direct, mais d'un événement déduit de la comparaison entre le délai de résolution et la date d'échéance du SLA.
Pourquoi c’est important Cet indicateur mesure directement la performance du service par rapport aux engagements et constitue un KPI important pour la direction. Il aide à identifier les types de demandes ou les niveaux de priorité les plus susceptibles de ne pas respecter les objectifs. Où les obtenir Calculé en comparant l'horodatage « Resolved » à l'horodatage « SLA Due By ». Si la résolution intervient plus tard, cet événement est déclenché. Collecte 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	Cette situation intervient lorsque le demandeur indique qu'un problème persiste après que la demande a été marquée comme « Resolved », ce qui fait repasser le ticket à l'état ouvert. Elle est déduite d'un changement de statut de « Resolved » vers « Open » ou « In Progress ».
Pourquoi c’est important Les demandes rouvertes sont un indicateur fort d'un faible taux de résolution au premier contact et de l'insatisfaction des clients. Le suivi de cette boucle de reprise est essentiel pour améliorer la qualité des solutions. Où les obtenir Déduit de l'historique des changements de statut du ticket dans le journal d'activité. Il s'agit d'une transition directe du statut « Resolved » vers « Open ». Collecte Détectez un changement de statut d'un état résolu vers un état ouvert. Type d’événement inferred
	Demande priorisée	Cette activité intervient lorsqu'un niveau de priorité, tel que Low, Medium ou High, est attribué à la demande de service. Elle est déduite de la détection d'une modification du champ « Priority » dans l'historique du ticket.
Pourquoi c’est important La priorisation est essentielle à l'affectation des ressources et au respect des objectifs de SLA. L'analyse de cette activité permet de vérifier que les demandes sont évaluées correctement et dans les délais. Où les obtenir Déduit de l'historique des modifications de champs du ticket dans Freshservice. Recherchez les mises à jour du champ « Priority » et capturez l'horodatage de la modification. Collecte Détectez une modification du champ « Priority » depuis une valeur nulle ou sa valeur précédente, puis enregistrez l'horodatage. Type d’événement inferred
	Demande réaffectée	Cette activité capture toute modification de l'agent ou du groupe affecté après l'affectation initiale. Elle est déduite de la détection de mises à jour ultérieures des champs « Assigned Agent » ou « Assigned Group ».
Pourquoi c’est important Des réaffectations fréquentes peuvent révéler des problèmes au niveau du triage initial, de l'adéquation entre les compétences et les demandes ou de l'équilibrage de la charge de travail. Cette activité est essentielle au KPI Agent Reassignment Count et à l'analyse des reprises. Où les obtenir Déduit de l'historique des modifications de champs du ticket. Cet événement est enregistré chaque fois que le champ « Assigned Agent » ou « Assigned Group » est mis à jour après la définition de sa valeur initiale. Collecte Détectez toute modification du champ « Assigned Agent » ou « Assigned Group » après la première affectation. Type d’événement inferred
	Demande triée	Représente l'évaluation et la catégorisation initiales d'une demande de service nouvellement créée. Cette activité est généralement déduite du premier paramétrage d'une priorité ou de l'affectation de la demande à un groupe, ce qui indique qu'elle a été examinée et qu'elle entre dans la file d'attente.
Pourquoi c’est important Le suivi du triage permet de mesurer l'efficacité de l'équipe chargée de la première réponse. Les retards à cette étape peuvent avoir une incidence importante sur les délais globaux de résolution et le respect des SLA. Où les obtenir Déduit du journal d'activité. Il peut être identifié à partir de l'horodatage du premier événement « Priority Set » ou « Group Assigned » survenant après la création. Collecte Identifiez l'horodatage le plus ancien correspondant soit à une modification du champ de priorité, soit à une modification du champ du groupe d'affectation. Type d’événement inferred
	Examen interne effectué	Indique qu'une solution proposée ou l'exécution d'une demande nécessite un examen ou une approbation interne avant de poursuivre. Cette situation est déduite d'un changement de statut vers un état tel que « Pending Approval » ou « Internal Review ».
Pourquoi c’est important Les contrôles internes peuvent être à l’origine de goulots d’étranglement, en particulier pour les demandes de service complexes ou à fort impact. Mesurer cette durée permet de simplifier les flux de travail d’approbation. Où les obtenir Déduit de l’historique des changements d’état du ticket. Cette méthode nécessite l’utilisation, dans le flux de travail, d’un état précis tel que « En attente d’approbation interne ». Collecte Détectez le moment où le champ de statut du ticket prend une valeur indiquant un examen ou une approbation interne. Type d’événement inferred
	Informations demandées au demandeur	Représente le moment où l'agent affecté a besoin d'informations supplémentaires de la part du demandeur et interrompt l'avancement du traitement. Cette situation est déduite d'un changement de statut du ticket vers « Pending » ou « Awaiting Customer ».
Pourquoi c’est important Cette activité met en évidence une source fréquente de retard et de reprise. L'analyse de sa fréquence permet d'identifier des possibilités d'amélioration des modèles de demande et de la collecte initiale des informations. Où les obtenir Déduit de l'historique des changements de statut du ticket. Recherchez un changement vers un statut tel que « Pending Customer Response » ou « Awaiting Information ». Collecte Détectez le moment où le champ de statut du ticket prend une valeur indiquant l'attente d'une réponse de l'utilisateur. Type d’événement inferred
	Informations fournies par le demandeur	Cette activité intervient lorsque le demandeur fournit les informations nécessaires, permettant à l'agent de reprendre le traitement. Elle est généralement déduite lorsque le statut du ticket passe automatiquement de « Pending » à « Open ».
Pourquoi c’est important Cette activité clôt le cycle des demandes d'informations. La durée entre la demande et la fourniture des informations constitue un temps d'attente important à analyser et à optimiser. Où les obtenir Déduit d'un changement de statut de « Pending » vers « Open » ou « In Progress », souvent déclenché par une réponse du demandeur. Collecte Détectez le moment où le statut du ticket passe d'un état d'attente à l'é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é du ticket.
Pourquoi c’est important L'analyse de la fréquence et du moment d'ajout des notes peut révéler les modes de communication, l'efficacité de la collaboration et les points de confusion dans le processus. Où les obtenir Explicitement enregistré dans l'historique des conversations du ticket dans Freshservice. Chaque note comporte un horodatage et un auteur. Collecte Extrayez chaque entrée du journal des conversations ou des commentaires du ticket. Type d’événement explicit
	Résolution confirmée par le demandeur	Cette activité représente la confirmation explicite du demandeur que la solution fournie est satisfaisante. 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 c’est 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ù les obtenir Cette information est difficile à capturer directement et peut nécessiter une configuration personnalisée. Elle peut être déduite d'une réponse à une enquête de satisfaction associée au ticket ou de l'application d'une étiquette spécifique. Collecte Nécessite l'analyse de données associées, telles que les enquêtes de satisfaction ou les étiquettes appliquées après la résolution. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment obtenir vos données depuis Freshservice

Étapes

Vérifier les prérequis : assurez-vous de disposer, dans Freshservice, d’un rôle utilisateur autorisé à accéder au module Analytics et à y créer des rapports. Cela nécessite généralement un forfait Pro ou Enterprise.
Configurer les automatisations, si nécessaire : pour capturer correctement les événements, vérifiez ou créez deux automatisations spécifiques dans Freshservice, sous Admin -> Workflow Automator. La première doit ajouter une note privée ou une balise spécifique, par exemple « SLA_Breached », à un ticket lorsque le délai de résolution de son SLA expire. La seconde doit ajouter 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 « Creation Events » : accédez à l’onglet Analytics de Freshservice. Créez un rapport et sélectionnez le module « Tickets » comme source de données. Ce rapport enregistrera le premier événement de chaque demande de service.
Configurer les widgets du rapport « Creation Events » : ajoutez un widget « Data Table ». Configurez les colonnes, ou mesures, suivantes : Ticket ID, Created at, Assigned to, Group, Priority, Status et Category. Appliquez un filtre sur la période de création souhaitée, par exemple les six derniers mois.
Exporter les données de « Creation Events » : exécutez le rapport et exportez le widget Data Table dans un fichier CSV. Nommez-le « creation_events.csv ».
Créer le rapport « Update Events » : créez un second rapport en sélectionnant cette fois le module « Ticket Activities » comme source de données. Ce rapport capture toutes les modifications et notes ultérieures de chaque demande de service.
Configurer les widgets du rapport « Update Events » : ajoutez un widget « Data Table ». Configurez les colonnes suivantes : Ticket ID, Activity Date, Performed by, Activity Type et, dans « Changes », Field, Old Value et New Value. Ajoutez également les attributs au niveau du ticket, tels que Group, Assigned to, Priority, Status et Category, afin de fournir le contexte de chaque événement.
Filtrer le rapport « Update Events » : appliquez à « Activity Date » le même filtre de période que celui utilisé pour le rapport de création. Filtrez ensuite « Activity Type » afin de ne conserver que les événements pertinents, tels que « Status changed », « Priority changed », « Group changed », « Agent changed », « Private Note added » et « Public Note added ».
Exporter les données de « Update Events » : exécutez le rapport et exportez le widget Data Table dans un fichier CSV. Nommez-le « update_events.csv ».
Combiner et transformer 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 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 combiné « event_log.csv », créez les nouvelles colonnes suivantes : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status et ServiceType. Renseignez-les selon 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.
Export final : enregistrez le fichier « event_log.csv » transformé. Vérifiez que le format des dates de EventTime et LastDataUpdate est standard, par exemple ISO 8601. Le fichier est désormais prêt à être importé dans un outil de Process Mining.

Configuration

Forfait Freshservice : Un forfait incluant le module Analytics, généralement Pro ou Entreprise, est requis.
Autorisations utilisateur : L’utilisateur qui effectue l’export doit être autorisé à 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 volume de données gérable. Appliquez un filtre de période cohérent fondé 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 » = « Service Request » afin d’isoler le processus approprié. Pour le rapport « Ticket Activities », filtrez « Activity Type » afin de ne conserver que les modifications pertinentes, notamment l’état, la priorité, l’affectation et les 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 préexistantes de l’Automator de flux de travail qui ajoutent une note ou une étiquette au ticket lors de ces événements. Sans ces règles, ces activités ne peuvent pas être capturées avec cette méthode.

a 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.
Obtenir la 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 volet de droite. Copiez-la et conservez-la en lieu sûr.
Enregistrer le script : enregistrez le code Python fourni dans un fichier nommé extract_freshservice_srm.py sur votre ordinateur local.
Configurer 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 d’exemple de FRESHSERVICE_DOMAIN, API_KEY, START_DATE et END_DATE. Adaptez le dictionnaire STATUS_MAPPING si votre instance utilise d’autres identifiants numériques pour les statuts personnalisés.
Installer les bibliothèques : si les bibliothèques requises ne sont pas installées, ouvrez votre ligne de commande ou votre terminal et exécutez : pip install requests pandas.
Exécuter le script : accédez au répertoire dans lequel vous avez enregistré le script depuis votre ligne de commande ou votre terminal. Lancez-le avec la commande : python extract_freshservice_srm.py.
Suivre l’exécution : le script affiche l’avancement 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érer le journal d’événements : une fois le script exécuté avec succès, il crée un fichier nommé freshservice_event_log.csv dans le même répertoire. Ce fichier contient le journal d’événements extrait.
Préparer l’importation : le fichier CSV généré comporte les colonnes requises (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) et est prêt à être importé dans ProcessMind. Aucune autre mise en forme n’est généralement nécessaire.

Configuration

FRESHSERVICE_DOMAIN : URL Freshservice de votre organisation, par exemple yourcompany.freshservice.com.
API_KEY : clé API personnelle obtenue dans le profil utilisateur Freshservice. Elle doit rester confidentielle.
START_DATE / END_DATE : 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 de statuts personnalisés utilisés pour déduire les événements, comme « External Vendor Engaged », à leurs identifiants 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.
Limitation du débit de l’API : tenez compte des limites de débit API de votre forfait Freshservice. Le script traite les tickets séquentiellement pour les respecter, mais, pour des volumes très importants, il peut être nécessaire d’effectuer l’extraction par lots couvrant des 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.

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érifiez que votre abonnement Freshservice et vos autorisations d’administrateur incluent Scheduled Data Export ainsi que la livraison vers le fournisseur de stockage cloud sélectionné. Les intitulés des menus et les possibilités d’export peuvent varier selon le forfait et le tenant Freshservice. Consultez donc la documentation administrateur à jour et utilisez [Configure based on your system] lorsque votre tenant présente des libellés différents.
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 contenant le Service Request ID, le statut, la priorité, l’affectation, le type de service, les horodatages, les champs SLA, l’historique des conversations ou activités et les informations relatives aux réponses des demandeurs. Ne supposez pas qu’un export de tickets dans leur état actuel contient l’historique des modifications de champs.
Configurez le périmètre de l’export. Sélectionnez, pour la validation initiale, une fenêtre glissante de trois à six mois, puis choisissez une fréquence récurrente 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 identifier les changements de champs, les notes, les transitions de statut, les résultats des SLA, les approbations et les confirmations des demandeurs. N’appliquez des filtres d’entreprise ou de service que s’ils sont explicitement requis, en utilisant [Company or service filter based on your system].
Sélectionnez CSV comme format de sortie et configurez la livraison vers l’emplacement de stockage cloud approuvé, par exemple Amazon S3. Fournissez [Cloud storage connection details] et [Credentials or role configuration] via la configuration Freshservice prise en charge. Confirmez le compartiment, le chemin, le chiffrement, la durée de conservation et la politique d’accès avec le responsable de la plateforme. Évitez de placer des identifiants directement dans des scripts ou des fichiers exportés.
Exécutez un export de test et examinez les fichiers CSV livrés. Identifiez les noms réels des colonnes exportées pour le Service Request ID, le statut, la priorité, l’agent affecté, le groupe affecté, le type de service, l’heure de création, l’heure de mise à jour, l’heure de résolution, l’heure de clôture, l’heure d’échéance du SLA, l’horodatage de l’historique, le champ de l’historique, l’ancienne valeur, la nouvelle valeur, le type de note, l’auteur de la note, l’horodatage de la note et la réponse ou le résultat de l’enquête du demandeur. Si un champ source requis n’est pas disponible, documentez cette limite au lieu d’inventer un nom de champ.
Chargez les fichiers CSV dans une table de staging ou une trame de données. Remplacez les références aux sources dans la requête ci-dessous, 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éellement créées à partir de l’export. Faites correspondre 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émental à partir de [Last successful export timestamp] ou de l’horodatage de livraison du fichier d’export. Conservez une fenêtre de chevauchement suffisante, par exemple 24 à 48 heures, afin de capturer les historiques reçus tardivement et les corrections. Dédupliquez à l’aide de ServiceRequestId, ActivityName, EventTime et d’un identifiant d’événement source stable lorsqu’il est disponible. Ne dédupliquez pas uniquement selon ServiceRequestId, car une demande doit produire plusieurs lignes d’événements.
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érivées telles que le triage, la réaffectation, le dépassement du SLA, la confirmation du demandeur et la clôture. Lorsque 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.
Validez les volumes de lignes, la couverture des activités, les horodatages, les identifiants et le renseignement des attributs à l’aide des contrôles de validation ci-dessous. Vérifiez 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 au format CSV UTF-8 avec les colonnes requises ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status et ServiceType. Importez ensuite le journal d’événements dans ProcessMind, en mappant ServiceRequestId comme identifiant de cas, ActivityName comme activité et EventTime comme horodatage de l’événement. Conservez SourceSystem et LastDataUpdate comme attributs d’événement ou métadonnées, selon la configuration d’importation de ProcessMind.

Configuration

Source de l’export : sélectionnez le jeu de données des demandes de service ou des tickets Freshservice et, lorsqu’elles sont disponibles, les données d’historique, de conversation, de SLA, d’approbation et d’enquête. Un export limité à l’état actuel des tickets ne suffit pas à reconstituer toutes les activités demandées.
Planification : utilisez un export récurrent aligné sur le cycle de reporting opérationnel. Pour le premier chargement, utilisez une période de trois à six mois. Pour les chargements incrémentaux, prévoyez une fenêtre de chevauchement afin de capturer les mises à jour reçues tardivement.
Éléments sources requis : vérifiez que l’export contient un Service Request ID stable, les horodatages des événements ou mises à jour, l’historique des statuts, des priorités, des affectations et des groupes, les notes ou conversations, les informations d’échéance et d’achèvement des SLA, les horodatages de résolution et de clôture ainsi que, lorsqu’elle est disponible, la preuve de confirmation du demandeur.
Filtres : n’appliquez [Company or service filter based on your system] que lorsque cela est nécessaire. Évitez les filtres de statut restrictifs, car ils peuvent exclure les enregistrements rouverts, résolus, clôturés, en attente, liés à 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 la politique d’accès. Utilisez un rôle géré ou un mécanisme de secrets pris en charge par le tenant, plutôt que d’intégrer des identifiants dans des fichiers SQL ou CSV.
Gestion des fichiers : conservez les fichiers CSV d’origine, les horodatages d’export, 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 correspondant à la même exécution d’export.
Fuseaux horaires : consignez le fuseau horaire source et normalisez EventTime en UTC. Conservez l’horodatage d’origine lorsque la traçabilité l’exige.
Performances : partitionnez le traitement par date d’export, date d’événement ou ServiceRequestId lorsque cela est possible. Mettez les fichiers bruts en staging avant la transformation, évitez de parcourir plusieurs fois l’historique complet et utilisez des chargements incrémentaux avec un chevauchement maîtrisé.
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 ainsi que toute fonctionnalité d’abonnement ou licence requise pour la livraison des exports planifiés sont des prérequis.
Qualité des données : ne créez pas d’événements déduits à partir de la seule valeur actuelle lorsqu’aucune preuve historique n’est disponible. Par exemple, une priorité actuelle ne peut justifier l’activité Request Prioritized que si un horodatage d’affectation de la priorité ou un enregistrement historique existe.
Correspondance des sources : remplacez chaque objet source et chaque référence de colonne entre crochets dans la requête par les noms réels de l’export livré. Les noms des colonnes logiques de sortie doivent rester inchangés pour le mappage dans ProcessMind.

a 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 ?

Faites le premier pas vers l’optimisation de votre processus de gestion des demandes de service en préparant vos données. Nous sommes là pour vous accompagner dans la transformation de votre prestation de services.

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

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

Mettez fin aux traitements lents et à la frustration des utilisateurs, et atteignez 70 % d’automatisation.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en 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

a Exemple de requête sql

Script Python utilisant l’API REST Freshservice

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Améliorez dès aujourd’hui l’efficacité 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

a Exemple de requête sql

Script Python utilisant l’API REST Freshservice

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité