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

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

Zendesk Support

Atributos de gestión de solicitudes de servicio(21) Actividades de gestión de solicitudes de servicio(13) Guías de extracción(3)

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

Este Template ofrece una guía completa para extraer los datos necesarios para analizar el proceso de gestión de solicitudes de servicio en Zendesk Support. Describe los atributos de datos esenciales que debe recopilar, las actividades clave que debe registrar y cómo extraer esta información directamente de su sistema. Utilice este recurso para crear un registro de eventos sólido para sus iniciativas de Process Mining.

Atributos recomendados para un análisis completo
Actividades clave de las solicitudes de servicio que debe registrar
Guía para extraer datos de Zendesk Support

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

Descargar Template

Atributos de gestión de solicitudes de servicio

Estos son los campos de datos recomendados para incluir en el registro de eventos y analizar de forma completa la gestión de solicitudes de servicio en Zendesk Support.

5 Obligatorio 7 Recomendado 9 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre de la actividad empresarial o del evento que tuvo lugar en una solicitud de servicio.
Descripción La actividad representa un paso o evento concreto del ciclo de vida de una solicitud de servicio, como 'Solicitud de servicio creada', 'Solicitud asignada a un agente' o 'Solicitud de servicio resuelta'. Estas actividades se derivan de los cambios registrados en el registro de auditoría del ticket de Zendesk, que recoge modificaciones en campos como el estado, el responsable y la prioridad, así como la incorporación de comentarios. El análisis de actividades es la base de Process Mining. Permite visualizar el mapa del proceso, identificar cuellos de botella entre pasos y analizar ciclos de retrabajo. Al comprender la secuencia y la frecuencia de las actividades, las organizaciones pueden detectar ineficiencias y oportunidades de mejora. Por qué es importante Este atributo define los pasos del proceso y permite visualizar los mapas de procesos y analizar el flujo, las variaciones y la conformidad. Dónde obtenerlo Se deriva conceptualmente de los eventos registrados en la API de auditoría de tickets de Zendesk. Por ejemplo, un cambio en el campo 'status' de 'new' a 'open' puede corresponder a una actividad como 'Solicitud clasificada'. Ejemplos Solicitud de servicio creadaAgente reasignadoSolicitud de servicio resuelta
	Hora de inicio EventTimestamp	Fecha y hora exactas en que tuvo lugar la actividad.
Descripción La marca de tiempo del evento, o la hora de inicio, registra el momento exacto en que tuvo lugar una actividad. Por ejemplo, indica cuándo se asignó un agente, cuándo se envió una respuesta pública o cuándo cambió el estado del ticket a 'Resolved'. Estos datos temporales proceden del registro de auditoría de cada ticket de Zendesk. Este atributo es esencial para cualquier análisis basado en el tiempo. Se utiliza para ordenar cronológicamente los eventos, calcular la duración entre actividades, medir los tiempos de espera y analizar el tiempo de ciclo total del caso. También es fundamental para identificar cuellos de botella y evaluar el rendimiento frente a objetivos temporales, como los SLA. Por qué es importante Esta marca de tiempo ordena cronológicamente los eventos y es esencial para analizar duraciones, rendimiento y cuellos de botella. Dónde obtenerlo API de auditoría de tickets de Zendesk, campo 'created_at' de cada evento de auditoría. Ejemplos 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	ID de solicitud de servicio ServiceRequestId	Identificador único de cada ticket de solicitud de servicio en Zendesk.
Descripción El ID de solicitud de servicio, a menudo denominado ID del ticket en Zendesk, es la clave principal de cada caso. Vincula todas las actividades, los comentarios y los cambios de estado relacionados, desde la creación de la solicitud hasta su cierre. Así se puede seguir de principio a fin el ciclo de vida de una solicitud. En el análisis de Process Mining, este atributo es fundamental. Define el caso y permite reconstruir los flujos del proceso, identificar variantes y calcular métricas por caso, como el tiempo de ciclo. Cada evento del conjunto de datos debe asociarse a un ID de solicitud de servicio para entender su contexto dentro del proceso general. Por qué es importante Este es el identificador esencial del caso que conecta todos los eventos del recorrido de una solicitud de servicio y permite analizar el proceso de principio a fin. Dónde obtenerlo API de tickets de Zendesk, campo 'id'. Ejemplos 102451024610247
	Sistema de origen SourceSystem	Indica el sistema del que se extrajeron los datos.
Descripción Este atributo especifica el origen de los datos de la solicitud de servicio. En esta vista del proceso, el valor siempre será 'Zendesk Support', que identifica el sistema de registro de todas las actividades de gestión de servicios. En entornos con varios sistemas integrados, este campo es fundamental para rastrear el origen de los datos y resolver problemas. Permite delimitar correctamente los análisis al sistema previsto y ayuda a distinguir los datos cuando se combinan fuentes distintas. Por qué es importante Identifica el sistema de origen de los datos, permite rastrear su procedencia y evita confusiones al combinar datos de varios sistemas. Dónde obtenerlo Es un valor estático ('Zendesk Support') que se añade durante la extracción y transformación de los datos. Ejemplos Zendesk Support
	Última actualización de datos LastDataUpdate	Marca de tiempo que indica cuándo se actualizaron por última vez los datos del sistema de origen.
Descripción Este atributo registra la fecha y hora de la extracción más reciente de datos de Zendesk Support. Indica la antigüedad de los datos analizados y permite saber cuán actualizada está la vista del proceso. Esta información es esencial para la supervisión continua y la creación de Dashboards. Permite a analistas y usuarios de negocio saber si consultan datos casi en tiempo real o una instantánea de un periodo anterior, algo que influye en la validez de sus conclusiones. Por qué es importante Ofrece un contexto esencial sobre la actualidad de los datos y permite saber cuán actualizados están los análisis. Dónde obtenerlo Es un campo de metadatos que se genera y se añade al conjunto de datos durante la extracción. Ejemplos 2023-10-27T08:00:00Z
	Canal de la solicitud RequestChannel	Canal por el que se envió la solicitud de servicio (por ejemplo, correo electrónico, formulario web o teléfono).
