> Mejora continua de procesos > Gestión de incidentes > Freshservice > Template de datos

Su Template de datos para la gestión de incidencias

Freshservice

Atributos de gestión de incidencias(19) Actividades de gestión de incidencias(14) Guías de extracción(3)

Su Template de datos para la gestión de incidencias

Este Template le ayuda a preparar los datos para analizar eficazmente la gestión de incidencias. Describe los atributos esenciales que debe recopilar y las actividades clave que debe seguir, además de ofrecer orientación práctica para extraer esta información del sistema de origen. Utilice este recurso para agilizar la preparación de los datos.

Atributos recomendados para recopilar
Actividades clave que debe seguir
Guía de extracción

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos de gestión de incidencias

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar en profundidad el proceso de gestión de incidencias.

5 Obligatorio 7 Recomendado 7 Opcional

	Nombre	Descripción
	ID del incidente IncidentId	Identificador único de cada registro de incidente, que sirve como clave principal para hacer un seguimiento de todo su ciclo de vida.
Descripción El ID del incidente es la base del análisis de la gestión de incidentes. Funciona como ID del caso y vincula todas las actividades, marcas de tiempo y cambios de atributos relacionados en un único recorrido coherente. En Process Mining, cada entrada del registro de eventos se asocia a un ID del incidente, lo que permite reconstruir el flujo del proceso de principio a fin para cada incidente. Esto es esencial para calcular los tiempos de ciclo, analizar las variantes del proceso e identificar cuellos de botella en casos concretos. Sin un identificador único, sería imposible distinguir los incidentes y analizar su recorrido desde la notificación hasta la resolución. Por qué es importante Identifica de forma única cada incidente y permite hacer un seguimiento y analizar su ciclo de vida de principio a fin, desde su creación hasta el cierre. Dónde obtenerlo Es el identificador principal de un ticket y está disponible en la API de Tickets de Freshservice como el campo 'id' del objeto del ticket. Ejemplos INC-10234INC-10235INC-10236
	Marca de tiempo del evento EventTimestamp	La fecha y hora exactas en que se produjo la actividad o el evento.
Descripción La marca de tiempo del evento, o la hora de inicio, indica el momento exacto en que se realizó una actividad. Cada actividad del ciclo de vida del incidente, desde su creación hasta el cierre, tiene una marca de tiempo asociada. Este atributo es fundamental para todos los análisis de Process Mining basados en el tiempo. Se utiliza para ordenar cronológicamente los eventos, calcular la duración entre actividades, medir el tiempo de ciclo total del caso y analizar los tiempos de espera. También es la base para crear Dashboards que hagan un seguimiento del rendimiento del SLA, las demoras en los traspasos y los tiempos generales de resolución. Por qué es importante Establece el orden cronológico de los eventos, algo esencial para calcular duraciones, analizar tiempos de ciclo y comprender el rendimiento del proceso. Dónde obtenerlo Se deriva de varios campos de marca de tiempo de Freshservice, como 'created_at' y 'updated_at', y de las marcas de tiempo de la conversación o los registros de auditoría del ticket. Ejemplos 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Nombre de la actividad ActivityName	Nombre de la actividad empresarial o el evento concreto que se produjo en un momento determinado del ciclo de vida del incidente.
Descripción El nombre de la actividad describe un paso o evento del proceso de gestión de incidentes, como 'Incidente asignado a un grupo', 'Estado cambiado a pendiente' o 'Incidente resuelto'. Estas actividades se derivan de los cambios que experimentan los datos del incidente con el tiempo. Este atributo es fundamental para Process Mining, ya que define los nodos del mapa de procesos descubierto. Al analizar la secuencia y la frecuencia de estas actividades, las organizaciones pueden visualizar el proceso real de resolución de incidentes, identificar las rutas habituales, detectar desviaciones del procedimiento estándar y localizar ciclos de retrabajo, como las reasignaciones frecuentes. Por qué es importante Define los pasos del mapa de procesos y permite visualizar y analizar el flujo de resolución de incidentes, los cuellos de botella y las desviaciones. Dónde obtenerlo Este atributo no corresponde a un campo directo de Freshservice, sino que se deriva de los cambios en propiedades del ticket, como el estado, la prioridad, la asignación de agentes o grupos y la incorporación de notas. Ejemplos Incidente notificadoIncidente asignado a un grupoNota de resolución añadidaIncidente resuelto
	Sistema de origen SourceSystem	Sistema del que se extrajeron los datos, normalmente 'Freshservice'.
Descripción Este atributo identifica el origen de los datos. En este caso, siempre será 'Freshservice', pero es un campo fundamental en entornos que combinan datos de varios sistemas para obtener una visión integral del proceso. Incluir el atributo Sistema de origen es una buena práctica de gobernanza y trazabilidad de datos. Permite conocer claramente la procedencia de los datos, algo importante para validarlos, depurar problemas y ampliar en el futuro el proyecto de Process Mining a otros sistemas de gestión de servicios u operaciones. Por qué es importante Garantiza la trazabilidad y la gobernanza de los datos al identificar claramente el origen de los datos de gestión de incidentes. Dónde obtenerlo Suele ser un valor estático que se añade durante el proceso de transformación de datos (ETL) para etiquetar el conjunto de datos. Ejemplos FreshserviceFreshservice-EUFreshservice-PROD
	Última actualización de los datos LastDataUpdate	Marca de tiempo que indica la última vez que se actualizaron o extrajeron los datos de este proceso.
