> Mejora Continua de Procesos > Gestión de Incidencias > Freshservice > Plantilla de Datos

Plantilla de Datos: Gestión de Incidentes

Freshservice

Atributos de Gestión de Incidencias (20) Actividades de Gestión de Incidencias (14) Guías de Extracción (3)

Su Plantilla de datos para la Gestión de Incidentes

Prepare sus datos de incidentes. Plantilla con atributos y actividades clave a recopilar, más guía de extracción. Agilice su proceso de análisis.

Atributos recomendados para recopilar
Actividades clave para el seguimiento
Guía de Extracción

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de Gestión de Incidencias

Estos son los campos de datos recomendados para su registro de eventos para un análisis exhaustivo del proceso de gestión de incidentes.

5 Requerido 7 Recomendado 8 Opcional

	Nombre	Descripción
	ID de Incidencia IncidentId	El identificador único para cada registro de incidente, que sirve como clave primaria para rastrear todo el ciclo de vida del incidente.
Descripción El ID del incidente es la piedra angular del análisis de la gestión de incidentes. Funciona como el Case ID, vinculando todas las actividades, marcas de tiempo y cambios de atributos en un recorrido único y coherente. En Process Mining, cada entrada del registro de eventos está asociada a un ID de incidente, lo que permite reconstruir el flujo de proceso de extremo a extremo para cada caso. Esto es esencial para calcular tiempos de ciclo, analizar variantes de proceso e identificar cuellos de botella específicos de cada caso. Sin un identificador único, sería imposible distinguir entre incidentes y analizar sus trayectorias desde que se informa hasta su resolución. Por qué es importante Identifica de forma única cada incidente, permitiendo el seguimiento y análisis de principio a fin de su ciclo de vida, desde la creación hasta el cierre. Dónde obtener Este es el identificador principal para un ticket, disponible a través de la API de Tickets de Freshservice como el campo 'id' en el objeto de ticket. Ejemplos INC-10234INC-10235INC-10236
	Nombre de la Actividad ActivityName	El nombre de la actividad de negocio o del evento que ocurrió en un momento concreto dentro del ciclo de vida del incidente.
Descripción El nombre de la actividad describe un paso o evento concreto dentro del proceso de gestión de incidentes, por ejemplo: 'Incidente asignado a un grupo', 'Estado cambiado a Pendiente' o 'Incidente resuelto'. Estas actividades se obtienen a partir de los cambios en los datos del incidente a lo largo del tiempo. Este atributo es clave para Process Mining, ya que define los nodos del mapa de proceso descubierto. Al analizar la secuencia y la frecuencia de estas actividades, las organizaciones pueden visualizar cómo se resuelven realmente los incidentes, identificar rutas habituales, detectar desviaciones del procedimiento estándar y localizar bucles de retrabajo, como reasignaciones frecuentes. Por qué es importante Define los pasos en el mapa de procesos, permitiendo la visualización y el análisis del flujo de resolución de incidentes, los cuellos de botella y las desviaciones. Dónde obtener Este atributo no es un campo directo en Freshservice, sino que se deriva de cambios en las propiedades del ticket como el estado, la prioridad, la asignación de agente/grupo y la adición de notas. Ejemplos Incidencia ReportadaIncidencia Asignada a GrupoNota de resolución agregadaIncidencia Resuelta
	Source System SourceSystem	El sistema del que se extrajeron los datos, típicamente 'Freshservice'.
Descripción Este atributo identifica el origen de los datos. Si bien en este contexto siempre será 'Freshservice', es un campo crucial en entornos donde los datos de múltiples sistemas podrían combinarse para una visión holística del proceso. Incluir el atributo Sistema Fuente es una buena práctica para la gobernanza de datos y la trazabilidad. Asegura la claridad sobre la procedencia de los datos, lo cual es importante para la validación, la depuración y la futura expansión del proyecto de Process Mining para incluir otros sistemas de gestión de servicios u operativos. Por qué es importante Asegura la trazabilidad y la gobernanza de datos al identificar claramente el origen de los datos de gestión de incidentes. Dónde obtener Este es típicamente un valor estático añadido durante el proceso de transformación de datos (ETL) para etiquetar el conjunto de datos. Ejemplos FreshserviceFreshservice-EUFreshservice-PROD
	Timestamp del Evento EventTimestamp	La fecha y hora exactas en que ocurrió la actividad o el evento.
