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

Su Template de datos de gestión de incidentes

Freshservice

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

Su Template de datos de gestión de incidentes

Esta plantilla está diseñada para ayudarle a preparar sus datos para analizar eficazmente la gestión de incidentes. Describe los atributos esenciales que debe recopilar, las actividades clave que debe supervisar y ofrece orientación práctica para extraer esta información de su sistema de origen. Utilice este recurso para agilizar la preparación de sus datos.

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

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

Descargar Template

Atributos de la gestión de incidentes

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para realizar un análisis completo de su proceso de gestión de incidentes.

5 Obligatorio 7 Recomendado 7 Opcional

	Nombre	Descripción
	ID del incidente IncidentId	Identificador único de cada registro de incidente, que actúa como clave principal para realizar el seguimiento de todo el ciclo de vida del incidente.
Descripción El Incident ID es la base del análisis de la gestión de incidentes. Funciona como Case ID 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 está asociada a un Incident ID, lo que permite reconstruir el flujo completo del proceso para cada incidente. Esto resulta esencial para calcular los tiempos de ciclo, analizar las variantes del proceso e identificar cuellos de botella específicos de cada caso. Sin un identificador único, sería imposible distinguir entre distintos incidentes y analizar sus recorridos desde la notificación hasta la resolución. Por qué es importante Identifica de forma única cada incidente y permite realizar el seguimiento y análisis de su ciclo de vida completo, desde la creación hasta el cierre. Dónde obtenerlo Es el identificador principal de un ticket, disponible en la API de Freshservice Tickets como el campo «id» del objeto ticket. Ejemplos INC-10234INC-10235INC-10236
	Marca de tiempo del evento EventTimestamp	Fecha y hora exactas en las que tuvo lugar la actividad o el evento.
Descripción La Marca de tiempo del evento, o Hora de inicio, indica el momento exacto en que tuvo lugar una actividad. Cada actividad del ciclo de vida del incidente, desde su creación hasta su 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 los eventos cronológicamente, calcular la duración entre actividades, medir el tiempo de ciclo total del caso y analizar los tiempos de espera. Es la base para crear Dashboards que hagan seguimiento del rendimiento del SLA, los retrasos en las transferencias y los tiempos generales de resolución. Por qué es importante Proporciona el orden cronológico de los eventos, esencial para calcular duraciones, analizar los 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», «updated_at» y las marcas de tiempo de las conversaciones 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 evento específico que tuvo lugar en un momento determinado del ciclo de vida del incidente.
Descripción El nombre de la actividad describe un paso o evento individual del proceso de gestión de incidentes, como «Incident Assigned to Group», «Status Changed to Pending» o «Incident Resolved». Estas actividades se derivan de los cambios que experimentan los datos del incidente a lo largo del tiempo. Este atributo es fundamental para Process Mining, ya que define los nodos del mapa de procesos descubierto. Al analizar la secuencia y 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 bucles 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 es un campo directo de Freshservice, sino que se deriva de cambios en propiedades del ticket, como el estado, la prioridad, la asignación del agente o grupo 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. Aunque en este contexto será siempre «Freshservice», es un campo esencial en entornos donde se 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 gobierno y trazabilidad de datos. Garantiza la claridad sobre la procedencia de los datos, algo importante para la validación, la depuración y la futura ampliación del proyecto de Process Mining con otros sistemas de gestión de servicios u operativos. Por qué es importante Garantiza la trazabilidad y el gobierno de los datos al identificar claramente el origen de los datos de gestión de incidentes. Dónde obtenerlo Normalmente es 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 datos LastDataUpdate	Marca de tiempo que indica la última vez que se actualizaron o extrajeron los datos de este proceso.
Descripción Este atributo proporciona una marca de tiempo de la última actualización del conjunto de datos desde el sistema de origen. Es un campo de metadatos que se aplica al conjunto de datos completo, no a eventos individuales, aunque suele incluirse a nivel de evento para mantener la coherencia. En el análisis, esta información es esencial para comprender la actualización de los datos y el intervalo temporal que abarcan los Dashboards y los KPI. Permite confiar en la actualidad de la información y ayuda a gestionar las expectativas sobre si los incidentes más recientes están incluidos en el análisis. Por qué es importante Informa a los usuarios sobre la actualidad de los datos y garantiza que comprendan el periodo que abarca el análisis. Dónde obtenerlo Es una marca de tiempo de metadatos generada 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 empleada en la mesa de ayuda que es responsable del incidente en un momento determinado. Los cambios en este atributo representan una transferencia de responsabilidad entre agentes. Este atributo es esencial para el análisis del rendimiento, ya que permite crear Dashboards que hagan 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 se utiliza para analizar las transferencias entre agentes, que pueden ser una fuente de retrasos e ineficiencias. Al hacer seguimiento de las asignaciones de agentes, los responsables pueden identificar necesidades de formación y reconocer a las personas con mejor rendimiento del equipo. Por qué es importante Permite analizar el rendimiento de los agentes, la distribución de la carga de trabajo y el impacto de las transferencias entre agentes en los tiempos de resolución. Dónde obtenerlo Disponible en la API de Freshservice Tickets como el campo «responder_id». Este ID puede combinarse 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 Network.
Descripción La categoría del incidente permite clasificar los incidentes según el tipo de problema notificado. Esta clasificación jerárquica ayuda a dirigir el incidente al equipo adecuado y es fundamental para analizar tendencias. Este atributo se utiliza en el panel «Incident Categorization Accuracy» para analizar si una clasificación inicial incorrecta provoca tiempos de resolución más largos debido a las reasignaciones. Al agrupar los incidentes por categoría, las organizaciones pueden identificar problemas recurrentes, comprender dónde se concentra la mayor parte del esfuerzo de soporte y adaptar sus iniciativas de mejora. Por qué es importante Permite analizar las tendencias de los incidentes y ayuda a determinar si una categorización incorrecta está provocando retrasos en la resolución. Dónde obtenerlo Es un campo predeterminado, aunque personalizable, de Freshservice. Está disponible en la API de Tickets como «category», 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 Open, Pending, Resolved o Closed.
Descripción El estado del incidente indica su situación actual. Los cambios de estado son eventos clave que forman 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 empleado en cada estado ayuda a identificar cuellos de botella, como incidentes que permanecen demasiado tiempo en estado «Pending» a la espera de la respuesta del usuario. También es esencial para definir los puntos inicial y final de los cálculos del tiempo de ciclo. Por qué es importante Registra el avance del incidente durante su ciclo de vida y ayuda a identificar las etapas en las que suelen producirse retrasos. Dónde obtenerlo Disponible en la API de Freshservice Tickets 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 empresarial.
Descripción La Gravedad del incidente mide el impacto que un incidente tiene en la empresa y suele clasificarse como Baja, Media, Alta o Crítica. Aunque está relacionada con la prioridad, la gravedad se centra en el impacto, mientras que la prioridad se centra en la urgencia. La combinación de gravedad e impacto suele determinar la prioridad final. El análisis por gravedad ayuda a comprender hasta qué punto la organización gestiona los incidentes con consecuencias empresariales importantes. Se utiliza en los Dashboards para segmentar los tiempos de resolución y el rendimiento del SLA, garantizando que los problemas con mayor impacto reciban el nivel adecuado de atención y recursos durante todo su ciclo de vida. Por qué es importante Mide el impacto empresarial de un incidente y permite centrar el análisis en la mitigación de 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 BajoMedioAlto
	Grupo asignado AssignedGroup	Grupo o equipo de soporte asignado actualmente al incidente.