Descripción Este atributo indica cuándo se actualizaron por última vez todos los datos desde el sistema de origen. Es un campo de metadatos que se aplica al conjunto de datos completo, no a eventos individuales, aunque a menudo se incluye en cada evento para mantener la coherencia. En el análisis, esta información es fundamental para conocer la actualidad de los datos y el periodo que abarcan los Dashboards y los KPI. Permite confiar en que la información analizada es reciente y entender si el análisis incluye los incidentes más recientes. Por qué es importante Informa sobre la actualidad de los datos y permite conocer el periodo que abarca el análisis. Dónde obtenerlo Es una marca de tiempo de metadatos que se genera durante el proceso de extracción de datos (ETL). Ejemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Agente asignado AssignedAgent	Nombre o ID del agente de soporte asignado actualmente para resolver el incidente.
Descripción El agente asignado identifica a la persona del equipo de soporte responsable del incidente en un momento determinado. Los cambios en este atributo representan un traspaso de responsabilidad entre agentes. Este atributo es esencial para analizar el rendimiento y crear Dashboards que hagan un seguimiento de la carga de trabajo de los agentes, el tiempo medio de resolución por agente y las tasas de resolución en el primer contacto. También permite analizar los traspasos entre agentes, que pueden causar demoras e ineficiencias. Al hacer un seguimiento de las asignaciones, los responsables pueden detectar necesidades de formación y reconocer a quienes obtienen mejores resultados. Por qué es importante Permite analizar el rendimiento de los agentes, la distribución de la carga de trabajo y el efecto de los traspasos entre agentes en los tiempos de resolución. Dónde obtenerlo Está disponible en la API de Tickets de Freshservice como el campo 'responder_id'. Este ID se puede combinar con la API de Agents para obtener el nombre del agente. Ejemplos John DoeJane SmithSupportBot
	Categoría del incidente IncidentCategory	Categoría utilizada para clasificar el incidente, como hardware, software o redes.
Descripción La categoría del incidente permite clasificarlo según el tipo de problema notificado. Esta clasificación jerárquica ayuda a derivar el incidente al equipo adecuado y es fundamental para analizar tendencias. Este atributo se utiliza en el Dashboard 'Precisión de la categorización de incidentes' para analizar si una clasificación inicial incorrecta alarga los tiempos de resolución debido a las reasignaciones. Al agrupar los incidentes por categoría, las organizaciones pueden identificar problemas recurrentes, comprender dónde se concentra el esfuerzo de soporte y adaptar las iniciativas de mejora. Por qué es importante Permite analizar las tendencias de los incidentes y ayuda a determinar si una clasificación incorrecta está causando demoras en la resolución. Dónde obtenerlo Es un campo predeterminado y personalizable de Freshservice. Está disponible en la API de Tickets como 'category', junto con los campos relacionados 'sub_category' e 'item_category'. Ejemplos HardwareSoftwareProblema de redAcceso a la cuenta
	Estado del incidente IncidentStatus	Estado actual del incidente en su ciclo de vida, como abierto, pendiente, resuelto o cerrado.
Descripción El estado del incidente indica su situación actual. Los cambios de estado son eventos clave que constituyen la base del mapa de procesos descubierto, como pasar de 'In Progress' a 'Pending' o de 'Resolved' a 'Closed'. Este atributo es fundamental para comprender el recorrido del incidente. Analizar el tiempo que permanece en cada estado ayuda a identificar cuellos de botella, por ejemplo, incidentes que pasan demasiado tiempo en estado 'Pending' a la espera de la respuesta del usuario. También es esencial para definir los puntos de inicio y fin de los cálculos del tiempo de ciclo. Por qué es importante Permite hacer un seguimiento del avance del incidente durante su ciclo de vida y ayuda a identificar las etapas en las que suelen producirse demoras. Dónde obtenerlo Está disponible en la API de Tickets de Freshservice como el campo 'status'. Los valores son numéricos. Ejemplos AbiertoEn cursoPendienteResueltoCerrado
	Gravedad del incidente IncidentSeverity	Nivel de gravedad del incidente, que indica su impacto en el negocio.
Descripción La gravedad del incidente mide su impacto en el negocio y suele clasificarse como baja, media, alta o crítica. Aunque está relacionada con la prioridad, la gravedad se centra en el impacto y la prioridad, en la urgencia. La combinación de gravedad e impacto suele determinar la prioridad final. Analizar los incidentes por gravedad ayuda a comprender cómo gestiona la organización aquellos que tienen consecuencias importantes para el negocio. Se utiliza en los Dashboards para desglosar los tiempos de resolución y el rendimiento del SLA, y garantizar que los problemas de mayor impacto reciban la atención y los recursos adecuados durante todo su ciclo de vida. Por qué es importante Mide el impacto de un incidente en el negocio y permite centrar el análisis en mitigar los problemas más perjudiciales. Dónde obtenerlo Es un campo predeterminado de Freshservice, disponible en la API de Tickets como 'impact'. Los valores son numéricos. Ejemplos BajaMediaAlta
	Grupo asignado AssignedGroup	Grupo o equipo de soporte asignado actualmente al incidente.
Descripción El grupo asignado indica qué equipo, como 'Soporte de nivel 1', 'Equipo de redes' o 'Administradores de bases de datos', es responsable del incidente. Los cambios en este atributo indican una escalación o un traspaso entre equipos de distintas áreas. Analizar el grupo asignado es fundamental para comprender las demoras en los traspasos y las transferencias. Process Mining permite visualizar el flujo de incidentes entre grupos, destacar las rutas de escalación habituales y medir cuánto tiempo espera cada incidente antes de que el grupo actúe. Esto ayuda a identificar cuellos de botella organizativos y oportunidades para agilizar la colaboración entre equipos. Por qué es importante Permite hacer un seguimiento del equipo responsable, algo fundamental para analizar los traspasos, las escalaciones y las demoras entre equipos. Dónde obtenerlo Está disponible en la API de Tickets de Freshservice como el campo 'group_id'. Este ID se puede combinar con la API de Groups para obtener el nombre del grupo. Ejemplos Mesa de ayudaOperaciones de redSoporte de infraestructura
	Hora objetivo del SLA de resolución ResolutionSlaTargetTime	Fecha y hora límite en que se espera resolver el incidente según la política de SLA correspondiente.
