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

Su Template de datos para la gestión de incidencias

Zendesk Support

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

Su Template de datos para la gestión de incidencias

Este Template ofrece una visión estructurada de los datos esenciales para analizar eficazmente el proceso de gestión de incidencias. Describe los atributos clave que debe recopilar y las actividades importantes que debe seguir, e incluye indicaciones prácticas para extraer estos datos de Zendesk Support. Úselo para que su proyecto de Process Mining comience con un conjunto de datos completo y fiable.

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

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

Descargar Template

Atributos de gestión de incidencias

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

5 Obligatorio 7 Recomendado 11 Opcional

	Nombre	Descripción
	ID del incidente TicketId	Identificador único que el sistema genera para cada ticket de incidente.
Descripción El ID del incidente es la clave principal que identifica de forma única cada caso de incidente en Zendesk Support. En Process Mining, funciona como CaseId y vincula todas las actividades, los cambios de estado y las comunicaciones relacionadas, desde la creación del incidente hasta su cierre. Este ID es fundamental para reconstruir todo el recorrido de cada incidente durante el análisis. Permite agrupar los datos de eventos y hacer 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 del procedimiento estándar. Por qué es importante Este identificador esencial vincula todos los eventos con un mismo incidente, lo que permite seguir todo su ciclo de vida y analizar con precisión el rendimiento del proceso. Dónde obtenerlo API de tickets de Zendesk (/api/v2/tickets/{id}), campo id. Ejemplos 19428230113521941055
	Marca de tiempo del evento EventTimestamp	Fecha y hora exactas en que ocurrió la actividad.
Descripción Esta marca de tiempo registra el momento exacto en que ocurrió un evento del ciclo de vida del incidente, como la incorporación de un comentario o un cambio de estado. Establece 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 de los casos y analizar el rendimiento del proceso en distintos períodos. Las marcas de tiempo precisas son esenciales para crear un mapa animado del proceso que muestre cómo avanzan los casos con el tiempo y para crear Dashboards de rendimiento que hagan seguimiento de KPI como el tiempo promedio de resolución. Por qué es importante Las marcas de tiempo sitúan cronológicamente todas las actividades y permiten calcular duraciones, detectar cuellos de botella y analizar el rendimiento del proceso a lo largo del tiempo. Dónde obtenerlo API de auditoría de tickets de Zendesk (/api/v2/tickets/{ticket_id}/audits), campo created_at de cada evento de auditoría. Ejemplos 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Actividad ActivityName	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 concreta del proceso de gestión de incidentes, como 'Incidente creado', 'Ticket asignado a un agente' o 'Incidente resuelto'. Estas actividades se derivan del registro de eventos o de los datos del historial 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 y constituye la base de todo análisis. Al analizar el flujo de actividades, las organizaciones pueden descubrir las rutas reales de los incidentes, detectar cuellos de botella entre pasos, medir los ciclos de retrabajo, por ejemplo, cuando se vuelve 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 la base del análisis de Process Mining para detectar ineficiencias, desviaciones y oportunidades de mejora. Dónde obtenerlo Se deriva de los eventos de la API de auditoría de tickets de Zendesk. Por ejemplo, un evento Change en el campo de estado podría asignarse a 'Estado cambiado'. Ejemplos Incidente creadoTicket asignado a un agenteEstado cambiado a pendienteIncidente resueltoIncidente cerrado
	Sistema de origen SourceSystem	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', para indicar que todos los eventos y atributos proceden de ese sistema. En entornos que combinan datos de varios sistemas, este campo es fundamental para distinguir las distintas fuentes de datos. Ayuda a garantizar la integridad de los datos y permite realizar análisis por fuente, como comparar el proceso de gestión de incidentes de Zendesk con el de otra herramienta de 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 información 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 los datos LastDataUpdate	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 datos del sistema de origen. Por lo general, se aplica un único valor a todo el conjunto de datos de cada ciclo de actualización. Esta información es fundamental para la gobernanza de datos y para quienes utilizan el análisis de Process Mining. Indica qué tan recientes son los datos y ayuda a los analistas a saber si están consultando la información más actualizada disponible. Esto es especialmente importante para supervisar el rendimiento operativo y tomar decisiones oportunas basadas en el análisis. Por qué es importante Indica qué tan recientes son los datos, para que quienes consultan el análisis sepan hasta qué fecha está actualizado y cuándo se obtuvieron los datos por última vez. Dónde obtenerlo Marca de tiempo generada por el proceso de ETL o la canalización de datos al finalizar la actualización. Ejemplos 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente asignado Assignee	Agente de soporte asignado actualmente para gestionar el incidente.
Descripción Este atributo identifica al agente responsable del incidente en un momento determinado. Los cambios de persona asignada son eventos clave que indican el traspaso del trabajo de una persona a otra. Analizar los agentes asignados ayuda a comprender la distribución de la carga de trabajo, el desempeño individual y los patrones de colaboración. Registrar los cambios en este campo es esencial para calcular el KPI «Promedio de traspasos por incidente» e identificar los casos en que los incidentes pasan de una persona a otra con frecuencia, lo que puede indicar falta de conocimientos o un enrutamiento ineficiente. Por qué es importante Identifica al agente responsable y permite analizar la carga de trabajo y hacer un seguimiento de los traspasos, algo fundamental para detectar ineficiencias en el proceso. Dónde obtenerlo API de Tickets de Zendesk, campo assignee_id. Los cambios se registran en la API Ticket Audits. Ejemplos John SmithJane DoeAutomatización de la mesa de ayuda
	Canal de notificación Channel	Canal por el que se notificó inicialmente el incidente, como «Correo electrónico», «Web» o «API».