Descripción Este atributo identifica el canal por el que se envió la solicitud de servicio. Zendesk registra cómo se creó un ticket, ya sea por correo electrónico, un portal web, una integración de API, chat u otro canal. Esto aporta contexto sobre el medio de interacción del cliente. El canal de la solicitud es una dimensión útil para el análisis. Permite comparar los tiempos de resolución, las valoraciones de satisfacción y las tasas de retrabajo de distintos canales en el Dashboard 'Eficiencia del canal de solicitudes'. Así, las empresas pueden optimizar sus canales de soporte y orientar a los usuarios hacia los más eficientes. Por qué es importante Ayuda a analizar la eficiencia y los resultados de los distintos canales de soporte al cliente y permite orientar las mejoras. Dónde obtenerlo API de tickets de Zendesk, objeto 'via' y su propiedad 'channel'. Ejemplos webcorreo electrónicoapichat
	Equipo asignado AssignedTeam	Equipo o grupo de soporte asignado a la solicitud de servicio.
Descripción Este atributo indica qué equipo o grupo de la organización de soporte es responsable de la solicitud de servicio. En Zendesk, estos equipos se denominan 'Groups'. A menudo, los tickets se asignan primero a un grupo y luego a un agente. Analizar los datos por equipo asignado es esencial para comprender el rendimiento y la carga de trabajo de cada equipo. Permite saber qué equipos gestionan cada tipo de solicitud, cuáles son sus tiempos medios de resolución y sus tasas de cumplimiento del SLA. Es una dimensión clave del Dashboard de rendimiento de agentes y equipos. Por qué es importante Permite analizar el rendimiento de los equipos, equilibrar la carga de trabajo y evaluar la eficiencia del enrutamiento entre distintos grupos de soporte. Dónde obtenerlo API de grupos de Zendesk, mediante la unión con 'group_id' de la respuesta de la API de tickets. Ejemplos Soporte de nivel 1Soporte técnicoFacturación
	Estado de la solicitud RequestStatus	Estado de la solicitud de servicio en el momento del evento (por ejemplo, nueva, abierta o pendiente).
Descripción El estado de la solicitud representa la situación del ticket en un momento determinado. Zendesk tiene varios estados estándar, como New, Open, Pending, On-hold, Solved y Closed, que indican el avance de la solicitud durante su ciclo de vida. Los cambios en este campo son los principales desencadenantes de la creación de actividades en el registro de eventos. Analizar el tiempo que los tickets pasan en cada estado es una parte esencial del análisis de cuellos de botella. Ayuda a identificar dónde se atascan, por ejemplo, si pasan demasiado tiempo en estado 'Pending' o 'On-hold'. Comprender las transiciones entre estados también es clave para detectar ciclos de retrabajo. Por qué es importante Registrar el estado es fundamental para comprender el avance de la solicitud e identificar cuánto tiempo permanece en espera o en curso. Dónde obtenerlo API de tickets de Zendesk, campo 'status'. Ejemplos NuevoAbiertoPendienteResueltoCerrado
	Etiquetas del ticket TicketTags	Lista de etiquetas aplicadas a la solicitud de servicio para clasificarla y dirigirla.
Descripción Los agentes pueden añadir etiquetas a los tickets manualmente o mediante reglas de negocio. Sirven para añadir contexto o categorías específicas que quizá no cubran campos estándar como el tipo o la prioridad. Las etiquetas son un atributo muy versátil para analizar procesos. Permiten filtrar situaciones concretas, hacer seguimiento de flujos de trabajo personalizados o identificar causas raíz. Por ejemplo, una etiqueta 'VIP' permite analizar el proceso de clientes clave, mientras que 'product_bug' permite seguir el ciclo de vida de los informes de defectos. Por qué es importante Ofrece una forma flexible de segmentar los datos y analizar en profundidad subprocesos concretos o atributos del ticket que no se registran en otros campos. Dónde obtenerlo API de tickets de Zendesk, campo 'tags'. Es una matriz de cadenas. Ejemplos consulta_ventasproblema_facturaciónsolicitud_funcionalidadcliente_vip
	Nombre del agente AgentName	Nombre del agente asignado a la solicitud de servicio en el momento del evento.
Descripción Este atributo identifica al agente de soporte responsable de gestionar la solicitud de servicio. El agente asignado puede cambiar varias veces durante el ciclo de vida del ticket, y este campo registra quién era responsable en cada paso. El nombre del agente es fundamental para analizar el rendimiento. Permite filtrar y segmentar los datos para evaluar la distribución de la carga de trabajo, los tiempos de resolución por agente y la frecuencia de las reasignaciones. Esto ayuda a crear el Dashboard de rendimiento de agentes y equipos y a comprender la contribución de cada persona a la eficiencia general del proceso. Por qué es importante Este atributo es esencial para analizar el rendimiento de los agentes, la distribución de la carga de trabajo y el efecto de las reasignaciones en los tiempos de resolución. Dónde obtenerlo API de usuarios de Zendesk, mediante la unión con 'assignee_id' de la respuesta de la API de tickets. Ejemplos Jane DoeJohn SmithEmily Jones
	Prioridad de la solicitud RequestPriority	Nivel de prioridad asignado a la solicitud de servicio, como baja, normal, alta o urgente.
Descripción La prioridad de la solicitud es una clasificación que indica su urgencia. Este nivel suele determinar los tiempos de resolución previstos y las políticas de SLA aplicadas al ticket. El sistema o un usuario pueden establecer la prioridad inicialmente, y un agente puede cambiarla durante el ciclo de vida del ticket. Este atributo es fundamental para segmentar y analizar las causas raíz. Permite comprobar si los tickets de prioridad alta se resuelven más rápido que los de prioridad baja y es un factor clave en los Dashboards 'Tendencias de escalación de solicitudes de servicio' y 'Cumplimiento del SLA'. Por qué es importante Permite segmentar las solicitudes por urgencia, algo fundamental para analizar el cumplimiento del SLA y garantizar que los problemas críticos se atiendan a tiempo. Dónde obtenerlo API de tickets de Zendesk, campo 'priority'. Ejemplos BajaNormalAltaUrgente
	Tipo de servicio ServiceType	Categoría o tipo de solicitud de servicio (por ejemplo, incidente, consulta, problema o tarea).