Descripción La marca de tiempo del evento, o Start Time, señala el momento exacto en que ocurrió una actividad. Cada actividad en el ciclo de vida del incidente, desde su creación hasta su cierre, tiene una marca de tiempo asociada. Este atributo es crítico para todos los análisis de Process Mining basados en 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 construir dashboards que miden el cumplimiento de los SLA, los retrasos por traspasos y los tiempos de resolución. Por qué es importante Proporciona el orden cronológico de los eventos, lo cual es esencial para calcular duraciones, analizar tiempos de ciclo y comprender el rendimiento del proceso. Dónde obtener Esto se deriva de varios campos de marca de tiempo en Freshservice, como 'created_at', 'updated_at', y marcas de tiempo dentro de los registros de conversación o auditoría del ticket. Ejemplos 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Última actualización de datos LastDataUpdate	El timestamp que indica la última vez que los datos para este proceso se actualizaron o extrajeron.
Descripción Este atributo proporciona un timestamp de la última vez que se actualizó el conjunto de datos completo desde el sistema fuente. Es un campo de metadatos que se aplica a todo el dataset en lugar de a eventos individuales, pero a menudo se incluye a nivel de evento para mayor consistencia. En el análisis, esta información es vital para comprender la actualidad de los datos y la ventana de tiempo cubierta por los dashboards y los KPI. Ofrece a los usuarios confianza en la actualidad de los insights 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, asegurando que comprendan el marco de tiempo cubierto por el análisis. Dónde obtener Esta 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	El nombre o ID del agente de soporte actualmente asignado para resolver el incidente.
Descripción El agente asignado identifica a la persona de la mesa de servicio 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 de rendimiento, ya que permite dashboards que muestran la carga de trabajo por agente, el tiempo medio de resolución por agente y las tasas de resolución en el primer contacto. También se utiliza para analizar los traspasos entre agentes, que pueden ser una fuente de retrasos e ineficiencia. Al hacer seguimiento de las asignaciones, las personas responsables pueden detectar necesidades de formación y reconocer a quienes tienen un rendimiento destacado. Por qué es importante Permite el análisis del rendimiento del agente, la distribución de la carga de trabajo y el impacto de los traspasos de agentes en los tiempos de resolución. Dónde obtener Disponible en la API de Tickets de Freshservice como el campo 'responder_id'. Este ID se puede unir con la API de Agentes para obtener el nombre del agente. Ejemplos John DoeJane SmithSupportBot
	Categoría de Incidencia IncidentCategory	La categoría que se usa para clasificar el incidente, como Hardware, Software o Red.
Descripción La Categoría de Incidencia ofrece una forma de clasificar las incidencias según el tipo de problema reportado. Esta clasificación jerárquica ayuda a dirigir la incidencia al equipo correcto y es vital para el análisis de tendencias. Este atributo se utiliza en el dashboard 'Precisión en la Categorización de Incidencias' para analizar si una categorización inicial incorrecta conduce a tiempos de resolución más largos debido a reasignaciones. Al agrupar las incidencias por categoría, las organizaciones pueden identificar problemas recurrentes, comprender dónde se concentra la mayor parte del esfuerzo de soporte y personalizar las iniciativas de mejora. Por qué es importante Permite el análisis de las tendencias de incidentes y ayuda a determinar si una categorización incorrecta está causando retrasos en la resolución. Dónde obtener Este es un campo predeterminado pero personalizable en Freshservice. Está disponible en la API de Tickets como 'category', con campos relacionados 'sub_category' y 'item_category'. Ejemplos HardwareSoftwareProblema de redAcceso a la cuenta
	Estado de Incidencia IncidentStatus	El estado actual del incidente en su ciclo de vida, por ejemplo: Abierto, Pendiente, Resuelto o Cerrado.
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 proceso descubierto, como pasar de 'En progreso' a 'Pendiente' o de 'Resuelto' a 'Cerrado'. Este atributo es fundamental para entender el recorrido del incidente. Analizar el tiempo que cada incidente pasa en cada estado ayuda a identificar cuellos de botella, como incidentes que permanecen demasiado tiempo en 'Pendiente' esperando la respuesta de la persona usuaria. También es crucial para definir los puntos de inicio y fin al calcular los tiempos de ciclo. Por qué es importante Rastrea el progreso del incidente a lo largo de su ciclo de vida y ayuda a identificar etapas donde los retrasos son comunes. Dónde obtener Disponible en la API de Tickets de Freshservice como el campo 'status'. Los valores son numéricos. Ejemplos AbiertoEn ProgresoPendienteResueltoCerrado
	Grupo asignado AssignedGroup	El grupo o equipo de soporte actualmente asignado al incidente.
Descripción El grupo asignado indica qué equipo —por ejemplo, 'Soporte de nivel 1', 'Equipo de redes' o 'Administradores de bases de datos'— es responsable del incidente. Los cambios en este atributo señalan una escalada o transferencia entre equipos funcionales. Analizar el grupo asignado es clave para entender los retrasos por traspasos y transferencias. Process Mining puede visualizar el flujo de incidentes entre grupos, resaltar rutas de escalado comunes y medir el tiempo de espera hasta que cada grupo interviene. Esto ayuda a identificar cuellos de botella organizativos y oportunidades para agilizar la colaboración entre equipos. Por qué es importante Rastrea qué equipo es responsable, lo cual es crucial para analizar traspasos, escaladas y retrasos entre equipos. Dónde obtener Disponible en la API de Tickets de Freshservice como el campo 'group_id'. Este ID se puede unir con la API de Grupos para obtener el nombre del grupo. Ejemplos Mesa de AyudaOperaciones de redSoporte de infraestructura
	Prioridad de Incidencia IncidentPriority	El nivel de prioridad del incidente, que determina la urgencia de la respuesta y la resolución.
Descripción La Prioridad de Incidencia es un campo clave que determina la velocidad y el enfoque necesarios para manejar una incidencia. Se define típicamente en una escala como Baja, Media, Alta y Urgente, y a menudo impulsa los objetivos de SLA. En Process Mining, la prioridad es una dimensión crítica para el filtrado y el análisis. Permite comparar los procesos de resolución para incidencias de alta prioridad frente a las de baja prioridad, asegurando que los problemas críticos se gestionen de manera eficiente. Los dashboards a menudo segmentan métricas como el tiempo de ciclo y el cumplimiento del SLA por prioridad para proporcionar insights accionables a los gerentes de soporte. Por qué es importante Ayuda a priorizar 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 obtener Disponible en la API de Tickets de Freshservice como el campo 'priority'. Los valores son numéricos (p. ej., 1 para Baja, 4 para Urgente). Ejemplos BajoMedioAltoUrgente
	Severidad de Incidencia IncidentSeverity	El nivel de severidad del incidente, que indica su impacto en el negocio.