Descripción Este atributo registra el método que utilizó la persona usuaria final o el sistema para crear el ticket del incidente. Conocer el canal es importante para analizar el origen de los incidentes y adaptar el proceso de soporte. El análisis de los incidentes por canal puede revelar distintos patrones. Por ejemplo, los incidentes notificados por teléfono podrían resolverse más rápido que los recibidos por correo electrónico. Esta información contribuye al Dashboard «Volumen de incidentes gestionados» y ayuda a planificar los recursos y optimizar los canales. Por qué es importante Permite analizar el volumen de incidentes y el desempeño del proceso según su origen, lo que facilita mejoras específicas para cada canal y una mejor asignación de recursos. Dónde obtenerlo API de Tickets de Zendesk, campo via.channel. Ejemplos webcorreo electrónicoapiteléfono
	Estado del SLA SlaStatus	Estado actual del Acuerdo de Nivel de Servicio (SLA) del incidente.
Descripción Este atributo indica si el incidente va camino de cumplir los objetivos del SLA definidos, si ya los incumplió o si los temporizadores del SLA están en pausa. Zendesk registra automáticamente las métricas del SLA según las políticas configuradas. Este atributo es clave para el Dashboard «Supervisión del cumplimiento de los SLA». Mide directamente el desempeño respecto de los compromisos de servicio. Al analizar cuándo y por qué se incumplen los SLA, las organizaciones pueden detectar puntos débiles en los procesos y mejorar la fiabilidad del servicio. También contribuye directamente al KPI «Tasa de cumplimiento del SLA de incidentes». Por qué es importante Mide directamente el desempeño respecto de los compromisos de servicio y permite analizar los incumplimientos de los SLA y supervisar proactivamente el cumplimiento para mejorar el servicio. 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 pausaIncumplidoCumplido
	Estado del ticket TicketStatus	Estado del ticket del incidente en el momento del evento, por ejemplo, 'Abierto', 'Pendiente' o 'Resuelto'.
Descripción Este atributo refleja el estado del ticket del incidente en distintos momentos de su ciclo de vida. Los estados estándar de Zendesk incluyen nuevo, abierto, pendiente, en espera, resuelto y cerrado. El seguimiento de los cambios en este campo es una de las principales formas de generar actividades para Process Mining. Analizar el estado del ticket es fundamental para entender el proceso. Ayuda a determinar cuánto tiempo permanecen los incidentes en ciertos estados, como 'Pendiente', que suele indicar que se espera una respuesta del cliente. También es clave para definir cuándo se completa un caso y calcular los tiempos de resolución. Por qué es importante El seguimiento de los cambios de estado es clave para comprender cómo avanza el proceso, identificar los tiempos de espera y definir los puntos de inicio y fin del ciclo de vida del incidente. Dónde obtenerlo API de Tickets de Zendesk, campo status. Los cambios se registran en la API Ticket Audits. Ejemplos nuevoabiertopendienteresueltocerrado
	Grupo asignado AssignedGroup	Equipo o grupo de soporte asignado actualmente al incidente.
Descripción Este atributo indica qué equipo es responsable del incidente. A menudo, los incidentes pasan por distintos niveles de soporte o grupos especializados, por ejemplo, de «Soporte de nivel 1» al «Equipo de redes». Es una dimensión clave para analizar los traspasos entre equipos e identificar cuellos de botella. Al supervisar cómo pasan los incidentes de un grupo a otro, los analistas pueden medir las dependencias entre equipos, calcular los tiempos en cola de cada equipo y optimizar las reglas de enrutamiento. Este atributo contribuye directamente al Dashboard «Análisis de traspasos y retrabajo». Por qué es importante Registra qué equipo tiene asignado el incidente, un dato esencial para analizar los traspasos entre equipos, detectar cuellos de botella específicos de cada equipo y medir los tiempos en cola. Dónde obtenerlo API de Tickets de Zendesk, 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	Marca de tiempo que indica cuándo se completó una actividad.
Descripción La hora de finalización del evento marca el cierre de una actividad. En los datos del registro de eventos, la hora de finalización de una actividad suele inferirse a partir de la hora de inicio de la siguiente actividad del mismo caso. En la última actividad de un caso, 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. Estos datos son la base del análisis de cuellos de botella y permiten ver no solo cuánto tarda un paso, sino también cuánto tiempo permaneció inactivo el caso antes de que comenzara. Por qué es importante Permite calcular la duración de las actividades y los tiempos de espera, algo fundamental para analizar en detalle los cuellos de botella e identificar demoras en el proceso. Dónde obtenerlo Se calcula a partir de la hora de inicio del siguiente evento 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	Nivel de prioridad asignado al incidente, como «Baja», «Normal», «Alta» o «Urgente».
Descripción La prioridad de un incidente determina la urgencia con la que debe responderse y resolverse. Es un factor clave para priorizar el trabajo y asignar recursos dentro del equipo de soporte. En el análisis de procesos, la prioridad permite segmentar los incidentes y comparar sus flujos de proceso y su desempeño. Por ejemplo, los analistas pueden comprobar si los incidentes «Urgentes» se resuelven realmente más rápido que los de prioridad «Baja». También se utiliza para supervisar el cumplimiento de los SLA, que suelen definirse según los niveles de prioridad. El KPI «Tasa de cambios de prioridad» se basa en el seguimiento de los cambios en 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 según el nivel de urgencia. Dónde obtenerlo API de Tickets de Zendesk, campo priority. Los cambios se registran en la API Ticket Audits. Ejemplos bajanormalaltaurgente
	Calificación de satisfacción SatisfactionRating	Calificación de satisfacción que proporciona la persona usuaria final una vez resuelto el incidente.