Descripción El tipo de servicio clasifica la naturaleza de la solicitud. Zendesk utiliza un campo 'type' para distinguir los distintos tipos de interacciones de soporte. Esta clasificación inicial ayuda a dirigir el ticket al equipo adecuado y a aplicar los procesos correspondientes. Este atributo es esencial para filtrar y comparar. Permite analizar los flujos del proceso de distintos tipos de solicitudes, que suelen seguir rutas de resolución y SLA muy diferentes. Es una dimensión clave del Dashboard de rendimiento de agentes y equipos para identificar quién gestiona mejor cada tipo de solicitud. Por qué es importante Clasifica las solicitudes para analizar por separado procesos distintos, como los incidentes y las consultas, que siguen rutas diferentes. Dónde obtenerlo API de tickets de Zendesk, campo 'type'. Ejemplos consultaincidenteproblematarea
	¿Es una repetición del trabajo? IsRework	Indicador que señala si la solicitud de servicio se reabrió después de haberse resuelto.
Descripción Este indicador booleano identifica los casos en los que hubo que repetir el trabajo. Por lo general, se considera que una solicitud de servicio requiere repetir el trabajo cuando su estado cambia de «Resuelto» a un estado abierto. Esto indica que la resolución inicial no fue suficiente y que el cliente tuvo que volver a contactar por el mismo problema. Este atributo es esencial para calcular el KPI «Tasa de repetición del trabajo en solicitudes de servicio» y para el Dashboard «Análisis de la repetición del trabajo y las reaperturas». Al identificar estos casos, los analistas pueden aislar los flujos de proceso ineficientes, descubrir las causas de las reaperturas y trabajar para mejorar la resolución en el primer contacto. Por qué es importante Identifica fallos del proceso en los que la resolución no fue definitiva y pone de manifiesto problemas de calidad y eficiencia que afectan directamente a la satisfacción del cliente. Dónde obtenerlo Se calcula analizando la secuencia de estados de un ticket en Zendesk Ticket Audits API. El cambio de «resuelto» a «abierto» indica que hubo que repetir el trabajo. Ejemplos truefalse
	¿Se incumplió el SLA? IsSlaBreached	Indicador que señala si la solicitud de servicio incumplió alguno de sus objetivos de SLA.
Descripción Este atributo es un indicador booleano o categórico que muestra el resultado del SLA de un ticket. Puede reflejar estados como «Cumplido», «Incumplido» o «Activo». Se determina comparando los tiempos reales de respuesta o resolución con los objetivos establecidos en la política de SLA aplicada. Es un atributo fundamental para el Dashboard «Análisis del cumplimiento y las infracciones de SLA». Permite contar y visualizar fácilmente los tickets que cumplen los objetivos y los que no. A continuación, el análisis puede centrarse en las características del proceso de los tickets que incumplieron el SLA para identificar las causas principales, como tiempos de espera prolongados o demasiadas reasignaciones. Por qué es importante Mide directamente el rendimiento frente a los compromisos de nivel de servicio, un indicador clave de la calidad del servicio y la satisfacción del cliente. Dónde obtenerlo Se obtiene de Zendesk Ticket Metrics API, que proporciona información sobre el estado del SLA de cada ticket. Ejemplos CumplidoIncumplidoActivo
	¿Se resolvió en el primer contacto? IsFirstContactResolution	Indicador que señala si el primer agente asignado resolvió la solicitud sin reasignaciones ni respuestas del solicitante.
Descripción La resolución en el primer contacto (FCR) es una métrica clave que indica si el problema de un cliente se resolvió en una sola interacción. Este atributo calculado es un indicador booleano que toma el valor verdadero si el primer agente asignado resolvió el ticket, sin reasignaciones y con una sola respuesta del agente. Este atributo permite calcular directamente el KPI «Tasa de resolución en el primer contacto». Analizar las características de los casos resueltos en el primer contacto puede servir de referencia para mejorar el proceso. Por otro lado, analizar los casos que no cumplen este criterio puede revelar oportunidades para mejorar la formación de los agentes, los artículos de la base de conocimientos o la clasificación inicial. Por qué es importante Mide la capacidad de resolver problemas de forma eficiente en una sola interacción, lo que contribuye notablemente tanto a la satisfacción del cliente como a la eficiencia operativa. Dónde obtenerlo Este atributo calculado es complejo. Requiere analizar el registro de eventos de un ticket para comprobar si hubo reasignaciones de agentes y cuántas respuestas públicas enviaron. Ejemplos truefalse
	Hora de finalización EndTime	Fecha y hora exactas en que terminó la actividad.
Descripción La hora de finalización indica cuándo termina una actividad. En muchos eventos de Zendesk, la duración es instantánea, por lo que coincide con la hora de inicio. Sin embargo, en actividades basadas en estados, como 'Solicitud puesta en espera', la hora de finalización corresponde al momento en que se retira el ticket de la espera. Este atributo es esencial para calcular la duración de actividades concretas, un dato clave para el análisis de cuellos de botella. Al comparar la hora de inicio y la hora de finalización de una actividad, se puede medir directamente su tiempo de procesamiento e identificar los pasos que consumen más tiempo. Por qué es importante Permite calcular la duración de cada actividad, algo fundamental para identificar cuellos de botella en el proceso y medir la eficiencia de cada paso. Dónde obtenerlo En los eventos discretos, suele coincidir con StartTime. Para las duraciones de estado, corresponde a la marca de tiempo del siguiente evento que cambia el estado. Ejemplos 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Nombre de la política de SLA SlaPolicyName	Nombre de la política del acuerdo de nivel de servicio (SLA) aplicada a la solicitud.
Descripción Este atributo identifica la política de SLA específica que establece los tiempos objetivo de respuesta y resolución de la solicitud de servicio. La política suele depender de factores como la prioridad y el tipo de solicitud, o el nivel de suscripción del cliente. Conocer la política de SLA aplicada es esencial para el Dashboard «Análisis del cumplimiento y las infracciones de SLA». Proporciona el contexto necesario para evaluar el rendimiento, ya que cada política puede tener objetivos distintos. Así, es posible determinar de forma justa y precisa si un ticket cumplió sus objetivos de nivel de servicio específicos. Por qué es importante Proporciona el contexto necesario para analizar el SLA: identifica el conjunto de objetivos con el que se evaluó una solicitud y permite elaborar informes precisos sobre el cumplimiento. Dónde obtenerlo Zendesk Ticket Metrics API. Los datos de SLA suelen estar asociados a las métricas del ticket. Ejemplos Urgente: respuesta en 1 horaEstándar: resolución en 24 horasSLA para clientes prémium
	Nombre de quien realizó la solicitud RequestorName	Nombre del usuario final o cliente que envió la solicitud de servicio.
