> Mejora continua de procesos > Gestión de incidentes > Zendesk Support > Template de datos

Su Template de datos para la gestión de incidentes

Zendesk Support

Atributos de la gestión de incidentes (23) Actividades de gestión de incidentes (13) Guías de extracción (4)

Su Template de datos para la gestión de incidentes

Este Template ofrece una visión estructurada de los datos esenciales necesarios para analizar eficazmente su proceso de gestión de incidentes. Describe los atributos clave que debe recopilar, las actividades críticas que debe supervisar e incluye instrucciones prácticas para extraer estos datos de Zendesk Support. Utilícelo para asegurarse de que su proyecto de Process Mining comienza con un conjunto de datos completo y sólido.

Atributos recomendados para recopilar
Actividades clave que debe supervisar para el mapeo de procesos
Instrucciones prácticas para extraer datos

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

Descargar Template

Atributos de la gestión de incidentes

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

5 Obligatorio 7 Recomendado 11 Opcional

	Nombre	Descripción
	ID del incidente TicketId	El identificador único generado por el sistema para cada ticket de incidente.
Descripción El Incident ID es la clave principal que identifica de forma única cada caso de incidente en Zendesk Support. Actúa como CaseId para Process Mining y vincula todas las actividades, cambios de estado y comunicaciones relacionadas desde el momento en que se crea el incidente hasta su cierre. En el análisis, este ID es fundamental para reconstruir el recorrido completo de cada incidente. Permite agregar los datos de eventos para realizar un seguimiento de métricas como el tiempo total de resolución, el número de transferencias y el cumplimiento de los acuerdos de nivel de servicio de cada caso. Al agrupar los eventos por este ID, los analistas pueden visualizar los flujos del proceso, identificar las rutas habituales y detectar desviaciones respecto al procedimiento estándar. Por qué es importante Es el identificador esencial que conecta todos los eventos con un único incidente, lo que permite rastrear todo su ciclo de vida y analizar con precisión el rendimiento del proceso. Dónde obtenerlo API de Zendesk Tickets (/api/v2/tickets/{id}), campo id. Ejemplos 19428230113521941055
	Marca de tiempo del evento EventTimestamp	La fecha y hora exactas en que ocurrió la actividad.
Descripción Esta marca de tiempo registra el momento exacto en que ocurrió un evento durante el ciclo de vida del incidente, por ejemplo, cuando se añadió un comentario o se cambió el estado. Proporciona el orden cronológico de todas las actividades de un caso. Este atributo es fundamental para cualquier análisis de Process Mining basado en el tiempo. Se utiliza para calcular los tiempos de ciclo entre actividades, identificar tiempos de espera, medir la duración total del caso y analizar el rendimiento del proceso en distintos periodos. Las marcas de tiempo precisas son esenciales para crear un mapa de procesos animado que muestre el flujo de los casos a lo largo del tiempo y para crear Dashboards de rendimiento que hagan seguimiento de KPI como el tiempo medio de resolución. Por qué es importante Las marcas de tiempo proporcionan el contexto cronológico de todas las actividades, lo que permite calcular duraciones, identificar cuellos de botella y analizar el rendimiento del proceso a lo largo del tiempo. Dónde obtenerlo API Zendesk Ticket Audits (/api/v2/tickets/{ticket_id}/audits), campo created_at para cada evento de auditoría. Ejemplos 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Actividad ActivityName	El nombre de la actividad empresarial o del evento que ocurrió en un momento específico del ciclo de vida del incidente.
Descripción Este atributo describe un paso o una acción específicos realizados dentro del proceso de gestión de incidentes, como «Incident Created», «Ticket Assigned to Agent» o «Incident Resolved». Estas actividades se derivan de los datos del registro de eventos o de la pista de auditoría de Zendesk, donde se registran los cambios del sistema. En Process Mining, la secuencia de estas actividades forma el mapa del proceso, que constituye la base de todo el análisis. Al analizar el flujo de actividades, las organizaciones pueden descubrir las rutas reales que siguen los incidentes, identificar cuellos de botella entre pasos, medir los ciclos de retrabajo, como volver a abrir un ticket resuelto, y comprobar la conformidad con un proceso estándar definido. Por qué es importante La secuencia de actividades define el flujo del proceso, que es el núcleo del análisis de Process Mining para identificar ineficiencias, desviaciones y oportunidades de mejora. Dónde obtenerlo Se deriva de los eventos de la API Zendesk Ticket Audits. Por ejemplo, un evento Change en el campo de estado podría asignarse a «Status Changed». Ejemplos Incidente creadoTicket asignado a un agenteEstado cambiado a pendienteIncidente resueltoIncidente cerrado
	Sistema de origen SourceSystem	El sistema del que se extrajeron los datos del incidente.
Descripción Este atributo identifica el origen de los datos del proceso. En esta vista, el valor sería estático, por ejemplo, «Zendesk Support», lo que indica que todos los eventos y atributos proceden de ese sistema. En entornos donde se combinan datos de varios sistemas, este campo es fundamental para distinguir entre las distintas fuentes de datos. Ayuda a garantizar la integridad de los datos y permite realizar análisis específicos por fuente, como comparar el proceso de gestión de incidentes de Zendesk con el de otra herramienta ITSM. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos y para los análisis que combinan datos de varios sistemas de origen. Dónde obtenerlo Valor estático establecido durante la transformación de datos para identificar su origen. Ejemplos Zendesk SupportZendesk
	Última actualización de datos LastDataUpdate	La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este proceso.
Descripción Este atributo registra la fecha y hora de la extracción o actualización más reciente de los datos desde el sistema de origen. Normalmente, es un único valor aplicado a todo el conjunto de datos de un ciclo de actualización determinado. Esta información es esencial para la gobernanza de datos y para quienes utilizan el análisis de Process Mining. Proporciona contexto sobre la actualidad de los datos y ayuda a los analistas a saber si están consultando la información más reciente disponible. Esto es especialmente importante para supervisar el rendimiento operativo y tomar decisiones oportunas basadas en el análisis. Por qué es importante Proporciona un contexto esencial sobre la actualidad de los datos y permite a los usuarios saber hasta qué punto el análisis refleja información reciente y cuándo se obtuvieron los datos por última vez. Dónde obtenerlo Marca de tiempo generada por el proceso de canalización ETL/datos al finalizar la actualización de datos. Ejemplos 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente asignado Assignee	El agente de soporte asignado actualmente para gestionar el incidente.
Descripción Este atributo identifica al agente específico responsable del incidente en un momento determinado. Los cambios de responsable son eventos críticos que indican una transferencia de trabajo de una persona a otra. Analizar el agente asignado ayuda a comprender la distribución de la carga de trabajo, el rendimiento individual y los patrones de colaboración. El seguimiento de los cambios de este campo es esencial para calcular el KPI «Average Handoffs per Incident» e identificar situaciones en las que los incidentes se transfieren con frecuencia, lo que puede indicar carencias de conocimiento o un enrutamiento ineficiente. Por qué es importante Identifica al agente responsable y permite analizar la carga de trabajo y realizar un seguimiento de las transferencias, algo fundamental para detectar ineficiencias del proceso. Dónde obtenerlo API de Zendesk Tickets, campo assignee_id. Los cambios se registran en la API Ticket Audits. Ejemplos John SmithJane DoeAutomatización del Service Desk
	Canal de comunicación Channel	El canal por el que se informó inicialmente del incidente, como «Email», «Web» o «API».