Descripción Este atributo registra la retroalimentación del cliente sobre su experiencia de soporte. Normalmente se recopila mediante una encuesta después de resolver el ticket. En Zendesk, las calificaciones habituales son «Bueno» o «Malo». Aunque no mide directamente la eficiencia del proceso, la satisfacción es un indicador clave de resultados. En Process Mining, se puede relacionar 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 traspasos reciben calificaciones más bajas? Por qué es importante Proporciona un indicador clave de resultados que puede relacionarse con las características del proceso para comprender cómo influye su desempeño en 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
	Categoría de la causa raíz RootCauseCategory	Categoría general de la causa raíz del incidente.
Descripción Este atributo se utiliza para clasificar la causa fundamental de un incidente. Normalmente se registra hacia el final del ciclo de vida del incidente, a menudo como parte de un análisis posterior 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 en la identificación de la causa raíz» y el KPI «Cobertura del análisis de causa raíz». Analizar los incidentes según su causa raíz ayuda a detectar problemas recurrentes y orienta las medidas para aplicar soluciones permanentes y reducir futuros incidentes. Así, el enfoque pasa de reaccionar ante los problemas a prevenirlos de forma proactiva. Por qué es importante Facilita la gestión proactiva de problemas al clasificar las causas de los incidentes, detectar tendencias y prevenir casos futuros. Dónde obtenerlo Normalmente, se trata de un campo personalizado del ticket. Consulte la configuración de Ticket Fields en Zendesk Admin Center. Ejemplos Error de softwareFalla de hardwareError de usuarioInterrupción de la red
	Duración del caso CaseDuration	Tiempo total transcurrido desde la creación del incidente hasta su cierre definitivo.
Descripción Esta métrica calculada representa el tiempo de ciclo completo de un incidente. Se obtiene calculando la diferencia entre la marca de tiempo del primer evento (por ejemplo, «Incidente creado») y la del último (por ejemplo, «Incidente cerrado»). La duración del caso es un KPI clave para medir la eficiencia general del proceso. Se utiliza ampliamente en los Dashboards para mostrar los tiempos de ciclo promedio, identificar casos de larga duración y analizar tendencias a lo largo del tiempo. Ofrece una medida general de la rapidez con que el proceso permite gestionar y resolver incidentes. Por qué es importante Es un KPI clave para medir la velocidad general del proceso e identificar los factores que prolongan los tiempos de resolución. Dónde obtenerlo Se calcula restando la marca de tiempo del primer evento a la del último para cada ID de incidente. Ejemplos 25920060480086400
	Es automatizado IsAutomated	Indicador booleano que señala si una actividad la realizó un sistema automatizado o un agente humano.
Descripción Este atributo derivado permite distinguir los eventos ejecutados por personas usuarias de los realizados mediante automatizaciones del sistema, activadores o integraciones de API. Normalmente, se determina comprobando si el autor del evento es un usuario del sistema conocido. Comprender el nivel de automatización es fundamental para analizar los procesos actuales. Permite 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 también permite comparar los flujos de proceso de las actividades automatizadas y manuales. Por qué es importante Distingue las acciones humanas de 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 determina comprobando si el autor del evento (author_id en la API Ticket Audits) corresponde a un usuario conocido del sistema o de automatización. Ejemplos truefalse
	Etiquetas Tags	Lista de etiquetas aplicadas al incidente para clasificarlo y aportar contexto.
Descripción Las etiquetas son rótulos flexibles que se pueden añadir a los tickets para aportar contexto o facilitar su clasificación y enrutamiento. Los agentes pueden añadirlas manualmente o se pueden aplicar automáticamente mediante activadores y automatizaciones. Las etiquetas son una fuente de datos valiosa para el análisis de Process Mining. Permiten crear segmentos detallados, por ejemplo, para filtrar incidentes relacionados con el lanzamiento de un producto específico («launch_q4») o una interrupción conocida («outage_20231027»). Esta flexibilidad permite investigar en profundidad más allá de los campos estándar de los tickets. Por qué es importante Ofrece una forma flexible de clasificar y filtrar incidentes, lo que permite realizar análisis detallados y específicos según el contexto, incluso cuando los campos estándar no bastan. Dónde obtenerlo API de Tickets de Zendesk, campo tags. Ejemplos vip_usernetwork_issueoutage_20231027billing_related
	Gravedad Severity	Nivel de impacto del incidente en el negocio.