Descripción Este atributo identifica a la persona que inició la solicitud de servicio. Vincular la solicitud con un cliente concreto ofrece una perspectiva centrada en el usuario del proceso de soporte. En el análisis de procesos, se puede utilizar para estudiar patrones de clientes concretos o segmentos de clientes. Por ejemplo, se puede investigar si algunos clientes tienen tiempos de resolución más largos o más retrabajo, lo que podría indicar problemas con el producto o servicio que utilizan. Por qué es importante Vincula el proceso con el cliente y permite analizar problemas específicos, solicitudes recurrentes y niveles de satisfacción. Dónde obtenerlo API de usuarios de Zendesk, mediante la unión con 'requester_id' de la respuesta de la API de tickets. Ejemplos Alice JohnsonBob WilliamsCharlie Brown
	Número de reasignaciones del agente AgentReassignmentCount	Número total de veces que una solicitud se reasignó de un agente a otro.
Descripción Este atributo es un contador que aumenta cada vez que cambia el campo 'assignee_id' de un ticket. Un número elevado de reasignaciones de un mismo ticket puede indicar diversos problemas en el proceso, como una asignación inicial incorrecta, falta de conocimientos del agente o una solicitud demasiado compleja para que la gestione una sola persona. Es una métrica clave para medir la eficiencia del proceso y permite calcular el KPI «Tasa de reasignación de agentes». Analizar los casos con muchas reasignaciones puede revelar oportunidades para mejorar las reglas de asignación, la formación de los agentes o los recursos de la base de conocimientos, de modo que los tickets lleguen antes a la persona adecuada. Por qué es importante Ayuda a cuantificar los traspasos internos e identificar fricciones en el proceso, ya que una tasa elevada de reasignaciones suele provocar retrasos e ineficiencias. Dónde obtenerlo Se calcula contando los cambios del campo 'assignee_id' en Zendesk Ticket Audits API para cada ticket. Ejemplos 013
	Organización de quien realizó la solicitud RequestorOrganization	Organización o empresa a la que pertenece quien realizó la solicitud.
Descripción Este atributo vincula la solicitud de servicio con una organización cliente concreta. Es especialmente relevante en el soporte B2B, donde los acuerdos de nivel de servicio y los contratos de soporte suelen definirse para cada organización. Analizar los datos por organización ofrece una visión del rendimiento del soporte para cada empresa. Ayuda a identificar organizaciones que generan muchos tickets, sufren problemas recurrentes o tienen puntuaciones de satisfacción bajas. Esta información es útil para gestionar cuentas y detectar tendencias generales en la relación con los clientes. Por qué es importante Permite analizar el servicio B2B agrupando las solicitudes por empresa, algo fundamental para gestionar las relaciones con los clientes y los SLA a nivel organizativo. Dónde obtenerlo API de organizaciones de Zendesk, mediante la unión con 'organization_id' de la respuesta de la API de tickets. Ejemplos Acme CorporationGlobal Tech Inc.Innovate Solutions
	Valoración de satisfacción SatisfactionRating	Puntuación de satisfacción que proporciona quien realizó la solicitud después de que se resuelve el ticket.
Descripción Este atributo recoge la retroalimentación del cliente sobre su experiencia de soporte, que suele obtenerse mediante una encuesta después de marcar el ticket como resuelto. Las valoraciones habituales incluyen 'Bueno' o 'Malo', a veces acompañadas de un comentario. La valoración de satisfacción es una métrica clave de resultados. Relacionar los patrones del proceso con las puntuaciones de satisfacción puede revelar qué comportamientos generan clientes satisfechos o insatisfechos. Por ejemplo, el análisis podría mostrar una fuerte correlación entre las reasignaciones frecuentes o los largos tiempos de resolución y las valoraciones negativas. Por qué es importante Relaciona directamente la ejecución del proceso con los resultados para el cliente y ayuda a identificar qué comportamientos del proceso impulsan su satisfacción. Dónde obtenerlo API de tickets de Zendesk, campo 'satisfaction_rating.score' o 'satisfaction_rating.reason'. Ejemplos BuenoMaloOfrecido

Obligatorio Recomendado Opcional

Actividades de gestión de solicitudes de servicio

Estos son los pasos clave y los hitos del proceso que debe registrar en el registro de eventos para descubrir con precisión cómo se gestionan sus solicitudes de servicio.

7 Recomendado 6 Opcional

	Actividad	Descripción
	Objetivo del SLA incumplido	Esta actividad señala el momento en que una solicitud de servicio no cumple un objetivo del SLA establecido, como el tiempo hasta la primera respuesta o el tiempo de resolución. Zendesk registra un evento explícito cuando no se alcanza un objetivo.
Por qué es importante Este evento es fundamental para supervisar el cumplimiento y constituye un dato clave para calcular el KPI de tasa de cumplimiento del SLA. Permite identificar los incumplimientos de los compromisos de servicio. Dónde obtenerlo Se registra a partir del evento 'SLABreach' en los eventos del ticket de Zendesk o en el registro de auditoría. El evento especifica qué métrica del SLA se incumplió. Capturar Se identifica mediante el evento explícito 'SLABreach' en los datos del ticket. Tipo de evento explicit
	Respuesta pública enviada	Esta actividad señala cualquier comunicación que un agente envía a quien realizó la solicitud. Se registra como un evento explícito 'Comment' en los datos del ticket de Zendesk, cuando el atributo 'public' tiene el valor true.