Descripción Este atributo registra el método utilizado por el usuario final o el sistema para crear el ticket de incidente. Comprender el canal es importante para analizar el origen de los incidentes y adaptar el proceso de soporte en consecuencia. Analizar los incidentes por canal puede revelar patrones diferentes. Por ejemplo, los incidentes informados por teléfono podrían tener tiempos de resolución más cortos que los recibidos por correo electrónico. Esta información respalda el Dashboard «Incident Throughput Volume» y ayuda a planificar los recursos y optimizar los canales. Por qué es importante Ayuda a analizar el volumen de incidentes y el rendimiento del proceso por origen, lo que permite mejorar procesos específicos por canal y asignar recursos. Dónde obtenerlo API de Zendesk Tickets, campo via.channel. Ejemplos WebCorreo electrónicoAPITeléfono
	Estado del SLA SlaStatus	El estado actual del Acuerdo de Nivel de Servicio (SLA) del incidente.
Descripción Este atributo indica si un incidente avanza según lo previsto para cumplir los objetivos definidos del SLA, si ya los ha incumplido o si los temporizadores del SLA están en pausa. Zendesk realiza un seguimiento automático de las métricas del SLA según las políticas configuradas. Este atributo es fundamental para el Dashboard «Supervisión del cumplimiento del SLA». Proporciona una medida directa del rendimiento frente a los compromisos de servicio. Al analizar cuándo y por qué se incumplen los SLA, las organizaciones pueden identificar debilidades del proceso y mejorar la fiabilidad del servicio. También respalda directamente el KPI «Tasa de cumplimiento del SLA de incidentes». Por qué es importante Mide directamente el rendimiento frente a los compromisos de servicio, lo que permite analizar los incumplimientos del SLA y realizar una supervisión proactiva para mejorar el cumplimiento. Dónde obtenerlo API de métricas de tickets de Zendesk (/api/v2/ticket_metrics.json), derivada de campos como sla_policy, breached_at, etc. Ejemplos ActivoEn pausaIncumplidoCompletado
	Estado del ticket TicketStatus	El estado del ticket de incidente en el momento del evento, como «Open», «Pending» o «Solved».
Descripción Este atributo refleja el estado del ticket de incidente en distintos momentos de su ciclo de vida. Los estados estándar de Zendesk incluyen new, open, pending, on-hold, solved y closed. El seguimiento de los cambios de este campo es una forma principal de generar actividades para Process Mining. Analizar el estado del ticket es fundamental para comprender el proceso. Ayuda a identificar cuánto tiempo permanecen los incidentes en determinados estados, como «Pending», que suele indicar que se espera una respuesta del cliente. También es clave para definir la finalización del caso y calcular los tiempos de resolución. Por qué es importante El seguimiento de los cambios de estado es clave para comprender la progresión del proceso, identificar tiempos de espera y definir los puntos de inicio y final del ciclo de vida del incidente. Dónde obtenerlo API de Zendesk Tickets, campo status. Los cambios se registran en la API Ticket Audits. Ejemplos NuevoAbiertoPendienteResueltoCerrado
	Grupo asignado AssignedGroup	El equipo o grupo de soporte asignado actualmente al incidente.
Descripción Este atributo indica qué equipo es responsable del incidente. Los incidentes suelen pasar entre distintos niveles de soporte o grupos especializados, por ejemplo, de «L1 Support» al «Network Team». Es una dimensión crítica para analizar las transferencias del proceso e identificar cuellos de botella. Al supervisar cómo fluyen los incidentes entre grupos, los analistas pueden medir las dependencias entre equipos, calcular los tiempos de espera de equipos específicos y optimizar las reglas de enrutamiento. Además, respalda directamente el Dashboard «Handoffs and Rework Analysis». Por qué es importante Realiza un seguimiento de la responsabilidad de los equipos, algo esencial para analizar las transferencias entre equipos, identificar cuellos de botella específicos y medir los tiempos de espera. Dónde obtenerlo API de Zendesk Tickets, campo group_id. Los cambios se registran en la API Ticket Audits. Ejemplos Soporte de nivel 1Equipo de redes de nivel 2Infraestructura de nivel 3Facturación
	Hora de finalización del evento EventEndTime	La marca de tiempo que indica cuándo se completó una actividad.
Descripción La hora de finalización del evento marca la conclusión de una actividad. En los datos del registro de eventos, la hora de finalización de una actividad suele inferirse como la hora de inicio de la siguiente actividad de la secuencia para ese caso. En el caso de la última actividad, la hora de finalización puede coincidir con la hora de inicio. Este atributo es esencial para calcular la duración de cada actividad (ProcessingTime) y el tiempo de espera entre actividades. Esta información constituye la base del análisis de cuellos de botella, ya que permite ver no solo cuánto tarda un paso, sino también cuánto tiempo permaneció inactivo el caso antes de que comenzara ese paso. Por qué es importante Permite calcular la duración de las actividades y los tiempos de espera, algo fundamental para realizar un análisis detallado de cuellos de botella e identificar retrasos en el proceso. Dónde obtenerlo Se calcula como la hora de inicio del evento posterior dentro del mismo caso. La hora de finalización del último evento puede coincidir con su hora de inicio o con la hora de cierre del caso. Ejemplos 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Prioridad TicketPriority	El nivel de prioridad asignado al incidente, como «Low», «Normal», «High» o «Urgent».
Descripción La prioridad de un incidente determina la urgencia necesaria para responder y resolverlo. Es un factor clave para priorizar el trabajo y asignar recursos dentro del equipo de soporte. En el análisis de procesos, la prioridad se utiliza para segmentar los incidentes y comparar sus flujos y rendimiento. Por ejemplo, los analistas pueden comprobar si los incidentes «Urgent» se resuelven realmente más rápido que los de prioridad «Low». También se utiliza para supervisar el cumplimiento de los SLA, ya que estos suelen definirse según los niveles de prioridad. El KPI «Priority Change Rate» depende del seguimiento de los cambios de este campo. Por qué es importante Este atributo es fundamental para segmentar el análisis, evaluar la eficacia de la priorización y supervisar el cumplimiento de los SLA en distintos niveles de urgencia. Dónde obtenerlo API de Zendesk Tickets, campo priority. Los cambios se registran en la API Ticket Audits. Ejemplos BajaNormalAltaUrgente
	Categoría de la causa raíz RootCauseCategory	La categoría general de la causa raíz subyacente del incidente.
Descripción Este atributo se utiliza para clasificar la razón fundamental por la que ocurrió un incidente. Normalmente se registra hacia el final del ciclo de vida del incidente, a menudo como parte de un análisis post mortem o de un proceso de gestión de problemas, y se almacena en un campo personalizado. Estos datos son esenciales para el Dashboard «Precisión de la identificación de la causa raíz» y el KPI «Cobertura del RCA». Analizar los incidentes por causa raíz ayuda a identificar problemas recurrentes, orientar los esfuerzos para aplicar soluciones permanentes y reducir el volumen de incidentes futuros. De este modo, el enfoque pasa de una respuesta reactiva a la prevención proactiva de problemas. Por qué es importante Permite gestionar los problemas de forma proactiva mediante la categorización de las causas de los incidentes, lo que ayuda a identificar tendencias y prevenir futuras incidencias. Dónde obtenerlo Normalmente es un campo personalizado del ticket. Consulte la configuración de Ticket Fields en Zendesk Admin Center. Ejemplos Error de softwareFallo de hardwareError del usuarioInterrupción de la red
	Duración del caso CaseDuration	El tiempo total transcurrido desde la creación del incidente hasta su cierre definitivo.