Descripción Este atributo almacena la fecha y hora límite para resolver un incidente. El objetivo lo determina la política del acuerdo de nivel de servicio (SLA) aplicada al ticket y suele depender de factores como la prioridad. Esta hora objetivo es esencial para calcular el KPI 'Tasa de cumplimiento del SLA' y alimentar el Dashboard de Rendimiento del SLA. Al comparar la marca de tiempo real de resolución con este objetivo, podemos determinar si el incidente se resolvió a tiempo o si incumplió el SLA. Es fundamental para medir el cumplimiento de los niveles de servicio. Por qué es importante Indica la fecha y hora límite de resolución, necesarias para calcular el cumplimiento del SLA e identificar los incidentes que podrían incumplirlo. Dónde obtenerlo Está disponible en la API de Tickets de Freshservice en los campos 'fr_due_by' (primera respuesta) y 'due_by' (resolución). Ejemplos 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Prioridad del incidente IncidentPriority	Nivel de prioridad del incidente, que determina la urgencia de la respuesta y la resolución.
Descripción La prioridad del incidente es un campo clave que determina la rapidez y la atención necesarias para gestionarlo. Suele definirse en una escala como baja, media, alta y urgente, y a menudo determina los objetivos del SLA. En Process Mining, la prioridad es una dimensión fundamental para filtrar y analizar los datos. Permite comparar los procesos de resolución de incidentes de prioridad alta y baja, y comprobar si los problemas críticos se gestionan con eficiencia. Los Dashboards suelen desglosar métricas como el tiempo de ciclo y el cumplimiento del SLA por prioridad para ofrecer información útil a quienes gestionan el soporte. Por qué es importante Ayuda a centrar el análisis en los incidentes más críticos y es esencial para evaluar el rendimiento del SLA y la asignación de recursos. Dónde obtenerlo Está disponible en la API de Tickets de Freshservice como el campo 'priority'. Los valores son numéricos (por ejemplo, 1 para baja y 4 para urgente). Ejemplos BajaMediaAltaUrgente
	¿Se incumplió el SLA? IsSlaBreached	Indicador calculado que es verdadero si el incidente no se resolvió dentro del tiempo objetivo definido en el SLA.
Descripción Este atributo booleano es una métrica calculada que indica si el tiempo de resolución de un incidente superó el objetivo del SLA. Se obtiene al comparar la marca de tiempo real de resolución con 'ResolutionSlaTargetTime'. Este indicador es un dato de entrada directo para el KPI 'Tasa de cumplimiento del SLA' y el Dashboard de Rendimiento del SLA. Simplifica el análisis al ofrecer un resultado claro y binario del rendimiento del SLA para cada incidente, lo que facilita la agregación y el análisis de tendencias. Ayuda a identificar rápidamente el volumen y el porcentaje de incidentes que no cumplen los compromisos de servicio. Por qué es importante Mide directamente el cumplimiento del SLA en cada incidente, lo que facilita calcular las tasas generales de cumplimiento e identificar las áreas problemáticas. Dónde obtenerlo Es un campo calculado que se obtiene durante la transformación de datos al comparar la marca de tiempo de 'Incidente resuelto' con el campo 'ResolutionSlaTargetTime'. Ejemplos truefalse
	¿Se reabrió? IsReopened	Indicador calculado que es verdadero si un incidente se reabrió después de resolverse o cerrarse.
Descripción Este atributo booleano es un indicador calculado que identifica los incidentes reabiertos. Se establece como verdadero si, después de alcanzar el estado 'Resolved' o 'Closed', el estado del incidente vuelve a ser abierto o en curso. Este indicador es fundamental para calcular el KPI 'Tasa de reapertura de incidentes' y para el Dashboard 'Incidentes recurrentes'. Una tasa elevada de incidentes reabiertos puede señalar problemas con la calidad de la resolución inicial, un análisis de causa raíz incompleto o un cierre prematuro. Analizar estos casos ayuda a mejorar la calidad y la durabilidad de las soluciones. Por qué es importante Identifica fallos en el proceso de resolución y destaca los incidentes en los que la solución inicial no fue eficaz y generó retrabajo. Dónde obtenerlo Es un campo calculado que se deriva de la secuencia de actividades del registro de eventos. Es verdadero si se produce una actividad como 'Incidente reabierto' o si, para el mismo ID del incidente, una actividad de estado abierto aparece después de una de estado cerrado. Ejemplos truefalse
	Canal de notificación ReportingChannel	Método o canal por el que se notificó el incidente, como correo electrónico, portal o teléfono.
Descripción El canal de notificación, también conocido como origen, indica cómo llegó un incidente al sistema de soporte. Entre los canales habituales se encuentran el correo electrónico, el portal de autoservicio, las llamadas telefónicas y el chat. Analizar este atributo ayuda a evaluar la eficiencia de los distintos canales de notificación. El Dashboard 'Eficiencia de los canales de notificación' compara el volumen de incidentes y el tiempo medio de resolución por canal para determinar qué métodos son más eficaces y cuáles podrían requerir mejoras en el proceso. Por ejemplo, los incidentes notificados a través del portal podrían resolverse más rápido si desde el principio incluyen información más estructurada. Por qué es importante Ayuda a identificar los canales de notificación más eficientes y revela oportunidades para mejorar el proceso de recepción de incidentes. Dónde obtenerlo Está disponible en la API de Tickets de Freshservice como el campo 'source'. Los valores son numéricos. Ejemplos Correo electrónicoPortalTeléfonoChat
	Causa raíz RootCause	Motivo subyacente o causa raíz identificada para el incidente tras la investigación.
Descripción El atributo Causa raíz registra el problema fundamental que provocó el incidente. El personal de soporte suele completar esta información durante la resolución o después, como parte del análisis de causa raíz (RCA). Este atributo es fundamental para el Dashboard 'Incidentes recurrentes y causas raíz' y el KPI 'Tasa de finalización del análisis de causa raíz'. Analizar las causas raíz más frecuentes permite pasar de resolver incidentes de forma reactiva a gestionar los problemas de forma proactiva, aplicar soluciones permanentes que eviten incidentes futuros y reducir los problemas recurrentes. Por qué es importante Permite gestionar los problemas de forma proactiva al ayudar a identificar y eliminar las causas subyacentes de los incidentes recurrentes. Dónde obtenerlo A menudo es un campo personalizado de Freshservice, ya que la funcionalidad predeterminada puede ser limitada. Compruebe en la configuración de 'Ticket Fields' si existe un campo llamado 'Root Cause' o similar. Ejemplos Error de softwareError de configuración de redProblema de formación del usuarioFallo de hardware
	Departamento de quien solicita RequestersDepartment	Departamento al que pertenece la persona que notificó el incidente.