Por qué es importante Estos eventos son fundamentales para analizar la frecuencia de las comunicaciones, medir los tiempos de respuesta de los agentes e identificar cuántas interacciones se necesitan para resolver una solicitud. Dónde obtenerlo Se trata de un evento explícito 'Comment' en los datos del ticket. Los detalles del evento incluyen el atributo 'public: true', que lo distingue de las notas internas. Capturar Se registra a partir de los eventos 'Comment' del ticket cuyo indicador 'public' tiene el valor true. Tipo de evento explicit
	Solicitud asignada a un agente	Esta actividad ocurre cuando una solicitud de servicio se asigna por primera vez a un agente específico. Se infiere de un evento «Change» en el registro de auditoría del ticket, cuando el campo «assignee_id» pasa de estar vacío o contener el ID de un grupo a tener un valor.
Por qué es importante Marca el inicio del trabajo activo de un agente y es fundamental para medir los tiempos de primera respuesta, la demora hasta la primera asignación y la distribución de la carga de trabajo de los agentes. Dónde obtenerlo Se infiere del primer evento «Change» del campo «assignee_id» en el registro de auditoría del ticket en el que se establece el ID de un usuario específico. Capturar Se infiere del primer evento de cambio que asigna un agente al campo «assignee_id». Tipo de evento inferred
	Solicitud de servicio cerrada	Representa el cierre definitivo de la solicitud de servicio. El ticket pasa automáticamente al estado 'closed' después de permanecer un periodo determinado en estado 'solved' y ya no se puede reabrir.
Por qué es importante Esta actividad marca el fin definitivo del proceso de solicitud de servicio. Es el punto final para calcular la duración total del caso. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuando el nuevo valor es 'closed'. Capturar Se infiere a partir de un evento 'Change' del registro de auditoría en el que el estado pasa a ser 'closed'. Tipo de evento inferred
	Solicitud de servicio creada	Marca el inicio del ciclo de vida de una solicitud de servicio, cuando quien la presenta envía un nuevo ticket por cualquier canal. En el registro de auditoría de tickets de Zendesk, se registra como un evento «Create», que proporciona una hora de inicio precisa para el proceso.
Por qué es importante Esta actividad es el evento de inicio principal de cada solicitud de servicio. Por eso, resulta esencial para calcular los tiempos de ciclo de principio a fin y analizar el volumen de solicitudes recibidas. Dónde obtenerlo Se registra como un tipo de evento «Create» en el registro de auditoría de tickets de Zendesk. La marca de tiempo de este evento corresponde a la hora de creación del ticket de solicitud de servicio. Capturar Se obtiene directamente del evento «Create» en el registro de auditoría del ticket. Tipo de evento explicit
	Solicitud de servicio reabierta	Se produce cuando quien realizó la solicitud responde a una solicitud cuyo estado es 'solved', lo que cambia automáticamente su estado a 'open'. Esto indica que la solución propuesta no fue suficiente.
Por qué es importante Esta actividad es el principal indicador de retrabajo. Analizar su frecuencia ayuda a medir la calidad de las resoluciones e identificar las causas de insatisfacción de los clientes. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuando el valor anterior era 'solved' y el nuevo es 'open'. Capturar Se infiere a partir de un cambio de estado de 'solved' a 'open'. Tipo de evento inferred
	Solicitud de servicio resuelta	Esta actividad señala el momento en que un agente proporciona una solución y cambia el estado del ticket a 'solved'. Desde la perspectiva del agente, la solicitud se considera completa, aunque quien la realizó todavía puede reabrirla.
Por qué es importante Este es un hito importante que marca el fin del trabajo activo del agente. El tiempo que se tarda en llegar a este estado es una medida clave de la eficiencia de resolución. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuando el nuevo valor es 'solved'. Capturar Se infiere a partir de un evento 'Change' del registro de auditoría en el que el estado pasa a ser 'solved'. Tipo de evento inferred
	Agente reasignado	Representa el traspaso de la responsabilidad de una solicitud de servicio de un agente a otro. Se infiere a partir de cualquier evento 'Change' posterior en el campo 'assignee_id' después de la asignación inicial.
Por qué es importante Registrar las reasignaciones es clave para calcular el KPI de tasa de reasignación de agentes, que ayuda a identificar ineficiencias en el proceso, errores de enrutamiento o carencias de conocimientos. Dónde obtenerlo Se infiere a partir de los eventos 'Change' en el campo 'assignee_id' del registro de auditoría del ticket, sin incluir el primer evento de asignación del ticket. Capturar Se infiere a partir del segundo evento 'Change' y de los posteriores en el campo 'assignee_id'. Tipo de evento inferred
	Nota interna añadida	Un agente ha añadido una nota o un comentario interno a la solicitud de servicio. Solo otros agentes pueden verlo. Se registra como un evento 'Comment' cuyo atributo 'public' tiene el valor false.
Por qué es importante Registrar las notas internas permite conocer mejor la colaboración entre agentes o equipos, que puede causar demoras o ser clave para resolver problemas con eficacia. Dónde obtenerlo Se trata de un evento explícito 'Comment' en los datos del ticket. Los detalles del evento incluyen el atributo 'public: false', que indica que es una nota interna. Capturar Se registra a partir de los eventos 'Comment' del ticket cuyo indicador 'public' tiene el valor false. Tipo de evento explicit
	Objetivo de SLA aplicado	Indica el momento en que se aplica una política de acuerdo de nivel de servicio (SLA) al ticket de solicitud de servicio. El evento se registra explícitamente cuando las propiedades del ticket cumplen las condiciones de una política de SLA activa.
Por qué es importante Registrar cuándo se aplica un SLA es fundamental para supervisar el cumplimiento, analizar posibles incumplimientos y comprender los plazos de servicio previstos para cada tipo de solicitud. Dónde obtenerlo Se obtiene del evento «SLAPolicyApplied» en los eventos del ticket o en el registro de auditoría de Zendesk. Este evento especifica qué política se aplicó. Capturar Se identifica mediante el evento explícito «SLAPolicyApplied» en los datos del ticket. Tipo de evento explicit
	Prioridad modificada	Indica que se ha actualizado el nivel de prioridad de la solicitud de servicio, por ejemplo, «Baja», «Normal», «Alta» o «Urgente». Se registra como un evento «Change» en el campo «priority» del registro de auditoría del ticket.
