> Mejora continua de procesos > Gestión de solicitudes de servicio > Freshservice > Template de datos

Su Template de datos para la gestión de solicitudes de servicio

Freshservice

Atributos de la gestión de solicitudes de servicio (19) Actividades de la gestión de solicitudes de servicio (15) Guías de extracción (3)

Su Template de datos para la gestión de solicitudes de servicio

Esta plantilla ofrece una guía completa para recopilar los datos necesarios para analizar su proceso de gestión de solicitudes de servicio. Describe los atributos esenciales, las actividades clave que debe supervisar y recomendaciones prácticas para extraer esta información de sus sistemas de origen. Utilice este recurso para crear un Registro de eventos sólido que permita realizar un análisis detallado del proceso.

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 solicitudes de servicio

Estos son los campos de datos recomendados para incluir en su registro de eventos y obtener un análisis completo del proceso de gestión de solicitudes de servicio.

5 Obligatorio 5 Recomendado 9 Opcional

	Nombre	Descripción
	Hora del evento EventTime	La marca de tiempo exacta en la que ocurrió la actividad.
Descripción La hora del evento registra la fecha y la hora en que se registró una actividad específica de un Service Request. Esta marca de tiempo es fundamental para ordenar correctamente los eventos y calcular la duración entre ellos. En Process Mining, este atributo se utiliza para ordenar las actividades de cada caso y constituye la base de todos los análisis basados en el tiempo. Se utiliza para calcular tiempos de ciclo, tiempos de espera entre actividades y cumplimiento de los acuerdos de nivel de servicio (SLA). Las marcas de tiempo precisas son esenciales para identificar cuellos de botella y comprender el rendimiento del proceso. Por qué es importante Esta marca de tiempo ordena cronológicamente los eventos y constituye la base de todos los análisis de rendimiento, incluidos el tiempo de ciclo y la detección de cuellos de botella. Dónde obtenerlo Corresponde a la marca de tiempo de creación de una actividad o entrada del registro de auditoría en Freshservice. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	ID de la solicitud de servicio ServiceRequestId	El identificador único de cada Service Request.
Descripción El Service Request ID es un número o código único asignado a cada nuevo Service Request registrado en Freshservice. Actúa como clave principal para realizar el seguimiento de todo el ciclo de vida de la solicitud, desde su creación hasta su cierre. En Process Mining, este ID es fundamental porque actúa como Case ID. Todos los eventos relacionados, como cambios de estado, asignaciones de agentes y notas, se vinculan mediante este identificador. Analizar el recorrido de cada Service Request ID permite visualizar el proceso completo de principio a fin, identificar las rutas habituales y detectar desviaciones o cuellos de botella que afectan a casos individuales. Por qué es importante Este es el Case ID esencial que conecta todos los eventos relacionados y permite rastrear el recorrido completo de un único Service Request. Dónde obtenerlo Es un campo principal del objeto ticket en Freshservice. Está visible en la interfaz de usuario y disponible a través de la API de Freshservice. Ejemplos SR-12943SR-13501SR-14011
	Nombre de la actividad ActivityName	El nombre del evento o la tarea que ocurrió en un momento específico para un Service Request.
Descripción El nombre de la actividad describe un paso o evento específico dentro del ciclo de vida de Service Request. Estas actividades se extraen de los registros de auditoría del sistema, los cambios de estado o acciones concretas realizadas por los usuarios, como «Request Assigned to Agent», «Note Added» o «Service Request Resolved». Este atributo es fundamental para construir el mapa de procesos, que representa visualmente el flujo de Service Request. Al analizar la secuencia y la frecuencia de las distintas actividades, las organizaciones pueden comprender el proceso real, identificar cuellos de botella entre pasos, medir la duración de las actividades y detectar variantes del proceso que no cumplen las normas o son ineficientes. Por qué es importante Este atributo define los pasos del mapa de procesos y permite visualizar y analizar el Workflow de Service Request. Dónde obtenerlo Se genera a partir de las «activities» o «audits» asociadas a un ticket en Freshservice. A menudo requiere lógica de transformación para asignar nombres de actividad comprensibles para el negocio a los eventos del sistema. Ejemplos Service Request creadoSolicitud asignada a un agenteService Request resueltoService Request cerrado
	Sistema de origen SourceSystem	Identifica el sistema del que se extrajeron los datos.
Descripción Este atributo especifica el sistema de origen de los datos del proceso, que en este caso es Freshservice. Resulta especialmente útil en entornos donde se consolidan datos de varios sistemas para obtener una visión integral del proceso. Aunque pueda parecer redundante en un análisis de un solo sistema, incluir este atributo es una buena práctica para facilitar la escalabilidad futura y la gobernanza de datos. Garantiza la claridad sobre la procedencia de los datos y ayuda a gestionar las canalizaciones de integración de datos. Por qué es importante Garantiza la procedencia y la trazabilidad de los datos, aspectos fundamentales al combinar datos de varios sistemas o para fines de gobernanza de datos. Dónde obtenerlo Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos (ETL). Ejemplos FreshserviceFreshservice-API-v2
	Última actualización de datos LastDataUpdate	Marca de tiempo que indica cuándo se actualizaron por última vez los datos del sistema de origen.
Descripción Este atributo registra la fecha y la hora en que el conjunto de datos se extrajo o actualizó por última vez desde Freshservice. Proporciona contexto sobre la actualidad de los datos analizados. En cualquier análisis de procesos, conocer la actualización de los datos es fundamental. Esta marca de tiempo ayuda a los usuarios a saber si consultan la información más reciente, algo esencial para tomar decisiones operativas oportunas y confiar en las conclusiones derivadas del análisis. Por qué es importante Informa a los usuarios sobre la actualidad de los datos y garantiza que los análisis y las decisiones se basen en información actualizada. Dónde obtenerlo Este valor se genera y se incorpora al conjunto de datos durante el proceso de extracción y transformación de datos (ETL). Ejemplos 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Agente asignado AssignedAgent	El nombre del agente que actualmente tiene asignado el Service Request.
Descripción Este atributo identifica al agente de soporte específico responsable de gestionar el Service Request en un momento determinado. Las asignaciones de agentes pueden cambiar durante el ciclo de vida de una solicitud. Analizar el agente asignado es clave para comprender el rendimiento de los agentes y la distribución de la carga de trabajo. Permite calcular KPI como el tiempo medio de resolución por agente, el número de solicitudes activas y las tasas de reasignación. Esto ayuda a identificar a los agentes con mejor rendimiento, a quienes pueden necesitar formación adicional y los desequilibrios en la distribución de la carga de trabajo. Por qué es importante Permite analizar la carga de trabajo y el rendimiento de los agentes, así como el impacto de las reasignaciones en los tiempos de resolución. Dónde obtenerlo Está disponible como campo «agent» o «responder» en el objeto ticket de Freshservice. Ejemplos Alice JohnsonRobert SmithSin asignar
	Equipo asignado AssignedTeam	El equipo o grupo de soporte asignado para gestionar el Service Request.