Descripción La gravedad define el impacto de un incidente en el negocio y, a menudo, se combina 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 de los SLA» y «Métricas de eficacia de la priorización». Comparar los flujos de proceso según el nivel de gravedad puede revelar si los incidentes más graves se atienden con la rapidez y los recursos adecuados. Por qué es importante Indica el impacto de un incidente en el negocio y permite centrarse en los problemas más críticos para garantizar que se resuelvan con eficacia. Dónde obtenerlo Normalmente, se trata de un campo personalizado. Consulte la configuración de Ticket Fields en Zendesk Admin Center. Ejemplos 1 - Crítico2 - Alto3 - Medio4 - Bajo
	Número de traspasos HandoffCount	Número total de veces que se reasignó un incidente a otro agente o grupo.
Descripción Esta métrica calculada cuantifica cuántas veces se transfirió la responsabilidad de un incidente. Cada cambio en el campo Assignee o AssignedGroup incrementa el recuento del caso. Los traspasos son una causa frecuente de ineficiencia y demoras en la gestión de incidentes. Un número elevado puede indicar reglas de enrutamiento poco claras, falta de conocimientos en los equipos de soporte o procesos demasiado complejos. Esta métrica sirve de base para el KPI «Promedio de traspasos por incidente» y es fundamental para el Dashboard «Análisis de traspasos y retrabajo». Por qué es importante Cuantifica las fricciones del proceso causadas por los traspasos y ayuda a detectar ineficiencias de enrutamiento y falta de conocimientos que prolongan los tiempos de resolución. Dónde obtenerlo Se calcula contando cuántas veces cambió el campo AssignedGroup o Assignee de un incidente. Ejemplos 0135
	Organización del cliente Organization	Organización o empresa a la que pertenece la persona que solicita ayuda por el 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. El análisis de los incidentes por organización permite a los equipos de soporte supervisar la situación de cada cliente, detectar problemas recurrentes que afectan a clientes específicos y comprobar que se cumplen las obligaciones contractuales. Es una dimensión clave para filtrar Dashboards e informes y obtener una perspectiva del desempeño centrada en cada cliente. Por qué es importante Permite analizar los datos de cada cliente para supervisar los niveles de servicio, detectar tendencias en cuentas clave y gestionar eficazmente las relaciones con los clientes. Dónde obtenerlo API de Tickets de Zendesk, campo organization_id. Ejemplos Global Tech Inc.Innovate SolutionsData Corp
	Persona que envía el ticket Submitter	Persona usuaria final o sistema que notificó el incidente originalmente.
Descripción Este atributo identifica a la persona o entidad que creó el ticket. No es lo mismo que la persona solicitante, ya que un agente puede crear un ticket en nombre de otra persona. El análisis de quién envía el ticket permite comprender quién notifica los problemas. Al combinar este dato con la información de la organización, se puede identificar si determinados clientes o grupos de usuarios registran un volumen elevado de incidentes. Esto puede orientar iniciativas de soporte proactivo o formación. Por qué es importante Identifica el origen de la notificación del incidente y permite analizar patrones relacionados con usuarios, departamentos o sistemas automatizados específicos. Dónde obtenerlo API de Tickets de Zendesk, 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 agente o grupo asignado inicialmente resolvió el incidente sin traspasos.
Descripción La resolución en el primer contacto (FCR) es una métrica clave para medir la eficiencia del centro 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 suele comprobar si el ticket alcanzó el estado «Resuelto» mientras seguía asignado al agente y al grupo iniciales. En Process Mining, esto permite calcular directamente la tasa de FCR y comparar las rutas de los incidentes resueltos en el primer contacto con las de aquellos que requirieron una escalación. Así se pueden identificar oportunidades para dar más autonomía al equipo de soporte de primera línea. Por qué es importante Mide directamente la eficiencia del primer punto de contacto con soporte y ayuda a identificar oportunidades para resolver los incidentes antes en el proceso. Dónde obtenerlo Indicador booleano calculado. Es verdadero si el estado del ticket es «solved» o «closed» y solo hubo un agente o grupo asignado durante todo el ciclo de vida del incidente. Ejemplos truefalse
	Tipo de ticket TicketType	Clasificación del ticket, como «Incidente», «Problema», «Pregunta» o «Tarea».
Descripción Este campo clasifica el ticket según la naturaleza de la solicitud. El proceso de gestión de incidentes se centra específicamente en los tickets de tipo «Incidente», que representan una interrupción imprevista o una reducción de la calidad de un servicio de TI. En el análisis, este atributo se utiliza principalmente como filtro para incluir solo los incidentes en la vista del proceso. También puede servir para realizar análisis más amplios de ITSM y comparar los procesos de gestión de incidentes, problemas y 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 pertinente para el ciclo de vida de su gestión. Dónde obtenerlo API de Tickets de Zendesk, campo type. Ejemplos incidenteproblemapreguntatarea

Obligatorio Recomendado Opcional

Actividades de gestión de incidencias

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

6 Recomendado 7 Opcional

	Actividad	Descripción
	Estado cambiado a abierto	Indica que un agente ha empezado a trabajar activamente en el incidente. Esta actividad suele inferirse cuando el campo 'status' del ticket cambia de 'new' a 'open', lo que señala el inicio de la investigación y el diagnóstico.