Descripción Este atributo identifica el departamento de la persona solicitante, como 'Ventas', 'Finanzas' o 'TI'. Esta información suele obtenerse del perfil de usuario en Freshservice. Analizar los incidentes por departamento de quien solicita puede revelar si algunos departamentos se ven afectados de forma desproporcionada por los problemas o si existen problemas específicos de ciertos departamentos. Aporta un contexto valioso para comprender el impacto de los incidentes en el negocio y puede ayudar a priorizar las soluciones que afectan a departamentos clave. Por qué es importante Aporta contexto empresarial y permite analizar las tendencias de los incidentes y su impacto en departamentos concretos. Dónde obtenerlo Esta información está vinculada a quien solicita el ticket. Se puede obtener del endpoint 'Requesters' de la API mediante el 'requester_id' del ticket y, a continuación, consultando 'department_id' y el nombre del departamento. Ejemplos VentasMarketingFinanzasRecursos humanos
	Número de traspasos HandoffCount	Número de veces que un incidente se transfirió entre distintos agentes o grupos.
Descripción El número de traspasos es una métrica calculada que cuantifica las reasignaciones de un incidente durante su ciclo de vida. Cada cambio en el atributo 'AssignedAgent' o 'AssignedGroup' incrementa este recuento. Un número elevado de traspasos suele indicar ineficiencias en el proceso, una derivación inicial incorrecta o falta de experiencia entre los agentes. Esta métrica respalda directamente el KPI 'Número de traspasos de incidentes' y el Dashboard 'Análisis de demoras en traspasos y transferencias', y ayuda a identificar incidentes o rutas del proceso con transferencias excesivas que provocan demoras. Por qué es importante Cuantifica el retrabajo y las reasignaciones, y ayuda a identificar ineficiencias causadas por derivaciones incorrectas o falta de conocimientos. Dónde obtenerlo Es una métrica calculada que se obtiene contando los valores distintos o los cambios en los campos 'AssignedAgent' o 'AssignedGroup' durante el ciclo de vida de un incidente. Ejemplos 0125
	Solución temporal proporcionada WorkaroundProvided	Indicador que señala si se proporcionó al usuario una solución alternativa temporal antes de la resolución definitiva.
Descripción Este atributo booleano indica si se implementó una solución temporal o alternativa para mitigar el impacto del incidente mientras se desarrollaba una solución permanente. A menudo se registra mediante una casilla de verificación o un estado específico. En Process Mining, este atributo permite utilizar el Dashboard 'Métricas de eficacia de las soluciones alternativas'. Permite comparar los tiempos de resolución de los incidentes con y sin soluciones alternativas, y determinar si las soluciones temporales reducen eficazmente las interrupciones del negocio y contribuyen a una resolución general más rápida desde la perspectiva del usuario. Por qué es importante Ayuda a medir la eficacia de las soluciones alternativas temporales para reducir el impacto de los incidentes y acelerar la resolución percibida. Dónde obtenerlo Suele ser un campo booleano personalizado (casilla de verificación). Debe comprobarse si existe en la configuración de 'Ticket Fields' de Freshservice. Ejemplos truefalse

Obligatorio Recomendado Opcional

Actividades de gestión de incidencias

Estos son los pasos y los hitos clave que debe registrar en el Registro de eventos para descubrir el proceso con precisión e identificar cuellos de botella.

7 Recomendado 7 Opcional

	Actividad	Descripción
	Estado cambiado a En curso	Esta actividad marca el inicio oficial de la investigación y el trabajo activo sobre el incidente. Se registra cuando un agente cambia el estado del incidente a «En curso». Es un cambio de estado estándar que queda anotado en el historial de actividad del ticket.
Por qué es importante Este hito permite distinguir el tiempo de espera del tiempo de trabajo activo. Analizar cuánto tiempo permanece un incidente «En curso» es clave para comprender el esfuerzo necesario para resolverlo. Dónde obtenerlo Se deduce del registro de actividad del incidente al identificar cuándo se actualiza el campo «Estado» a «En curso». Capturar Filtre el registro de actividad para encontrar un cambio de estado a «En curso» y use su marca de tiempo. Tipo de evento inferred
	Incidente asignado a un grupo	Representa la asignación inicial de un incidente a un grupo de soporte. Puede realizarse automáticamente mediante reglas de enrutamiento o manualmente por una persona encargada de la distribución. Esta actividad se registra mediante el primer valor del campo «Grupo» en el historial de auditoría del incidente.
Por qué es importante Registrar las asignaciones es clave para medir los tiempos de primera respuesta e identificar cuellos de botella en el proceso de distribución. Permite analizar con qué eficiencia se enrutan los incidentes al equipo adecuado. Dónde obtenerlo Se deduce de la primera entrada del registro de actividad del incidente que completa o modifica el campo «Grupo». Capturar Identifique la primera marca de tiempo en la que se completa el campo «Grupo» de un incidente. Tipo de evento inferred
	Incidente cerrado	Representa el cierre formal y definitivo del registro del incidente. Suele producirse automáticamente tras un periodo determinado en estado 'Resolved', aunque también puede hacerlo manualmente un agente. Este evento marca el final del ciclo de vida del incidente.
Por qué es importante Esta actividad es el punto final definitivo del proceso. El tiempo total hasta este evento representa la duración completa del ciclo de vida del incidente, incluidos los periodos de espera de confirmación del usuario. Dónde obtenerlo Se infiere del registro de actividad del incidente al identificar cuándo el campo 'Status' se actualiza a 'Closed'. Capturar Use la marca de tiempo de la entrada del registro de actividad correspondiente al cambio de estado a 'Closed'. Tipo de evento inferred
	Incidente notificado	Indica la creación de un nuevo registro de incidente en Freshservice. Es el punto de partida del ciclo de vida del incidente y suele producirse cuando un usuario final lo notifica a través del portal o por correo electrónico, o cuando un agente de la mesa de ayuda crea un ticket en su nombre. Este evento queda registrado explícitamente con una marca de tiempo de creación.