Descripción El grupo asignado indica qué equipo, como «Level 1 Support», «Network Team» o «Database Admins», es responsable del incidente. Los cambios en este atributo señalan una escalación o transferencia entre distintos equipos funcionales. Analizar el grupo asignado es fundamental para comprender los retrasos en las transferencias y los traspasos. Process Mining puede visualizar el flujo de incidentes entre grupos, destacar las rutas de escalación habituales y medir el tiempo que cada grupo tarda en actuar. Esto ayuda a identificar cuellos de botella organizativos y oportunidades para agilizar la colaboración entre equipos. Por qué es importante Registra qué equipo es responsable, algo esencial para analizar transferencias, escalaciones y retrasos entre equipos. Dónde obtenerlo Disponible en la API de Freshservice Tickets como el campo «group_id». Este ID puede combinarse con la API de Groups para obtener el nombre del grupo. Ejemplos Mesa de ayudaOperaciones de redSoporte de infraestructura
	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 el nivel de atención necesarios para gestionar un incidente. Normalmente se define en una escala como Baja, Media, Alta y Urgente, y suele impulsar 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 alta prioridad con los de baja prioridad y garantizar que los problemas críticos se gestionen de forma eficiente. Los Dashboards suelen segmentar por prioridad métricas como el tiempo de ciclo y el cumplimiento del SLA para proporcionar información útil para la acción a los responsables. Por qué es importante Ayuda a priorizar el análisis de los incidentes más críticos y es esencial para evaluar el rendimiento del SLA y la asignación de recursos. Dónde obtenerlo Disponible en la API de Freshservice Tickets como el campo «priority». Los valores son numéricos, por ejemplo, 1 para Baja y 4 para Urgente. Ejemplos BajoMedioAltoUrgente
	Tiempo objetivo del SLA de resolución ResolutionSlaTargetTime	Marca de tiempo límite en la que se espera resolver el incidente según su política de SLA.