Descripción La Severidad de Incidencia mide el impacto que una incidencia tiene en el negocio, a menudo categorizada como Baja, Media, Alta o Crítica. Aunque relacionada con la prioridad, la severidad se centra en el impacto, mientras que la prioridad se enfoca en la urgencia. La combinación de severidad e impacto a menudo determina la prioridad final. Analizar por severidad ayuda a comprender qué tan bien la organización maneja las incidencias con consecuencias significativas para el negocio. Se utiliza en dashboards para segmentar los tiempos de resolución y el rendimiento del SLA, asegurando que los problemas más impactantes reciban el nivel adecuado de atención y recursos a lo largo de su ciclo de vida. Por qué es importante Mide el impacto comercial de un incidente, permitiendo un análisis centrado en mitigar los problemas más perjudiciales. Dónde obtener Este es un campo predeterminado en Freshservice, disponible a través de la API de Tickets como 'impact'. Los valores son numéricos. Ejemplos BajoMedioAlto
	Tiempo objetivo del SLA de resolución ResolutionSlaTargetTime	El timestamp que indica la fecha límite de resolución del incidente según su política de SLA.
Descripción Este atributo almacena la fecha y hora específicas que sirven como plazo para resolver un incidente. Este objetivo lo determina la política de Acuerdo de Nivel de Servicio (SLA) aplicada al ticket, que típicamente depende de factores como la prioridad. Este tiempo objetivo es esencial para calcular el KPI de 'Tasa de Cumplimiento de SLA' y para alimentar el dashboard de 'Rendimiento de SLA'. Al comparar el timestamp de resolución real con este objetivo, podemos determinar si un incidente se resolvió a tiempo o si incumplió su SLA. Esto es fundamental para medir el cumplimiento del nivel de servicio. Por qué es importante Proporciona la fecha límite de resolución, que es necesaria para calcular el cumplimiento del SLA y para identificar incidentes en riesgo. Dónde obtener Disponible en la API de Tickets de Freshservice 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	Un indicador calculado que indica si el incidente no se resolvió dentro del plazo objetivo de SLA establecido.
Descripción Este atributo booleano es una métrica calculada que indica si el tiempo de resolución de un incidente excedió su objetivo de SLA. Se obtiene al comparar el timestamp de resolución real con el ResolutionSlaTargetTime. Este indicador es una entrada directa para el KPI de 'Tasa de Cumplimiento de SLA' y el dashboard de 'Rendimiento de SLA'. Simplifica el análisis al proporcionar un resultado claro y binario para el rendimiento de SLA de cada incidente, permitiendo una fácil agregación y análisis de tendencias. Ayuda a identificar rápidamente el volumen y el porcentaje de incidentes que no cumplen con los compromisos de servicio. Por qué es importante Mide directamente el cumplimiento del SLA para cada incidente, facilitando el cálculo de las tasas de adherencia generales y la identificación de áreas problemáticas. Dónde obtener Este es un campo calculado, derivado durante la transformación de datos al comparar la marca de tiempo de 'Incidente Resuelto' con el campo 'ResolutionSlaTargetTime'. Ejemplos truefalse
	¿Se reabrió? IsReopened	Un indicador calculado que indica si un incidente se reabrió después de haber sido resuelto o cerrado.
Descripción Este atributo booleano es un indicador calculado que identifica los incidentes que se han reabierto. Se establece en true si un incidente, después de alcanzar un estado 'Resolved' o 'Closed', cambia su estado de nuevo a 'Open' o 'In Progress'. Este indicador es crítico para calcular el KPI de 'Tasa de Reapertura de Incidentes' y para el dashboard de 'Incidentes Recurrentes'. Una alta tasa de incidentes reabiertos puede indicar problemas con la calidad de la resolución inicial, un análisis de la causa raíz incompleto o un cierre prematuro. Analizar estos casos ayuda a mejorar la calidad y sostenibilidad de las soluciones. Por qué es importante Identifica fallas en el proceso de resolución, destacando incidentes donde la solución inicial fue ineficaz y condujo a retrabajo. Dónde obtener Es un campo calculado que se deriva de la secuencia de actividades en el registro de eventos. Su valor es verdadero si ocurre una actividad como 'Incidente Reabierto' o si una actividad en estado abierto sigue a una en estado cerrado para el mismo ID de Incidente. Ejemplos truefalse
	Canal de Reporte ReportingChannel	El método o canal por el que se registró el incidente, como Correo electrónico, Portal o Teléfono.
Descripción El Canal de Reporte, también conocido como el origen, identifica cómo un incidente ingresó al sistema de soporte. Los canales comunes incluyen el correo electrónico, un portal de autoservicio, las llamadas telefónicas o el chat. Analizar este atributo ayuda a evaluar la eficiencia de los diferentes canales de reporte. El dashboard de 'Eficiencia del Canal de Reporte' compara el volumen de incidentes y el tiempo promedio de resolución por canal para determinar qué métodos son más efectivos y cuáles podrían requerir mejoras en el proceso. Por ejemplo, los incidentes reportados a través del portal pueden resolverse más rápido si contienen información más estructurada desde el inicio. Por qué es importante Ayuda a identificar los canales de reporte más eficientes y revela oportunidades para mejorar el proceso de ingreso de incidentes. Dónde obtener Disponible en la API de Tickets de Freshservice como el campo 'source'. Los valores son numéricos. Ejemplos EmailPortalTeléfonoChat
	Causa Raíz RootCause	La razón subyacente o causa raíz que se identificó para el incidente después de la investigación.