Por qué es importante Este evento marca el paso de la espera en cola al trabajo activo. El tiempo que los tickets permanecen en estado 'new' antes de pasar a 'open' es una métrica clave del tiempo de primera respuesta. Dónde obtenerlo Se infiere del registro de auditoría del ticket al identificar un evento 'Change' en el que el nuevo valor del campo 'status' es 'open' y el anterior era 'new'. Capturar Se infiere de un cambio en el 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 período establecido desde que se resuelve el ticket y queda registrado como un cambio de estado final.
Por qué es importante Esta es la actividad que marca el final definitivo del proceso. La duración total se calcula desde 'Incidente creado' hasta este evento y ofrece una visión integral del tiempo de ciclo. Dónde obtenerlo Se obtiene del registro de auditoría del ticket mediante un evento 'Change' en el que el nuevo valor del campo 'status' pasa a ser 'closed'. Capturar Se identifica mediante un evento 'Change' que cambia el campo 'status' a 'closed'. Tipo de evento explicit
	Incidente creado	Marca el inicio del ciclo de vida del incidente, cuando se crea un ticket en Zendesk. Este evento queda registrado explícitamente en el registro de auditoría de creación de tickets de Zendesk y sirve como punto de partida de 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 primera respuesta. Dónde obtenerlo Este evento explícito queda registrado en los registros de auditoría de tickets de Zendesk. Cada ticket nuevo genera un evento 'Create' con su correspondiente marca de tiempo. Capturar 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 aplica una solución y marca el ticket como 'solved'. Es una acción explícita que queda registrada 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 clave para medir el tiempo de resolución. El tiempo entre este evento y 'Incidente cerrado' corresponde al período de confirmación del usuario o de cierre automático. Dónde obtenerlo Se obtiene del registro de auditoría del ticket mediante un evento 'Change' en el que el nuevo valor del campo 'status' pasa a ser 'solved'. Capturar Se identifica mediante un evento 'Change' que cambia el 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 que lo gestione. Queda registrada explícitamente en el historial de auditoría del ticket e indica que una persona se ha hecho cargo del caso.
Por qué es importante Este hito es esencial para medir el tiempo hasta la primera asignación y sirve de base para analizar las transferencias, el retrabajo y el índice de resolución en el primer contacto. Dónde obtenerlo Se obtiene del registro de auditoría del ticket cuando se completa o cambia el campo 'assignee_id'. La primera asignación es un hito clave para calcular los KPI. Capturar 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, después de la asignación inicial, la responsabilidad del ticket se transfiere de un agente o grupo a otro. Este evento explícito queda registrado en el historial de auditoría del ticket.
Por qué es importante Las reasignaciones son importantes para analizar las transferencias y el retrabajo. Si son frecuentes, suelen indicar una asignación inicial incorrecta, problemas complejos o cuellos de botella en el proceso. Dónde obtenerlo Se obtiene del registro de auditoría del ticket al identificar un evento 'Change' en el campo 'assignee_id' o 'group_id' después de que se haya completado por primera vez. Capturar 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 se espera una respuesta de quien solicitó el servicio. 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. Si el ticket permanece mucho tiempo en este estado, el tiempo total de resolución puede aumentar considerablemente y revelar demoras en la comunicación. Dónde obtenerlo Se infiere del registro de auditoría del ticket al identificar un evento 'Change' en el que el nuevo valor del campo 'status' es 'pending'. Capturar 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: un agente añade una nota privada al ticket para otros miembros del equipo. Se registra explícitamente cuando un comentario se marca como no público.
Por qué es importante El análisis de las notas internas puede aportar información sobre problemas complejos que requieren colaboración. Sin embargo, un número excesivo puede indicar falta de conocimientos o ineficiencias en el proceso. Dónde obtenerlo Se obtiene de los datos de comentarios del ticket. Un comentario se considera una nota interna cuando su atributo 'public' tiene el valor false. Capturar Se registra un evento cuando se añade al ticket un comentario nuevo con 'public: false'. Tipo de evento explicit
	Objetivo del SLA incumplido	Marca el momento en que un ticket incumple un acuerdo de nivel de servicio definido, como el tiempo de primera respuesta o el tiempo de resolución. Este evento se calcula a partir de las definiciones de las políticas de SLA y las marcas de tiempo de actualización del ticket.
Por qué es importante Este evento permite supervisar directamente el 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 Este evento se calcula. Puede derivarse del análisis de los datos 'sla_policy_metrics' asociados al ticket, utilizando la marca de tiempo 'breached_at' de cada objetivo del SLA. Capturar 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 del incidente, por ejemplo, bajo, normal, alto o urgente. Este cambio queda registrado explícitamente y determina la urgencia y el tiempo de respuesta requerido para el ticket.
Por qué es importante Registrar cuándo y cómo se establece la prioridad es fundamental para el Dashboard de métricas de eficacia de la priorización y ayuda a atender rápidamente los problemas críticos. Dónde obtenerlo Se obtiene de un evento 'Change' del campo 'priority' en el registro de auditoría del ticket. También se pueden seguir los cambios posteriores para medir el KPI de tasa de cambio de prioridad. Capturar 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 que un agente de soporte envía al usuario final. Es un evento explícito de Zendesk que se registra cada vez que se añade un comentario público al ticket.
Por qué es importante El seguimiento de las respuestas públicas permite entender la frecuencia de las comunicaciones y puede ser clave para analizar las demoras en la confirmación del usuario. Dónde obtenerlo Se obtiene de los datos de comentarios del ticket. Un comentario se considera público cuando su atributo 'public' tiene el valor true. Capturar Se registra un evento cuando se añade al ticket un comentario nuevo con 'public: true'. Tipo de evento explicit
	Satisfacción del usuario calificada	Representa el momento en que el usuario final califica la asistencia recibida. Es un evento explícito que Zendesk registra después de resolver un ticket.