Descripción Este atributo almacena la fecha y hora concretas que sirven como plazo para resolver un incidente. Este objetivo lo determina la política del Acuerdo de Nivel de Servicio (SLA) aplicada al ticket, que normalmente depende de factores como la prioridad. Este tiempo objetivo es esencial para calcular el KPI «SLA Adherence Rate» y alimentar el «SLA Performance Dashboard». Al comparar la marca de tiempo real de resolución con este objetivo, podemos determinar si un incidente se resolvió a tiempo o incumplió su SLA. Esto es fundamental para medir el cumplimiento del nivel de servicio. Por qué es importante Proporciona el plazo de resolución, necesario para calcular el cumplimiento del SLA e identificar los incidentes en riesgo. Dónde obtenerlo Disponible en la API de Freshservice Tickets como 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
	¿Se incumplió el SLA? IsSlaBreached	Indicador calculado cuyo valor 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 comparando la marca de tiempo real de resolución con «ResolutionSlaTargetTime». Este indicador es una entrada directa para el KPI «SLA Adherence Rate» y el «SLA Performance Dashboard». Simplifica el análisis al proporcionar un resultado binario claro para el rendimiento del SLA de 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 de 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 «Incident Resolved» con el campo «ResolutionSlaTargetTime». Ejemplos truefalse
	¿Se reabrió? IsReopened	Indicador calculado cuyo valor 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. Su valor es verdadero si, después de alcanzar el estado «Resolved» o «Closed», el estado del incidente vuelve a cambiar a un estado abierto o en curso. Este indicador es fundamental para calcular el KPI «Incident Reopening Rate» y para el panel «Recurring Incidents». Una tasa elevada de incidentes reabiertos puede señalar problemas en la calidad de la resolución inicial, un análisis incompleto de la causa raíz o un cierre prematuro. Analizar estos casos ayuda a mejorar la calidad y sostenibilidad de las correcciones. Por qué es importante Identifica fallos en el proceso de resolución y destaca los incidentes en los que la correcció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. Su valor es verdadero si se produce una actividad como «Incident Reopened» o si una actividad de estado abierto sigue a una actividad de estado cerrado para el mismo Incident ID. Ejemplos truefalse
	Canal de notificación ReportingChannel	Método o canal a través del cual se notificó el incidente, como correo electrónico, portal o teléfono.
Descripción El canal de notificación, también conocido como origen, identifica cómo llegó un incidente al sistema de soporte. Entre los canales habituales se encuentran el correo electrónico, un 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 panel «Reporting Channel Efficiency» 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 pueden requerir mejoras. Por ejemplo, los incidentes notificados a través del portal pueden resolverse más rápido si incluyen información más estructurada desde el principio. 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 Disponible en la API de Freshservice Tickets 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 después de la investigación.
Descripción El atributo Causa raíz registra el problema fundamental que provocó el incidente. Normalmente, los agentes de soporte completan esta información durante la resolución o después de ella, como parte de un proceso de análisis de causa raíz (RCA). Este atributo es fundamental para el panel «Recurring Incidents And Root Causes» y el KPI «Root Cause Analysis Completion Rate». Al analizar las causas raíz habituales, las organizaciones pueden pasar de corregir incidentes de forma reactiva a gestionar los problemas de forma proactiva, aplicar soluciones permanentes que prevengan futuros incidentes 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 la configuración de «Ticket Fields» para buscar un campo denominado «Root Cause» o similar. Ejemplos Error de softwareError de configuración de redProblema de capacitación del usuarioFallo de hardware
	Departamento del solicitante RequestersDepartment	Departamento al que pertenece el usuario que notificó el incidente.
Descripción Este atributo identifica el departamento empresarial del solicitante, como «Sales», «Finance» o «IT». Normalmente, esta información procede del perfil del usuario en Freshservice. Analizar los incidentes por departamento del solicitante puede revelar si determinadas unidades de negocio se ven afectadas de forma desproporcionada por los problemas o si existen problemas específicos de un departamento. Proporciona un contexto valioso para comprender el impacto empresarial de los incidentes y ayuda a priorizar las correcciones que afectan a departamentos críticos. Por qué es importante Proporciona contexto empresarial y permite analizar las tendencias de los incidentes y su impacto en departamentos específicos. Dónde obtenerlo Esta información está vinculada al solicitante del ticket. Puede obtenerse del endpoint de la API «Requesters» mediante el «requester_id» del ticket y, después, accediendo a «department_id» y al nombre. Ejemplos VentasMarketingFinanzasRecursos Humanos
	Número de transferencias HandoffCount	Número de veces que un incidente se transfirió entre distintos agentes o grupos.