Descripción El atributo Causa Raíz registra el problema fundamental que originó el incidente. Esta información es típicamente completada por los agentes de soporte durante o después de la resolución, como parte de un proceso de análisis de la causa raíz (RCA). Este atributo es crucial para el dashboard de 'Incidentes Recurrentes y Causas Raíz' y el KPI de 'Tasa de Finalización del Análisis de Causa Raíz'. Al analizar las causas raíz comunes, las organizaciones pueden pasar de la resolución reactiva de incidentes a una gestión proactiva de problemas, implementando soluciones permanentes que prevengan incidentes futuros y reduzcan los problemas recurrentes. Por qué es importante Permite una gestión proactiva de problemas al ayudar a identificar y eliminar las causas subyacentes de los incidentes recurrentes. Dónde obtener A menudo es un campo personalizado en Freshservice, ya que la funcionalidad predeterminada puede ser limitada. Verifique la configuración de 'Campos del Ticket' para un campo llamado 'Causa Raíz' o similar. Ejemplos Error de SoftwareError de configuración de redProblema de Capacitación del UsuarioFallo de Hardware
	Departamento de la persona solicitante RequestersDepartment	El departamento al que pertenece la persona usuaria que informó el incidente.
Descripción Este atributo identifica el departamento de negocio del solicitante, como 'Ventas', 'Finanzas' o 'TI'. Esta información típicamente se obtiene del perfil del usuario en Freshservice. Analizar los incidentes por el departamento del solicitante puede revelar si ciertas unidades de negocio se ven desproporcionadamente afectadas por problemas o si existen problemas específicos del departamento. Proporciona un contexto valioso para comprender el impacto comercial de los incidentes y puede ayudar a priorizar las soluciones que afectan a los departamentos críticos. Por qué es importante Proporciona contexto empresarial, permitiendo el análisis de tendencias de incidentes e impactos en departamentos específicos. Dónde obtener Esta información está vinculada al solicitante del ticket. Se puede recuperar del endpoint de la API 'Requesters' utilizando el requester_id del ticket, y luego accediendo al department_id y al nombre. Ejemplos VentasMarketingFinanzasRecursos Humanos
	Recuento de Traspasos HandoffCount	El número de veces que un incidente se transfirió entre distintos agentes o grupos.
Descripción Recuento de Traspasos es una métrica calculada que cuantifica el número de reasignaciones que experimenta un incidente durante su ciclo de vida. Cada cambio en el atributo 'AssignedAgent' o 'AssignedGroup' incrementa este recuento. Un alto recuento de traspasos a menudo es un indicador de ineficiencia del proceso, enrutamiento inicial incorrecto o falta de experiencia del agente. Esta métrica apoya directamente el KPI de 'Recuento de Traspasos de Incidentes' y el dashboard de 'Análisis de Demoras por Traspaso y Transferencia', ayudando a identificar incidentes o rutas de proceso con transferencias excesivas que provocan demoras. Por qué es importante Cuantifica el retrabajo y las reasignaciones, ayudando a identificar ineficiencias causadas por un enrutamiento incorrecto o brechas de conocimiento. Dónde obtener Esta es una métrica calculada que se obtiene al contar 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 Provisional Proporcionada WorkaroundProvided	Un indicador que señala si se proporcionó una solución temporal al usuario antes de la resolución final.
Descripción Este atributo booleano indica si se implementó una solución temporal o workaround para mitigar el impacto del incidente mientras se desarrollaba una solución permanente. Esto a menudo se rastrea mediante una casilla de verificación o un estado específico. En Process Mining, este atributo soporta el dashboard de 'Métricas de Efectividad de Workarounds'. Permite una comparación de los tiempos de resolución para incidentes con y sin workarounds, ayudando a determinar si la provisión de soluciones temporales reduce eficazmente la interrupción del negocio y contribuye a una resolución general más rápida desde la perspectiva del usuario. Por qué es importante Ayuda a medir la efectividad de las soluciones temporales para reducir el impacto del incidente y acelerar la resolución percibida. Dónde obtener Típicamente es un campo booleano (casilla de verificación) personalizado. Su existencia debe verificarse en la configuración de 'Campos del Ticket' de Freshservice. Ejemplos truefalse
	Tiempo de Ciclo de Resolución ResolutionCycleTime	El tiempo total transcurrido desde que un incidente se reportó por primera vez hasta que se resolvió.
Descripción El tiempo de ciclo de resolución es un indicador clave calculado para cada incidencia. Mide la duración total del proceso de gestión desde la perspectiva de la persona usuaria, desde el reporte inicial hasta la confirmación de la resolución. Esta métrica calculada es la base del dashboard 'Incident Resolution Cycle Time'. Se usa para medir la eficiencia global del proceso y suele analizarse por prioridad, categoría y agente. Identificar incidencias con tiempos de ciclo elevados ayuda a detectar demoras e ineficiencias sistémicas. Por qué es importante Es una medida principal del rendimiento del proceso, indicando directamente cuánto tiempo lleva resolver incidentes de principio a fin. Dónde obtener Esta es una métrica calculada. Representa la diferencia entre la marca de tiempo de la actividad 'Incidente Resuelto' y la actividad 'Incidente Reportado'. Ejemplos 259200000864000003600000

Requerido Recomendado Opcional

Actividades de Gestión de Incidencias

Estos son los pasos clave del proceso y los hitos a registrar en tu registro de eventos para un descubrimiento preciso del proceso y la identificación de cuellos de botella.