Descripción Esta métrica calculada representa el tiempo de ciclo integral de un único incidente. Se calcula obteniendo la diferencia entre la marca de tiempo del primer evento (por ejemplo, «Incidente creado») y la del último evento (por ejemplo, «Incidente cerrado»). La duración del caso es un KPI principal de la eficiencia general del proceso. Se utiliza ampliamente en los Dashboards para mostrar los tiempos de ciclo medios, identificar casos de larga duración y analizar tendencias a lo largo del tiempo. Proporciona una medida general de la rapidez con la que el proceso puede gestionar y resolver incidentes. Por qué es importante Es un KPI fundamental para medir la velocidad general del proceso e identificar los factores que contribuyen a los tiempos de resolución prolongados. Dónde obtenerlo Se calcula obteniendo la diferencia entre la marca de tiempo del último evento y la del primero para cada ID de incidente. Ejemplos 25920060480086400
	Es automatizado IsAutomated	Indicador booleano que señala si una actividad fue realizada por un sistema automatizado o por un agente humano.
Descripción Este atributo derivado ayuda a distinguir entre los eventos ejecutados por personas usuarias y los realizados mediante automatizaciones del sistema, activadores o integraciones de API. Normalmente se determina comprobando si la persona autora de un evento es una persona usuaria del sistema conocida. Comprender el nivel de automatización es fundamental para el análisis moderno de procesos. Ayuda a evaluar la eficacia de las reglas de automatización, identificar tareas manuales que podrían automatizarse y medir el impacto de la automatización en la eficiencia y los tiempos de resolución. Este atributo puede utilizarse para comparar los flujos de proceso de las actividades automatizadas y manuales. Por qué es importante Distingue entre las acciones humanas y las del sistema, algo esencial para analizar el impacto de la automatización en la eficiencia del proceso e identificar nuevas oportunidades de automatización. Dónde obtenerlo Se obtiene comprobando si la persona autora del evento (author_id en la API de auditorías de tickets) corresponde a una persona usuaria conocida del sistema o de una automatización. Ejemplos truefalse
	Etiquetas Tags	Lista de etiquetas aplicadas al incidente para su categorización y contextualización.
Descripción Las etiquetas son rótulos flexibles que pueden añadirse a los tickets para proporcionar contexto adicional o facilitar su categorización y enrutamiento. Los agentes pueden añadirlas manualmente, o bien pueden añadirse automáticamente mediante activadores y automatizaciones. Las etiquetas son una fuente de datos muy valiosa para el análisis de Process Mining. Pueden utilizarse para crear segmentos detallados, como filtrar los incidentes relacionados con el lanzamiento de un producto específico («launch_q4») o con una interrupción conocida («outage_20231027»). Esta flexibilidad permite realizar investigaciones exhaustivas que van más allá de los campos estándar de los tickets. Por qué es importante Ofrece una forma flexible de categorizar y filtrar incidentes, lo que permite realizar análisis detallados y específicos del contexto que quizá no serían posibles utilizando únicamente los campos estándar. Dónde obtenerlo API de tickets de Zendesk, campo tags. Ejemplos usuario_vipproblema_de_redinterrupcion_20231027relacionado_con_facturacion
	Gravedad Severity	El nivel de impacto que el incidente tiene en el negocio.
Descripción La gravedad define el impacto empresarial de un incidente y suele utilizarse junto con la prioridad para determinar la urgencia general. Normalmente se configura como un campo personalizado en Zendesk. Analizar la gravedad ayuda a comprender la criticidad de los incidentes gestionados. Es una dimensión clave para segmentar los datos en Dashboards como «Supervisión del cumplimiento del SLA» y «Métricas de eficacia de la priorización». Comparar los flujos de proceso de distintos niveles de gravedad puede revelar si los incidentes de alta gravedad se gestionan con la rapidez y los recursos adecuados. Por qué es importante Indica el impacto empresarial de un incidente, lo que permite analizar los problemas más críticos y garantizar que se resuelvan de forma eficiente. Dónde obtenerlo Normalmente es un campo personalizado. Consulte la configuración de Ticket Fields en Zendesk Admin Center. Ejemplos 1 - Crítica2 - Alta3 - Media4 - Baja
	Número de transferencias HandoffCount	El número total de veces que un incidente se reasignó a otro agente o grupo.
Descripción Esta métrica calculada cuantifica el número de veces que se transfirió la responsabilidad de un incidente. Cada cambio en los campos Assignee o AssignedGroup incrementa este recuento para el caso. Las transferencias son una fuente habitual de ineficiencia y retrasos en la gestión de incidentes. Un número elevado de transferencias puede indicar reglas de enrutamiento poco claras, carencias de conocimiento en los equipos de soporte o procesos excesivamente complejos. Esta métrica constituye la base del KPI «Promedio de transferencias por incidente» y es fundamental para el Dashboard «Análisis de transferencias y retrabajo». Por qué es importante Cuantifica la fricción del proceso causada por las transferencias y ayuda a localizar ineficiencias de enrutamiento y carencias de conocimiento que prolongan los tiempos de resolución. Dónde obtenerlo Se calcula contando el número de veces que cambió el campo AssignedGroup o Assignee de un incidente. Ejemplos 0135
	Organización del cliente Organization	La organización o empresa a la que pertenece el solicitante del incidente.
Descripción Este atributo vincula un incidente con la organización del cliente. Es esencial en entornos de soporte B2B, donde los niveles de servicio y los procesos de soporte pueden variar según el cliente. Analizar los incidentes por organización permite a los equipos de soporte supervisar la salud del cliente, identificar problemas recurrentes que afectan a clientes concretos y garantizar el cumplimiento de las obligaciones contractuales. Es una dimensión clave para filtrar Dashboards e informes y ofrecer una visión del rendimiento centrada en el cliente. Por qué es importante Permite realizar análisis específicos por cliente, supervisar los niveles de servicio, identificar tendencias en cuentas clave y gestionar eficazmente las relaciones con los clientes. Dónde obtenerlo API de Zendesk Tickets, campo organization_id. Ejemplos Global Tech Inc.Innovate SolutionsData Corp
	Remitente Submitter	El usuario final o sistema que informó originalmente del incidente.
Descripción Este atributo identifica a la persona o entidad que creó el ticket. Se diferencia del solicitante, ya que un agente puede crear un ticket en nombre de otra persona. En el análisis, el remitente puede utilizarse para comprender quién informa de los problemas. Al combinarlo con los datos de la organización, ayuda a identificar si determinados clientes o grupos de usuarios experimentan un volumen elevado de incidentes. Esto puede orientar iniciativas de soporte proactivo o acciones de formación. Por qué es importante Identifica el origen del informe del incidente y permite analizar patrones relacionados con usuarios, departamentos o sistemas automatizados específicos. Dónde obtenerlo API de Zendesk Tickets, campo submitter_id. Ejemplos alice.jones@example.combob.williams@example.comMonitor del sistema
	Se resuelve en el primer contacto IsFirstContactResolution	Indicador booleano que es verdadero si el incidente fue resuelto por el agente o grupo asignado inicialmente, sin ninguna transferencia.