Descripción El número de transferencias es una métrica calculada que cuantifica las reasignaciones que experimenta un incidente durante su ciclo de vida. Cada cambio en el atributo «AssignedAgent» o «AssignedGroup» incrementa este número. Un número elevado de transferencias suele indicar ineficiencias del proceso, un enrutamiento inicial incorrecto o falta de conocimientos por parte de los agentes. Esta métrica respalda directamente el KPI «Incident Handoff Count» y el panel «Handoff And Transfer Delay Analysis», y ayuda a identificar incidentes o rutas del proceso con transferencias excesivas que provocan retrasos. Por qué es importante Cuantifica el retrabajo y las reasignaciones, y ayuda a identificar ineficiencias causadas por un enrutamiento incorrecto o carencias de conocimientos. Dónde obtenerlo Es una métrica calculada que se obtiene contando el número de valores distintos o cambios en los campos «AssignedAgent» o «AssignedGroup» durante el ciclo de vida de un único incidente. Ejemplos 0125
	Solución temporal proporcionada WorkaroundProvided	Indicador que señala si se proporcionó una solución alternativa temporal al usuario antes de la resolución definitiva.
Descripción Este atributo booleano indica si se implementó una corrección temporal o una solución 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 respalda el panel «Workaround Effectiveness Metrics». Permite comparar los tiempos de resolución de los incidentes con y sin soluciones alternativas y ayuda a determinar si las correcciones temporales reducen eficazmente la interrupción 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 Normalmente es un campo booleano personalizado, como una casilla de verificación. Su existencia debe comprobarse en la configuración «Ticket Fields» de Freshservice. Ejemplos truefalse

Obligatorio Recomendado Opcional

Actividades de gestión de incidentes

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

7 Recomendado 7 Opcional

	Actividad	Descripción
	Estado cambiado a In Progress	Esta actividad marca el inicio oficial de la investigación activa y del trabajo sobre el incidente. Se captura cuando un agente cambia el estado del incidente a «In Progress». Es un cambio de estado estándar que queda registrado en el historial de actividades del ticket.
Por qué es importante Este hito ayuda a diferenciar el tiempo de espera del tiempo de trabajo activo. Analizar cuánto tiempo permanece un incidente «In Progress» es clave para comprender el esfuerzo de resolución. Dónde obtenerlo Se infiere a partir del Registro de actividades del incidente al identificar cuándo se actualiza el campo «Status» a «In Progress». Recopilar Filtre el Registro de actividades para localizar un cambio de estado a «In Progress» y utilice 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 parte de una persona encargada de la distribución. Esta actividad se captura mediante el seguimiento de la primera introducción del campo «Group» en el Registro de auditoría del incidente.
Por qué es importante El seguimiento de las asignaciones es clave para medir los tiempos de primera respuesta e identificar cuellos de botella en el proceso de distribución. Ayuda a analizar la eficiencia con la que los incidentes se dirigen al equipo adecuado. Dónde obtenerlo Se infiere a partir de la primera entrada del Registro de actividades del incidente que completa o modifica el campo «Group». Recopilar Identifique la primera marca de tiempo en la que se completa el campo «Group» de un incidente. Tipo de evento inferred
	Incidente cerrado	Representa el cierre formal y definitivo del registro del incidente. Normalmente ocurre de forma automática después de un periodo establecido en el estado «Resolved», aunque un agente también puede realizarlo manualmente. 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 confirmación del usuario. Dónde obtenerlo Inferido a partir del registro de actividad del incidente al identificar cuándo el campo «Status» se actualiza a «Closed». Recopilar Utilice 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 inicio del ciclo de vida del incidente y normalmente lo activa un usuario final a través de un portal o correo electrónico, o un agente del centro de servicios que crea un ticket en su nombre. Este evento se registra 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. Recopilar Utilice la marca de tiempo «Created at» del registro principal del incidente. Tipo de evento explicit
	Incidente priorizado	Se produce cuando se establece o actualiza la prioridad del incidente. El nivel de prioridad determina la urgencia y los objetivos de SLA para la resolución. Se captura mediante la supervisión de los cambios en el campo «Priority» del historial del incidente.
Por qué es importante Una priorización 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 infiere a partir del Registro de actividades del incidente, que registra todas las actualizaciones del campo «Priority». Recopilar Utilice las marcas de tiempo del Registro de auditoría en las que se estableció o modificó el valor del campo «Priority». Tipo de evento inferred
	Incidente resuelto	Marca el momento en que el agente ha implementado una solución y considera que el incidente está resuelto. Se captura cuando el estado del incidente cambia a «Resolved». En Freshservice, es un hito clave que detiene el contador del SLA.