Descripción Este atributo indica el grupo o equipo funcional, como «IT Support Level 2» o «Hardware Procurement», responsable del Service Request. Una solicitud puede asignarse a un equipo antes de que un agente concreto la atienda. Analizar por equipo asignado ayuda a comprender el rendimiento y la carga de trabajo a nivel de equipo, así como a identificar cuellos de botella específicos de determinadas áreas funcionales. Es fundamental para evaluar la eficiencia con la que los distintos equipos procesan las solicitudes y optimizar la asignación de recursos en toda la organización de soporte. Por qué es importante Permite analizar el rendimiento y la carga de trabajo a nivel de equipo o grupo, algo esencial para gestionar recursos e identificar cuellos de botella funcionales. Dónde obtenerlo Está disponible como campo «group» en el objeto ticket de Freshservice. Ejemplos Mesa de serviciosOperaciones de redSoporte de aplicaciones
	Estado Status	El estado actual del Service Request dentro de su ciclo de vida.
Descripción El campo de estado representa la situación del Service Request en un momento determinado, por ejemplo, «Open», «Pending», «Resolved» o «Closed». Los cambios de estado suelen ser la principal fuente de actividades para Process Mining. Analizar el estado proporciona contexto sobre el flujo del proceso y ayuda a comprender cuánto tiempo permanecen las solicitudes en determinados estados. Por ejemplo, una duración prolongada en el estado «Pending» podría indicar un cuello de botella a la espera de información del solicitante o de un proveedor externo. Es un atributo clave para definir los puntos de inicio y final de las distintas etapas del proceso. Por qué es importante Proporciona un contexto esencial para cada evento y ayuda a medir el tiempo transcurrido en distintos estados, como «Open» o «Pending», para identificar retrasos. Dónde obtenerlo Está disponible como campo «status» en el objeto ticket de Freshservice. Ejemplos AbiertoPendienteResueltoCerrado
	Prioridad Priority	El nivel de prioridad del Service Request, como Low, Medium, High o Urgent.
Descripción La prioridad indica la importancia y la urgencia de un Service Request, y suele determinar el tiempo objetivo de resolución y los recursos asignados. La prioridad puede establecerse automáticamente mediante reglas o manualmente por los agentes. En Process Mining, la prioridad es una dimensión crítica para el análisis. Se utiliza para segmentar las solicitudes y comparar los flujos y el rendimiento de los procesos de los elementos de alta y baja prioridad. Es esencial para analizar el cumplimiento de los SLA y comprender si la priorización se realiza de forma eficaz y rápida durante la clasificación inicial. Por qué es importante Es fundamental para analizar el cumplimiento de los SLA y comprender si las solicitudes se clasifican y gestionan de acuerdo con su impacto empresarial. Dónde obtenerlo Está disponible como campo «priority» en el objeto ticket de Freshservice. Ejemplos BajaMediaAltaUrgente
	Tipo de servicio ServiceType	El tipo o la categoría específicos del servicio solicitado.
Descripción El tipo de servicio clasifica la solicitud según el servicio necesario, como «New Hardware Request», «Software Access» o «Password Reset». A menudo está vinculado al elemento del catálogo de servicios seleccionado por el usuario. Este atributo permite segmentar los Service Request para comparar los procesos y el rendimiento de distintos tipos de servicios. Es esencial para calcular KPI como «Average Activity Count per Service Type», que ayuda a identificar qué servicios son más complejos o requieren más recursos. Este análisis puede impulsar iniciativas de simplificación y automatización para tipos de servicio específicos. Por qué es importante Permite comparar los flujos y la complejidad de los procesos entre distintas categorías de solicitudes, lo que ayuda a identificar áreas que pueden estandarizarse o automatizarse. Dónde obtenerlo A menudo corresponde a «category», «item» o a un campo personalizado del objeto ticket en Freshservice, según la configuración. Ejemplos Incorporación de nuevo personalSolicitud de licencia de softwareAcceso VPN
	¿Es retrabajo? IsRework	Indicador booleano que señala si la solicitud incluyó actividades de retrabajo.
Descripción Este indicador calculado se establece en verdadero si una solicitud de servicio pasa por determinadas actividades que indican retrabajo. Algunos ejemplos son la reapertura después de la resolución («Service Request Reopened»), varias reasignaciones o solicitudes repetidas de información a la persona solicitante («Information Requested from Requestor»). Este atributo simplifica el análisis de las ineficiencias del proceso. Permite filtrar fácilmente los casos con retrabajo y comparar sus mapas de proceso y tiempos de ciclo con los de casos «limpios». Respaldan directamente el Dashboard «Análisis del retrabajo en solicitudes de servicio» y ayudan a cuantificar el impacto de las transferencias ineficientes o de la información inicial incompleta. Por qué es importante Ofrece una forma sencilla de marcar y analizar los casos que incluyen ciclos ineficientes o pasos repetidos, lo que ayuda a cuantificar el coste de la mala calidad. Dónde obtenerlo Se calcula durante la transformación de datos aplicando la lógica empresarial a la secuencia de actividades de cada «ServiceRequestId». Ejemplos truefalse
	¿Se incumplió el SLA? IsSlaBreached	Indicador booleano que señala si la solicitud de servicio superó el objetivo de resolución establecido en el SLA.
Descripción Este atributo calculado es un indicador sencillo de verdadero o falso que señala si la solicitud de servicio se cerró después de la fecha límite de su SLA. Se obtiene comparando la marca de tiempo de «Service Request Closed» o «Service Request Resolved» con «SlaDueDate». Este atributo simplifica el análisis y la visualización en el Dashboard de cumplimiento del SLA. Permite filtrar y agregar fácilmente los datos para calcular el KPI general de tasa de cumplimiento del SLA. La segmentación mediante este indicador ayuda a aislar y analizar rápidamente las características del proceso de las solicitudes incumplidas frente a las resueltas a tiempo. Por qué es importante Simplifica el análisis del cumplimiento del SLA al proporcionar un indicador claro para filtrar y agregar las solicitudes que no alcanzaron sus objetivos. Dónde obtenerlo Es un campo calculado que se obtiene durante la transformación de datos al comparar la marca de tiempo de resolución final con el campo «SlaDueDate». Ejemplos truefalse
	Canal Channel	El método o canal a través del cual se envió el Service Request.
Descripción El canal indica cómo se creó el Service Request, por ejemplo, mediante el portal de autoservicio, correo electrónico, llamada telefónica o chat. Esta información ayuda a comprender las preferencias de los usuarios y la eficiencia de cada canal. Analizar el proceso por canal puede revelar información importante. Por ejemplo, las solicitudes enviadas a través del portal pueden estar más completas y resolverse más rápido que las enviadas por correo electrónico, que podrían requerir más intercambios de comunicación. Este análisis puede orientar las iniciativas para promover canales más eficientes. Por qué es importante Ayuda a analizar si el canal de envío afecta la eficiencia del proceso, el tiempo de resolución o la cantidad de retrabajo necesaria. Dónde obtenerlo Está disponible como campo «source» en el objeto ticket de Freshservice. Ejemplos Correo electrónicoPortalTeléfonoChat
	Departamento del solicitante RequestorDepartment	El departamento al que pertenece el solicitante.