7 Recomendado 7 Opcional

	Actividad	Descripción
	Estado Cambiado a En Progreso	Esta actividad marca el inicio oficial de la investigación activa y el trabajo en el incidente. Se registra cuando un agente cambia el estado del incidente a 'In Progress'. Este es un cambio de estado estándar registrado en el historial de actividades del ticket.
Por qué es importante Este hito ayuda a diferenciar entre el tiempo de espera y el tiempo de trabajo activo. Analizar la duración en que un incidente permanece 'En Progreso' es clave para entender el esfuerzo de resolución. Dónde obtener Inferido del registro de actividad del incidente al identificar cuándo el campo 'Status' se actualiza a 'In Progress'. Capturar Filtre el registro de actividad para un cambio de estado a 'In Progress' y use su timestamp. Tipo de evento inferred
	Incidencia Asignada a Grupo	Representa la asignación inicial de una incidencia a un grupo de soporte. Puede hacerse automáticamente mediante reglas de enrutamiento o manualmente por una persona del equipo. Esta actividad se captura al registrar la primera vez que se completa el campo 'Grupo' en el registro de auditoría de la incidencia.
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 despacho. Ayuda a analizar la eficiencia con la que se enrutan los incidentes al equipo correcto. Dónde obtener Inferido de la primera entrada en el registro de actividad del incidente que completa o cambia el campo 'Group'. Capturar Identifique el primer timestamp donde el campo 'Group' se rellena para un incidente. Tipo de evento inferred
	Incidencia Cerrada	Representa el cierre final y formal del registro de la incidencia. Suele ocurrir automáticamente después de un periodo establecido en el estado 'Resuelto', o bien puede realizarse manualmente por un agente. Este evento marca el final del ciclo de vida de la incidencia.
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, incluyendo cualquier período de confirmación del usuario. Dónde obtener Inferido del registro de actividad del incidente al identificar cuándo el campo 'Status' se actualiza a 'Closed'. Capturar Utilice la marca de tiempo de la entrada del registro de actividad para el cambio de estado a 'Cerrado'. Tipo de evento inferred
	Incidencia Priorizada	Ocurre cuando se establece o actualiza la prioridad de la incidencia. El nivel de prioridad define la urgencia y los objetivos de SLA para su resolución. Se captura siguiendo los cambios en el campo 'Prioridad' dentro del historial de la incidencia.
Por qué es importante Una priorización incorrecta o tardía puede llevar a incumplimientos de los SLA y a una asignación ineficiente de recursos. Analizar esta actividad ayuda a asegurar que los incidentes críticos reciban atención inmediata. Dónde obtener Inferido del registro de actividad del incidente, que rastrea todas las actualizaciones del campo 'Priority'. Capturar Utilice las marcas de tiempo del registro de auditoría donde el valor del campo 'Prioridad' fue establecido o cambiado. Tipo de evento inferred
	Incidencia Reportada	Marca la creación de un nuevo registro de incidente en Freshservice. Este es el punto de partida del ciclo de vida del incidente, típicamente activado por un usuario final a través de un portal, correo electrónico, o un agente de mesa de servicio creando un ticket en su nombre. Este evento se registra explícitamente con un timestamp de creación.
Por qué es importante Esta actividad es el evento de inicio principal para todo el proceso. Analizar el tiempo desde este evento hasta la resolución es fundamental para medir los tiempos de ciclo generales y el cumplimiento de los SLA. Dónde obtener Capturado de la marca de tiempo de creación de la tabla de incidentes. Freshservice registra esto explícitamente para cada nuevo ticket. Capturar Utilice la marca de tiempo 'Creado en' del registro principal del incidente. Tipo de evento explicit
	Incidencia Resuelta	Marca el punto en el que el agente ha implementado una solución y considera el incidente resuelto. Esto se captura cuando el estado del incidente cambia a 'Resolved'. En Freshservice, este es un hito clave que detiene el reloj del SLA.
Por qué es importante Este es un hito crítico para medir el Tiempo de Resolución (TTR). El período entre 'Resuelto' y 'Cerrado' es importante para analizar los retrasos en la confirmación del usuario y las políticas de cierre automático. Dónde obtener Inferido del registro de actividad del incidente al identificar cuándo el campo 'Status' se actualiza a 'Resolved'. Capturar Utilice la marca de tiempo de la entrada del registro de actividad para el cambio de estado a 'Resuelto'. Tipo de evento inferred
	Nota de resolución agregada	Ocurre cuando un agente documenta la solución de la incidencia añadiendo una nota de resolución. En Freshservice es una acción independiente antes de cambiar el estado a 'Resuelto'. Esta acción y su contenido quedan registrados explícitamente.
Por qué es importante Esto marca la identificación de una solución. El tiempo entre este estado y el de 'Incidente Resuelto' puede indicar revisión interna o carga de documentación. Dónde obtener Capturado de la marca de tiempo cuando se agrega una nota de resolución al incidente, que se registra en el historial de conversación. Capturar Identifique el timestamp de la entrada 'Resolution Note' en el registro de conversación del incidente. Tipo de evento explicit
	Agente asignado al incidente	Esta actividad marca cuándo se asigna un agente específico para gestionar el incidente. Significa la propiedad individual del ticket. La asignación se registra en el historial de actividades del ticket, mostrando qué agente fue asignado y cuándo.
Por qué es importante Esto permite el análisis de la carga de trabajo del agente, el rendimiento y el tiempo que tarda un individuo en asumir un incidente después de la asignación a un grupo. Es crucial para los dashboards de rendimiento del agente. Dónde obtener Seguido a través de cambios en el campo 'Agente' dentro del registro de actividad o rastro de auditoría del incidente. Capturar Identifique los timestamps correspondientes a los cambios en el campo 'Agent'. Tipo de evento inferred
	Estado cambiado a Pendiente	Representa un punto en el que el proceso de resolución queda en pausa, normalmente mientras se espera información de la persona usuaria o de un tercero. Se infiere por un cambio de estado a cualquiera de los estados 'Pendiente'. El tiempo en este estado suele excluirse de los cálculos del SLA.