Por qué es importante Este es un hito fundamental para medir el tiempo hasta la resolución, TTR. El periodo entre «Resolved» y «Closed» es importante para analizar los retrasos en la confirmación por parte del usuario y las políticas de cierre automático. Dónde obtenerlo Se infiere a partir del Registro de actividades del incidente al identificar cuándo se actualiza el campo «Status» a «Resolved». Recopilar Utilice la marca de tiempo de la entrada del Registro de actividades 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 mediante la adición de una nota de resolución. Es una acción diferenciada en Freshservice que se realiza antes de cambiar el estado a «Resolved». Tanto esta acción como su contenido quedan registrados explícitamente.
Por qué es importante Marca la identificación de una solución. El tiempo transcurrido entre este evento y el estado «Incident Resolved» puede indicar una revisión interna o una sobrecarga de documentación. Dónde obtenerlo Se captura a partir de la marca de tiempo en la que se añade una nota de resolución al incidente, registrada en el historial de conversaciones. Recopilar Identifique la marca de tiempo de la entrada «Resolution Note» en el Registro de conversaciones del incidente. Tipo de evento explicit
	Agente asignado al incidente	Esta actividad indica cuándo se asigna un agente específico para gestionar el incidente. Representa la responsabilidad individual sobre el ticket. La asignación queda registrada en el historial de actividades del ticket, donde se muestra 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 a un grupo. Es fundamental para los Dashboards de rendimiento de los agentes. Dónde obtenerlo Se realiza un seguimiento mediante los cambios en el campo «Agent» del Registro de actividades o del Registro de auditoría del incidente. Recopilar Identifique las marcas de tiempo correspondientes a los cambios en el campo «Agent». Tipo de evento inferred
	Estado cambiado a Pending	Representa un momento en el que el proceso de resolución se pausa, normalmente mientras se espera información del usuario o de un tercero. Se infiere a partir de un cambio de estado a cualquier estado «Pending». El tiempo transcurrido 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 los retrasos. Ayuda a separar el tiempo de trabajo del agente del tiempo de espera. Dónde obtenerlo Se infiere a partir del Registro de actividades del incidente cuando el campo «Status» se actualiza a un valor como «Pending» o «Awaiting User Response». Recopilar Filtre el Registro de actividades para localizar cambios de estado a cualquier estado pendiente y utilice la marca de tiempo asociada. Tipo de evento inferred
	Incidente reabierto	Se produce cuando un incidente marcado previamente como «Resolved» vuelve a un estado abierto, normalmente porque el usuario no está de acuerdo con la resolución. Se infiere mediante un cambio de estado de «Resolved» a un estado como «Open» o «In Progress».
Por qué es importante Una tasa elevada de reapertura apunta a problemas en la calidad de la resolución o a soluciones incompletas. Es una métrica clave para analizar el retrabajo y el rendimiento de los agentes. Dónde obtenerlo Inferido a partir del registro de actividad del incidente al detectar un cambio de estado de «Resolved» a un estado activo. Recopilar 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. Representa una transferencia en el proceso de resolución. Este evento se infiere al detectar cambios posteriores en los campos «Agent» o «Group» después de la asignación inicial.
Por qué es importante Las reasignaciones frecuentes, o transferencias, suelen indicar ineficiencias del proceso, carencias de conocimiento o un enrutamiento inicial incorrecto. Analizar estos eventos ayuda a identificar y reducir los retrasos. Dónde obtenerlo Se infiere a partir del Registro de actividades del incidente mediante el seguimiento de cualquier cambio en los campos «Agent» o «Group» después de la primera asignación. Recopilar Detecte los cambios en los campos «Agent» o «Group» del historial de auditoría del ticket. Tipo de evento inferred
	Objetivo de SLA incumplido	Es un evento calculado que se produce cuando el tiempo transcurrido en un incidente supera el objetivo de SLA definido para la respuesta o la resolución. Freshservice realiza un seguimiento interno del estado del SLA y este evento puede derivarse comparando 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 los incumplimientos es esencial para el Dashboard de rendimiento de los SLA y la mejora continua. Dónde obtenerlo Se calcula comparando la marca de tiempo de resolución o respuesta con la hora límite del objetivo de SLA. Freshservice suele marcar los tickets como «SLA Violated». Recopilar Derívelo comparando la marca de tiempo «Resolved at» con la marca de tiempo «Due by», o cuando el campo «SLA Status» cambie 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 haya notificado 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 interactúan con los nuevos incidentes. Dónde obtenerlo Se identifica localizando la marca de tiempo de la primera nota pública o respuesta añadida por un agente en el Registro de conversaciones del incidente. Recopilar Filtre el historial de conversaciones del incidente para localizar 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 capturarla, normalmente se requiere una configuración específica del sistema, como una casilla de verificación específica, un tipo de nota concreto o un análisis de palabras clave en las notas de los agentes.