Descripción Este atributo especifica el departamento organizativo del usuario que envió el Service Request, como «Sales», «Finance» o «Human Resources». Normalmente, esta información procede del perfil del usuario en el sistema. Analizar el rendimiento del proceso por departamento es un requisito habitual. Puede mostrar si determinados departamentos experimentan tiempos de resolución más largos o tienen necesidades específicas. Esta información puede orientar la asignación de recursos, las iniciativas de formación o la creación de servicios adaptados a cada departamento. Por qué es importante Permite segmentar el proceso por unidad de negocio y ayuda a identificar problemas específicos de cada departamento o variaciones en el rendimiento. Dónde obtenerlo Esta información está vinculada al perfil del solicitante. Puede encontrarse en un campo predeterminado «department» o en un campo de usuario personalizado de Freshservice. Ejemplos FinanzasMarketingTecnologías de la información
	Fecha límite del SLA SlaDueDate	La marca de tiempo límite en la que se espera resolver la solicitud de servicio según su SLA.
Descripción Este atributo especifica la fecha límite para resolver la solicitud de servicio, tal como la define la política de SLA aplicable. Es una marca de tiempo calculada a partir de la hora de creación de la solicitud, su prioridad y el horario laboral definido en el SLA. Este es un dato fundamental para supervisar el rendimiento en tiempo real y analizar posteriormente el cumplimiento del SLA. Al comparar la hora real de resolución con SlaDueDate, se puede determinar si el SLA se ha «Cumplido» o «Incumplido». Es la base para calcular el KPI de tasa de cumplimiento del SLA. Por qué es importante Esta es la fecha límite objetivo de resolución y sirve de base para calcular si una solicitud de servicio cumplió o incumplió su SLA. Dónde obtenerlo Es un campo calculado de Freshservice, visible en el ticket como «Due by». Está disponible mediante la API. Ejemplos 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	Hora de finalización EndTime	La marca de tiempo exacta en la que se completó la actividad.
Descripción La hora de finalización representa la marca de tiempo de finalización de una actividad. En muchos eventos de Freshservice, la hora de inicio y la de finalización coinciden, por lo que son eventos puntuales. Sin embargo, en las actividades basadas en estados, la hora de finalización sería la marca de tiempo del siguiente cambio de estado. Este atributo es esencial para calcular la duración de las actividades y los tiempos de espera entre ellas. Al restar StartTime de EndTime, se puede determinar el tiempo de procesamiento de una tarea específica. Esto resulta fundamental para identificar las actividades que consumen más tiempo y que son las principales candidatas a optimización. Por qué es importante Permite calcular la duración de las actividades, algo fundamental para identificar cuellos de botella y medir los tiempos de procesamiento de cada paso. Dónde obtenerlo No es un campo directo de los registros de Freshservice. Debe derivarse tomando la marca de tiempo del evento posterior en la secuencia de una solicitud de servicio determinada. Ejemplos 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Nombre de la política de SLA SlaPolicyName	El nombre de la política de Acuerdo de Nivel de Servicio (SLA) aplicada a la solicitud.
Descripción Este atributo identifica la política de SLA específica que establece los tiempos objetivo de respuesta y resolución del Service Request. Las políticas suelen basarse en factores como la prioridad, el tipo de servicio o el grupo del solicitante. Saber qué política de SLA se aplica es esencial para el Dashboard de análisis de cumplimiento e incumplimiento de SLA. Permite medir con precisión el rendimiento frente a los objetivos definidos y analizar qué políticas se incumplen con mayor frecuencia. Esto puede dar lugar a revisiones del rendimiento del proceso o de la viabilidad de los propios objetivos de los SLA. Por qué es importante Identifica los objetivos de servicio específicos con los que se mide la solicitud, algo esencial para elaborar informes precisos sobre el cumplimiento de los SLA. Dónde obtenerlo Esta información forma parte de los datos del SLA asociados a un ticket. Puede ser necesario consultar endpoints o campos específicos de la API relacionados con los SLA. Ejemplos Incidentes de alta prioridad: 4 horasSolicitudes estándar: 3 díasSoporte VIP: 1 hora
	Número de reasignaciones ReassignmentCount	El número total de veces que una solicitud de servicio se ha reasignado a otro agente o equipo.
Descripción Este atributo calculado cuenta las apariciones de «Request Reassigned» o de actividades similares para cada solicitud de servicio. Un número elevado de reasignaciones suele indicar problemas en la clasificación inicial, un enrutamiento incorrecto basado en habilidades o desequilibrios en la carga de trabajo. Este atributo respalda directamente el Dashboard «Rendimiento de los agentes y distribución de la carga de trabajo» y el KPI «Promedio de reasignaciones por solicitud». El análisis de esta métrica ayuda a las organizaciones a identificar debilidades del proceso que hacen que los tickets pasen de un equipo a otro, lo que aumenta el tiempo de resolución y genera frustración tanto en los agentes como en las personas solicitantes. Por qué es importante Mide la ineficiencia del enrutamiento y la fricción del proceso. Un número elevado indica problemas en la clasificación inicial o en la carga de trabajo de los agentes, lo que provoca retrasos. Dónde obtenerlo Se calcula contando las actividades específicas de cambio de asignación de cada «ServiceRequestId» durante la transformación de datos. Ejemplos 013
	Solicitante Requestor	El usuario que envió el Service Request.
Descripción Este atributo identifica a la persona, normalmente un empleado, que inició el Service Request. Proporciona contexto sobre quién utiliza la mesa de servicio y cuáles son sus necesidades. Aunque no siempre es una dimensión principal para analizar el flujo del proceso, analizar los datos por solicitante o por su departamento puede revelar patrones. Por ejemplo, podría mostrar que un departamento concreto envía con frecuencia solicitudes incompletas, lo que indicaría la necesidad de una formación específica. También es esencial para cualquier análisis centrado en la experiencia del cliente. Por qué es importante Proporciona contexto sobre el usuario que inicia la solicitud y permite analizar los patrones de solicitud por persona, departamento o ubicación. Dónde obtenerlo Está disponible como campo «requester» en el objeto ticket de Freshservice. Ejemplos John DoeJane SmithCuenta de servicio

Obligatorio Recomendado Opcional

Actividades de la gestión de solicitudes de servicio

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir y analizar con precisión sus Workflows de solicitudes de servicio.

6 Recomendado 9 Opcional

	Actividad	Descripción
	Objetivo del SLA incumplido	Evento calculado que ocurre cuando el tiempo necesario para resolver un Service Request supera el objetivo definido en su Acuerdo de Nivel de Servicio (SLA). No es un evento directo del sistema, sino que se deriva de comparar el tiempo de resolución con la fecha límite del SLA.
Por qué es importante Mide directamente el rendimiento del servicio frente a los compromisos y es un KPI clave para la dirección. Ayuda a identificar qué tipos de solicitudes o prioridades presentan mayor riesgo de incumplimiento. Dónde obtenerlo Se calcula comparando la marca de tiempo de «Resolved» con la marca de tiempo de «SLA Due By». Si la resolución es posterior, se activa este evento. Recopilar Compare la marca de tiempo de resolución con la marca de tiempo límite del SLA. Si resolved_at > sla_due_by, cree este evento. Tipo de evento calculated
	Proveedor externo involucrado	Esta actividad marca el momento en que un ticket se transfiere a un proveedor externo o a un tercero para su resolución. Se infiere a partir de un cambio de estado a uno específico, como «Pending Vendor» o «Awaiting Third Party».