Por qué es importante Identificar el tiempo pasado en estados pendientes es crucial para comprender las dependencias externas y las demoras. Ayuda a aislar el tiempo de trabajo del agente del tiempo de espera. Dónde obtener Inferido del registro de actividad del incidente cuando el campo 'Status' se actualiza a un valor como 'Pending' o 'Awaiting User Response'. Capturar Filtre el registro de actividad para los cambios de estado a cualquier estado pendiente y use el timestamp asociado. Tipo de evento inferred
	Incidencia Reabierta	Ocurre cuando una incidencia previamente marcada como 'Resuelto' vuelve a un estado abierto, normalmente porque la persona usuaria no está de acuerdo con la resolución. Se infiere por un cambio de estado de 'Resuelto' a uno como 'Abierto' o 'En progreso'.
Por qué es importante Una alta tasa de reapertura indica problemas con la calidad de la resolución o correcciones incompletas. Esta es una métrica clave para analizar el retrabajo y el rendimiento del agente. Dónde obtener Inferido 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 un cambio de 'Status' de 'Resolved' a 'Open' o 'In Progress'. Tipo de evento inferred
	Incidencia Reasignada	Indica que el incidente fue transferido de un agente o grupo a otro. Esto significa un traspaso 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 traspasos, a menudo indican ineficiencias en el proceso, lagunas de conocimiento o un enrutamiento inicial incorrecto. Analizar estos eventos ayuda a identificar y reducir las demoras. Dónde obtener Inferido del registro de actividad del incidente al rastrear cualquier cambio en los campos 'Agent' o 'Group' después de la primera asignación. Capturar Detecta cambios en los campos 'Agent' o 'Group' en el historial de auditoría del ticket. Tipo de evento inferred
	Objetivo de SLA Incumplido	Este es un evento calculado que ocurre cuando el tiempo transcurrido en un incidente excede su objetivo de SLA definido para respuesta o resolución. Freshservice rastrea el estado de SLA internamente y este evento puede obtenerse comparando timestamps 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é ocurren los incumplimientos es esencial para el Dashboard de Rendimiento de SLA y la mejora continua. Dónde obtener Calculado comparando la marca de tiempo de resolución o respuesta con el plazo objetivo del SLA. Freshservice a menudo marca los tickets como 'SLA violado'. Capturar Se deriva comparando el timestamp 'Resolved at' con el timestamp '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 reportó el incidente. Puede ser una nota pública o una respuesta directa. Freshservice registra todas las comunicaciones del agente con timestamps.
Por qué es importante Cumplir el SLA de Primera Respuesta es un KPI crítico para la satisfacción del cliente. Esta actividad permite la medición y el análisis de la rapidez con la que los agentes interactúan con nuevos incidentes. Dónde obtener Identificado al encontrar el timestamp de la primera nota pública o respuesta añadida por un agente en el registro de conversación del incidente. Capturar Filtre el historial de conversaciones del incidente para la entrada más temprana realizada por un agente. Tipo de evento explicit
	Solución Provisional Proporcionada	Esta actividad significa que se ha comunicado una solución temporal o workaround al usuario para mitigar el impacto del incidente. La captura de esto a menudo requiere una configuración específica del sistema, como una casilla de verificación dedicada, un tipo de nota específico o un análisis de palabras clave en las notas del agente.
Por qué es importante Esto ayuda a analizar la efectividad de los workarounds en la reducción del impacto comercial y su relación con el tiempo de resolución final. Soporta el dashboard de 'Métricas de Efectividad de Workarounds'. Dónde obtener Probablemente no sea un evento explícito. Puede inferirse al marcar notas que contengan palabras clave como 'workaround', o si se utiliza un campo de casilla de verificación personalizado 'Workaround Provided' y se registra su cambio. Capturar Inferido de un cambio en un campo personalizado o del análisis de palabras clave en las notas del agente. Tipo de evento inferred

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Freshservice

Pasos