Por qué es importante Esto ayuda a analizar la eficacia de las soluciones temporales para reducir el impacto en el negocio y su relación con el tiempo de resolución final. Es compatible con el panel de métricas de eficacia de las soluciones temporales. Dónde obtenerlo Probablemente no se trata de un evento explícito. Puede inferirse marcando las notas que contienen palabras clave como «workaround» o si se utiliza un campo personalizado «Workaround Provided» cuyo cambio queda registrado. Recopilar Se infiere a partir 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 acceder a informes y crearlos. Vaya al módulo Analítica desde el menú principal.
Cree un informe nuevo: Haga clic en el botón Nuevo informe. Proporcione un nombre descriptivo, como «Registro de eventos de gestión de incidentes». Cuando se le solicite seleccionar una fuente de datos, elija el módulo Gestión de incidentes.
Seleccione el widget del informe: Dentro del editor de informes, añada un widget nuevo y seleccione el tipo Tabla. Esta tabla será la base de los datos del Registro de eventos.
Añada las columnas de datos principales: En el panel de la fuente de datos situado a la derecha, arrastre y suelte los campos necesarios en la configuración de columnas de la tabla. Empiece por ID de incidente, Creado el, Agente, Grupo, Prioridad, Gravedad, Estado y Categoría.
Incorpore los datos de actividad: Para capturar eventos individuales, debe unir o incluir datos de las actividades del ticket. Añada la fuente de datos Actividades a su widget. Desde esta fuente, añada Realizado el, para la marca de tiempo del evento, y Descripción de la actividad u otros campos similares que describan el cambio ocurrido.
Cree una columna calculada «ActivityName»: Este es el paso más importante. Cree una columna calculada o un campo de fórmula nuevo. Utilice instrucciones IF anidadas o una función CASE para traducir los datos de actividad sin procesar a los valores de ActivityName necesarios. Consulte la sección Consulta para conocer la lógica detallada de cada una de las 14 actividades.
Configure «EventTimestamp»: Cree otra columna calculada para EventTimestamp. La lógica de esta columna debe seleccionar la marca de tiempo de Creado el para la actividad «Incidente notificado» y la marca de tiempo de Realizado el de la actividad para todos los demás eventos.
Aplique filtros al informe: Configure los filtros del informe para delimitar los datos. Como mínimo, establezca un filtro de intervalo de fechas en el campo «Creado el». Se recomienda un intervalo de los últimos 3 a 6 meses. También debe añadir un filtro para incluir solo los tickets cuyo «Tipo de ticket» sea «Incidente».
Ejecute y perfeccione el informe: Ejecute el informe para generar una vista previa de los datos. Revise el resultado para asegurarse de que las columnas ActivityName y EventTimestamp se rellenan correctamente. Ajuste las fórmulas y los filtros según sea necesario.
Guarde y exporte el informe: Cuando esté satisfecho con el resultado del informe, guárdelo. Utilice 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áticas del informe. Configure una programación, por ejemplo, diaria o semanal, para enviar el CSV a su correo electrónico o a otro destino.
Prepare los datos para la carga: Abra el archivo CSV exportado. Cambie el nombre de los encabezados de columna para que coincidan con el esquema necesario para ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Añada las columnas estáticas SourceSystem, con el valor «Freshservice», y LastDataUpdate, con la marca de tiempo actual. El archivo ya está listo para cargarse.

Configuración

Módulo Analytics: Esta extracción requiere acceso al módulo Analytics de Freshservice, disponible en planes superiores, como Pro o Enterprise.
Permisos necesarios: Su cuenta de usuario necesita un rol con permisos para crear, editar y ejecutar informes en el módulo Analytics.
Intervalo de fechas: Es fundamental establecer un filtro de intervalo de fechas sobre la fecha de creación del incidente 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 Ticket Type igual a Incident para excluir las solicitudes de servicio y otros tipos de tickets del análisis del proceso.
Campos calculados: El método depende en gran medida del uso de campos calculados, es decir, fórmulas, para obtener ActivityName y EventTimestamp para cada evento. Es conveniente conocer el editor de fórmulas de Freshservice.
Volumen de datos: Tenga en cuenta que esta extracción genera varias filas por cada incidente, una por cada actividad. En instancias grandes de Freshservice, el archivo CSV resultante puede ser muy grande, lo que afecta al tiempo de generación del informe y a la velocidad de exportación.