Por qué es importante La intervención de proveedores puede introducir retrasos significativos. El seguimiento de esta actividad es esencial para medir el rendimiento de los proveedores y su impacto en el tiempo de ciclo general de Service Request. Dónde obtenerlo Se infiere a partir del historial de cambios de estado del ticket. Busque un estado configurado específicamente para registrar la dependencia de proveedores externos. Recopilar Detecte cuándo el campo de estado del ticket cambia a un valor que indique que se espera la intervención de un tercero. Tipo de evento inferred
	Service Request cerrado	Esta es la actividad final y señala el fin del ciclo de vida de Service Request. Normalmente ocurre de forma automática después de que transcurre un periodo establecido en el estado «Resolved» sin que el ticket se reabra.
Por qué es importante Este evento marca el final definitivo de la instancia del proceso. El tiempo entre «Resolved» y «Closed» representa el periodo de confirmación del solicitante. Dónde obtenerlo Se infiere a partir del historial de cambios de estado del ticket. Corresponde a la marca de tiempo en la que el estado cambia a «Closed». Recopilar Capture la marca de tiempo en la que el estado del ticket cambia a «Closed». Tipo de evento inferred
	Service Request creado	Esta actividad marca el inicio del ciclo de vida de Service Request, cuando una nueva solicitud se registra formalmente en Freshservice. El evento se captura explícitamente cuando se genera un nuevo registro de ticket, ya sea a través del catálogo de servicios, por correo electrónico o mediante otro canal, y se crea un Service Request ID único.
Por qué es importante Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta las demás es fundamental para medir los tiempos de ciclo generales e identificar retrasos iniciales en el procesamiento. Dónde obtenerlo Este evento se registra explícitamente en Freshservice. Puede encontrarse en el registro de actividad o en el historial de auditoría del ticket y suele corresponder a la marca de tiempo de creación del ticket. Recopilar Utilice la marca de tiempo de creación del ticket de los datos de tickets de Freshservice. Tipo de evento explicit
	Service Request resuelto	Este hito crítico marca el momento en que el agente ha proporcionado una solución y considera que el trabajo ha terminado. Se infiere a partir del cambio de estado del ticket a «Resolved».
Por qué es importante Esta actividad señala el final de la fase de trabajo activo. La duración hasta este momento es una medida clave de la eficiencia del agente y del proceso, y constituye la base para los cálculos de los SLA. Dónde obtenerlo Se infiere a partir del historial de cambios de estado del ticket. Corresponde a la marca de tiempo en la que el estado se estableció por primera vez en «Resolved». Recopilar Capture la marca de tiempo en la que el estado del ticket cambia por primera vez a «Resolved». Tipo de evento inferred
	Solicitud asignada a un agente	Marca el momento en que un Service Request se asigna a un agente específico para su gestión. Es un hito clave y se infiere mediante el seguimiento de los cambios en el campo «Assigned Agent» u «Owner» del ticket.
Por qué es importante Esta actividad es fundamental para analizar la carga de trabajo de los agentes e identificar cuellos de botella en el proceso de asignación. El tiempo transcurrido entre la creación y la asignación es un indicador clave de rendimiento. Dónde obtenerlo Se infiere a partir del registro de actividad o del historial de auditoría de campos del ticket, mediante el seguimiento de los cambios en el campo «Agent» o «Assignee». Recopilar Capture la marca de tiempo en la que se completa el campo «Assigned Agent» o cambia su valor. Tipo de evento inferred
	Información proporcionada por el solicitante	Ocurre cuando el solicitante responde con la información necesaria, lo que permite al agente reanudar el trabajo. Normalmente se infiere cuando el estado del ticket cambia automáticamente de «Pending» a «Open».
Por qué es importante Esta actividad cierra el ciclo de las solicitudes de información. La duración entre la solicitud y la entrega de la información es un tiempo de espera crítico que conviene analizar y optimizar. Dónde obtenerlo Se infiere a partir de un cambio de estado de «Pending» a «Open» o «In Progress», normalmente provocado por una respuesta del solicitante. Recopilar Detecte cuándo el estado del ticket cambia de pendiente a abierto. Tipo de evento inferred
	Información solicitada al solicitante	Representa el momento en que el agente asignado necesita más información del solicitante y pausa el avance. Se infiere a partir de un cambio de estado del ticket a «Pending» o «Awaiting Customer».
Por qué es importante Esta actividad pone de relieve una fuente habitual de retrasos y retrabajo. Analizar su frecuencia ayuda a identificar oportunidades para mejorar las plantillas de solicitud y la recopilación inicial de datos. Dónde obtenerlo Se infiere a partir del historial de cambios de estado del ticket. Busque un cambio a un estado como «Pending Customer Response» o «Awaiting Information». Recopilar Detecte cuándo el campo de estado del ticket cambia a un valor que indique que se espera información del usuario. Tipo de evento inferred
	Nota añadida	Representa cualquier nota pública o privada que un agente o el solicitante añada a Service Request. Es un evento explícito que se captura en la conversación o el registro de actividad del ticket.
Por qué es importante Analizar la frecuencia y el momento de las notas puede revelar patrones de comunicación, la eficiencia de la colaboración y puntos de confusión en el proceso. Dónde obtenerlo Se registra explícitamente en el historial de conversaciones del ticket en Freshservice. Cada nota incluye una marca de tiempo y un autor. Recopilar Extraiga cada entrada del registro de conversaciones o comentarios del ticket. Tipo de evento explicit
	Resolución confirmada por el solicitante	Esta actividad representa una confirmación explícita del solicitante de que la solución proporcionada es satisfactoria. Puede inferirse a partir de una respuesta positiva en una encuesta o de un comentario específico antes de cerrar el ticket.
Por qué es importante La confirmación proporciona información directa sobre la calidad de la resolución. Una tasa de confirmación baja puede indicar que las soluciones no satisfacen por completo las necesidades de los usuarios, aunque no se reabran. Dónde obtenerlo Es difícil capturarla directamente y puede requerir una configuración personalizada. Podría inferirse a partir de una respuesta de una encuesta de satisfacción vinculada al ticket o de la aplicación de una etiqueta específica. Recopilar Requiere analizar datos relacionados, como encuestas de satisfacción o etiquetas aplicadas después de la resolución. Tipo de evento inferred
	Revisión interna realizada	Indica que una solución propuesta o la atención de una solicitud requiere una revisión o aprobación interna antes de continuar. Se infiere a partir de un cambio de estado a uno como «Pending Approval» o «Internal Review».