Por qué es importante Esta actividad es el evento de inicio principal de todo el proceso. Analizar el tiempo transcurrido desde este evento hasta la resolución es fundamental para medir los tiempos de ciclo generales y el cumplimiento de los SLA. Dónde obtenerlo Se obtiene de la marca de tiempo de creación de la tabla de incidentes. Freshservice la registra explícitamente para cada ticket nuevo. Capturar Use la marca de tiempo «Creado el» del registro principal del incidente. Tipo de evento explicit
	Incidente resuelto	Indica que el agente ha aplicado una solución y considera que el incidente está resuelto. Se registra cuando el estado del incidente cambia a «Resuelto». En Freshservice, este hito detiene el contador del SLA.
Por qué es importante Este hito es fundamental para medir el tiempo hasta la resolución (TTR). El período entre los estados «Resuelto» y «Cerrado» es importante para analizar las demoras en la confirmación del usuario y las políticas de cierre automático. Dónde obtenerlo Se infiere del registro de actividad del incidente al identificar cuándo el campo 'Status' se actualiza a 'Resolved'. Capturar Use la marca de tiempo de la entrada del registro de actividad correspondiente al cambio de estado a 'Resolved'. Tipo de evento inferred
	Nota de resolución añadida	Se produce cuando un agente documenta la solución del incidente añadiendo una nota de resolución. En Freshservice, es una acción independiente que se realiza antes de cambiar el estado a «Resuelto». Tanto la acción como su contenido quedan registrados explícitamente.
Por qué es importante Este evento marca el momento en que se identifica una solución. El tiempo transcurrido hasta que el estado cambia a «Incidente resuelto» puede indicar demoras por revisiones internas o documentación. Dónde obtenerlo Se obtiene de la marca de tiempo registrada en el historial de conversación cuando se añade una nota de resolución al incidente. Capturar Identifique la marca de tiempo de la entrada «Nota de resolución» en el registro de conversación del incidente. Tipo de evento explicit
	Prioridad del incidente establecida	Se produce cuando se establece o actualiza la prioridad del incidente. El nivel de prioridad determina la urgencia y los objetivos de SLA para su resolución. Se registra mediante el seguimiento de los cambios en el campo «Prioridad» del historial del incidente.
Por qué es importante Una asignación de prioridad incorrecta o tardía puede provocar incumplimientos de los SLA y una asignación ineficiente de los recursos. Analizar esta actividad ayuda a garantizar que los incidentes críticos reciban atención inmediata. Dónde obtenerlo Se deduce del registro de actividad del incidente, que recoge todas las actualizaciones del campo «Prioridad». Capturar Use las marcas de tiempo del registro de auditoría en las que se estableció o modificó el valor del campo «Prioridad». Tipo de evento inferred
	Agente asignado al incidente	Esta actividad indica cuándo se asigna un agente concreto para gestionar el incidente y quién se hace cargo del ticket. La asignación queda registrada en el historial de actividad del ticket, donde se indica qué agente fue asignado y cuándo.
Por qué es importante Esto permite analizar la carga de trabajo y el rendimiento de los agentes, así como el tiempo que tarda una persona en hacerse cargo de un incidente después de su asignación al grupo. Es fundamental para los Dashboards de rendimiento de los agentes. Dónde obtenerlo Se registra mediante los cambios en el campo «Agente» del registro de actividad o del historial de auditoría del incidente. Capturar Identifique las marcas de tiempo correspondientes a los cambios en el campo «Agente». Tipo de evento inferred
	Estado cambiado a Pendiente	Indica que el proceso de resolución se ha pausado, normalmente mientras se espera información del usuario o de un tercero. Se deduce de un cambio de estado a cualquier estado «Pendiente». El tiempo en este estado suele excluirse de los cálculos de los SLA.
Por qué es importante Identificar el tiempo transcurrido en estados pendientes es fundamental para comprender las dependencias externas y las demoras. Permite separar el tiempo de trabajo de los agentes del tiempo de espera. Dónde obtenerlo Se deduce del registro de actividad del incidente cuando el campo «Estado» se actualiza a un valor como «Pendiente» o «A la espera de respuesta del usuario». Capturar Filtre el registro de actividad para encontrar cambios a cualquier estado pendiente y use la marca de tiempo correspondiente. Tipo de evento inferred
	Incidente reabierto	Se produce cuando un incidente que se había marcado como 'Resolved' vuelve a un estado abierto, normalmente porque el usuario no está de acuerdo con la resolución. Se infiere a partir de un cambio de estado de 'Resolved' a un estado como 'Open' o 'In Progress'.
Por qué es importante Una tasa elevada de reaperturas apunta a problemas con la calidad de la resolución o a soluciones incompletas. Es una métrica clave para analizar el retrabajo y el desempeño de los agentes. Dónde obtenerlo Se infiere del registro de actividad del incidente al detectar un cambio de estado de 'Resolved' a un estado activo. Capturar Filtre el registro de actividad para encontrar un cambio de 'Status' de 'Resolved' a 'Open' o 'In Progress'. Tipo de evento inferred
	Incidente reasignado	Indica que el incidente se transfirió de un agente o grupo a otro, es decir, que hubo un traspaso durante el proceso de resolución. Este evento se deduce al detectar cambios posteriores a la asignación inicial en los campos «Agente» o «Grupo».
Por qué es importante Las reasignaciones o transferencias frecuentes suelen indicar ineficiencias en el proceso, falta de conocimientos o un enrutamiento inicial incorrecto. Analizar estos eventos ayuda a identificar y reducir las demoras. Dónde obtenerlo Se deduce del registro de actividad del incidente mediante el seguimiento de cualquier cambio en los campos «Agente» o «Grupo» después de la primera asignación. Capturar Detecte los cambios en los campos «Agente» o «Grupo» del historial de auditoría del ticket. Tipo de evento inferred
	Incumplimiento del objetivo del SLA	Este es un evento calculado que se produce cuando el tiempo transcurrido desde que se registra un incidente supera el objetivo de SLA definido para la respuesta o la resolución. Freshservice realiza un seguimiento interno del estado del SLA. Este evento puede derivarse al comparar las marcas de tiempo con las políticas de SLA.