a 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 mediante pip: pip install requests pandas.
Genere una clave de API: Inicie sesión en su instancia de Freshservice como administrador. Vaya a Profile Settings haciendo clic en su imagen de perfil, situada en la esquina superior derecha. Acceda a la sección «API Key» y copie su clave de API personal. Trate esta clave 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 marcador de posición de FRESHSERVICE_DOMAIN, por ejemplo, 'yourcompany.freshservice.com', API_KEY, la clave que acaba de copiar, y START_DATE_STR, el inicio del periodo de extracción deseado en formato 'YYYY-MM-DD'.
Comprenda la lógica del script: El script obtiene primero todos los tickets de incidentes creados después de la fecha de inicio especificada. Recorre cada página de resultados devuelta por la API. Para cada ticket, realiza una segunda llamada a la API para recuperar su historial detallado de actividades.
Genere el registro de eventos: El script procesa los datos principales del ticket y su registro de actividades para identificar y crear registros para cada una de las 14 actividades empresariales requeridas. Por ejemplo, «Incident Reported» se crea a partir de la fecha de creación del ticket, mientras que «Status Changed to In Progress» se obtiene de una entrada específica del registro de actividades.
Obtenga eventos complejos: Se obtienen eventos como «SLA Target Breached». El script comprueba si se incumplió el SLA de resolución del ticket. Si es así, crea un evento con la fecha due_by, que marca el momento en que se produjo el incumplimiento.
Ejecute el script: Abra un terminal o símbolo del sistema, 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á actualizaciones del progreso en la consola e indicará cuántos tickets se han procesado. Según el número de tickets y los límites de frecuencia de la API, el proceso puede tardar un tiempo.
Revise el resultado: Cuando finalice el script, generará un archivo CSV llamado freshservice_incident_event_log.csv en el mismo directorio. Este archivo contiene el registro de eventos completo.
Prepárese para la carga: Abra el archivo CSV en un programa de hojas de cálculo para comprobar que las columnas IncidentId, ActivityName, EventTimestamp, etc., se han rellenado como esperaba. El archivo ya está listo para cargarse en ProcessMind u otra herramienta de Process Mining.

Configuración

FRESHSERVICE_DOMAIN: La URL específica de Freshservice de su empresa, por ejemplo, mycompany.freshservice.com. Es un parámetro obligatorio del script.
API_KEY: La clave de API personal de un usuario con permisos suficientes para leer todos los datos de incidentes. Es un parámetro obligatorio.
START_DATE_STR: La fecha de inicio de la extracción de datos en formato 'YYYY-MM-DD'. Se recomienda extraer inicialmente un periodo de 3 a 6 meses para obtener un análisis significativo.
PAGE_SIZE: Establézcalo en 100, el máximo permitido por la API de Freshservice, para minimizar el número de llamadas a la API y mejorar el rendimiento. Por lo general, no se recomienda cambiar este valor.
Limitación 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 de gran volumen, puede ser necesario ajustarla para evitar errores.
Permisos necesarios: La clave de API utilizada debe pertenecer a una cuenta de usuario, por ejemplo, una cuenta de servicio específica, con permisos de rol «SD Agent» como mínimo, para garantizar el acceso a todos los campos de tickets y registros de actividades necesarios en los distintos grupos del centro de soporte.

a 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 utilizar reglas de Workflow Automator, acciones de webhook, acceso a incidentes y acceso al historial de actividades de los 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. Utilice un objeto JSON por cada entrega de webhook con IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory y ResolutionSlaTargetTime. Configure el receptor para conservar la carga útil original del webhook y la marca de tiempo de entrega.
Cree una regla de Workflow Automator para la creación de incidentes. Configure la regla para que se ejecute cuando se cree un incidente 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 del incidente 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 utilizando los campos del incidente y el historial de actividades disponibles en su cuenta de Freshservice. Cada regla debe enviar un evento de webhook independiente cuando se produzca la actividad correspondiente. No dependa de ProcessMind para inferir actividades a partir de una instantánea final del incidente.
Configure una asignación explícita 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 o nota pública válida del agente, Incident Reassigned cuando Agent o Group cambie 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 únicamente cuando exista un indicador de solución alternativa 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 configurada de incumplimiento del SLA, 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 como JSON e incluya el identificador del incidente, el nombre de la actividad, la marca de tiempo del evento, el sistema de origen, la última actualización de datos y los atributos contextuales recomendados. Utilice las variables de webhook de Freshservice que exponga su cuenta. Si una variable obligatoria no está disponible en el editor de webhooks, complete el valor en el servicio receptor mediante una interfaz de Freshservice aprobada o déjelo vacío en lugar de inventarlo.
Configure la idempotencia y la gestión de entregas en el endpoint. Utilice un identificador de evento estable si Freshservice lo expone. De lo contrario, cree una clave de deduplicación a partir de IncidentId, ActivityName, EventTimestamp y el identificador de entrega de origen. Devuelva una respuesta HTTP correcta únicamente después de aceptar la carga útil de forma duradera.
Pruebe cada regla con incidentes controlados. Cree un incidente, asigne un grupo y un agente, cambie la prioridad y el estado, envíe una respuesta válida, añada una solución alternativa y una nota de resolución cuando estén configuradas, resuelva, reabra y cierre el incidente. Pruebe por separado un incumplimiento del SLA mediante una política o cola de prueba controlada. Confirme que cada actividad esperada llega como una carga útil de webhook independiente.
Deposite las cargas útiles de los webhooks en un área de preparación duradera, normalice las marcas de tiempo a una única zona horaria y convierta cada carga útil en una fila del registro de eventos. Conserve una fila por cada actividad explícita del webhook. Rellene 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 únicamente las entregas duplicadas exactas y conserve las actividades repetidas legítimas, como varios cambios de prioridad o transiciones de estado. Asegúrese de que IncidentId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate estén presentes en cada fila.
Exporte el registro de eventos normalizado como CSV u 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 el origen de eventos preparado a ProcessMind, asignando IncidentId como identificador del caso y ActivityName como campo de actividad.