Acceder a Freshservice Analytics: Inicie sesión en su instancia de Freshservice con una cuenta que tenga permisos para acceder y crear informes. Navegue al módulo Analytics desde el menú principal.
Crear un nuevo informe: Haga clic en el botón New Report. Proporcione un nombre descriptivo, como "Registro de eventos de gestión de incidentes". Seleccione el módulo Incident Management cuando se le solicite elegir una fuente de datos.
Seleccionar un widget de informe: Dentro del editor de informes, agregue un nuevo widget y seleccione el tipo Table. Esto formará la base de sus datos de registro de eventos.
Agregar columnas de datos primarios: Desde el panel de fuente de datos a la derecha, arrastre y suelte los campos necesarios en la configuración de columnas de la tabla. Comience con Incident ID, Created at, Agent, Group, Priority, Severity, Status y Category.
Incorporar datos de actividad: Para capturar eventos individuales, debe unir o incluir datos de las actividades del ticket. Agregue la fuente de datos Activities a su widget. Desde esta fuente, agregue Performed at (para el timestamp del evento) y Activity description o campos similares que describan el cambio que ocurrió.
Crear una columna calculada 'ActivityName': Este es el paso más crítico. Cree una nueva columna calculada o campo de fórmula. Utilice sentencias IF anidadas o una función CASE para traducir los datos de actividad sin procesar a los valores ActivityName requeridos. Consulte la sección Query para la lógica detallada de cada una de las 14 actividades.
Configurar el 'EventTimestamp': Cree otra columna calculada para el EventTimestamp. La lógica para esta columna debe seleccionar el timestamp Created at para la actividad 'Incident Reported' y el timestamp Performed at de la actividad para todos los demás eventos.
Aplicar filtros de informe: Configure los filtros del informe para acotar los datos. Como mínimo, establezca un filtro de rango de fechas en el campo 'Created at'. Se recomienda un rango de los últimos 3 a 6 meses. También debe agregar un filtro para incluir solo tickets donde 'Ticket Type' sea 'Incident'.
Ejecutar y refinar el informe: Ejecute el informe para generar una vista previa de los datos. Revise la salida para asegurarse de que las columnas ActivityName y EventTimestamp se estén poblando correctamente. Ajuste las fórmulas y los filtros según sea necesario.
Guardar y exportar el informe: Una vez que esté satisfecho con la salida del informe, guárdelo. Use la opción Exportar y seleccione CSV como formato.
Programar la exportación (opcional): Para un análisis continuo, puede programar que el informe se ejecute y exporte automáticamente. Establezca un cronograma (por ejemplo, diario o semanal) para que el CSV se entregue a su correo electrónico u otro destino.
Preparar datos para la carga: Abra el archivo CSV exportado. Cambie el nombre de los encabezados de columna para que coincidan con el esquema requerido para ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Agregue las columnas estáticas SourceSystem (con el valor 'Freshservice') y LastDataUpdate (con el timestamp actual). El archivo ya está listo para ser cargado.

Configuración

Analytics Module: Esta extracción requiere acceso al módulo Analytics de Freshservice, que está disponible en planes de nivel superior (por ejemplo, Pro, Enterprise).
Permisos requeridos: Su cuenta de usuario necesita un rol con permisos para crear, editar y ejecutar informes en el módulo Analytics.
Rango de fechas: Es crucial establecer un filtro de rango de fechas en la fecha de creación del incidente para gestionar el volumen de datos. Se recomienda un período continuo de 3 a 6 meses para equilibrar el contexto histórico y el rendimiento.
Filtros de informe: Siempre filtre por 'Ticket Type' igual a 'Incident' para excluir solicitudes de servicio u otros tipos de tickets de su análisis de procesos.
Calculated Fields: El método se basa en gran medida en el uso de Calculated Fields (fórmulas) para derivar el ActivityName y el EventTimestamp para cada evento. Familiarizarse con el editor de fórmulas de Freshservice es beneficioso.
Volumen de datos: Tenga en cuenta que, por cada incidente, esta extracción genera múltiples filas (una por cada actividad). Para instancias grandes de Freshservice, el archivo CSV resultante puede volverse muy grande, afectando el tiempo de generación del informe y 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 Python 3.6+ instalado junto con las bibliotecas requests y pandas. Puede instalarlas usando pip: pip install requests pandas.
Generar clave de API: Inicie sesión en su instancia de Freshservice como administrador. Navegue a la Configuración de su Perfil haciendo clic en su foto de perfil en la esquina superior derecha. Vaya a la sección 'Clave de API' y copie su clave de API personal. Trate esta clave como una contraseña.
Configurar el script: Guarde el código Python proporcionado en un archivo llamado extract_freshservice_incidents.py en su máquina local.
Configurar parámetros: Abra el archivo del script en un editor de texto. Actualice los valores de los marcadores de posición para FRESHSERVICE_DOMAIN (p. ej., 'suempresa.freshservice.com'), API_KEY (la clave que acaba de copiar) y START_DATE_STR (el inicio de su período de extracción deseado en formato 'YYYY-MM-DD').
Comprender la lógica del script: El script primero recupera todos los tickets de incidente creados después de la fecha de inicio especificada. Itera a través de cada página de resultados devueltos por la API. Para cada ticket, realiza una segunda llamada a la API para recuperar su historial detallado de actividades.
Generación de Registro de eventos: El script procesa los datos principales del ticket y su registro de actividad para identificar y crear registros para cada una de las 14 actividades comerciales requeridas. Por ejemplo, 'Incidente reportado' se crea a partir de la fecha de creación del ticket, mientras que 'Estado cambiado a en progreso' se deriva de una entrada específica en el registro de actividad.
Derivar eventos complejos: El script deriva eventos complejos como 'Objetivo de SLA incumplido'. Verifica si se violó el SLA de resolución de un ticket. Si es así, crea un evento con la fecha due_by como marca de tiempo, registrando el momento en que ocurrió la infracción.
Ejecutar el script: Abra una terminal o un símbolo del sistema, navegue hasta el directorio donde guardó el script y ejecútelo usando el comando: python extract_freshservice_incidents.py.
Monitorear la ejecución: El script imprimirá actualizaciones de progreso en la consola, mostrando cuántos tickets se han procesado. Dependiendo del número de tickets y de los límites de solicitudes de la API, esto puede llevar algún tiempo.
Revisar el resultado: Una vez que el script finalice, generará un archivo CSV llamado freshservice_incident_event_log.csv en el mismo directorio. Este archivo contiene el registro de eventos completo.
Preparar para la carga: Abra el archivo CSV en un programa de hoja de cálculo para asegurarse de que las columnas (IncidentId, ActivityName, EventTimestamp, etc.) se completen según lo esperado. El archivo ya está listo para ser cargado en ProcessMind u otra herramienta de Process Mining.

Configuración