Por qué es importante Mide directamente el cumplimiento de los compromisos de nivel de servicio. Identificar cuándo y por qué se producen incumplimientos es esencial para el Dashboard de Rendimiento del SLA y la mejora continua. Dónde obtenerlo Se calcula comparando la marca de tiempo de resolución o respuesta con la fecha y hora límite del objetivo del SLA. Freshservice suele marcar los tickets como 'SLA Violated'. Capturar Se deriva comparando la marca de tiempo de 'Resolved at' con la de 'Due by', o cuando el campo 'SLA Status' cambia a 'Violated'. Tipo de evento calculated
	Primera respuesta enviada	Esta actividad representa la primera comunicación de un agente al usuario después de que se notifica el incidente. Puede ser una nota pública o una respuesta directa. Freshservice registra todas las comunicaciones de los agentes con sus marcas de tiempo.
Por qué es importante Cumplir el SLA de primera respuesta es un KPI fundamental para la satisfacción de los clientes. Esta actividad permite medir y analizar la rapidez con la que los agentes atienden los incidentes nuevos. Dónde obtenerlo Se identifica mediante la marca de tiempo de la primera nota pública o respuesta que un agente añade al registro de conversación del incidente. Capturar Filtre el historial de conversación del incidente para encontrar la primera entrada realizada por un agente. Tipo de evento explicit
	Solución temporal proporcionada	Esta actividad indica que se comunicó al usuario una solución temporal para mitigar el impacto del incidente. Para registrarla, suele ser necesario configurar el sistema, por ejemplo, con una casilla específica, un tipo de nota concreto o el análisis de palabras clave en las notas de los agentes.
Por qué es importante Esto permite analizar la eficacia de las soluciones temporales para reducir el impacto en el negocio y su relación con el tiempo de resolución definitiva. También sirve de base para el Dashboard de métricas de eficacia de las soluciones temporales. Dónde obtenerlo Es probable que no se trate de un evento explícito. Puede deducirse al marcar las notas que contienen palabras clave como «solución temporal» o al registrar un cambio en un campo personalizado de casilla «Solución temporal proporcionada». Capturar Se deduce de un cambio en un campo personalizado o del análisis de palabras clave en las notas de los agentes. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Freshservice

Pasos

Acceda a Freshservice Analítica: Inicie sesión en su instancia de Freshservice con una cuenta que tenga permisos para consultar y crear informes. En el menú principal, vaya al módulo Analítica.
Cree un informe: Haga clic en el botón New Report. Asígnele un nombre descriptivo, como "Incident Management Event Log". Cuando se le solicite elegir una fuente de datos, seleccione el módulo Incident Management.
Seleccione el widget del informe: En el editor del informe, añada un widget y seleccione el tipo Table. Este será la base de los datos del registro de eventos.
Añada las columnas de datos principales: En el panel de fuentes de datos de la derecha, arrastre los campos necesarios hasta la configuración de columnas de la tabla. Empiece con Incident ID, Created at, Agent, Group, Priority, Severity, Status y Category.
Incluya los datos de actividad: Para registrar eventos individuales, debe unir o incluir los datos de las actividades del ticket. Añada la fuente de datos Activities al widget. Desde esta fuente, añada Performed at (para la marca de tiempo del evento) y Activity description u otros campos que describan el cambio realizado.
Cree una columna calculada 'ActivityName': Este es el paso más importante. Cree una columna calculada o un campo de fórmula. Use instrucciones IF anidadas o una función CASE para convertir los datos de actividad sin procesar en los valores de ActivityName requeridos. Consulte la sección Query para ver la lógica detallada de cada una de las 14 actividades.
Configure 'EventTimestamp': Cree otra columna calculada para EventTimestamp. La lógica debe seleccionar la marca de tiempo Created at para la actividad 'Incident Reported' y la marca de tiempo Performed at de la actividad para todos los demás eventos.
Aplique filtros al informe: Configure los filtros para delimitar los datos. Como mínimo, establezca un filtro de intervalo de fechas en el campo 'Created at'. Se recomienda usar un intervalo de los últimos 3 a 6 meses. También debe añadir un filtro para incluir solo los tickets cuyo 'Ticket Type' sea 'Incident'.
Ejecute y ajuste el informe: Ejecute el informe para generar una vista previa de los datos. Revise los resultados para comprobar que las columnas ActivityName y EventTimestamp se completen correctamente. Ajuste las fórmulas y los filtros según sea necesario.
Guarde y exporte el informe: Cuando esté conforme con los resultados, guarde el informe. Use la opción Exportar y seleccione CSV como formato.
Programe la exportación (opcional): Para realizar análisis continuos, puede programar la ejecución y exportación automática del informe. Configure una frecuencia, por ejemplo, diaria o semanal, para que el archivo CSV se envíe a su correo electrónico o a otro destino.
Prepare los datos para cargarlos: Abra el archivo CSV exportado. Cambie los encabezados de columna para que coincidan con el esquema requerido por ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, entre otros. Añada las columnas estáticas SourceSystem (con el valor 'Freshservice') y LastDataUpdate (con la fecha y hora actuales). El archivo ya está listo para cargarse.

Configuración

Módulo de analítica: Para extraer los datos, necesita acceso al módulo de analítica de Freshservice, disponible en los planes de nivel superior, como Pro y Enterprise.
Permisos necesarios: Su cuenta de usuario debe tener un rol con permisos para crear, editar y ejecutar informes en el módulo de analítica.
Intervalo de fechas: Es fundamental filtrar por fecha de creación de la incidencia para controlar el volumen de datos. Se recomienda un periodo móvil de 3 a 6 meses para equilibrar el contexto histórico y el rendimiento.
Filtros del informe: Filtre siempre por «Tipo de ticket» igual a «Incidencia» para excluir solicitudes de servicio y otros tipos de tickets del análisis del proceso.
Campos calculados: Este método depende en gran medida de campos calculados (fórmulas) para obtener ActivityName y EventTimestamp de cada evento. Es útil conocer el editor de fórmulas de Freshservice.
Volumen de datos: Tenga en cuenta que la extracción genera varias filas por incidencia, una por cada actividad. En instancias grandes de Freshservice, el archivo CSV resultante puede ser muy voluminoso y afectar al tiempo de generación del informe y a la velocidad de exportación.

Consulta de ejemplo config

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

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

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

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

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

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

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

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

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

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

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

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

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

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

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

Pasos