Configuración

Ámbito del activador: Configure reglas de Workflow Automator independientes para la creación de incidentes y para cada condición de actualización. Una única regla amplia de actualización puede crear eventos duplicados o ambiguos, a menos que el receptor aplique una asignación estricta de actividades.
Carga útil del webhook: Incluya todos los atributos obligatorios en cada carga útil. Incluya los atributos recomendados cuando estén disponibles en el momento del evento. Conserve la carga útil sin procesar para auditorías y repeticiones.
Semántica de las actividades: Las asignaciones iniciales de grupo y agente deben distinguirse de los cambios posteriores. Los cambios posteriores generan Incident Reassigned, mientras que la asignación inicial genera la actividad de asignación inicial correspondiente.
Gestión de estados: Asigne los valores de estado exactos configurados en la cuenta de Freshservice. Si la cuenta utiliza estados personalizados de pendiente o abierto, configure asignaciones explícitas para esos valores.
Primera respuesta: Defina si una respuesta pública, una nota pública u otro tipo de comunicación cuenta como primera respuesta. Aplique la definición de forma coherente y emita el evento únicamente para la primera comunicación válida de cada incidente.
Detección de soluciones alternativas: 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, Workaround Provided no se puede identificar de forma fiable.
Incumplimiento del SLA: Configure un activador explícito de incumplimiento del SLA o un proceso programado independiente que compare la hora actual con ResolutionSlaTargetTime. Una instantánea final del incidente por sí sola 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 incidentes. Para la operación en tiempo real, comience la ingesta antes del periodo de análisis objetivo y conserve el historial de webhooks para repetir entregas.
Filtros: Aplique únicamente filtros aprobados de empresa, espacio de trabajo, departamento, servicio, categoría o fecha. No dé por supuestos nombres de campos ni sintaxis de filtros de Freshservice que no estén expuestos en la configuración de la cuenta.
Rendimiento: Utilice procesamiento asíncrono de webhooks, ponga en cola las solicitudes entrantes, agrupe las escrituras posteriores e indexe IncidentId y EventTimestamp. Evite las llamadas de enriquecimiento síncronas durante la recepción del webhook.
Fiabilidad: Configure reintentos, gestión de mensajes no entregables, supervisión y supresión de duplicados. Registre las entregas fallidas y repítalas después de corregir el problema.
Requisitos previos: Acceso de administrador, disponibilidad de Workflow Automator, permisos para webhooks, un endpoint HTTPS, configuración de autenticación, capacidades suficientes del plan de Freshservice y un proceso de carga o almacenamiento compatible con ProcessMind.
Seguridad: Utilice HTTPS, restrinja el acceso entrante cuando sea posible, rote las credenciales, minimice los campos sensibles y proteja las descripciones y notas de los incidentes si se incluyen en las cargas útiles.

a 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
};

¿Listo para comenzar?

Utilice esta plantilla para configurar correctamente sus datos y obtener información valiosa sobre sus flujos de trabajo de gestión de incidentes. Comience hoy su camino hacia tiempos de resolución optimizados.

Volver a la guía de mejora Descargar Template

Evite los incumplimientos del SLA: optimice hoy la gestión de incidentes

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

Inicie su prueba gratuita

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

Su Template de datos de gestión de incidentes

Su Template de datos de gestión de incidentes

Atributos de la gestión de incidentes

Actividades de gestión de incidentes

Guías de extracción

Exportación de datos del módulo Analytics de Freshservice a CSV

Pasos

Configuración

a Consulta de ejemplo config

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

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Evite los incumplimientos del SLA: optimice hoy la gestión de incidentes

Su Template de datos de gestión de incidentes

Su Template de datos de gestión de incidentes

Atributos de la gestión de incidentes

Actividades de gestión de incidentes

Guías de extracción

Exportación de datos del módulo Analytics de Freshservice a CSV

Pasos

Configuración

a Consulta de ejemplo config

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

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Evite los incumplimientos del SLA: optimice hoy la gestión de incidentes

Valoramos su privacidad