Por qué es importante Las revisiones internas pueden convertirse en cuellos de botella, especialmente en Service Request complejos o de gran impacto. Medir esta duración ayuda a agilizar los Workflow de aprobación. Dónde obtenerlo Se infiere a partir del historial de cambios de estado del ticket. Para ello, el Workflow debe utilizar un estado específico como «Pending Internal Approval». Recopilar Detecte cuándo el campo de estado del ticket cambia a un valor que indique una revisión o aprobación interna. Tipo de evento inferred
	Service Request reabierto	Ocurre cuando el solicitante indica que un problema persiste después de marcarlo como «Resolved», lo que hace que el ticket vuelva a un estado abierto. Se infiere a partir de un cambio de estado de «Resolved» a «Open» o «In Progress».
Por qué es importante Las solicitudes reabiertas son un indicador claro de una baja tasa de resolución en el primer contacto y de insatisfacción del cliente. El seguimiento de este ciclo de retrabajo es fundamental para mejorar la calidad de las soluciones. Dónde obtenerlo Se infiere a partir del historial de cambios de estado del ticket en el registro de actividad. Es una transición directa de «Resolved» a «Open». Recopilar Detecte un cambio de estado de resuelto a abierto. Tipo de evento inferred
	Solicitud clasificada inicialmente	Representa la evaluación y categorización iniciales de un Service Request recién creado. Esta actividad suele inferirse a partir de la primera vez que se establece una prioridad o se asigna la solicitud a un grupo, lo que indica que se ha revisado y entra en la cola de trabajo.
Por qué es importante El seguimiento de la clasificación inicial ayuda a medir la eficiencia del equipo de respuesta inicial. Los retrasos en esta etapa pueden afectar significativamente los tiempos generales de resolución y el cumplimiento de los SLA. Dónde obtenerlo Se infiere a partir del registro de actividad. Puede identificarse mediante la marca de tiempo del primer evento «Priority Set» o «Group Assigned» que ocurre después de la creación. Recopilar Identifique la primera marca de tiempo de un cambio en el campo de prioridad o en el campo del grupo de asignación. Tipo de evento inferred
	Solicitud priorizada	Esta actividad ocurre cuando se asigna a Service Request un nivel de prioridad, como Low, Medium o High. Se infiere al detectar un cambio en el campo «Priority» del historial del ticket.
Por qué es importante La priorización es fundamental para asignar recursos y garantizar el cumplimiento de los objetivos de los SLA. Analizar esta actividad ayuda a verificar que las solicitudes se evalúen correctamente y a tiempo. Dónde obtenerlo Se infiere a partir del historial de cambios de campos del ticket en Freshservice. Busque actualizaciones en el campo «Priority» y capture la marca de tiempo del cambio. Recopilar Detecte un cambio en el campo «Priority» desde null o desde su valor anterior y registre la marca de tiempo. Tipo de evento inferred
	Solicitud reasignada	Esta actividad captura cualquier cambio en el agente o grupo asignado después de la asignación inicial. Se infiere al detectar actualizaciones posteriores en los campos «Assigned Agent» o «Assigned Group».
Por qué es importante Las reasignaciones frecuentes indican posibles problemas en la clasificación inicial, la correspondencia entre habilidades y agentes o el equilibrio de la carga de trabajo. Esta actividad es esencial para el KPI Agent Reassignment Count y el análisis del retrabajo. Dónde obtenerlo Se infiere a partir del historial de cambios de campos del ticket. Este evento se registra cada vez que se actualiza el campo «Assigned Agent» o «Assigned Group» después de establecer su valor inicial. Recopilar Detecte cualquier cambio en el campo «Assigned Agent» o «Assigned Group» después de la primera asignación. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Freshservice

Pasos

Comprobación de requisitos previos: Asegúrese de tener un rol de usuario de Freshservice con permisos para acceder al módulo Analytics y crear informes. Normalmente, esto requiere un plan Pro o Enterprise.
Configure las automatizaciones, si es necesario: Para capturar los eventos correctamente, verifique o cree dos automatizaciones específicas en Freshservice, en Admin -> Workflow Automator. Primero, una automatización que añada una nota privada o una etiqueta específica, por ejemplo, «SLA_Breached», a un ticket cuando expire su temporizador de resolución del SLA. Segundo, una automatización que añada una etiqueta específica, por ejemplo, «Resolution_Confirmed», cuando se reciba una encuesta positiva de satisfacción del cliente para un ticket.
Cree el informe «Creation Events»: Vaya a la pestaña Analytics de Freshservice. Cree un informe nuevo y seleccione el módulo «Tickets» como fuente de datos. Este informe capturará el primer evento de cada solicitud de servicio.
Configure los widgets del informe «Creation Events»: Añada un widget «Data Table». Configure las columnas, o métricas, para incluir: Ticket ID, Created at, Assigned to, Group, Priority, Status y Category. Aplique un filtro para el intervalo de fechas de creación deseado, por ejemplo, los últimos 6 meses.
Exporte los datos de «Creation Events»: Ejecute el informe y exporte el widget de tabla de datos a un archivo CSV. Asígnele el nombre «creation_events.csv».
Cree el informe «Update Events»: Cree un segundo informe y seleccione esta vez el módulo «Ticket Activities» como fuente de datos. Este informe captura todos los cambios y notas posteriores de cada solicitud de servicio.
Configure los widgets del informe «Update Events»: Añada un widget «Data Table». Configure las columnas para incluir: Ticket ID, Activity Date, Performed by y Activity Type. En «Changes», incluya Field, Old Value y New Value. También debe añadir atributos del nivel del ticket, como Group, Assigned to, Priority, Status y Category, para proporcionar contexto a cada evento.
Filtre el informe «Update Events»: Aplique un filtro a «Activity Date» que coincida con el mismo intervalo de fechas utilizado en el informe de creación. Después, filtre «Activity Type» para incluir únicamente eventos relevantes, como «Status changed», «Priority changed», «Group changed», «Agent changed», «Private Note added» y «Public Note added».
Exporte los datos de «Update Events»: Ejecute el informe y exporte el widget de tabla de datos a un archivo CSV. Asígnele el nombre «update_events.csv».
Combine y transforme los datos: Abra los dos archivos CSV en un programa de hojas de cálculo o utilice un script de preparación de datos. Copie todos los datos de «update_events.csv» y péguelos debajo de los datos de «creation_events.csv» en un archivo nuevo llamado «event_log.csv».
Asigne las actividades y los atributos: En el archivo combinado «event_log.csv», cree las columnas nuevas: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status y ServiceType. Rellene estas columnas utilizando la lógica definida en la sección Query que aparece a continuación. Este paso implica utilizar fórmulas o un script para convertir los datos sin procesar al formato final del Registro de eventos.
Exportación final: Guarde el archivo transformado «event_log.csv». Asegúrese de que el formato de fecha de EventTime y LastDataUpdate sea un formato estándar, como ISO 8601. El archivo ya está listo para cargarlo en una herramienta de Process Mining.

Configuración