Requisitos previos: Asegúrese de tener instalado Python 3.6 o una versión posterior, junto con las bibliotecas requests y pandas. Puede instalarlas con pip: pip install requests pandas.
Genere una clave de API: Inicie sesión en su instancia de Freshservice como administrador. Abra la configuración de su perfil haciendo clic en la foto de perfil, en la esquina superior derecha. Vaya a la sección «API Key» y copie su clave de API personal. Trátela como una contraseña.
Configure el script: Guarde el código de Python proporcionado en un archivo llamado extract_freshservice_incidents.py en su equipo local.
Configure los parámetros: Abra el archivo del script en un editor de texto. Actualice los valores de ejemplo de FRESHSERVICE_DOMAIN (por ejemplo, 'suempresa.freshservice.com'), API_KEY (la clave que acaba de copiar) y START_DATE_STR (el inicio del periodo que desea extraer, en formato 'YYYY-MM-DD').
Comprenda la lógica del script: Primero, el script obtiene todos los tickets de incidencias creados después de la fecha de inicio especificada. Recorre cada página de resultados que devuelve la API. Para cada ticket, realiza una segunda llamada a la API para recuperar su historial detallado de actividades.
Generación del Registro de eventos: El script procesa los datos principales del ticket y su registro de actividades para identificar y crear registros de cada una de las 14 actividades empresariales necesarias. Por ejemplo, «Incidencia reportada» se genera a partir de la fecha de creación del ticket, mientras que «Estado cambiado a En curso» se obtiene de una entrada específica del registro de actividades.
Obtenga eventos complejos: Se generan eventos como «Objetivo de SLA incumplido». El script comprueba si se incumplió el SLA de resolución del ticket. Si es así, crea un evento con la fecha due_by como marca de tiempo, que indica cuándo se produjo el incumplimiento.
Ejecute el script: Abra una terminal o una línea de comandos, vaya al directorio donde guardó el script y ejecútelo con el comando: python extract_freshservice_incidents.py.
Supervise la ejecución: El script mostrará el progreso en la consola e indicará cuántos tickets se han procesado. El proceso puede tardar, según el número de tickets y los límites de frecuencia de la API.
Revise el resultado: Al finalizar, el script generará en el mismo directorio un archivo CSV llamado freshservice_incident_event_log.csv. Este archivo contiene el Registro de eventos completo.
Prepare el archivo para cargarlo: Abra el CSV en una hoja de cálculo y compruebe que las columnas (IncidentId, ActivityName, EventTimestamp, etc.) tengan los valores esperados. El archivo ya está listo para cargarse en ProcessMind o en otra herramienta de Process Mining.

Configuración

FRESHSERVICE_DOMAIN: URL específica de Freshservice de su empresa, por ejemplo, mycompany.freshservice.com. Es un parámetro obligatorio del script.
API_KEY: Clave de API personal de una cuenta con permisos suficientes para leer todos los datos de incidencias. Es un parámetro obligatorio.
START_DATE_STR: Fecha de inicio de la extracción de datos, en formato 'YYYY-MM-DD'. Se recomienda extraer inicialmente entre 3 y 6 meses de datos para obtener un análisis significativo.
PAGE_SIZE: Está establecido en 100, el máximo permitido por la API de Freshservice, para reducir el número de llamadas a la API y mejorar el rendimiento. Por lo general, no se recomienda cambiar este valor.
Límite de frecuencia de la API: El script incluye una llamada básica a time.sleep(1) después de procesar cada ticket para respetar los límites de frecuencia de la API de Freshservice. En instancias con un gran volumen de datos, quizá sea necesario ajustar este valor para evitar errores.
Permisos necesarios: La clave de API debe pertenecer a una cuenta de usuario, por ejemplo, una cuenta de servicio dedicada, con permisos de al menos el rol «SD Agent». Así se garantiza el acceso a todos los campos necesarios de los tickets y a los registros de actividad de los distintos grupos de la mesa de ayuda.

Consulta de ejemplo python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pasos

Confirme que su plan de Freshservice y sus permisos de administrador permiten usar reglas de Workflow Automator, acciones de webhook, acceso a incidencias e historial de actividad de tickets. Verifique con el equipo receptor el endpoint de destino, el método de autenticación, los requisitos de TLS y la política de retención.
Defina el contrato de eventos antes de configurar el automatizador. Use un objeto JSON por cada entrega del webhook con IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory y ResolutionSlaTargetTime. Configure el receptor para conservar el payload original del webhook y la marca de tiempo de entrega.
Cree una regla de Workflow Automator para la creación de incidencias. Configure la regla para que se ejecute cuando se cree una incidencia y añada una acción de webhook que envíe la actividad Incident Reported. Establezca EventTimestamp con la marca de tiempo de creación de la incidencia y ActivityName con Incident Reported.
Cree reglas de actualización para los cambios de asignación, prioridad, estado, comunicación, notas, SLA y cierre. Configure las condiciones con los campos de incidencia y el historial de actividad disponibles en su cuenta de Freshservice. Cada regla debe enviar un evento de webhook independiente cuando se produzca la actividad correspondiente. No confíe en que ProcessMind deduzca las actividades a partir de una instantánea final de la incidencia.
Configure un mapeo explícito de actividades. Envíe Incident Assigned to Group cuando el campo Group reciba su valor inicial; Agent Assigned to Incident cuando el campo Agent reciba su valor inicial; Incident Prioritized cuando se establezca o cambie Priority; First Response Sent cuando se registre la primera respuesta pública o nota del agente que cumpla los criterios; Incident Reassigned cuando Agent o Group cambien después de la asignación inicial; Status Changed to In Progress y Status Changed to Pending para las transiciones de estado correspondientes; Workaround Provided solo cuando haya un indicador de solución temporal configurado; Resolution Note Added cuando se añada una nota de resolución; Incident Resolved cuando el estado cambie a Resolved; SLA Target Breached cuando se cumpla la condición de incumplimiento del SLA configurada; Incident Reopened cuando el estado cambie de Resolved a un estado abierto; e Incident Closed cuando el estado cambie a Closed.
Configure el cuerpo de la solicitud del webhook en formato JSON e incluya el identificador de la incidencia, el nombre de la actividad, la marca de tiempo del evento, el sistema de origen, la fecha de la última actualización de datos y los atributos contextuales recomendados. Utilice las variables de webhook que expone su cuenta de Freshservice. Si el editor de webhooks no ofrece una variable necesaria, complétela en el servicio receptor mediante una interfaz de Freshservice aprobada o deje el valor vacío, en lugar de inventarlo.
Configure la idempotencia y la gestión de entregas en el endpoint. Use un identificador de evento estable si Freshservice lo proporciona. De lo contrario, cree una clave de deduplicación con IncidentId, ActivityName, EventTimestamp y el identificador de entrega de origen. Devuelva una respuesta HTTP correcta solo después de aceptar el payload de forma duradera.
Pruebe cada regla con incidencias controladas. Cree una incidencia, asígnele un grupo y un agente, cambie la prioridad y el estado, envíe una respuesta que cumpla los criterios, añada una solución temporal y una nota de resolución si están configuradas, resuelva y vuelva a abrir la incidencia, y ciérrela. Pruebe por separado el incumplimiento del SLA con una política o una cola de prueba controlada. Confirme que cada actividad esperada llegue en un payload de webhook distinto.
Guarde los payloads del webhook en un área de preparación duradera, normalice las marcas de tiempo a una única zona horaria y convierta cada payload en una fila del Registro de eventos. Conserve una fila por cada actividad explícita del webhook. Complete LastDataUpdate con la marca de tiempo de actualización de la extracción o la ingesta, no con la marca de tiempo del evento empresarial.
Valide el Registro de eventos preparado, elimine solo las entregas exactamente duplicadas y conserve las repeticiones legítimas, como varios cambios de prioridad o transiciones de estado. Asegúrese de que todas las filas incluyan IncidentId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate.
Exporte el Registro de eventos normalizado como CSV o en otro formato compatible con ProcessMind. Utilice exactamente los nombres de columna IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory y ResolutionSlaTargetTime. Cargue el archivo o conecte la fuente de eventos preparada a ProcessMind y asigne IncidentId al identificador del caso y ActivityName al campo de actividad.