Descripción La resolución en el primer contacto (FCR) es una métrica fundamental para la eficiencia de los centros de soporte y la satisfacción del cliente. Este atributo calculado identifica los incidentes que se resolvieron sin reasignarlos a otro agente o equipo. La lógica normalmente comprueba si el ticket alcanzó el estado «Resuelto» mientras seguía asignado al agente y grupo iniciales. En Process Mining, esto permite calcular directamente la tasa de FCR y comparar las rutas de proceso de los incidentes resueltos en el primer contacto con las de aquellos que requirieron una escalación, lo que ayuda a identificar oportunidades para dotar de más autonomía al soporte de primera línea. Por qué es importante Mide directamente la eficiencia del contacto inicial con el soporte y ayuda a identificar oportunidades para adelantar la resolución en el proceso. Dónde obtenerlo Indicador booleano calculado. Es verdadero si el estado del ticket es «solved» o «closed» y solo hubo una persona asignada o un grupo asignado únicos durante todo el ciclo de vida del incidente. Ejemplos truefalse
	Tipo de ticket TicketType	La clasificación del ticket, como «Incidente», «Problema», «Pregunta» o «Tarea».
Descripción Este campo categoriza el ticket según la naturaleza de la solicitud. El proceso de gestión de incidentes se centra específicamente en los tickets cuyo tipo es «Incidente», que representa una interrupción no planificada o una reducción de la calidad de un servicio de TI. En el análisis, este atributo se utiliza principalmente como filtro para garantizar que solo se incluyan incidentes en la vista del proceso. También puede utilizarse para realizar análisis más amplios de ITSM y comparar los procesos de gestión de incidentes con los de problemas o solicitudes de servicio. Por qué es importante Permite filtrar los datos para centrarse específicamente en los incidentes y garantizar que el análisis del proceso sea relevante para el ciclo de vida de la gestión de incidentes. Dónde obtenerlo API de tickets de Zendesk, tipo de campo. Ejemplos IncidenteProblemaPreguntaTarea
	Valoración de satisfacción SatisfactionRating	La valoración de satisfacción proporcionada por la persona usuaria final después de resolver el incidente.
Descripción Este atributo recoge los comentarios del cliente sobre su experiencia con el soporte, normalmente mediante una encuesta después de resolver el ticket. Las valoraciones habituales en Zendesk son «Buena» o «Mala». Aunque no mide directamente la eficiencia del proceso, la valoración de satisfacción proporciona una métrica de resultados fundamental. En Process Mining, puede correlacionarse con las variantes del proceso para comprender qué rutas de resolución generan una mayor satisfacción del cliente. Por ejemplo, ¿los incidentes con más transferencias reciben valoraciones más bajas? Por qué es importante Proporciona una métrica de resultados clave que puede correlacionarse con las características del proceso para comprender cómo su rendimiento afecta a la satisfacción de las personas usuarias. Dónde obtenerlo API de métricas de tickets de Zendesk (/api/v2/ticket_metrics.json), campo satisfaction_rating.score. Ejemplos BuenoMaloOfrecidoNo ofrecido

Obligatorio Recomendado Opcional

Actividades de gestión de incidentes

Estos son los pasos críticos y los hitos del proceso que debe capturar en su registro de eventos para descubrir y analizar el proceso con precisión.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Estado cambiado a abierto	Indica que un agente ha comenzado a trabajar activamente en el incidente. Normalmente, esta actividad se infiere cuando el campo «status» del ticket cambia de «new» a «open», lo que señala el inicio de la fase de investigación y diagnóstico.
Por qué es importante Este evento marca la transición de la espera al trabajo activo. El tiempo que los tickets permanecen en estado «new» antes de pasar a «open» es un indicador clave del tiempo de respuesta inicial. Dónde obtenerlo Se infiere del registro de auditoría del ticket al identificar un evento «Change» cuyo nuevo valor del campo «status» es «open» y cuyo valor anterior era «new». Recopilar Se infiere de un cambio del campo de estado de «new» a «open». Tipo de evento inferred
	Incidente cerrado	Marca el final definitivo del ciclo de vida del incidente, cuando el ticket se cierra de forma permanente. En Zendesk, esto suele ocurrir automáticamente después de un periodo determinado desde su resolución y se captura como un cambio de estado final.
Por qué es importante Esta es la actividad final definitiva del proceso. La duración total del proceso se calcula desde «Incident Created» hasta este evento, lo que proporciona una visión integral del tiempo de ciclo. Dónde obtenerlo Se captura del registro de auditoría del ticket mediante un evento «Change» cuyo nuevo valor del campo «status» pasa a ser «closed». Recopilar Se identifica mediante un evento «Change» del campo «status» a «closed». Tipo de evento explicit
	Incidente creado	Marca el inicio del ciclo de vida del incidente, cuando se crea un nuevo ticket en Zendesk. Este evento se captura explícitamente mediante el registro de auditoría de creación de tickets de Zendesk y sirve como punto de partida para cada caso.
Por qué es importante Esta es la actividad inicial principal. Analizar el tiempo transcurrido entre este evento y los demás es fundamental para medir la duración total del ciclo de vida del ticket y los tiempos de respuesta iniciales. Dónde obtenerlo Es un evento explícito capturado en los registros de auditoría de tickets de Zendesk. Cada ticket nuevo genera un evento «Create» con su correspondiente marca de tiempo. Recopilar Directamente del evento de creación del ticket en el registro de auditoría. Tipo de evento explicit
	Incidente resuelto	Este hito clave ocurre cuando un agente ha implementado una solución y marca el ticket como «solved». Es una acción explícita que se captura como un cambio de estado en el registro de auditoría del ticket.
Por qué es importante Esta es la actividad principal de resolución y un punto crítico para medir el tiempo hasta la resolución. El tiempo entre este evento y «Incident Closed» representa el periodo de confirmación del usuario o de cierre automático. Dónde obtenerlo Se captura del registro de auditoría del ticket mediante un evento «Change» cuyo nuevo valor del campo «status» pasa a ser «solved». Recopilar Se identifica mediante un evento «Change» del campo «status» a «solved». Tipo de evento explicit
	Ticket asignado a un agente	Esta actividad ocurre cuando se asigna un ticket a un agente específico para su gestión. Es un evento explícito registrado en el historial de auditoría del ticket e indica que una persona ha asumido la responsabilidad.
Por qué es importante Este hito es esencial para medir el tiempo hasta la primera asignación y sirve de base para analizar transferencias, retrabajo y tasas de resolución en el primer contacto. Dónde obtenerlo Se captura del registro de auditoría del ticket cuando el campo «assignee_id» se completa o cambia. La primera asignación es un hito clave para calcular los KPI. Recopilar Se identifica mediante un evento «Change» del campo «assignee_id» en el registro de auditoría del ticket. Tipo de evento explicit
	Ticket reasignado	Ocurre cuando la responsabilidad de un ticket se transfiere de un agente o grupo a otro después de la asignación inicial. Es un evento explícito registrado en el historial de auditoría del ticket.
Por qué es importante Las reasignaciones son fundamentales para analizar las transferencias y el retrabajo. Una frecuencia elevada de reasignaciones suele indicar un enrutamiento inicial incorrecto, problemas complejos o cuellos de botella del proceso. Dónde obtenerlo Se captura del registro de auditoría del ticket al identificar un evento «Change» en el campo «assignee_id» o «group_id» después de que este se haya completado por primera vez. Recopilar Se identifica mediante un evento «Change» posterior del campo «assignee_id» o «group_id». Tipo de evento explicit
	Estado cambiado a pendiente	Indica que el proceso está en pausa mientras espera una respuesta del solicitante. Este evento se infiere cuando el campo «status» del ticket cambia a «pending».