FRESHSERVICE_DOMAIN: La URL específica de su empresa en Freshservice, por ejemplo, mycompany.freshservice.com. Este es un parámetro obligatorio en el script.
API_KEY: La clave API personal de un usuario con permisos suficientes para leer todos los datos de incidentes. Este es un parámetro obligatorio.
START_DATE_STR: La fecha de inicio para la extracción de datos en formato 'YYYY-MM-DD'. Se recomienda extraer un período inicial de 3 a 6 meses de datos para un análisis significativo.
PAGE_SIZE: Establecido 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. Generalmente no se recomienda cambiar este valor.
API Rate Limiting: 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. Para instancias de alto volumen, esto podría necesitar ajustarse para evitar errores.
Required Permissions: La clave API utilizada debe pertenecer a una cuenta de usuario (por ejemplo, una cuenta de servicio dedicada) con al menos permisos de rol de 'SD Agent' para asegurar que pueda acceder a todos los campos de tickets y registros de actividad necesarios en los diferentes grupos de la mesa de servicio.

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

Acceder a Freshservice Analytics: Inicie sesión en su instancia de Freshservice con una cuenta que tenga permisos para acceder y crear informes. Navegue al módulo Analytics desde el menú principal.
Crear un nuevo informe: Haga clic en el botón New Report. Proporcione un nombre descriptivo, como "Registro de eventos de gestión de incidentes". Seleccione el módulo Incident Management cuando se le solicite elegir una fuente de datos.
Seleccionar un widget de informe: Dentro del editor de informes, agregue un nuevo widget y seleccione el tipo Table. Esto formará la base de sus datos de registro de eventos.
Agregar columnas de datos primarios: Desde el panel de fuente de datos a la derecha, arrastre y suelte los campos necesarios en la configuración de columnas de la tabla. Comience con Incident ID, Created at, Agent, Group, Priority, Severity, Status y Category.
Incorporar datos de actividad: Para capturar eventos individuales, debe unir o incluir datos de las actividades del ticket. Agregue la fuente de datos Activities a su widget. Desde esta fuente, agregue Performed at (para el timestamp del evento) y Activity description o campos similares que describan el cambio que ocurrió.
Crear una columna calculada 'ActivityName': Este es el paso más crítico. Cree una nueva columna calculada o campo de fórmula. Utilice sentencias IF anidadas o una función CASE para traducir los datos de actividad sin procesar a los valores ActivityName requeridos. Consulte la sección Query para la lógica detallada de cada una de las 14 actividades.
Configurar el 'EventTimestamp': Cree otra columna calculada para el EventTimestamp. La lógica para esta columna debe seleccionar el timestamp Created at para la actividad 'Incident Reported' y el timestamp Performed at de la actividad para todos los demás eventos.
Aplicar filtros de informe: Configure los filtros del informe para acotar los datos. Como mínimo, establezca un filtro de rango de fechas en el campo 'Created at'. Se recomienda un rango de los últimos 3 a 6 meses. También debe agregar un filtro para incluir solo tickets donde 'Ticket Type' sea 'Incident'.
Ejecutar y refinar el informe: Ejecute el informe para generar una vista previa de los datos. Revise la salida para asegurarse de que las columnas ActivityName y EventTimestamp se estén poblando correctamente. Ajuste las fórmulas y los filtros según sea necesario.
Guardar y exportar el informe: Una vez que esté satisfecho con la salida del informe, guárdelo. Use la opción Exportar y seleccione CSV como formato.
Programar la exportación (opcional): Para un análisis continuo, puede programar que el informe se ejecute y exporte automáticamente. Establezca un cronograma (por ejemplo, diario o semanal) para que el CSV se entregue a su correo electrónico u otro destino.
Preparar datos para la carga: Abra el archivo CSV exportado. Cambie el nombre de los encabezados de columna para que coincidan con el esquema requerido para ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Agregue las columnas estáticas SourceSystem (con el valor 'Freshservice') y LastDataUpdate (con el timestamp actual). El archivo ya está listo para ser cargado.

Configuración

Analytics Module: Esta extracción requiere acceso al módulo Analytics de Freshservice, que está disponible en planes de nivel superior (por ejemplo, Pro, Enterprise).
Permisos requeridos: Su cuenta de usuario necesita un rol con permisos para crear, editar y ejecutar informes en el módulo Analytics.
Rango de fechas: Es crucial establecer un filtro de rango de fechas en la fecha de creación del incidente para gestionar el volumen de datos. Se recomienda un período continuo de 3 a 6 meses para equilibrar el contexto histórico y el rendimiento.
Filtros de informe: Siempre filtre por 'Ticket Type' igual a 'Incident' para excluir solicitudes de servicio u otros tipos de tickets de su análisis de procesos.
Calculated Fields: El método se basa en gran medida en el uso de Calculated Fields (fórmulas) para derivar el ActivityName y el EventTimestamp para cada evento. Familiarizarse con el editor de fórmulas de Freshservice es beneficioso.
Volumen de datos: Tenga en cuenta que, por cada incidente, esta extracción genera múltiples filas (una por cada actividad). Para instancias grandes de Freshservice, el archivo CSV resultante puede volverse muy grande, afectando el tiempo de generación del informe y 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'

Plantilla de Datos: Gestión de Incidentes

Su Plantilla de datos para la Gestión de Incidentes

Atributos de Gestión de Incidencias

Actividades de Gestión de Incidencias

Guías de Extracción

Exportación de Datos del Módulo de Analíticas de Freshservice a CSV

Pasos

Configuración

a Consulta de ejemplo config

Extracción con script en 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 incumplir los SLA: optimice la gestión de incidentes hoy