Por qué es importante Analizar los cambios de prioridad ayuda a identificar las solicitudes que se vuelven más urgentes con el tiempo y a evaluar si la priorización se gestiona de forma eficaz. Dónde obtenerlo Se registra como un evento 'Change' en el campo 'priority' del registro de auditoría del ticket de Zendesk, con los valores anterior y nuevo. Capturar Se infiere a partir de los eventos 'Change' en el campo 'priority' del registro de auditoría. Tipo de evento inferred
	Solicitud escalada	Representa la escalación formal de una solicitud de servicio a un nivel superior de soporte, a otro equipo o a la dirección. Por lo general, se infiere a partir de un cambio en el grupo asignado al ticket o en un campo personalizado destinado a registrar las escalaciones.
Por qué es importante Supervisar las escalaciones ayuda a identificar solicitudes complejas, necesidades de formación de los agentes de primera línea y problemas sistémicos que requieren la intervención de un nivel superior. Dónde obtenerlo No es un evento estándar. Debe inferirse a partir de un evento 'Change' en el campo 'group_id' que asigne el ticket a un grupo de escalación, o de un cambio en un campo personalizado del ticket utilizado para registrar las escalaciones. Capturar Se infiere a partir de un cambio en 'group_id' o en un campo personalizado 'escalation'. Tipo de evento inferred
	Solicitud puesta en espera	Esta actividad se produce cuando el estado de la solicitud de servicio cambia a 'on-hold'. Por lo general, esto indica que el agente espera información de quien realizó la solicitud o de un tercero. Se infiere a partir de un evento de cambio de estado.
Por qué es importante Esto permite aislar y medir los tiempos de espera que escapan al control directo del equipo de soporte y ofrece una visión más precisa del tiempo de gestión de los agentes. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuando el nuevo valor es 'on-hold'. Capturar Se infiere a partir de un evento 'Change' del registro de auditoría en el que el estado pasa a ser 'on-hold'. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Acceda a Zendesk Explore y cree el informe principal: Vaya al icono de productos de Zendesk, en la barra superior derecha, y seleccione Explore. Una vez allí, haga clic en el icono Queries de la izquierda y, después, en New query. Seleccione el conjunto de datos Support: Ticket updates como origen.
Configure las métricas y los atributos de los eventos de tickets: En el generador de consultas, añada una métrica como COUNT(Tickets) para visualizar los datos. Después, vaya a la sección Rows y añada estos atributos: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type y Ticket tags.
Cree un atributo calculado para ActivityName: Para convertir las actualizaciones sin procesar en actividades significativas, cree un atributo calculado estándar. Vaya al menú Calculations (icono de calculadora), seleccione Standard calculated attribute y asígnele el nombre ActivityName. Pegue en el cuadro de fórmula la lógica proporcionada en la sección Query. La fórmula asigna nombres de actividad a los distintos eventos de actualización de tickets.
Ajuste y filtre el informe principal: Añada el nuevo atributo ActivityName a la sección Rows. Cree un filtro para excluir de este atributo los valores (null) y los valores no deseados generados por el sistema, a fin de depurar el conjunto de datos. Añada también un filtro para Ticket created - Date y limite la consulta a un periodo manejable, por ejemplo, los últimos 6 meses.
Cree el segundo informe para los eventos de SLA: Cree otra consulta y seleccione el conjunto de datos Support: SLAs. Es necesario porque el conjunto de datos Ticket updates no incluye eventos de SLA.
Configure el informe de SLA: En la consulta de SLA, añada COUNT(SLA tickets) a Metrics. En la sección Rows, añada Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status y Updater name. En el paso de transformación, deduciremos la actividad a partir de SLA status.
Exporte ambos conjuntos de datos: Ejecute las dos consultas en la interfaz de Explore. Cuando se generen las tablas, haga clic en el botón Export y seleccione CSV como formato. Obtendrá dos archivos CSV independientes.
Combine y transforme los datos: Combine los dos archivos CSV con una herramienta de hojas de cálculo, como Microsoft Excel, o un lenguaje de programación, como Python. El objetivo es crear un único registro de eventos. Para el archivo de SLA, deberá crear la columna ActivityName. Si SLA status es Active, la actividad es SLA Target Applied. Si SLA status es Breached, la actividad es SLA Target Breached. Utilice SLA updated - Timestamp como EventTimestamp.
Estandarice los encabezados de columna: En el archivo final combinado, cambie el nombre de las columnas para que coincidan con el formato requerido para Process Mining. Por ejemplo, cambie Ticket ID por ServiceRequestId, Update - Timestamp por EventTimestamp y Updater name por AgentName.
Añada columnas estáticas y finalice el archivo: Añada dos columnas al archivo CSV final. En SourceSystem, introduzca el valor 'Zendesk'. En LastDataUpdate, introduzca la fecha y hora en que realizó la exportación. El archivo ya está listo para cargarse.

Configuración

Plan de Zendesk: Para crear consultas y atributos personalizados, se necesita un plan de Zendesk Support que incluya Zendesk Explore Professional o Enterprise.
Permisos: Debe tener el rol de agente y permiso para crear y editar consultas en Explore. Normalmente, este acceso corresponde a un administrador o a un agente con un rol personalizado.
Selección de conjuntos de datos: Este método requiere crear dos informes independientes a partir de conjuntos de datos distintos: Support: Ticket updates para los eventos generales y Support: SLAs para los eventos específicos de SLA.
Filtro de fechas: Es fundamental aplicar un filtro de fechas, por ejemplo, en Ticket created - Date, para mantener un volumen de datos manejable. Para el análisis inicial, se recomienda un periodo de 3 a 6 meses.
Atributos calculados: La lógica para obtener los nombres de las actividades se implementa mediante un atributo calculado personalizado y complejo en Explore. Compruebe que la fórmula esté bien creada para evitar errores en los resultados.
Volumen de datos: La interfaz de Zendesk Explore y la función de exportación pueden ser lentas o agotar el tiempo de espera con conjuntos de datos muy grandes. Si va a extraer más de un año de datos o millones de tickets, considere dividir la exportación en periodos más cortos.

Consulta de ejemplo config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Pasos