Por qué es importante Esta actividad es fundamental para calcular el tiempo de espera de confirmación del usuario. Las duraciones prolongadas en este estado pueden aumentar considerablemente el tiempo total de resolución y poner de manifiesto demoras en la comunicación. Dónde obtenerlo Se infiere del registro de auditoría del ticket al identificar un evento «Change» cuyo nuevo valor del campo «status» es «pending». Recopilar Se infiere de un cambio del campo de estado a «pending». Tipo de evento inferred
	Nota interna añadida	Esta actividad representa la colaboración interna, cuando un agente añade una nota privada al ticket para otros miembros del equipo. Se captura explícitamente cuando un comentario se marca como no público.
Por qué es importante Analizar las notas internas puede aportar información sobre problemas complejos que requieren colaboración, aunque un número excesivo puede indicar carencias de conocimiento o ineficiencias del proceso. Dónde obtenerlo Se captura a partir de los datos de comentarios del ticket. Un comentario se identifica como nota interna cuando su atributo «public» es false. Recopilar Evento registrado cuando se añade al ticket un comentario nuevo con «public: false». Tipo de evento explicit
	Objetivo de SLA incumplido	Marca el momento en que un ticket no cumple un acuerdo de nivel de servicio definido, como el tiempo de primera respuesta o el tiempo de resolución. Este evento se calcula según las definiciones de la política de SLA y las marcas de tiempo de actualización del ticket.
Por qué es importante Este evento respalda directamente la supervisión del cumplimiento de los SLA. Identificar cuándo y por qué se producen los incumplimientos es fundamental para mejorar la fiabilidad del servicio y la confianza de los clientes. Dónde obtenerlo Es un evento calculado. Puede derivarse mediante el análisis de los datos «sla_policy_metrics» asociados a un ticket, utilizando la marca de tiempo «breached_at» de cada objetivo de SLA. Recopilar Se deriva de la marca de tiempo «breached_at» incluida en los datos de métricas de SLA del ticket. Tipo de evento calculated
	Prioridad establecida	Se define el nivel de prioridad de un incidente, por ejemplo, Low, Normal, High o Urgent. Esto se registra como un evento de cambio explícito y determina la urgencia y el tiempo de respuesta necesario para el ticket.
Por qué es importante Registrar cuándo y cómo se establece la prioridad es fundamental para el Dashboard «Prioritization Effectiveness Metrics» y garantiza que los problemas críticos se atiendan con rapidez. Dónde obtenerlo Se captura a partir de un evento «Change» del campo «priority» en el registro de auditoría del ticket. También pueden registrarse cambios posteriores para medir el KPI Priority Change Rate. Recopilar Se identifica mediante un evento «Change» del campo «priority» en el registro de auditoría del ticket. Tipo de evento explicit
	Respuesta pública enviada	Representa una comunicación enviada por un agente de soporte al usuario final. Es un evento explícito en Zendesk que se captura cada vez que se añade un comentario público al ticket.
Por qué es importante El seguimiento de las respuestas públicas es importante para comprender la frecuencia de comunicación y puede ser una parte clave de la cronología al analizar las demoras en la confirmación del usuario. Dónde obtenerlo Se captura a partir de los datos de comentarios del ticket. Un comentario se identifica como público cuando su atributo «public» es true. Recopilar Evento registrado cuando se añade al ticket un comentario nuevo con «public: true». Tipo de evento explicit
	Satisfacción del usuario valorada	Representa el momento en que el usuario final proporciona una valoración de satisfacción sobre el soporte recibido. Es un evento explícito que Zendesk captura después de resolver un ticket.
Por qué es importante Analizar las valoraciones de satisfacción proporciona información esencial sobre el rendimiento de los agentes y la eficacia del proceso, y relaciona las métricas del proceso con los resultados para el cliente. Dónde obtenerlo Se captura a partir de los datos de valoraciones de satisfacción asociados al ticket. Normalmente incluyen una puntuación («good» o «bad») y un comentario opcional. Recopilar Evento registrado cuando se envía una valoración de satisfacción para el ticket. Tipo de evento explicit
	Ticket asignado a un grupo	Representa el enrutamiento o triaje inicial de un incidente a un grupo de soporte específico. Normalmente es el primer paso para asignar la responsabilidad y se registra como un evento de cambio explícito en el historial de auditoría del ticket.
Por qué es importante El seguimiento de las asignaciones de grupo ayuda a analizar la eficiencia del proceso de triaje inicial e identificar demoras antes de que el ticket se envíe al equipo adecuado. Dónde obtenerlo Se captura del registro de auditoría del ticket cada vez que el campo «group_id» se establece o cambia. La primera aparición de este cambio después de la creación corresponde a la asignación inicial. Recopilar Se identifica mediante un evento «Change» del campo «group_id» en el registro de auditoría del ticket. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Acceda a Zendesk Explore: Inicie sesión en su instancia de Zendesk Support con una cuenta de usuario que tenga permisos para crear y gestionar informes en Zendesk Explore.
Cree un informe nuevo: Acceda al módulo Explore. Haga clic en el icono «Reports» de la barra de navegación izquierda y, después, en el botón «New report».
Seleccione el conjunto de datos: En la ventana «Choose a dataset», seleccione el conjunto de datos Support: Ticket updates [default]. Este conjunto contiene el registro de auditoría de cada cambio en los tickets, algo esencial para crear un Registro de eventos.
Añada los atributos iniciales (columnas): En el generador de informes, vaya a la sección «Rows». Haga clic en «Add» y seleccione los siguientes atributos. Estos formarán las columnas de su Registro de eventos: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Cree atributos calculados: Este es el paso más importante. Vaya al menú «Calculations» (el icono del matraz) y seleccione «Standard calculated attribute». Cree los tres atributos definidos en la sección «Query»: ActivityName, SourceSystem y LastDataUpdate. Deberá copiar exactamente las fórmulas proporcionadas.
Ajuste las columnas del informe: Añada los atributos calculados que acaba de crear (ActivityName, SourceSystem, LastDataUpdate) a la sección «Rows». Ahora puede eliminar los campos sin procesar utilizados para crear ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) para simplificar la vista.
Añada filtros al informe: Vaya a la sección «Filters» y haga clic en «Add». Añada un filtro para Update - Date y seleccione un intervalo adecuado, por ejemplo, los últimos 3 meses. Añada otro filtro sobre el atributo calculado ActivityName y excluya los valores nulos para eliminar las actualizaciones de tickets que no correspondan a una actividad deseada.
Ejecute y revise el informe: Zendesk Explore actualizará automáticamente el informe a medida que añada atributos y filtros. Revise la tabla de datos para comprobar que las filas y columnas aparecen como esperaba. El informe debe mostrar una fila por evento.
Exporte los datos a CSV: Cuando el informe esté listo, haga clic en el botón «Export» situado en la esquina superior derecha y seleccione «CSV». Zendesk generará y descargará el archivo CSV.
Prepare la carga: Abra el archivo CSV exportado. Cambie el nombre de los encabezados de columna para que coincidan con los nombres de atributos requeridos por su herramienta de Process Mining, por ejemplo, cambie «Ticket ID» por TicketId y «Update - Timestamp» por EventTimestamp. Asegúrese de que el formato de fecha de las marcas de tiempo cumpla con ISO 8601. El archivo ya estará listo para cargarse.