Plan de Freshservice: Se requiere un plan que incluya el módulo Analytics, normalmente Pro o Enterprise.
Permisos de usuario: La persona que realice la exportación necesita permisos para crear y ejecutar informes en Analytics.
Intervalo de fechas: Se recomienda extraer datos de un periodo reciente, como los últimos 3 a 6 meses, para mantener el conjunto de datos bajo control. Aplique un filtro de intervalo de fechas coherente basado en «Created at» para el informe de creación y en «Activity Date» para el informe de actualizaciones.
Filtros de informes: En el informe del módulo «Tickets», filtre por «Type» = «Service Request» para aislar el proceso correcto. En el informe «Ticket Activities», filtre «Activity Type» para incluir únicamente los cambios relevantes, como estado, prioridad, asignación y notas, y reducir así el ruido de los datos exportados.
Automatizaciones necesarias: La extracción de las actividades «SLA Target Breached» y «Resolution Confirmed by Requestor» depende de reglas preexistentes de Workflow Automator que añadan una nota o etiqueta al ticket cuando se produzcan esos eventos. Sin estas reglas, no se pueden capturar las actividades mediante este método.

a Consulta de ejemplo sql

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

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

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

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

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

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

Pasos

Requisitos previos: Asegúrese de tener Python 3.6 o una versión posterior instalada en su sistema, junto con las bibliotecas requests y pandas. También necesitará una clave de API de Freshservice con permisos para leer los datos de los tickets.
Obtenga la clave de API: Inicie sesión en su instancia de Freshservice como administrador. Haga clic en el icono de su perfil, situado en la esquina superior derecha, vaya a «Profile Settings» y encontrará su clave de API en el panel derecho. Cópiela y guárdela de forma segura.
Guarde el script: Guarde el código de Python proporcionado en un archivo llamado extract_freshservice_srm.py en su equipo local.
Configure los parámetros del script: Abra el script guardado en un editor de texto. Busque la sección de configuración situada al principio y sustituya los valores de marcador de posición de FRESHSERVICE_DOMAIN, API_KEY, START_DATE y END_DATE. Ajuste el diccionario STATUS_MAPPING si su instancia utiliza identificadores numéricos diferentes para los estados personalizados.
Instale las bibliotecas: Si no tiene instaladas las bibliotecas necesarias, abra la línea de comandos o el terminal y ejecute el comando: pip install requests pandas.
Ejecute el script: Vaya al directorio donde guardó el script mediante la línea de comandos o el terminal. Ejecútelo con el comando: python extract_freshservice_srm.py.
Supervise la ejecución: El script mostrará actualizaciones del progreso en la consola e indicará qué página de tickets está procesando. Según el intervalo de fechas y el volumen de tickets, el proceso puede tardar un tiempo.
Recupere el Registro de eventos: Cuando el script finalice correctamente, creará un archivo llamado freshservice_event_log.csv en el mismo directorio. Este archivo contiene el Registro de eventos extraído.
Prepárese para la carga: El archivo CSV generado está estructurado con las columnas necesarias (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) y está listo para cargarlo en ProcessMind. Normalmente no se necesita ningún formato adicional.

Configuración

FRESHSERVICE_DOMAIN: La URL de Freshservice de su organización, por ejemplo, yourcompany.freshservice.com.
API_KEY: La clave de API personal obtenida del perfil de usuario de Freshservice. Debe mantenerla confidencial.
START_DATE / END_DATE: El intervalo de fechas para extraer los tickets, con el formato «YYYY-MM-DD». Para un análisis inicial, se recomienda un periodo de 3 a 6 meses para equilibrar el volumen de datos y la información obtenida.
STATUS_MAPPING: Un diccionario de Python fundamental en el script que asigna los nombres de estados personalizados utilizados para inferir eventos, como «External Vendor Engaged», a sus identificadores numéricos correspondientes en su instancia de Freshservice. Debe verificar y actualizar estos identificadores para que coincidan con la configuración de su sistema.
Límites de la API: Tenga en cuenta los límites de solicitudes de la API de su plan de Freshservice. El script procesa los tickets secuencialmente para respetar estos límites, pero en conjuntos de datos extremadamente grandes puede ser necesario ejecutar la extracción en lotes con intervalos de fechas más pequeños.
Alcance de los datos: El script está configurado para extraer únicamente tickets de tipo «Service Request». Este filtro se aplica durante la obtención inicial de los tickets.

a Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain and API key
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com" 
API_KEY = class="hl-string">"[YOUR_API_KEY]"

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Map your custom status names to their numeric IDs in Freshservice ---
class=class="hl-string">"hl-comment"># To find these IDs, you may need to inspect API responses or admin settings
class=class="hl-string">"hl-comment"># Common defaults: Open: 2, Pending: 3, Resolved: 4, Closed: 5
STATUS_MAPPING = {
    class="hl-string">'Open': 2,
    class="hl-string">'Pending': 3, 
    class="hl-string">'Resolved': 4, 
    class="hl-string">'Closed': 5,
    class="hl-string">'Awaiting Customer': 3, class=class="hl-string">"hl-comment"># Example, often maps to Pending
    class="hl-string">'Pending Vendor': [6], class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
    class="hl-string">'Pending Approval': [7]  class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
}
class=class="hl-string">"hl-comment"># --- END CONFIGURATION ---

BASE_URL = fclass="hl-string">"https://{FRESHSERVICE_DOMAIN}/api/v2"
AUTH = (API_KEY, class="hl-string">"X")

class=class="hl-string">"hl-comment"># Caching for agent and group lookups to reduce API calls
agent_cache = {}
group_cache = {}

def get_api_data(url):
    class="hl-string">"""Helper function to handle API requests and rate limiting."""
    while True:
        try:
            response = requests.get(url, auth=AUTH)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            return response.json()
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue
            else:
                print(fclass="hl-string">"HTTP Error: {e}")
                return None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            return None