Requisitos previos: Compruebe que tiene instalada la versión 3.6 o posterior de Python. También necesita acceso administrativo a su instancia de Zendesk Support para generar un token de API.
Instale las bibliotecas de Python: Abra la terminal o el símbolo del sistema e instale con pip las bibliotecas necesarias. La biblioteca requests permite realizar llamadas a la API y pandas sirve para manipular los datos y exportarlos a un archivo CSV.
```
pip install requests pandas
```
Genere un token de Zendesk API: Inicie sesión en Zendesk como administrador. Vaya a Admin Center > Apps and integrations > APIs > Zendesk API. En la sección Token Access, actívelo si aún no lo está y haga clic en "Add API token". Añada una descripción, por ejemplo, "ProcessMind Extraction", y copie el token generado. No podrá volver a verlo.
Configure el script de Python: Abra el script de Python proporcionado en un editor de texto. Complete las variables de configuración al principio del archivo: ZENDESK_SUBDOMAIN (el nombre del dominio de Zendesk de su empresa), ZENDESK_EMAIL (la dirección de correo electrónico del usuario administrador asociado al token) y ZENDESK_API_TOKEN. Configure también START_TIME_STR para indicar el inicio del periodo de extracción de datos, normalmente entre 3 y 6 meses antes de la fecha actual.
Comprenda la lógica del script: Primero, el script obtiene una lista de tickets actualizados dentro del periodo especificado mediante Incremental Tickets API, que es eficiente. Después, obtiene para cada ticket el historial completo de auditoría, los comentarios y las métricas de SLA. Por último, procesa los eventos en orden cronológico para crear un historial detallado.
Asigne actividades a los eventos de Zendesk: El script incluye la lógica necesaria para convertir los eventos sin procesar de Zendesk en las actividades empresariales requeridas. Por ejemplo, un evento 'Change' en el campo 'status' se asigna a actividades como 'Solicitud de servicio resuelta' o 'Solicitud puesta en espera'. En los eventos de comentarios, se comprueba si se trata de una 'Respuesta pública enviada' o una 'Nota interna añadida'.
Ejecute el script de extracción: Ejecute el script desde la terminal con python your_script_name.py. A medida que obtiene datos de Zendesk API, el script muestra el progreso. El proceso puede tardar un tiempo, según el volumen de datos y los límites de frecuencia de la API.
Revise el archivo de salida: Al finalizar, se generará en el mismo directorio un archivo CSV llamado zendesk_event_log.csv. Contiene el registro de eventos extraído, con todas las actividades y atributos especificados.
Prepare el archivo para cargarlo: Abra el archivo CSV y compruebe que tenga el formato correcto. Los encabezados de columna deben coincidir con los atributos requeridos, entre ellos ServiceRequestId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate. El archivo ya está listo para cargarse en ProcessMind.

Configuración

Acceso a Zendesk API: El script requiere un token de API activo asociado a un administrador o a un agente con permisos suficientes. La dirección de correo electrónico del usuario configurada en el script debe ser la misma con la que se creó el token.
Parámetros del script: Antes de ejecutarlo, configure estas variables clave: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN y START_TIME_STR. START_TIME_STR debe tener el formato 'YYYY-MM-DD'.
Periodo de fechas: Para empezar, recomendamos extraer los datos de los últimos 3 a 6 meses (START_TIME_STR). Así obtendrá un conjunto de datos representativo para el análisis sin prolongar demasiado la ejecución ni alcanzar los límites de la API con demasiada frecuencia. Un periodo más amplio aumentará considerablemente el tiempo de extracción.
API de exportaciones incrementales: El script utiliza el endpoint Incremental Exports (/api/v2/incremental/tickets/cursor.json) para obtener de forma eficiente solo los tickets actualizados desde la última ejecución o desde una fecha de inicio especificada. Es mucho más eficaz que examinar todos los tickets.
Límites de frecuencia: Zendesk aplica límites de frecuencia a la API. El script incluye una gestión básica para hacer una pausa si se alcanza un límite, pero la extracción puede tardar bastante en instancias muy grandes. Lo más recomendable es ejecutarlo fuera de las horas de mayor actividad.
Lógica de escalamiento: La actividad 'Solicitud escalada' se deduce de un cambio en el campo group_id. Si su organización utiliza otro mecanismo, como un campo personalizado del ticket, deberá modificar la lógica del script para identificar correctamente los escalamientos.

Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
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.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'A critical error occurred: {e}')
            break

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'zendesk_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">'Event log saved to {output_filename}')

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

Pasos