Configuración

Conjunto de datos de Zendesk: El informe debe basarse en el conjunto de datos Support: Ticket updates [default]. Es el único conjunto de datos estándar que proporciona el registro de auditoría detallado necesario para reconstruir el proceso evento por evento.
Filtrado por intervalo de fechas: Es fundamental aplicar un filtro de fecha para limitar el volumen de datos. Utilice el atributo Update - Date como filtro principal. Para un análisis inicial, normalmente se recomienda un intervalo de 3 a 6 meses.
Filtro de actividad: Después de crear el atributo calculado ActivityName, debe filtrar el informe para excluir las filas cuyo valor sea nulo. Esto elimina los cambios irrelevantes de los tickets, como las actualizaciones del sistema o los cambios de etiquetas, del Registro de eventos.
Atributos calculados: La lógica de esta extracción depende en gran medida de un atributo calculado estándar que traduzca los cambios sin procesar de los campos de los tickets en nombres de actividades comprensibles. La precisión de la fórmula es fundamental.
Requisitos previos: El usuario que ejecute el informe necesita al menos el rol «Viewer» en Zendesk Explore. Para crear y guardar el informe, se requieren permisos de «Editor» o «Admin».

a Consulta de ejemplo config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Pasos

Requisitos previos: Asegúrese de tener Python 3.6 o una versión posterior instalado en su sistema, junto con las bibliotecas requests y pandas. Puede instalarlas mediante pip: pip install requests pandas.
Genere un token de API de Zendesk: Inicie sesión en su instancia de Zendesk Support como administrador. Vaya a Admin Center > Apps and integrations > APIs > Zendesk APIs. En la sección «API Tokens», añada un token de API activo y guarde de forma segura la cadena de token generada.
Configure el script de Python: Cree un archivo nuevo de Python, por ejemplo, extract_zendesk_logs.py, y copie en él el script proporcionado. Actualice las variables de marcador de posición situadas al principio del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y ZENDESK_API_TOKEN con sus credenciales específicas. Establezca START_TIMESTAMP para definir el inicio del periodo de extracción deseado, utilizando una marca de tiempo Unix epoch.
Comprenda los endpoints de la API: El script utiliza principalmente dos endpoints de la API de Zendesk. El endpoint incremental/tickets/cursor.json se utiliza para obtener de forma eficiente todos los tickets actualizados desde START_TIMESTAMP. Después, para cada ticket, el script llama al endpoint tickets/{ticket_id}/audits.json para obtener un historial detallado de cada cambio y evento.
Ejecute el script: Ejecute el script desde su terminal con el comando: python extract_zendesk_logs.py. El script comenzará a obtener datos de la API de Zendesk.
Supervise el progreso del script: El script imprimirá en la consola el número de tickets procesados, lo que le permitirá supervisar el progreso. Según el intervalo de fechas y el volumen de tickets, el proceso puede tardar bastante.
Obtención de datos y paginación: El script gestiona automáticamente la paginación de la API. Comienza con la URL inicial de exportación de tickets y sigue la after_url proporcionada en cada respuesta de la API hasta recuperar todos los tickets del periodo.
Transformación de eventos: Para cada ticket, el script recorre su historial de auditoría. Analiza cada evento de auditoría y asigna los tipos de evento internos de Zendesk, como Create, Change y Comment, a las actividades empresariales requeridas, como Incident Created, Status Changed to Open y Public Reply Sent.
Gestión de datos de SLA: El script incluye una función específica, get_sla_breach_events, para obtener las métricas de SLA de cada ticket resuelto. Esto es necesario porque los incumplimientos de SLA no son eventos estándar del registro de auditoría. Esta función realiza una llamada adicional a la API para obtener los detalles de aplicación de la política de SLA.
Genere el Registro de eventos: Una vez procesados todos los tickets, el script compila los eventos extraídos en un DataFrame de pandas y guarda el Registro de eventos final como un archivo CSV llamado zendesk_incident_event_log.csv en el mismo directorio desde el que se ejecutó el script.
Prepare la carga: Revise el archivo CSV generado para comprobar que sea correcto. El archivo ya tendrá el formato necesario para cargarse directamente en ProcessMind y analizarse.

Configuración

Credenciales de la API de Zendesk: Debe proporcionar el subdominio de Zendesk, la dirección de correo electrónico asociada a una cuenta de administrador o agente y un token de API válido. Guarde estas credenciales de forma segura y no las incluya directamente en scripts bajo control de versiones para uso en producción.
Marca de tiempo inicial (START_TIMESTAMP): Este valor entero determina el punto de inicio de la extracción de datos. Debe ser una marca de tiempo Unix epoch. Se recomienda comenzar entre 3 y 6 meses atrás para recopilar una cantidad significativa de datos sin sobrecargar el sistema. Puede utilizar un conversor en línea para obtener la marca de tiempo correcta de una fecha concreta.
Limitación de solicitudes de la API: El script realiza numerosas llamadas a la API. Zendesk aplica límites de solicitudes que varían según el plan. Aunque el script funciona con volúmenes de datos moderados, en instancias muy grandes puede ser necesario añadir llamadas a time.sleep() dentro de los bucles para evitar alcanzar el límite y recibir un error 429.
Bibliotecas de Python necesarias: El script depende de la biblioteca requests para realizar llamadas a la API y de pandas para manipular datos y exportar archivos CSV. Asegúrese de que estén instaladas en su entorno de Python.
Permisos de usuario: La cuenta de usuario asociada al token de API debe tener permisos suficientes para leer los datos de los tickets, incluidas las auditorías y las métricas 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 Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Pasos

Cree un cliente de API de Zendesk con permisos para leer tickets, auditorías de tickets, usuarios, grupos, valoraciones de satisfacción y exportaciones incrementales. Utilice un token de API o una credencial OAuth configurada para su instancia de Zendesk Support. Guarde el subdominio, la credencial y la marca de control de extracción como valores de configuración seguros.
Utilice la API de exportación incremental de tickets de Zendesk para recuperar los tickets actualizados después de la última marca de control procesada correctamente. El script siguiente utiliza el patrón de endpoint documentado, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, y sigue la paginación mediante cursor hasta que la API indica que el conjunto de resultados está completo.
Para cada ticket devuelto, solicite su historial de auditoría mediante el endpoint de auditorías de tickets. Los registros de auditoría son necesarios porque ProcessMind lee el Registro de eventos tal como está y no infiere actividades a partir del estado final del ticket. Conserve la marca de tiempo de auditoría, el actor, el identificador del ticket y los eventos de auditoría.
Convierta los eventos de auditoría en filas de eventos explícitas. Extraiga la creación del ticket, la asignación de grupo, la asignación de agente, los cambios de prioridad, los cambios de estado a abierto, las respuestas públicas, las notas internas, la reasignación, los cambios de estado a pendiente, el estado resuelto y el estado cerrado. Extraiga las valoraciones de satisfacción como filas independientes cuando estén disponibles. Calcule los incumplimientos de SLA solo cuando estén disponibles el objetivo de SLA requerido y las marcas de tiempo de los eventos, y documente los datos utilizados para el cálculo.
Mantenga la última marca de tiempo de actualización o el último cursor procesado correctamente. No avance la marca de control hasta que todas las páginas, auditorías de tickets y registros opcionales de satisfacción se hayan escrito correctamente. En la primera ejecución, utilice una hora de inicio acotada, como [Start date in ISO 8601 format], que normalmente cubra entre tres y seis meses.
Complete las columnas obligatorias TicketId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate. Complete las columnas recomendadas TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus y EventEndTime siempre que los datos de origen las admitan. Utilice valores vacíos únicamente cuando Zendesk no proporcione el atributo para el evento.
Elimine duplicados utilizando TicketId, ActivityName, EventTimestamp y un identificador de evento de origen estable cuando esté disponible. Conserve las apariciones legítimas múltiples de una misma actividad, como varias respuestas públicas, notas internas, asignaciones o cambios de estado.
Escriba las filas resultantes en un archivo CSV u otro formato de Registro de eventos compatible con ProcessMind. Asegúrese de que las marcas de tiempo estén en formato ISO 8601 con un desplazamiento UTC explícito, que TicketId tenga un tipo coherente, que los valores de ActivityName coincidan exactamente con los nombres de actividades documentados y que LastDataUpdate sea idéntico en todas las filas del mismo lote de extracción.
Cargue el Registro de eventos en ProcessMind y configure Incident ID como identificador del caso, Activity como columna de actividad y Event Timestamp como columna de fecha y hora del evento. Valide que cada actividad obligatoria esté representada por filas explícitas y no se derive durante la visualización.