Configuración

Ámbito de los activadores: Configure reglas independientes de Workflow Automator para la creación de incidencias y para cada condición de actualización. Una única regla general de actualización puede generar eventos duplicados o ambiguos, salvo que el receptor aplique un mapeo estricto de actividades.
Payload del webhook: Incluya todos los atributos obligatorios en cada payload. Añada los atributos recomendados cuando estén disponibles en el momento del evento. Conserve el payload sin procesar para auditorías y reproducciones.
Semántica de las actividades: Distinga las asignaciones iniciales de grupo y agente de los cambios posteriores. Estos últimos generan Incident Reassigned, mientras que la asignación inicial genera la actividad correspondiente.
Gestión de estados: Asigne los valores exactos de estado configurados en la cuenta de Freshservice. Si la cuenta utiliza estados personalizados de espera o abiertos, configure asignaciones explícitas para esos valores.
Primera respuesta: Defina si se considera válida una respuesta pública, una nota pública u otro tipo de comunicación. Aplique el criterio de forma coherente y genere el evento solo para la primera comunicación válida de cada incidencia.
Detección de soluciones temporales: Configure un campo específico, una casilla de verificación, un tipo de nota o una regla de palabras clave aprobada. Sin esta configuración, no es posible identificar de forma fiable Workaround Provided.
Incumplimiento del SLA: Configure un activador explícito para el incumplimiento del SLA o un proceso programado independiente que compare la hora actual con ResolutionSlaTargetTime. Una instantánea final de la incidencia no basta para reconstruir la marca de tiempo del incumplimiento.
Intervalo de fechas: Para la validación inicial, utilice aproximadamente entre 3 y 6 meses de incidencias. Para la operación en tiempo real, inicie la ingesta antes del periodo de análisis previsto y conserve el historial de webhooks para poder reproducirlo.
Filtros: Aplique solo filtros aprobados de empresa, espacio de trabajo, departamento, servicio, categoría o fecha. No dé por sentados nombres de campos ni sintaxis de filtros de Freshservice que no aparezcan en la configuración de la cuenta.
Rendimiento: Procese los webhooks de forma asíncrona, ponga en cola las solicitudes entrantes, agrupe las escrituras posteriores e indexe IncidentId y EventTimestamp. Evite las llamadas de enriquecimiento síncronas al recibir webhooks.
Fiabilidad: Configure reintentos, gestión de mensajes fallidos, supervisión y supresión de duplicados. Registre las entregas fallidas y reprodúzcalas una vez corregido el problema.
Requisitos previos: Acceso de administrador, disponibilidad de Workflow Automator, permisos para usar webhooks, un endpoint HTTPS, configuración de autenticación, capacidades suficientes del plan de Freshservice y un proceso de carga o recepción compatible con ProcessMind.
Seguridad: Utilice HTTPS, restrinja el acceso entrante cuando sea posible, rote las credenciales, limite los campos sensibles y proteja las descripciones y notas de las incidencias si se incluyen en los payloads.

Consulta de ejemplo config

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

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

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

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

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

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

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

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

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

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

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

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

¿Todo listo para comenzar?

Utilice este Template para estructurar correctamente sus datos y obtener información valiosa sobre los flujos de trabajo de gestión de incidencias. Empiece hoy mismo a reducir los tiempos de resolución.

Volver a la guía de mejora

Descargar Template

Evite incumplimientos de SLA: optimice hoy la gestión de incidencias

Únase a las empresas que reducen el MTTR un 35 % y evitan costosos incumplimientos de SLA.

Comience su prueba gratuita

Prueba gratuita de 14 días, sin necesidad de tarjeta de crédito.

Su Template de datos para la gestión de incidencias

Su Template de datos para la gestión de incidencias

Atributos de gestión de incidencias

Actividades de gestión de incidencias

Guías de extracción

Exportar datos del módulo de analítica de Freshservice a CSV

Pasos

Configuración

Consulta de ejemplo config

Extracción mediante script de Python a través de la API REST de Freshservice

Pasos

Configuración

Consulta de ejemplo python

Envío de datos en tiempo real mediante webhooks de Workflow Automator

Pasos

Configuración

Consulta de ejemplo config

¿Todo listo para comenzar?

Evite incumplimientos de SLA: optimice hoy la gestión de incidencias