Por qué es importante El análisis de las calificaciones de satisfacción aporta retroalimentación clave sobre el rendimiento de los agentes y la eficacia del proceso, y relaciona las métricas del proceso con los resultados para los clientes. Dónde obtenerlo Se obtiene de los datos de calificaciones de satisfacción asociados al ticket. Por lo general, incluyen una puntuación ('good' o 'bad') y un comentario opcional. Capturar Se registra un evento cuando se envía una calificación de satisfacción para el ticket. Tipo de evento explicit
	Ticket asignado a un grupo	Representa la asignación o clasificación inicial del incidente a un grupo de soporte específico. Suele ser el primer paso para asignar la responsabilidad y queda registrado como un evento de cambio explícito en el historial de auditoría del ticket.
Por qué es importante El seguimiento de las asignaciones a grupos ayuda a analizar la eficiencia de la clasificación inicial y a detectar demoras antes de que el ticket llegue al equipo adecuado. Dónde obtenerlo Se obtiene del registro de auditoría del ticket cada vez que se establece o cambia el campo 'group_id'. El primer cambio después de la creación corresponde a la asignación inicial. Capturar 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: Vaya 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 historial de auditoría de cada cambio en los tickets, necesario 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, que formarán las columnas del 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» a continuación: ActivityName, SourceSystem y LastDataUpdate. Copie 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». Después, puede quitar los campos sin procesar usados 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 para 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 aparezcan como espera. 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» de la esquina superior derecha y seleccione «CSV». Zendesk generará y descargará el archivo CSV.
Prepare el archivo para cargarlo: Abra el archivo CSV exportado. Cambie los encabezados de las columnas 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 las marcas de tiempo tengan el formato ISO 8601. El archivo ya está 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 estándar que ofrece el historial 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. Use el atributo Update - Date como filtro principal. Para un análisis inicial, se suele recomendar 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 en las que este valor sea nulo. Así se eliminan cambios irrelevantes en los tickets, como actualizaciones del sistema o cambios de etiquetas, del Registro de eventos.
Atributos calculados: Esta extracción depende en gran medida de un atributo calculado estándar que convierte los cambios sin procesar de los campos del ticket en nombres de actividad fáciles de entender. La fórmula debe ser precisa.
Requisitos previos: La persona que ejecute el informe necesita, como mínimo, el rol «Viewer» en Zendesk Explore. Para crear y guardar el informe, se requieren permisos de «Editor» o «Admin».

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 con 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 generada.
Configure el script de Python: Cree un archivo de Python, por ejemplo, extract_zendesk_logs.py, y copie en él el script proporcionado. Actualice las variables de marcador de posición al principio del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y ZENDESK_API_TOKEN con sus credenciales. Defina START_TIMESTAMP para indicar el inicio del periodo de extracción deseado, mediante una marca de tiempo Unix.
Conozca los endpoints de la API: El script utiliza principalmente dos endpoints de la API de Zendesk. El endpoint incremental/tickets/cursor.json permite obtener de forma eficiente todos los tickets actualizados desde START_TIMESTAMP. Para cada ticket, el script llama después al endpoint tickets/{ticket_id}/audits.json para obtener un historial detallado de cada cambio y evento.
Ejecute el script: Ejecútelo desde la terminal con el comando: python extract_zendesk_logs.py. El script empezará a obtener datos de la API de Zendesk.
Supervise el progreso del script: El script mostrará en la consola el número de tickets procesados para que pueda seguir 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 el valor after_url de 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 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. 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 las políticas de SLA.
Genere el Registro de eventos: Una vez procesados todos los tickets, el script reúne 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 el archivo para cargarlo: Revise que el archivo CSV generado sea correcto. Ya tiene el formato necesario para cargarlo directamente en ProcessMind y analizarlo.

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 con control de versiones para uso en producción.
Marca de tiempo inicial (START_TIMESTAMP): Este valor entero determina el inicio de la extracción de datos y debe ser una marca de tiempo Unix. Se recomienda comenzar entre 3 y 6 meses atrás para obtener una cantidad de datos significativa sin sobrecargar el sistema. Puede usar un conversor en línea para obtener la marca de tiempo correcta de una fecha concreta.
Límites de solicitudes de la API: El script realiza numerosas llamadas a la API. Zendesk aplica límites que varían según el plan. Aunque el script funciona con volúmenes moderados, en instancias muy grandes quizá deba añadir llamadas a time.sleep() dentro de los bucles para no superar el límite y recibir un error 429.
Bibliotecas de Python necesarias: El script depende de 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 asociada al token de API debe tener permisos suficientes para leer los datos de los tickets, incluidos los registros de auditoría y las métricas de los tickets.

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, registros de auditoría de tickets, usuarios, grupos, calificaciones de satisfacción y exportaciones incrementales. Use un token de API o credenciales OAuth configuradas para su instancia de Zendesk Support. Guarde el subdominio, las credenciales y la marca de agua de extracción como valores de configuración seguros.
Use la API de exportación incremental de tickets de Zendesk para recuperar los tickets actualizados después de la última marca de agua procesada correctamente. El script siguiente usa el patrón de endpoint documentado, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, y recorre la paginación por cursor hasta que la API indica que se ha completado el conjunto de resultados.
Para cada ticket obtenido, solicite su historial de auditoría mediante el endpoint de auditoría de tickets. Los registros de auditoría son necesarios porque ProcessMind lee el Registro de eventos tal como está y no deduce 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 a un grupo, la asignación a un agente, los cambios de prioridad, los cambios de estado a abierto, las respuestas públicas, las notas internas, las reasignaciones, los cambios de estado a pendiente, el estado resuelto y el estado cerrado. Si hay calificaciones de satisfacción, extráigalas como filas independientes. Calcule los incumplimientos de SLA solo cuando estén disponibles el objetivo de SLA y las marcas de tiempo de los eventos necesarios, y documente los datos usados en el cálculo.
Mantenga la marca de tiempo o el cursor de la última actualización procesada correctamente. No avance la marca de agua hasta que se hayan escrito correctamente todas las páginas, los registros de auditoría de los tickets y los registros de satisfacción opcionales. En la primera ejecución, use una fecha de inicio acotada, como [Start date in ISO 8601 format], que normalmente abarque 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 lo permitan. Use valores vacíos solo cuando Zendesk no proporcione el atributo para el evento.
Elimine duplicados mediante TicketId, ActivityName, EventTimestamp y un identificador de evento de origen estable, si está disponible. Conserve las repeticiones legítimas 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 sigan el formato ISO 8601 con un desfase UTC explícito, que TicketId tenga un tipo de dato uniforme, que los valores de ActivityName coincidan exactamente con los nombres de actividad 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 hora del evento. Compruebe 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 por cursor. Use el endpoint de auditoría de tickets para extraer eventos y el endpoint de satisfacción cuando las calificaciones estén habilitadas y sean accesibles.
Configuración necesaria: subdominio de Zendesk, autenticación de API, fecha de inicio inicial, marca de agua 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 implementación.
Intervalo de fechas: Para la carga inicial, use entre tres y seis meses, salvo que se necesite un historial más amplio. En las cargas recurrentes, solicite los registros posteriores a la última marca de agua procesada correctamente e incluya un pequeño intervalo de solapamiento para cubrir las actualizaciones tardías; después, elimine los duplicados.
Filtros: Aplique filtros por empresa, marca, grupo, organización, formulario de ticket, canal o campos personalizados solo cuando el alcance del proceso lo requiera expresamente. Zendesk Support no usa filtros de Company Code o Document Type al estilo de SAP, salvo que esos conceptos estén representados por campos configurados en Zendesk.
Semántica de los eventos: Considere los eventos de auditoría como fuente autorizada de los cambios explícitos. No cree un evento de cambio de estado solo porque el ticket tenga un estado actual. El evento de estado debe proceder de un evento de auditoría o de otro evento de origen documentado.
Configuración de SLA: Para determinar SLA Target Breached, se necesita 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 ofrece un evento o una métrica de incumplimiento, use esa fuente. De lo contrario, calcúlelo solo con datos documentados de la política y conserve la base del cálculo.
Configuración de satisfacción: User Satisfaction Rated requiere que las calificaciones de satisfacción estén habilitadas y que se pueda acceder al registro de calificación mediante la API. No genere un evento de calificación ficticio para un ticket resuelto sin calificación.
Rendimiento: Use paginación por cursor, concurrencia limitada para las solicitudes de auditoría de tickets, reutilización de conexiones, espera exponencial para los límites de solicitudes y puntos de control después de cada lote procesado correctamente. Evite volver a solicitar 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. Use un intervalo de solapamiento y claves de deduplicación 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 se necesitan y acceso a los datos de SLA si se requiere calcular incumplimientos. La disponibilidad de determinados tipos de eventos de auditoría puede variar según la configuración y la suscripción de Zendesk.

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 de tickets y la extracción de comentarios, 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 con Zendesk en la herramienta seleccionada. Introduzca el subdominio de Zendesk, el método de autenticación, las credenciales o el token y los ajustes de conexión necesarios mediante la interfaz de configuración de la herramienta. Conceda acceso a tickets, auditorías de tickets, comentarios, usuarios, grupos, calificaciones 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. Para la carga inicial, use un periodo móvil de 3 a 6 meses y, después, configure cargas incrementales según la marca de tiempo de actualización o de auditoría que admita el conector. Guarde la marca de agua de la última extracción correcta fuera del Registro de eventos para evitar duplicar u omitir eventos en ejecuciones posteriores.
Extraiga los datos de los tickets necesarios para el contexto del caso, incluidos el identificador del ticket, el estado actual o el estado de cada evento, la persona asignada, el grupo, la prioridad, el canal de notificación, el estado del SLA y las marcas de tiempo de actualización pertinentes. Extraiga los registros de auditoría de los tickets, ya que las asignaciones y los cambios de prioridad, estado y otros 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 o de carácter público del conector. Extraiga las marcas de tiempo de los comentarios, los identificadores de los tickets y de los autores, así como las horas de finalización disponibles. Cree filas Public Reply Sent para los comentarios públicos y filas Internal Note Added para las notas privadas.
Extraiga los registros de calificaciones de satisfacción y de incumplimientos de SLA cuando el conector los ofrezca. Si el conector no expone directamente los eventos de incumplimiento de SLA, configure la herramienta ETL para calcularlos a partir del objetivo y la política de SLA, las horas laborables y las marcas de tiempo de los eventos del ticket disponibles. No cree una fila de incumplimiento salvo que los datos de origen o el cálculo configurado confirmen que se incumplió el objetivo.
Reestructure los registros de origen extraídos para crear un Registro de eventos normalizado. Cree una fila por cada actividad explícita. Asigne la creación del ticket a Incident Created; los cambios de grupo a Ticket Assigned to Group o Ticket Reassigned; los cambios de agente asignado 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. Use 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. Genere 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 con el contexto del evento o el registro de origen válido más cercano. Mantenga las marcas de tiempo de origen en una zona horaria uniforme, preferiblemente UTC, y conserve la precisión original que admita el conector.
Valide los datos transformados 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 estén representados los 13 nombres de actividad obligatorios cuando haya 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 o en el archivo de destino, en un formato tabular compatible con ProcessMind, como CSV o el formato del conector de almacén admitido. Use una fila de encabezado, nombres de columna estables, codificación UTF-8, marcas de tiempo ISO 8601 y ninguna estructura JSON anidada 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: Use 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, calificaciones de satisfacción e información de SLA, según lo que admitan 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 solo los permisos necesarios para extraer tickets, auditorías, comentarios, usuarios, grupos, datos de satisfacción y datos de SLA. Confirme que la cuenta de integración pueda leer registros históricos.
Intervalo de fechas: Empiece con entre 3 y 6 meses para la validación y la carga inicial. Amplíe el intervalo solo después de verificar el número de filas, la paginación y el comportamiento de los límites de solicitudes. Use una marca de agua incremental para las ejecuciones programadas.
Filtros necesarios: Aplique solo filtros específicos de la empresa que estén confirmados en la configuración de origen, como un subdominio de Zendesk, una marca, organización, grupo o 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 duplicados en las cargas incrementales.
Comentarios: Extraiga tanto los comentarios públicos como los privados. Use el indicador de visibilidad de origen para clasificar Public Reply Sent e Internal Note Added. No deduzca la visibilidad a partir del texto del comentario.
Clasificación de asignaciones: Compare los valores anteriores y nuevos del grupo o de la persona asignada. Clasifique por separado la primera asignación que cumpla los criterios y genere Ticket Reassigned para los cambios posteriores de responsable.
Clasificación de estados: Genere filas solo para las transiciones de estado explícitas. Asigne los valores new, open, pending, solved y closed según el modelo de estados de Zendesk configurado. Si se usan estados personalizados, documente la asignación antes de cargar los datos.
Gestión de SLA: Priorice los eventos de incumplimiento de SLA de origen. Si no están disponibles, configure un cálculo documentado con el objetivo y la política de SLA, las 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 o a otra zona horaria documentada. Conserve la marca de tiempo de origen y no la sustituya por la hora de extracción.
LastDataUpdate: Asigne a LastDataUpdate la marca de tiempo de la actualización ETL completada correctamente y use el mismo valor en todas las filas de esa carga.
Rendimiento: Use paginación, extracción incremental, particiones por hora de actualización del ticket o de auditoría, paralelismo controlado, reintentos y espera tras alcanzar los límites de solicitudes. Evite volver a extraer 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 deducir cambios de estado, asignaciones, respuestas, notas, incumplimientos de SLA ni hitos del ciclo de vida. Cada actividad debe existir ya como fila de evento antes de cargar los datos.

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;

¿Todo listo para empezar?

Use este Template para agilizar la preparación de los datos y obtener información útil sobre el rendimiento de la gestión de incidencias. Empiece hoy mismo a optimizar el proceso.

Volver a la guía de mejora

Descargar Template

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

Reduzca el MTTR un 35 %, elimine las incidencias recurrentes y mejore la satisfacción.

Comience la prueba gratuita

No se requiere tarjeta de crédito. Empiece a mejorar en cuestión de minutos.

Su Template de datos para la gestión de incidencias

Su Template de datos para la gestión de incidencias

Atributos de gestión de incidencias

Actividades de gestión de incidencias

Guías de extracción

Exportar informes de Zendesk Explore a archivos CSV desde la interfaz

Pasos

Configuración

Consulta de ejemplo config

Script de Python con la API REST de Zendesk Support

Pasos

Configuración

Consulta de ejemplo python

API de exportación incremental de Zendesk para sincronizar datos en bloque

Pasos

Configuración

Consulta de ejemplo python

Herramienta ETL de terceros con conector de API de Zendesk

Pasos

Configuración

Consulta de ejemplo config

¿Todo listo para empezar?

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