Configuración

Método de API: API de exportación incremental de tickets de Zendesk con paginación mediante cursor. Utilice el endpoint de auditoría de tickets para la extracción a nivel de evento y el endpoint de satisfacción cuando las valoraciones de satisfacción estén habilitadas y sean accesibles.
Configuración obligatoria: subdominio de Zendesk, autenticación de la API, fecha de inicio inicial, marca de control de extracción, tiempo de espera de las solicitudes, política de reintentos y ubicación de salida. Sustituya [Your Zendesk subdomain], [Your API email] y [Your API token] por valores seguros de despliegue.
Intervalo de fechas: Para una carga inicial, utilice entre tres y seis meses, salvo que se necesite un historial más amplio. Para cargas recurrentes, solicite los registros posteriores a la última marca de control correcta e incluya una pequeña ventana de solapamiento para protegerse frente a actualizaciones recibidas con retraso; después, elimine los duplicados.
Filtros: Aplique filtros por empresa, marca, grupo, organización, formulario de ticket, canal o campos personalizados únicamente cuando el alcance del proceso los requiera explícitamente. Zendesk Support no utiliza filtros de Company Code o Document Type al estilo de SAP, salvo que esos conceptos estén representados por campos de Zendesk configurados.
Semántica de eventos: Considere los eventos de auditoría como la fuente autorizada para los cambios explícitos. No cree un evento de cambio de estado simplemente porque el estado actual del ticket tenga un valor. El evento de estado debe proceder de un evento de auditoría u otra fuente de eventos documentada.
Configuración de SLA: SLA Target Breached requiere acceso a la política de SLA aplicable, la duración objetivo, el calendario de horas laborables y las marcas de tiempo necesarias para evaluar el objetivo. Si Zendesk expone un evento o una métrica de incumplimiento, utilice esa fuente. De lo contrario, calcúlelo únicamente con datos de política documentados y conserve la base del cálculo.
Configuración de satisfacción: User Satisfaction Rated requiere que las valoraciones de satisfacción estén habilitadas y que el registro de valoración sea accesible mediante la API. Un ticket resuelto sin valoración no debe recibir un evento de valoración sintético.
Rendimiento: Utilice paginación mediante cursor, concurrencia limitada para las solicitudes de auditoría de tickets, reutilización de conexiones, retroceso exponencial para los límites de solicitudes y puntos de control después de los lotes procesados correctamente. Evite solicitar repetidamente todas las auditorías de tickets en cada ejecución.
Integridad: Las exportaciones incrementales pueden incluir tickets actualizados después de la hora solicitada, pero la recuperación de auditorías y las actualizaciones tardías deben gestionarse por separado. Utilice una ventana de solapamiento y claves de eliminación de duplicados estables.
Requisitos previos: acceso a la API, permisos para leer tickets y auditorías, acceso a usuarios y grupos para resolver nombres, acceso a los datos de satisfacción si son necesarios y acceso a los datos de SLA si se requiere calcular incumplimientos. La disponibilidad de tipos de eventos de auditoría específicos puede variar según la configuración y la suscripción de Zendesk.

a Consulta de ejemplo python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"SourceSystem", class="hl-string">"LastDataUpdate",
    class="hl-string">"TicketStatus", class="hl-string">"Assignee", class="hl-string">"AssignedGroup", class="hl-string">"TicketPriority", class="hl-string">"Channel",
    class="hl-string">"SlaStatus", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Pasos

Seleccione una herramienta comercial de ETL o integración de datos que ofrezca un conector verificado para Zendesk Support, admita el historial de auditoría y la extracción de comentarios de tickets y pueda escribir en su almacén de datos o sistema de archivos de destino. Confirme que el conector admita la extracción incremental, la paginación, la gestión de límites de solicitudes y la conservación de las marcas de tiempo de origen.
Cree la conexión de Zendesk en la herramienta seleccionada. Introduzca el subdominio de Zendesk, el método de autenticación, las credenciales o el token y cualquier configuración de conexión necesaria mediante la interfaz de configuración de la herramienta. Conceda acceso a tickets, auditorías de tickets, comentarios, usuarios, grupos, valoraciones de satisfacción y datos de SLA cuando esos objetos estén disponibles en su plan de Zendesk y en el conector.
Configure el intervalo de extracción. Utilice un periodo móvil de 3 a 6 meses para la carga inicial y, después, configure cargas incrementales basadas en la marca de tiempo de actualización o de auditoría que admita el conector. Guarde la última marca de control de extracción correcta fuera del Registro de eventos para evitar duplicar u omitir eventos en ejecuciones posteriores.
Extraiga los datos a nivel de ticket necesarios para el contexto del caso, incluidos el identificador del ticket, el estado actual o del evento, el agente asignado, el grupo, la prioridad, el canal de información, el estado del SLA y las marcas de tiempo de actualización relevantes. Extraiga los registros de auditoría de tickets porque las asignaciones, los cambios de prioridad, los cambios de estado y otros cambios de campos deben representarse como filas de eventos explícitas.
Extraiga los comentarios de los tickets y distinga los comentarios públicos de las notas internas mediante el indicador de visibilidad pública o privada del conector. Extraiga las marcas de tiempo de los comentarios, los identificadores de los tickets, los identificadores de los autores y cualquier hora de finalización disponible. Cree filas Public Reply Sent para los comentarios públicos y filas Internal Note Added para los comentarios privados.
Extraiga los registros de valoraciones de satisfacción y de incumplimientos de SLA cuando el conector los exponga. Si el conector no expone directamente los eventos de incumplimiento de SLA, configure la herramienta ETL para calcularlos a partir del objetivo de SLA, la política, el calendario de horas laborables y las marcas de tiempo de los eventos disponibles. No cree una fila de incumplimiento salvo que los datos de origen o un cálculo configurado demuestren que se superó el objetivo.
Reestructure los registros de origen extraídos en un Registro de eventos normalizado. Cree una fila por cada aparición explícita de una actividad. Asigne la creación del ticket a Incident Created, los cambios de asignación de grupo a Ticket Assigned to Group o Ticket Reassigned, los cambios de asignación de agente a Ticket Assigned to Agent o Ticket Reassigned, los cambios de prioridad a Priority Set, las transiciones de estado a la actividad de estado correspondiente, los comentarios a Public Reply Sent o Internal Note Added, el estado resuelto a Incident Resolved, los registros de satisfacción a User Satisfaction Rated y el estado cerrado a Incident Closed.
Aplique las reglas de clasificación de eventos en un orden determinista. Utilice los valores anteriores y nuevos del historial de auditoría cuando estén disponibles. Clasifique la primera asignación a un grupo como Ticket Assigned to Group, la primera asignación a un agente como Ticket Assigned to Agent y los cambios posteriores de responsable como Ticket Reassigned. Emita una fila por cada cambio que cumpla los criterios, no solo por el estado más reciente del ticket.
Complete las columnas obligatorias TicketId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate. Complete las columnas recomendadas TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus y EventEndTime a partir del contexto del evento o del registro de origen válido más cercano. Conserve las marcas de tiempo de origen en una zona horaria coherente, preferiblemente UTC, y mantenga la precisión original que admita el conector.
Valide el resultado transformado comprobando que cada TicketId tenga una fila Incident Created, que las marcas de tiempo de los eventos estén dentro del intervalo de extracción cuando corresponda, que los 13 nombres de actividades obligatorios estén representados cuando existan datos de origen y que las claves de eventos duplicadas se gestionen según el identificador de auditoría de origen o una clave compuesta documentada.
Escriba el Registro de eventos en la tabla del almacén de datos de destino o en un archivo con formato tabular compatible con ProcessMind, como CSV o el formato del conector de almacén admitido. Utilice una única fila de encabezados, nombres de columnas estables, codificación UTF-8, marcas de tiempo ISO 8601 y ningún JSON anidado en las columnas finales de eventos. Cargue o conecte el Registro de eventos resultante a ProcessMind sin depender de actividades inferidas, ya que ProcessMind lee las filas extraídas tal como están.