def get_agent_name(agent_id):
    class="hl-string">"""Fetch agent name by ID with caching."""
    if not agent_id: return None
    if agent_id in agent_cache:
        return agent_cache[agent_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/agents/{agent_id}")
    if data and class="hl-string">'agent' in data:
        name = data[class="hl-string">'agent'][class="hl-string">'first_name'] + class="hl-string">' ' + data[class="hl-string">'agent'][class="hl-string">'last_name']
        agent_cache[agent_id] = name
        return name
    return None

def get_group_name(group_id):
    class="hl-string">"""Fetch group name by ID with caching."""
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/groups/{group_id}")
    if data and class="hl-string">'group' in data:
        name = data[class="hl-string">'group'][class="hl-string">'name']
        group_cache[group_id] = name
        return name
    return None

def parse_iso_datetime(dt_string):
    if not dt_string: return None
    return datetime.fromisoformat(dt_string.replace(class="hl-string">'Z', class="hl-string">'+00:00'))

def main():
    event_log = []
    last_data_update = datetime.now().isoformat()

    page = 1
    while True:
        print(fclass="hl-string">"Fetching tickets, page {page}...")
        query = fclass="hl-string">'"created_at:>\\'{START_DATE}\\class="hl-string">' AND created_at:<\\'{END_DATE}\\class="hl-string">' AND ticket_type:\\\'Service Request\\\class="hl-string">'"'
        url = fclass="hl-string">"{BASE_URL}/tickets?query={query}&page={page}&per_page=100"

        data = get_api_data(url)

        if not data or class="hl-string">'tickets' not in data or not data[class="hl-string">'tickets']:
            break

        tickets = data[class="hl-string">'tickets']

        for ticket in tickets:
            service_request_id = ticket[class="hl-string">'id']
            created_at = parse_iso_datetime(ticket[class="hl-string">'created_at'])
            due_by = parse_iso_datetime(ticket[class="hl-string">'due_by'])
            resolved_at = parse_iso_datetime(ticket[class="hl-string">'resolved_at'])
            closed_at = parse_iso_datetime(ticket[class="hl-string">'closed_at'])

            class=class="hl-string">"hl-comment"># --- Activity: Service Request Created ---
            event_log.append({
                class="hl-string">'ServiceRequestId': service_request_id,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
                class="hl-string">'EventTime': created_at,
                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                class="hl-string">'LastDataUpdate': last_data_update,
                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                class="hl-string">'Status': ticket[class="hl-string">'status'],
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
            })
            
            class=class="hl-string">"hl-comment"># Fetch conversations for detailed history
            conv_url = fclass="hl-string">"{BASE_URL}/tickets/{service_request_id}/conversations"
            conversations = get_api_data(conv_url)
            
            if not conversations or class="hl-string">'conversations' not in conversations:
                continue
                
            class=class="hl-string">"hl-comment"># Sort conversations chronologically
            sorted_convos = sorted(conversations[class="hl-string">'conversations'], key=lambda x: parse_iso_datetime(x[class="hl-string">'created_at']))

            initial_group_assigned = False
            initial_priority_set = False
            initial_agent_assigned = False
            triaged = False

            for conv in sorted_convos:
                conv_time = parse_iso_datetime(conv[class="hl-string">'created_at'])

                class=class="hl-string">"hl-comment"># --- Activity: Note Added ---
                if conv[class="hl-string">'body_text']:
                     event_log.append({
                        class="hl-string">'ServiceRequestId': service_request_id,
                        class="hl-string">'ActivityName': class="hl-string">'Note Added',
                        class="hl-string">'EventTime': conv_time,
                        class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                        class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                        class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                        class="hl-string">'Status': ticket[class="hl-string">'status'],
                        class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                    })

                class=class="hl-string">"hl-comment"># Process system activities from the activity log within conversations
                if class="hl-string">'activities' in conv and conv[class="hl-string">'activities']:
                    for activity in conv[class="hl-string">'activities']:
                        shipping_info = activity.get(class="hl-string">'shipping_info', {})
                        changes = shipping_info.get(class="hl-string">'changes', {})
                        
                        class=class="hl-string">"hl-comment"># --- Priority Change Activities ---
                        if class="hl-string">'priority' in changes:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Request Prioritized',
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': changes[class="hl-string">'priority'][1], class=class="hl-string">"hl-comment"># New value
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            if not initial_priority_set and not triaged:
                                initial_priority_set = True
                                triaged = True
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Request Triaged'})
                        
                        class=class="hl-string">"hl-comment"># --- Assignment Change Activities ---
                        if class="hl-string">'responder_id' in changes:
                            activity_name = class="hl-string">'Request Assigned to Agent' if not initial_agent_assigned else class="hl-string">'Request Reassigned'
                            initial_agent_assigned = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(changes[class="hl-string">'responder_id'][1]),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        if class="hl-string">'group_id' in changes:
                            activity_name = class="hl-string">'Request Reassigned' class=class="hl-string">"hl-comment"># Any group change after creation is a reassignment
                            if not initial_group_assigned and not triaged:
                                activity_name = class="hl-string">'Request Triaged'
                                initial_group_assigned = True
                                triaged = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(changes[class="hl-string">'group_id'][1]),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        class=class="hl-string">"hl-comment"># --- Status Change Activities ---
                        if class="hl-string">'status' in changes:
                            old_status, new_status = changes[class="hl-string">'status']
                            
                            if new_status == STATUS_MAPPING[class="hl-string">'Resolved']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Closed']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Closed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Requested from Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer'] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Provided by Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status in [STATUS_MAPPING[class="hl-string">'Resolved'], STATUS_MAPPING[class="hl-string">'Closed']] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Reopened', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Vendor']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'External Vendor Engaged', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Approval']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Internal Review Performed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
            
            class=class="hl-string">"hl-comment"># --- Derived/Calculated Activities ---
            class=class="hl-string">"hl-comment"># --- Activity: SLA Target Breached ---
            resolution_time = closed_at or resolved_at
            if due_by and resolution_time and resolution_time > due_by:
                event_log.append({
                    class="hl-string">'ServiceRequestId': service_request_id,
                    class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                    class="hl-string">'EventTime': due_by,
                    class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                    class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                    class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                    class="hl-string">'Status': ticket[class="hl-string">'status'],
                    class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                })

            class=class="hl-string">"hl-comment"># --- Activity: Resolution Confirmed by Requestor (Inferred from survey) ---
            if ticket.get(class="hl-string">'satisfaction_ratings'):
                for rating in ticket[class="hl-string">'satisfaction_ratings']:
                    if rating.get(class="hl-string">'ratings'): class=class="hl-string">"hl-comment"># Check if there is a rating
                        rating_time = parse_iso_datetime(rating.get(class="hl-string">'created_at'))
                        if resolved_at and rating_time > resolved_at:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Resolution Confirmed by Requestor',
                                class="hl-string">'EventTime': rating_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            break class=class="hl-string">"hl-comment"># Only add one confirmation event

        page += 1

    if not event_log:
        print(class="hl-string">"No events were generated. Please check your configuration and date range.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTime'])
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df[class="hl-string">'LastDataUpdate'] = pd.to_datetime(df[class="hl-string">'LastDataUpdate']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    output_filename = class="hl-string">'freshservice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {output_filename}")

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

Pasos

Confirme que su suscripción de Freshservice y sus permisos de administrador incluyen la exportación programada de datos y la entrega al proveedor de almacenamiento en la nube seleccionado. Los nombres de los menús y las funciones de exportación de Freshservice pueden variar según el plan y el tenant, por lo que debe consultar la documentación actual para administradores y utilizar [Configure based on your system] cuando el tenant muestre etiquetas diferentes.
En Freshservice, abra el área de administración y localice la configuración de exportación programada de datos. Seleccione la fuente de datos de solicitudes de servicio o tickets que contenga el ID de solicitud de servicio, el estado, la prioridad, la asignación, el tipo de servicio, las marcas de tiempo, los campos del SLA, el historial de conversaciones o actividades y la información sobre las respuestas de las personas solicitantes. No dé por hecho que una exportación del estado actual del ticket contiene los cambios históricos de los campos.
Configure el alcance de la exportación. Seleccione una ventana de extracción móvil de 3 a 6 meses para la validación inicial y, después, elija una programación recurrente adecuada para sus necesidades de informes. Incluya todos los registros de solicitudes de servicio y los datos históricos de actividad o auditoría necesarios para identificar cambios de campos, notas, transiciones de estado, resultados del SLA, aprobaciones y confirmaciones de las personas solicitantes. Aplique filtros de empresa o servicio solo cuando sean necesarios de forma explícita, utilizando [Company or service filter based on your system].
Seleccione CSV como formato de salida y configure la entrega en la ubicación de almacenamiento en la nube aprobada, como Amazon S3. Proporcione [Cloud storage connection details] y [Credentials or role configuration] mediante la configuración compatible de Freshservice. Confirme el bucket, la ruta, el cifrado, la retención y la política de acceso con la persona responsable de la plataforma. Evite incluir credenciales directamente en scripts o archivos exportados.
Ejecute una exportación de prueba e inspeccione los archivos CSV entregados. Identifique los nombres reales de las columnas exportadas para el ID de solicitud de servicio, el estado, la prioridad, el agente asignado, el grupo asignado, el tipo de servicio, la hora de creación, la hora de actualización, la hora de resolución, la hora de cierre, la hora límite del SLA, la marca de tiempo del historial, el campo del historial, el valor anterior, el valor nuevo, el tipo de nota, la persona autora de la nota, la marca de tiempo de la nota y la respuesta o el resultado de la encuesta de la persona solicitante. Si un campo de origen necesario no está disponible, documente la limitación en lugar de inventar un nombre de campo.
Cargue los archivos CSV en una tabla de preparación o un marco de datos. Sustituya las referencias de origen de la consulta siguiente, incluidas [Your ticket table name], [Your ticket history table name], [Your conversation table name], [Your SLA table name] y [Your survey or confirmation table name], por las estructuras reales creadas a partir de la exportación. Asigne las columnas de origen a los campos lógicos utilizados por la consulta. Conserve las marcas de tiempo de origen y normalícelas a una única zona horaria, preferiblemente UTC.
Configure el procesamiento incremental mediante [Last successful export timestamp] o la marca de tiempo de entrega del archivo de exportación. Mantenga una ventana de solapamiento suficiente, por ejemplo, de 24 a 48 horas, para capturar historiales y correcciones que lleguen tarde. Elimine duplicados utilizando ServiceRequestId, ActivityName, EventTime y un identificador de evento de origen estable cuando esté disponible. No elimine duplicados basándose únicamente en ServiceRequestId, porque cada solicitud debe generar varias filas de eventos.
Ejecute la transformación SQL completa. La consulta crea explícitamente filas para las 15 actividades necesarias, incluidas actividades derivadas como la clasificación inicial, la reasignación, el incumplimiento del SLA, la confirmación de la persona solicitante y el cierre. Cuando la exportación no proporcione pruebas históricas de una actividad, no se podrá generar de forma fiable y deberá notificarse como una carencia de datos de origen.
Valide los recuentos de filas, la cobertura de actividades, las marcas de tiempo, los identificadores y la población de atributos mediante las comprobaciones de validación que aparecen a continuación. Confirme que cada ServiceRequestId puede tener varios eventos ordenados y que EventTime está informado en todas las filas emitidas.
Exporte el resultado de la consulta como un CSV UTF-8 con las columnas necesarias ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status y ServiceType. Cargue el Registro de eventos resultante en ProcessMind, asigne ServiceRequestId como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento. Mantenga SourceSystem y LastDataUpdate como atributos del evento o metadatos, según la configuración de importación de ProcessMind.

Configuración

Fuente de exportación: Seleccione el conjunto de datos de solicitudes de servicio o tickets de Freshservice y, cuando estén disponibles, sus conjuntos de datos de historial, conversaciones, SLA, aprobaciones y encuestas. Una exportación únicamente del estado actual de los tickets no basta para reconstruir todas las actividades solicitadas.
Programación: Utilice una exportación recurrente alineada con el ciclo de informes operativos. Para la primera carga, use un intervalo de fechas de 3 a 6 meses. Para las cargas incrementales, utilice una ventana de solapamiento que permita capturar actualizaciones que lleguen tarde.
Evidencias de origen necesarias: Asegúrese de que la exportación incluya un ID de solicitud de servicio estable, marcas de tiempo de eventos o actualizaciones, historial de estados, historial de prioridades, historial de asignaciones, historial de grupos, notas o conversaciones, información sobre la fecha límite y la finalización del SLA, marcas de tiempo de resolución y cierre, y evidencias de confirmación de la persona solicitante cuando estén disponibles.
Filtros: Aplique [Company or service filter based on your system] únicamente cuando sea necesario. Evite los filtros de estado restrictivos, ya que pueden excluir registros reabiertos, resueltos, cerrados, pendientes, de proveedores, de aprobación e históricos.
Almacenamiento en la nube: Configure el bucket o contenedor aprobado, la ruta, el cifrado, la retención y la política de acceso. Utilice un rol administrado o un mecanismo de secretos compatible con el tenant, en lugar de insertar credenciales en archivos SQL o CSV.
Gestión de archivos: Conserve los archivos CSV originales, las marcas de tiempo de exportación, la versión del esquema y los metadatos de entrega. Si Freshservice divide las exportaciones grandes en varios archivos, procese todos los archivos de la misma ejecución de exportación.
Zonas horarias: Registre la zona horaria de origen y normalice EventTime a UTC. Conserve la marca de tiempo original cuando sea necesario garantizar la auditabilidad.
Rendimiento: Particione el procesamiento por fecha de exportación, fecha del evento o ServiceRequestId cuando sea compatible. Prepare los archivos sin procesar antes de transformarlos, evite examinar repetidamente todo el historial y utilice cargas incrementales con un solapamiento controlado.
Autorizaciones y licencias: El acceso de administrador, los permisos para configurar exportaciones programadas, los permisos para leer los datos seleccionados de Freshservice, el acceso de escritura al almacenamiento en la nube y cualquier función de suscripción o licencia necesaria para entregar exportaciones programadas son requisitos previos.
Calidad de los datos: No cree eventos inferidos únicamente a partir del valor actual cuando no haya evidencias históricas. Por ejemplo, una prioridad actual solo puede respaldar «Request Prioritized» si existe una marca de tiempo de asignación de prioridad o un registro histórico.
Asignación de origen: Sustituya cada objeto de origen y referencia de columna entre corchetes de la consulta por los nombres reales de la exportación entregada. Los nombres lógicos de las columnas de salida deben mantenerse sin cambios para la asignación en ProcessMind.

a Consulta de ejemplo sql

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

¿Listo para comenzar?

Dé el primer paso para optimizar su proceso de gestión de solicitudes de servicio preparando sus datos. Estamos aquí para ayudarle a transformar la prestación de sus servicios.

Volver a la guía de mejora Descargar Template

Mejore hoy la eficiencia de sus solicitudes de servicio en Freshservice

Ponga fin a la gestión lenta y a la frustración de las personas usuarias, y alcance un 70 % de automatización.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Configuración en minutos.

Su Template de datos para la gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

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

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Freshservice

Pasos

Configuración

a Consulta de ejemplo python

Exportación programada de datos de Freshservice al almacenamiento en la nube

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Mejore hoy la eficiencia de sus solicitudes de servicio en Freshservice

Su Template de datos para la gestión de solicitudes de servicio

Su Template de datos para la gestión de solicitudes de servicio

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

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

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Freshservice

Pasos

Configuración

a Consulta de ejemplo python

Exportación programada de datos de Freshservice al almacenamiento en la nube

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Mejore hoy la eficiencia de sus solicitudes de servicio en Freshservice

Valoramos su privacidad