En Zendesk Admin Center, solicite o inicie la exportación JSON nativa de la cuenta completa mediante la función de exportación disponible en su suscripción y cuenta de Zendesk. La ruta exacta del menú y los requisitos de autorización varían según la configuración de la cuenta. Utilice la opción de exportación disponible en Admin Center y siga el proceso de aprobación de su organización.
Seleccione un periodo que abarque el análisis requerido, preferiblemente de tres a seis meses. Si la exportación nativa no permite filtrar por fecha, descargue la exportación completa de la cuenta y aplique el filtro de fechas durante la transformación.
Descargue y conserve todos los archivos JSON que genere la exportación. Guarde los archivos originales, la fecha y hora de exportación, el identificador de la cuenta y cualquier archivo de manifiesto o metadatos. No sobrescriba los archivos de origen durante el procesamiento.
Analice los registros de tickets, auditorías de tickets, eventos de auditoría, comentarios, usuarios, organizaciones, grupos, registros relacionados con SLA y campos personalizados incluidos en la exportación. Como los nombres de archivo y las estructuras JSON pueden variar según la versión de exportación de Zendesk, configure las rutas de origen y las correspondencias de propiedades JSON en los marcadores de posición del script antes de ejecutarlo.
Normalice cada evento de auditoría de ticket en una estructura común que incluya ServiceRequestId, fecha y hora de auditoría, tipo de evento, nombre del campo, valor anterior, valor nuevo, identificador del actor, indicador de visibilidad pública, estado del ticket, agente asignado, grupo, prioridad, canal, tipo de servicio, etiquetas, sistema de origen y LastDataUpdate.
Genere una fila del registro de eventos por cada actividad que cumpla los criterios. La extracción debe crear explícitamente filas para Solicitud de servicio creada, Objetivo de SLA aplicado, Solicitud asignada a un agente, Prioridad modificada, Agente reasignado, Respuesta pública enviada, Nota interna añadida, Solicitud puesta en espera, Solicitud escalada, Objetivo de SLA incumplido, Solicitud de servicio reabierta, Solicitud de servicio resuelta y Solicitud de servicio cerrada. ProcessMind lee estas filas tal como están y no deduce eventos adicionales.
Cuando haya datos disponibles, resuelva los identificadores de agentes, grupos, organizaciones y solicitantes mediante los registros de usuarios, grupos y organizaciones exportados correspondientes. Complete AgentName y AssignedTeam según la asignación vigente en el momento del evento. Si no se puede resolver un nombre para mostrar, conserve el identificador o deje el valor en blanco.
Aplique reglas deterministas a los eventos. Utilice el evento de auditoría Create del ticket para Solicitud de servicio creada; los eventos explícitos de auditoría de SLA para Objetivo de SLA aplicado y Objetivo de SLA incumplido; el primer cambio de agente asignado que cumpla los criterios para Solicitud asignada a un agente; los cambios posteriores para Agente reasignado; los indicadores de comentarios públicos y privados para las respuestas y notas; los cambios de estado para las solicitudes puestas en espera, reabiertas, resueltas y cerradas; y los cambios de grupo o del campo de escalamiento configurado para Solicitud escalada.
Ordene las filas resultantes por ServiceRequestId y EventTimestamp, y utilice una secuencia estable de eventos de origen como criterio de desempate. No elimine eventos solo porque tengan la misma fecha y hora: puede haber varios comentarios o eventos de auditoría en el mismo momento.
Compruebe que estén presentes todas las columnas obligatorias y que cada actividad tenga al menos una fila que cumpla los criterios cuando los datos de origen incluyan el evento correspondiente. Exporte el resultado final como CSV UTF-8 o en otro formato de registro de eventos compatible con ProcessMind, con una fila por evento y los nombres de columna obligatorios ServiceRequestId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate.

Configuración

Alcance de la exportación: Utilice la exportación JSON nativa de la cuenta completa de Zendesk Support y conserve todos los archivos JSON que genere. La exportación debe incluir los datos de tickets y de auditorías o eventos de tickets. Si los datos de SLA, comentarios, usuarios, organizaciones, grupos o campos personalizados se entregan por separado, incluya esos archivos en los datos de entrada para la transformación.
Periodo de fechas: Para la extracción y validación iniciales, se recomienda un periodo de tres a seis meses. Si la exportación nativa abarca toda la cuenta y no permite restringir las fechas, filtre EventTimestamp después del análisis y conserve el archivo completo de origen.
Reglas de actividad: Configure correspondencias explícitas para las 13 actividades. No confíe en que ProcessMind deduzca eventos de asignación, escalamiento, SLA, estado o comentarios a partir de otras filas.
Configuración de SLA: Asigne los nombres de eventos o las propiedades exportadas que utilice la cuenta para aplicar los objetivos de SLA y registrar sus incumplimientos. Si la exportación no contiene eventos explícitos de SLA, no los invente. Configure las rutas de origen correspondientes en los marcadores de posición y documente las actividades que no estén disponibles.
Configuración del escalamiento: Identifique el campo de grupo específico de la cuenta o el campo personalizado que representa el escalamiento. Antes de ejecutar el script, asigne a ESCALATION_FIELD_ID o a la configuración equivalente el identificador real del campo exportado.
Rutas de origen: Configure las rutas de los archivos JSON y las correspondencias de propiedades JSON en el script. Los nombres de archivo y la estructura anidada de la exportación de Zendesk pueden variar según la versión y la configuración de la cuenta.
Resultado obligatorio: Complete ServiceRequestId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate en cada fila de evento. Se recomienda incluir también AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType y TicketTags.
Filtros: Aplique el periodo de análisis requerido, el alcance de cuenta o marca y cualquier filtro específico de la empresa solo después de confirmar que la propiedad correspondiente está en la exportación. No aplique filtros basados en nombres de campo que no se hayan verificado o que no sean compatibles.
Rendimiento: Procese los archivos JSON de forma incremental siempre que sea posible, evite cargar toda la exportación de la cuenta en la memoria, indexe los identificadores de tickets y auditorías y escriba archivos intermedios normalizados antes de generar el registro de eventos final. Para las exportaciones grandes, puede ser necesario dividir el procesamiento por fecha o identificador de ticket.
Requisitos previos: Acceso administrativo para solicitar o descargar la exportación nativa de la cuenta; autorización para acceder a las auditorías de tickets y a los datos de referencia de usuarios o grupos; una suscripción de Zendesk que admita la función de exportación; almacenamiento local para la exportación completa; y un entorno de ejecución capaz de analizar JSON y escribir archivos CSV UTF-8.
Protección de datos: Considere potencialmente confidenciales los datos de solicitantes, agentes, organizaciones, comentarios y tickets. Almacene los archivos de origen y los transformados de acuerdo con los requisitos de conservación, control de acceso y privacidad de su organización.

Consulta de ejemplo config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

¿Todo listo para comenzar?

Empiece hoy mismo a optimizar el proceso de solicitudes de servicio. Utilice este Template de datos para descubrir cuellos de botella y mejorar la eficiencia en Zendesk Support.

Volver a la guía de mejora

Descargar Template

Optimice la gestión de solicitudes de servicio. Reduzca los retrasos hoy mismo.

Ponga fin a las demoras en la atención y a la frustración de los usuarios. Alcance un 70 % de automatización.

Comience su prueba gratuita

No se requiere tarjeta de crédito. Configuración rápida.

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

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

Atributos de gestión de solicitudes de servicio

Actividades de gestión de solicitudes de servicio

Guías de extracción

Interfaz de Zendesk Explore para informes y exportación de datos

Pasos

Configuración

Consulta de ejemplo config

Extracción de Zendesk REST API mediante un script de Python

Pasos

Configuración

Consulta de ejemplo python

Exportación JSON nativa de la cuenta completa de Zendesk Support

Pasos

Configuración

Consulta de ejemplo config

¿Todo listo para comenzar?

Optimice la gestión de solicitudes de servicio. Reduzca los retrasos hoy mismo.