Configuración

Conector y licencia: Utilice una herramienta comercial de ETL o integración de datos con un conector de Zendesk Support que exponga tickets, auditorías de tickets, comentarios, usuarios, grupos, valoraciones de satisfacción e información de SLA según lo admita el plan de Zendesk y la versión del conector.
Autenticación y autorización: Configure el subdominio de Zendesk y un método de autenticación aprobado. Conceda únicamente los permisos necesarios para extraer tickets, auditorías, comentarios, usuarios, grupos, satisfacción y SLA. Confirme que la cuenta de integración pueda leer registros históricos.
Intervalo de fechas: Comience con entre 3 y 6 meses para la validación y la carga inicial. Amplíe el intervalo solo después de verificar los recuentos de filas, la paginación y el comportamiento de los límites de solicitudes. Utilice una marca de control incremental para las ejecuciones programadas.
Filtros obligatorios: Aplique únicamente filtros específicos de la empresa confirmados en la configuración de origen, como un subdominio de Zendesk, una marca, una organización, un grupo o un alcance de tickets seleccionados. No aplique filtros de Company Code o Document Type salvo que esos campos existan en el modelo de datos de Zendesk configurado.
Historial de auditoría: Habilite la extracción de eventos de auditoría de tickets y conserve el identificador de auditoría de origen, cuando esté disponible, para evitar eventos duplicados durante las cargas incrementales.
Comentarios: Extraiga tanto los comentarios públicos como los privados. Utilice el indicador de visibilidad de origen para clasificar Public Reply Sent e Internal Note Added. No infiera la visibilidad a partir del texto del comentario.
Clasificación de asignaciones: Compare los valores anteriores y nuevos del grupo o del agente asignado. Clasifique por separado la primera asignación que cumpla los criterios y los cambios posteriores, y emita Ticket Reassigned para los cambios posteriores de responsable.
Clasificación de estados: Emita filas únicamente para transiciones de estado explícitas. Asigne los valores new, open, pending, solved y closed según el modelo de estados de Zendesk configurado. Si utiliza estados personalizados, documente la correspondencia antes de cargar los datos.
Gestión de SLA: Dé prioridad a los eventos de incumplimiento de SLA de origen. Si no están disponibles, configure un cálculo documentado utilizando el objetivo de SLA, la política, el calendario de horas laborables y las marcas de tiempo de los eventos disponibles. Registre la base del cálculo en los metadatos de ETL, sin inventar campos de origen.
Gestión de marcas de tiempo: Normalice EventTimestamp y EventEndTime a UTC u otra zona horaria documentada. Conserve la marca de tiempo de origen y no la sustituya por la hora de extracción.
LastDataUpdate: Establezca LastDataUpdate en la marca de tiempo de la actualización de ETL completada correctamente, de forma coherente para todas las filas de esa carga.
Rendimiento: Utilice paginación, extracción incremental, particionamiento por actualización del ticket o marca de tiempo de auditoría, paralelismo controlado, gestión de reintentos y retroceso ante límites de solicitudes. Evite extraer repetidamente todo el historial de tickets en cada ejecución programada.
Esquema de destino: Configure una tabla o un archivo de eventos plano con las columnas obligatorias TicketId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate, además de los atributos recomendados cuando estén disponibles.
Comportamiento de ProcessMind: No dependa de ProcessMind para derivar cambios de estado, asignaciones, respuestas, notas, incumplimientos de SLA o hitos del ciclo de vida. Cada actividad debe existir ya como fila de evento antes de la carga.

a Consulta de ejemplo config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

¿Listo para comenzar?

Utilice este Template para agilizar la preparación de sus datos y obtener información valiosa sobre el rendimiento de su gestión de incidentes. Comience hoy mismo a optimizar su proceso.

Volver a la guía de mejora Descargar Template

Optimice la gestión de incidentes y resuélvalos más rápido desde hoy

Reduzca el MTTR un 35 %, elimine los incidentes recurrentes y aumente la satisfacción.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Comience a mejorar en cuestión de minutos.

Su Template de datos para la gestión de incidentes

Su Template de datos para la gestión de incidentes

Atributos de la gestión de incidentes

Actividades de gestión de incidentes

Guías de extracción

Exportación de informes de Zendesk Explore desde la interfaz a un archivo CSV

Pasos

Configuración

a Consulta de ejemplo config

Script de Python mediante la API REST de Zendesk Support

Pasos

Configuración

a Consulta de ejemplo python

API de exportación incremental de Zendesk para sincronización masiva de datos

Pasos

Configuración

a Consulta de ejemplo python

Herramienta ETL de terceros con conector de la API de Zendesk

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Optimice la gestión de incidentes y resuélvalos más rápido desde hoy

Su Template de datos para la gestión de incidentes

Su Template de datos para la gestión de incidentes

Atributos de la gestión de incidentes

Actividades de gestión de incidentes

Guías de extracción

Exportación de informes de Zendesk Explore desde la interfaz a un archivo CSV

Pasos

Configuración

a Consulta de ejemplo config

Script de Python mediante la API REST de Zendesk Support

Pasos

Configuración

a Consulta de ejemplo python

API de exportación incremental de Zendesk para sincronización masiva de datos

Pasos

Configuración

a Consulta de ejemplo python

Herramienta ETL de terceros con conector de la API de Zendesk

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Optimice la gestión de incidentes y resuélvalos más rápido desde hoy

Valoramos su privacidad