> 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 la gestión de solicitudes de servicio (21) Actividades de la 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 su 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 seguir y recomendaciones prácticas para 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 seguir
Guía para extraer datos de Zendesk Support

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

Descargar Template

Atributos de la gestión de solicitudes de servicio

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

5 Obligatorio 7 Recomendado 9 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre de la actividad empresarial o del evento que tuvo lugar para una solicitud de servicio.
Descripción La actividad representa un paso o evento diferenciado 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 realiza un seguimiento de las modificaciones en campos como el estado, el responsable y la prioridad, así como de la adición de comentarios. El análisis de las actividades es el núcleo del 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 del proceso. Por qué es importante Este atributo define los pasos del proceso y permite visualizar los mapas de proceso y analizar el flujo, las variaciones y la conformidad del proceso. Dónde obtenerlo Conceptualmente, se deriva de los eventos registrados en la API de auditorías de tickets de Zendesk. Por ejemplo, un cambio en el campo 'status' de 'new' a 'open' puede asignarse a una actividad como 'Solicitud clasificada'. Ejemplos Solicitud de servicio creadaAgente reasignadoSolicitud de servicio resuelta
	Hora de inicio EventTimestamp	La fecha y hora exactas en que tuvo lugar la actividad.
Descripción La marca de tiempo del evento, o 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 el estado del ticket cambió a 'Resolved'. Estos datos temporales proceden del registro de auditoría de cada ticket de Zendesk. Este atributo es fundamental 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 general del caso. Es esencial para identificar cuellos de botella y evaluar el rendimiento frente a objetivos basados en el tiempo, como los SLA. Por qué es importante Esta marca de tiempo ordena cronológicamente los eventos y es esencial para todos los análisis de duración, rendimiento y cuellos de botella. Dónde obtenerlo API de auditorías 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 la solicitud de servicio ServiceRequestId	El identificador único de cada ticket de solicitud de servicio en Zendesk.
Descripción El ID de la solicitud de servicio, denominado a menudo ID del ticket en Zendesk, actúa como clave principal de cada caso. Vincula todas las actividades, comentarios y cambios de estado relacionados desde el momento en que se crea la solicitud hasta su cierre. Esto permite realizar un seguimiento completo, de principio a fin, del ciclo de vida de una única solicitud. En el análisis de Process Mining, este atributo es fundamental. Define el caso, permite reconstruir los flujos del proceso, identificar variantes y calcular métricas a nivel de caso, como el tiempo de ciclo. Cada evento del conjunto de datos debe asociarse a un ID de solicitud de servicio para comprender 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 las solicitudes de servicio. En esta vista del proceso, el valor será siempre 'Zendesk Support', que lo identifica como el sistema de registro de todas las actividades de gestión del servicio. En entornos con varios sistemas integrados, este campo es fundamental para la trazabilidad de los datos y la resolución de problemas. Garantiza que los análisis se limiten correctamente al sistema previsto y ayuda a diferenciar los datos cuando se combinan fuentes diversas. Por qué es importante Identifica el sistema de origen de los datos, garantiza su trazabilidad y evita confusiones cuando se combinan 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	La marca de tiempo que indica la última vez que se actualizaron los datos desde el sistema de origen.
Descripción Este atributo registra la fecha y hora de la extracción de datos más reciente de Zendesk Support. Proporciona contexto sobre la actualidad de los datos analizados y permite saber hasta qué punto está actualizado el panorama del proceso. Para la supervisión continua y la creación de Dashboards, esta información es fundamental. Permite a analistas y usuarios de negocio comprender si están consultando datos casi en tiempo real o una instantánea de un periodo anterior, lo que afecta a la validez de sus conclusiones. Por qué es importante Proporciona un contexto fundamental sobre la actualidad de los datos y permite saber hasta qué punto está actualizado el análisis. Dónde obtenerlo Es un campo de metadatos que se genera y registra en el conjunto de datos en el momento de la extracción. Ejemplos 2023-10-27T08:00:00Z
	Canal de la solicitud RequestChannel	El canal a través del cual se envió la solicitud de servicio, por ejemplo, correo electrónico, formulario web o teléfono.
Descripción Este atributo identifica el origen del envío de la solicitud de servicio. Zendesk registra cómo se creó un ticket, ya sea mediante correo electrónico, un portal web, una integración de API, chat u otros canales. Esto aporta contexto sobre el método de interacción del cliente. El canal de la solicitud es una dimensión muy útil para el análisis. Permite comparar los tiempos de resolución, las valoraciones de satisfacción y las tasas de retrabajo en distintos canales mediante el panel «Eficiencia del canal de solicitudes». Esta información puede ayudar a las empresas a 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, lo que permite aplicar mejoras específicas. Dónde obtenerlo API de Zendesk Tickets, objeto «via» y su propiedad «channel». Ejemplos webcorreo electrónicoAPIchat
	Equipo asignado AssignedTeam	El 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, se conocen como 'Groups'. Los tickets suelen asignarse primero a un grupo antes de que un agente individual se haga cargo de ellos. Analizar los datos por equipo asignado es esencial para comprender el rendimiento y la carga de trabajo a nivel de equipo. Ayuda a responder preguntas sobre qué equipos gestionan cada tipo de solicitud, cuáles son sus tiempos medios de resolución y cuáles son sus tasas de cumplimiento de SLA. Es una dimensión principal del panel de rendimiento de agentes y equipos. Por qué es importante Permite analizar el rendimiento del equipo, equilibrar la carga de trabajo y evaluar la eficiencia del enrutamiento entre distintos grupos de soporte. Dónde obtenerlo API de Zendesk Groups, mediante la unión de «group_id» de la respuesta de la API de Tickets. Ejemplos Soporte de nivel 1Soporte técnicoFacturación
	Estado de la solicitud RequestStatus	El 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 concreto. Zendesk cuenta con varios estados estándar, como Nueva, Abierta, Pendiente, En espera, Resuelta y Cerrada, que indican el avance de una 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 empleado en los distintos estados es una parte esencial del análisis de cuellos de botella. Permite identificar dónde se quedan atascados los tickets, por ejemplo, cuando pasan demasiado tiempo en estado «Pendiente» o «En espera». Comprender las transiciones de estado también es clave para descubrir bucles de retrabajo. Por qué es importante Realizar un seguimiento del estado es fundamental para comprender el avance de la solicitud e identificar cuánto tiempo se emplea en estados de espera o activos. Dónde obtenerlo API de Zendesk Tickets, campo «status». Ejemplos NuevoAbiertoPendienteResueltoCerrado
	Etiquetas del ticket TicketTags	Lista de etiquetas aplicadas a la solicitud de servicio para su categorización y enrutamiento.
Descripción Las etiquetas son rótulos flexibles que los agentes pueden añadir manualmente a los tickets o que pueden aplicarse automáticamente mediante reglas de negocio. Se utilizan para añadir contexto o categorías específicas que quizá no cubran campos estándar como Tipo o Prioridad. Las etiquetas son un atributo muy versátil para el análisis de Process Mining. Pueden utilizarse para filtrar situaciones muy concretas, realizar un seguimiento de Workflow personalizados o identificar causas raíz. Por ejemplo, una etiqueta «VIP» podría servir para analizar el proceso de clientes clave, mientras que una etiqueta «product_bug» podría utilizarse para seguir el ciclo de vida de los informes de defectos. Por qué es importante Ofrece una forma flexible de segmentar y explorar los datos, lo que permite analizar en profundidad subprocesos específicos o atributos de tickets que no se registran en otros campos. Dónde obtenerlo API de Zendesk Tickets, campo «tags». Es una matriz de cadenas de texto. Ejemplos consulta_comercialproblema_de_facturaciónsolicitud_de_funcionalidadcliente_vip
	Nombre del agente AgentName	El 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 panel de rendimiento de agentes y equipos y a comprender la contribución individual 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 impacto de las reasignaciones en los tiempos de resolución. Dónde obtenerlo API de usuarios de Zendesk, mediante la unión del 'assignee_id' de la respuesta de la API de Tickets. Ejemplos Jane DoeJohn SmithEmily Jones
	Prioridad de la solicitud RequestPriority	El nivel de prioridad asignado a la solicitud de servicio, como Baja, Normal, Alta o Urgente.
Descripción Request Priority es una clasificación que indica la urgencia de una solicitud de servicio. Este nivel suele determinar los tiempos objetivo de resolución y las políticas de SLA aplicadas al ticket. El sistema o la persona usuaria pueden establecer la prioridad inicialmente, y un agente puede cambiarla durante el ciclo de vida del ticket. Este atributo es fundamental para la segmentación y el análisis de causa raíz. Ayuda a analizar si los tickets de alta prioridad se resuelven más rápido que los de baja prioridad y es un factor clave en los Dashboards «Service Request Escalation Trends» y «SLA Adherence». Por qué es importante Permite segmentar las solicitudes por urgencia, un aspecto fundamental para analizar el cumplimiento de los SLA y garantizar que los problemas críticos se atiendan con rapidez. Dónde obtenerlo API de Zendesk Tickets, campo «priority». Ejemplos BajaNormalAltaUrgente
	Tipo de servicio ServiceType	La categoría o el tipo de solicitud de servicio, por ejemplo, Incidente, Pregunta, Problema o Tarea.
Descripción El tipo de servicio categoriza la naturaleza de la solicitud de servicio. Zendesk utiliza un campo «type» para distinguir entre 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 a los analistas examinar los flujos de proceso de distintos tipos de solicitudes, que a menudo siguen rutas de resolución y SLA muy diferentes. Es una dimensión clave del panel «Rendimiento de agentes y equipos», ya que permite identificar quién gestiona mejor cada tipo de solicitud. Por qué es importante Clasifica las solicitudes para permitir un análisis independiente de distintos procesos, como incidentes y preguntas, que siguen rutas diferentes. Dónde obtenerlo API de Zendesk Tickets, campo «type». Ejemplos preguntaincidenteproblematarea
	¿Es retrabajo? IsRework	Indicador que es verdadero si la solicitud de servicio se reabrió después de resolverse.
Descripción Este indicador booleano identifica los casos que han requerido retrabajo. Normalmente, una solicitud de servicio se considera retrabajo si su estado cambia de «Resuelta» a un estado abierto, lo que indica que la resolución inicial no fue suficiente y el cliente tuvo que volver a contactar por el mismo problema. Este atributo es esencial para calcular el KPI «Tasa de retrabajo de solicitudes de servicio» y para el panel «Análisis de la actividad de retrabajo y reapertura». Al marcar los casos con retrabajo, los analistas pueden aislar estos flujos de proceso ineficientes, descubrir las causas raíz 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 relieve 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 la API de auditorías de tickets de Zendesk. Una transición de «solved» a «open» indica retrabajo. Ejemplos truefalse
	¿Se ha incumplido 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 indicar estados como «Cumplido», «Incumplido» o «Activo». Se determina comparando los tiempos reales de respuesta o resolución con los objetivos definidos en la política de SLA aplicada. Es un atributo fundamental para el panel «Análisis del cumplimiento y las infracciones de SLA». Permite contar y visualizar fácilmente los tickets que cumplen y los que no cumplen. A continuación, el análisis puede centrarse en las características de los tickets con incumplimientos para identificar causas raíz, como tiempos de espera prolongados o reasignaciones excesivas. 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 la API de métricas de tickets de Zendesk, 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 la solicitud fue resuelta por el primer agente asignado, sin reasignaciones ni respuestas del solicitante.
Descripción La resolución en el primer contacto (FCR) es una métrica fundamental que indica que el problema de un cliente se resolvió en una sola interacción. Este atributo calculado es un indicador booleano que es verdadero si el ticket fue resuelto por el primer agente al que se asignó, sin reasignaciones y con una sola respuesta del agente. Este atributo respalda directamente el KPI «Tasa de resolución en el primer contacto». Analizar las características de los casos con FCR puede proporcionar un modelo para la excelencia operativa. Por el contrario, analizar los casos que no alcanzan la FCR 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, un factor que impulsa tanto la satisfacción del cliente como la eficiencia operativa. Dónde obtenerlo Es un atributo calculado complejo. Requiere analizar el registro de eventos de un ticket para comprobar las reasignaciones de agentes y el número de respuestas públicas de los agentes. Ejemplos truefalse
	Hora de finalización EndTime	La fecha y hora exactas en que se completó la actividad.
Descripción La hora de finalización marca la conclusión de una actividad. En muchos eventos de Zendesk, la duración es instantánea, por lo que la hora de finalización coincide con la hora de inicio. Sin embargo, en actividades basadas en estados, como 'Solicitud puesta en espera', la hora de finalización correspondería al momento en que el ticket deja de estar en espera. Este atributo es esencial para calcular la duración de actividades específicas, un dato clave para analizar cuellos de botella. Al comparar la hora de inicio y la hora de finalización de una actividad, es posible medir directamente su tiempo de procesamiento y localizar 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 del proceso y medir la eficiencia de cada paso. Dónde obtenerlo A menudo coincide con StartTime en los eventos discretos. 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	El nombre de la política de Acuerdo de Nivel de Servicio (SLA) aplicada a la solicitud.
Descripción Este atributo identifica la política de SLA específica que establece los tiempos objetivo de respuesta y resolución de la solicitud de servicio. Una política suele determinarse según factores como la prioridad o el tipo de solicitud, o el nivel de suscripción del cliente. Conocer la política de SLA aplicada es esencial para el panel «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 diferentes. Así, es posible valorar de forma justa y precisa si un ticket cumplió sus objetivos específicos de nivel de servicio. Por qué es importante Aporta el contexto necesario para analizar los SLA al identificar el conjunto de objetivos con el que se midió una solicitud y permite elaborar informes precisos de cumplimiento. Dónde obtenerlo API de métricas de tickets de Zendesk. 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 de cliente premium
	Nombre del solicitante RequestorName	El 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 proporciona una visión del proceso de soporte centrada en el usuario. En el análisis de procesos, el solicitante puede utilizarse para analizar patrones de clientes concretos o segmentos de clientes. Por ejemplo, puede investigarse si determinados clientes experimentan tiempos de resolución más largos o tasas de retrabajo más elevadas, lo que podría indicar problemas con el producto o servicio que utilizan. Por qué es importante Conecta el proceso con el cliente y permite analizar problemas específicos de cada cliente, solicitudes repetidas y niveles de satisfacción. Dónde obtenerlo API de Zendesk Users, mediante la unión de «requester_id» de la respuesta de la API de Tickets. Ejemplos Alice JohnsonBob WilliamsCharlie Brown
	Número de reasignaciones del agente AgentReassignmentCount	El 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 para un mismo ticket puede indicar diversos problemas de proceso, como un enrutamiento inicial incorrecto, falta de conocimientos del agente o solicitudes demasiado complejas para que las gestione una sola persona. Es una métrica clave para medir la eficiencia del proceso y respalda directamente el KPI «Tasa de reasignación de agentes». Analizar los casos con un número elevado de reasignaciones puede revelar oportunidades para mejorar las reglas de enrutamiento, la formación de los agentes o los recursos de la base de conocimientos, de modo que los tickets lleguen más rápido a la persona adecuada. Por qué es importante Ayuda a cuantificar las transferencias internas e identifica fricciones del proceso, ya que las tasas elevadas de reasignación suelen provocar retrasos e ineficiencias. Dónde obtenerlo Se calcula contando el número de cambios de «assignee_id» en la API de auditorías de tickets de Zendesk para cada ticket. Ejemplos 013
	Organización del solicitante RequestorOrganization	La organización o empresa a la que pertenece el solicitante.
Descripción Este atributo vincula la solicitud de servicio con una organización cliente concreta. Es especialmente relevante en escenarios de soporte B2B, donde los acuerdos de nivel de servicio y los contratos de soporte suelen definirse a nivel de organización. Analizar los datos por organización proporciona una visión del rendimiento del soporte a nivel empresarial. Puede ayudar a identificar organizaciones que generan un gran volumen de tickets, experimentan problemas recurrentes o presentan puntuaciones de satisfacción bajas. Esta información resulta valiosa para la gestión de cuentas y para identificar tendencias generales sobre la salud de 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 Zendesk Organizations, mediante la unión de «organization_id» de la respuesta de la API de Tickets. Ejemplos Acme CorporationGlobal Tech Inc.Innovate Solutions
	Valoración de satisfacción SatisfactionRating	La puntuación de satisfacción proporcionada por el solicitante después de resolver el ticket.
Descripción Este atributo recoge la opinión del cliente sobre su experiencia de soporte, normalmente mediante una encuesta después de marcar un ticket como resuelto. Las valoraciones habituales incluyen «Buena» o «Mala», a veces acompañadas de un comentario. La valoración de satisfacción es una métrica de resultados fundamental. Correlacionar los patrones del proceso con las puntuaciones de satisfacción puede revelar qué comportamientos del proceso generan clientes satisfechos o insatisfechos. Por ejemplo, el análisis puede mostrar que las tasas elevadas de reasignación o los tiempos de resolución prolongados están estrechamente relacionados con valoraciones de satisfacción negativas. Por qué es importante Relaciona directamente la ejecución del proceso con los resultados del cliente y ayuda a identificar qué comportamientos del proceso impulsan la satisfacción del cliente. Dónde obtenerlo API de Zendesk Tickets, campo «satisfaction_rating.score» o «satisfaction_rating.reason». Ejemplos BuenoMaloOfrecido

Obligatorio Recomendado Opcional

Actividades de la gestión de solicitudes de servicio

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

7 Recomendado 6 Opcional

	Actividad	Descripción
	Objetivo de SLA incumplido	Esta actividad marca el momento en que una solicitud de servicio no cumple un objetivo de SLA definido, como el tiempo de primera respuesta o el tiempo de resolución. Zendesk lo registra como un evento explícito cuando no se alcanza un objetivo.
Por qué es importante Este es un evento crítico para supervisar el cumplimiento y un dato clave para el KPI de tasa de cumplimiento de SLA. Permite localizar los incumplimientos de los compromisos de servicio. Dónde obtenerlo Se captura del evento 'SLABreach' en los eventos del ticket de Zendesk o en el registro de auditoría. El evento especifica qué métrica de SLA se incumplió. Recopilar Se identifica mediante el evento explícito 'SLABreach' en los datos del ticket. Tipo de evento explicit
	Respuesta pública enviada	Esta actividad marca cualquier comunicación enviada por un agente a la persona solicitante. Se captura como un evento 'Comment' explícito en los datos del ticket de Zendesk cuando el atributo 'public' es 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 el número de interacciones necesarias para resolver una solicitud. Dónde obtenerlo Se trata de un evento 'Comment' explícito en los datos del ticket. Los detalles del evento incluyen el atributo 'public: true', que lo distingue de las notas internas. Recopilar Se captura de los eventos 'Comment' del ticket cuyo indicador 'public' está establecido en 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 a partir de un evento 'Change' en el registro de auditoría del ticket, cuando el campo 'assignee_id' se completa después de estar vacío o contener un ID de grupo.
Por qué es importante Esto marca el inicio del trabajo activo de un agente y es fundamental para medir los tiempos de respuesta inicial, la demora hasta la primera asignación y la distribución de la carga de trabajo entre los agentes. Dónde obtenerlo Se infiere a partir del primer evento 'Change' del campo 'assignee_id' en el registro de auditoría del ticket en el que se establece un ID de usuario específico. Recopilar Se infiere a partir del primer evento de cambio que asigna el campo 'assignee_id' a un agente. Tipo de evento inferred
	Solicitud de servicio cerrada	Representa el cierre final y permanente de la solicitud de servicio. Un ticket pasa automáticamente al estado 'closed' después de permanecer un periodo determinado en estado 'solved' y ya no puede reabrirse.
Por qué es importante Esta actividad marca el final definitivo del proceso de solicitud de servicio. Proporciona el punto final para calcular la duración completa del caso. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuyo nuevo valor es 'closed'. Recopilar 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 la solicitud de servicio, cuando una persona solicitante envía un ticket a través de cualquier canal. Se registra como un evento 'Create' en el registro de auditoría del ticket de Zendesk, lo que proporciona una hora de inicio definitiva para el proceso.
Por qué es importante Esta actividad actúa como el evento de inicio principal de cada solicitud de servicio, por lo que es 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 del ticket de Zendesk. La marca de tiempo de este evento corresponde a la hora de creación del ticket de la solicitud de servicio. Recopilar Se captura directamente del evento 'Create' en el registro de auditoría del ticket. Tipo de evento explicit
	Solicitud de servicio reabierta	Ocurre cuando una persona solicitante responde a una solicitud que se encuentra en estado '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 la resolución e identificar las causas de la insatisfacción del cliente. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuyo valor anterior era 'solved' y cuyo nuevo valor es 'open'. Recopilar Se infiere a partir de un cambio de estado de 'solved' a 'open'. Tipo de evento inferred
	Solicitud de servicio resuelta	Esta actividad marca el momento en que un agente proporciona una solución y cambia el estado del ticket a 'solved'. La solicitud se considera completada desde la perspectiva del agente, aunque la persona solicitante todavía puede reabrirla.
Por qué es importante Este es un hito importante que señala el final del trabajo activo del agente. El tiempo necesario para alcanzar este estado es una medida principal de la eficiencia de la resolución. Dónde obtenerlo Se infiere a partir de un evento 'Change' en el campo 'status' del registro de auditoría del ticket, cuyo nuevo valor es 'solved'. Recopilar 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 la transferencia 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 Supervisar las reasignaciones es fundamental para calcular el KPI de tasa de reasignación de agentes, que ayuda a identificar ineficiencias del proceso, enrutamientos incorrectos o carencias de conocimiento. Dónde obtenerlo Se infiere a partir de los eventos 'Change' del campo 'assignee_id' en el registro de auditoría del ticket, excluyendo el primer evento de asignación del ticket. Recopilar Se infiere a partir del segundo evento de cambio 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 comentario interno a la solicitud de servicio, visible únicamente para otros agentes. Se registra como un evento 'Comment' cuyo atributo 'public' es false.
Por qué es importante Supervisar las notas internas ofrece información sobre la colaboración entre agentes o equipos, que puede ser una fuente de retrasos o una clave para resolver problemas de forma eficiente. Dónde obtenerlo Se trata de un evento 'Comment' explícito en los datos del ticket. Los detalles del evento incluyen el atributo 'public: false', que indica que es una nota interna. Recopilar Se captura de los eventos 'Comment' del ticket cuyo indicador 'public' está establecido en false. Tipo de evento explicit
	Objetivo de SLA aplicado	Representa el momento en que se aplica una política de Acuerdo de Nivel de Servicio (SLA) al ticket de la solicitud de servicio. Este evento se registra explícitamente cuando las propiedades del ticket coinciden con 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 el plazo de servicio previsto para los distintos tipos de solicitudes. Dónde obtenerlo Se captura del evento 'SLAPolicyApplied' en los eventos del ticket de Zendesk o en el registro de auditoría. Este evento especifica qué política coincidió. Recopilar 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, como 'Low', 'Normal', 'High' o 'Urgent'. Se captura 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 cuya urgencia aumenta 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, mostrando los valores anterior y nuevo. Recopilar Se infiere a partir de los eventos 'Change' del campo 'priority' en el 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. Normalmente se infiere a partir de un cambio en el grupo asignado al ticket o de un cambio en un campo personalizado destinado a registrar las escalaciones.
Por qué es importante Supervisar las escalaciones ayuda a identificar solicitudes complejas, necesidades de capacitación de los agentes de primera línea y problemas sistémicos que requieren una intervención de mayor nivel. Dónde obtenerlo No es un evento estándar. Debe inferirse a partir de un evento 'Change' en el campo 'group_id' hacia un grupo de escalación o de un cambio en un campo personalizado del ticket utilizado para registrar las escalaciones. Recopilar 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 ocurre cuando el estado de la solicitud de servicio cambia a 'on-hold', lo que normalmente indica que el agente está esperando información de la persona solicitante o de un tercero. Se infiere a partir de un evento de cambio de estado.
Por qué es importante Esto ayuda a aislar y medir los tiempos de espera que están fuera del control directo del equipo de soporte, y proporciona 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, cuyo nuevo valor es 'on-hold'. Recopilar 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: Acceda al icono de productos de Zendesk en la barra superior derecha y seleccione Explore. Una vez en Explore, haga clic en el icono Queries de la izquierda y, después, en New query. Seleccione el conjunto de datos Support: Ticket updates como fuente.
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 los siguientes atributos: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Nombre del Group, 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, representado por el icono de calculadora, seleccione Standard calculated attribute y asígnele el nombre ActivityName. Pegue la lógica proporcionada en la sección Query en el cuadro de fórmula. Esta fórmula asigna distintos eventos de actualización de tickets a los nombres de actividad necesarios.
Ajuste y filtre el informe principal: Añada el atributo ActivityName a la sección Rows. Cree un filtro para este atributo que excluya cualquier valor (null) o generado por el sistema que no desee, con el fin de limpiar el conjunto de datos. Añada también un filtro para Ticket created - Date que limite la consulta a un periodo manejable, como los últimos 6 meses.
Cree el segundo informe para los eventos de SLA: Cree otra consulta nueva y seleccione esta vez el conjunto de datos Support: SLAs. Esto es necesario porque los eventos de SLA no están disponibles en el conjunto de datos Ticket updates.
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. Inferiremos la actividad a partir de SLA status durante el paso de transformación.
Exporte ambos conjuntos de datos: Ejecute las dos consultas en la interfaz de Explore. Cuando se hayan generado las tablas, haga clic en el botón Export y elija CSV como formato. Ahora tendrá 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 scripting como Python. El objetivo es crear un único Registro de eventos. En el archivo de SLA, deberá crear la columna ActivityName. Si SLA status es Activo, la actividad será SLA Target Applied. Si SLA status es Breached, la actividad será SLA Target Breached. Utilice SLA updated - Timestamp como EventTimestamp.
Estandarice los encabezados de columna: En el archivo combinado final, 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 las columnas estáticas y finalice: Añada dos columnas nuevas al archivo CSV final. Rellene SourceSystem con el valor 'Zendesk'. Rellene LastDataUpdate con la marca de tiempo del momento en que realizó la exportación. El archivo ya está listo para cargarse.

Configuración

Plan de Zendesk: Se requiere un plan de Zendesk Support que incluya Zendesk Explore Professional o Enterprise para crear consultas y atributos personalizados.
Permisos: Debe ser Agent y tener permisos para crear y editar consultas en Explore. Normalmente, se trata de un administrador o de un agente con un rol personalizado.
Selección del conjunto de datos: Este método requiere crear dos informes independientes basados en dos conjuntos de datos diferentes: Support: Ticket updates para los eventos generales y Support: SLAs para los eventos específicos de SLA.
Filtro de intervalo de fechas: Es fundamental aplicar un filtro de intervalo de fechas, por ejemplo sobre Ticket created - Date, para mantener un volumen de datos manejable. Se recomienda un intervalo de 3 a 6 meses para el análisis inicial.
Atributos calculados: La lógica para obtener los nombres de las actividades se gestiona mediante un atributo calculado personalizado y complejo dentro de Explore. Asegúrese de crear correctamente la fórmula para evitar errores en el resultado.
Volumen de datos: La interfaz de usuario y la función de exportación de Zendesk Explore pueden funcionar lentamente o agotar el tiempo de espera con conjuntos de datos muy grandes. Para extracciones que cubran más de un año de datos o millones de tickets, considere dividir la exportación en periodos más pequeños y procesarlos por lotes.

a 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: Asegúrese de tener Python 3.6 o una versión posterior instalada en su sistema. También necesitará acceso administrativo a su instancia de Zendesk Support para generar un token de API.
Instale las bibliotecas de Python: Abra el terminal o el símbolo del sistema e instale las bibliotecas de Python necesarias mediante pip. La biblioteca requests se utiliza para realizar llamadas a la API y pandas para manipular los datos y exportarlos a un archivo CSV.
```
pip install requests pandas
```
Genere un token de API de Zendesk: 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". Introduzca una descripción, por ejemplo "ProcessMind Extraction", y copie el token generado. Este token no volverá a mostrarse.
Configure el script de Python: Abra el script de Python proporcionado en un editor de texto. Rellene las variables de configuración situadas al principio del archivo: ZENDESK_SUBDOMAIN (el nombre de 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. Establezca también START_TIME_STR para definir el inicio del periodo de extracción de datos, normalmente entre 3 y 6 meses atrás.
Comprenda la lógica del script: Primero, el script obtiene una lista de tickets actualizados dentro del intervalo de fechas especificado mediante la API Incremental Tickets, que es eficiente. Después, obtiene el historial completo de auditoría, los comentarios y las métricas de SLA de cada ticket. A continuación, procesa estos eventos cronológicamente para crear un historial detallado.
Asigne los eventos de Zendesk a actividades: El script contiene la lógica 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 'Service Request Resolved' o 'Request Placed On-Hold'. Los eventos de comentarios se analizan para determinar si corresponden a 'Public Reply Sent' o 'Internal Note Added'.
Ejecute el script de extracción: Ejecute el script desde el terminal mediante python your_script_name.py. El script mostrará actualizaciones del progreso mientras obtiene los datos de la API de Zendesk. Según el volumen de datos y los límites de frecuencia de la API, el proceso puede tardar un tiempo.
Revise el archivo de salida: Cuando finalice el script, generará un archivo CSV llamado zendesk_event_log.csv en el mismo directorio. Este archivo contiene el registro de eventos extraído, con todas las actividades y los atributos especificados.
Prepare la carga: Abra el archivo CSV para comprobar que tiene el formato correcto. Los encabezados de las columnas deben coincidir con los atributos requeridos: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, entre otros. El archivo ya está listo para cargarse en ProcessMind.

Configuración

Acceso a la API de Zendesk: El script requiere un token de API activo asociado a un administrador o a un agente con permisos suficientes. El correo electrónico de usuario configurado en el script debe ser el mismo que creó el token de API.
Parámetros del script: Antes de ejecutarlo, debe configurar estas variables clave dentro del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN y START_TIME_STR. START_TIME_STR debe utilizar el formato 'YYYY-MM-DD'.
Intervalo de fechas: Recomendamos comenzar con un periodo de extracción que abarque los últimos 3 a 6 meses de datos (START_TIME_STR). Esto proporciona un conjunto de datos representativo para el análisis sin provocar un tiempo de ejecución excesivo ni alcanzar los límites de la API con demasiada frecuencia. Un intervalo mayor aumentará considerablemente el tiempo de extracción.
API de exportaciones incrementales: El script utiliza el endpoint de exportaciones incrementales (/api/v2/incremental/tickets/cursor.json) para obtener de forma eficiente solo los tickets que se han actualizado desde la última ejecución o desde una hora de inicio especificada. Este método ofrece un rendimiento muy superior al de analizar 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 pausar el proceso si se alcanza un límite, pero en instancias extremadamente grandes la extracción puede tardar bastante. Lo más recomendable es ejecutar el script fuera de las horas de mayor actividad.
Lógica de escalamiento: La actividad 'Request Escalated' se infiere a partir 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.

a 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 capacidad 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, por lo que debe utilizar la opción de exportación disponible en Admin Center y seguir el proceso de aprobación de su organización.
Seleccione un intervalo de fechas que cubra el periodo de análisis requerido, preferiblemente de tres a seis meses. Si la exportación nativa no ofrece un filtro de fechas, 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 generados por la exportación. Preserve los archivos originales, la marca de tiempo de la 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, los registros de auditoría de tickets, los eventos de auditoría, los comentarios, los usuarios, las organizaciones, los grupos, los registros relacionados con SLA y los 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 contenga ServiceRequestId, la marca de tiempo de auditoría, el tipo de evento, el nombre del campo, el valor anterior, el valor nuevo, el identificador del actor, el indicador de visibilidad pública, el estado del ticket, el agente asignado, el grupo, la prioridad, el canal, el tipo de servicio, las etiquetas, el 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 Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved y Service Request Closed. ProcessMind lee estas filas tal como están y no infiere eventos adicionales.
Resuelva los identificadores de agentes, grupos, organizaciones y solicitantes utilizando, cuando estén disponibles, los registros exportados correspondientes de usuarios, grupos y organizaciones. Rellene AgentName y AssignedTeam según el estado de asignación en el momento del evento. Conserve el identificador o deje el valor en blanco cuando no se pueda resolver un nombre visible.
Aplique reglas de eventos deterministas. Utilice el evento de auditoría Create del ticket para Service Request Created; los eventos de auditoría de SLA explícitos para SLA Target Applied y SLA Target Breached; el primer cambio de agente asignado que cumpla los criterios para Request Assigned to Agent; los cambios posteriores de agente para Agent Reassigned; los indicadores de comentarios públicos y privados para los eventos de respuesta y nota; las transiciones de estado para los eventos de puesta en espera, reapertura, resolución y cierre; y los cambios de grupo o del campo de escalamiento configurado para Request Escalated.
Ordene las filas resultantes por ServiceRequestId y EventTimestamp, conservando una secuencia estable del evento de origen como criterio de desempate. No elimine eventos únicamente porque tengan la misma marca de tiempo, ya que pueden producirse varios comentarios o eventos de auditoría al mismo tiempo.
Valide que todas las columnas obligatorias estén presentes y que cada actividad tenga al menos una fila que cumpla los criterios cuando los datos de origen contengan el evento correspondiente. Exporte el resultado final como CSV UTF-8 u 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 generados. La exportación debe incluir los datos de tickets y los datos de auditoría o eventos de tickets. Si los datos de SLA, comentarios, usuarios, organizaciones, grupos o campos personalizados se entregan por separado, incluya esos archivos en la entrada de transformación.
Intervalo 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 puede restringirse por fecha, 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 dependa de ProcessMind para derivar eventos de asignación, escalamiento, SLA, estado o comentarios a partir de otras filas.
Configuración de SLA: Asigne los nombres o propiedades de eventos exportados que la cuenta utiliza realmente para los eventos de aplicación y vencimiento del objetivo de SLA. Si la exportación no contiene eventos de SLA explícitos, no los invente. Configure las rutas de origen correspondientes en los marcadores de posición y documente cualquier actividad no disponible.
Configuración del escalamiento: Identifique el campo de grupo específico de la cuenta o el campo personalizado que representa el escalamiento. Establezca ESCALATION_FIELD_ID o la configuración equivalente con el identificador real del campo exportado antes de la ejecución.
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 de exportación y la configuración de la cuenta.
Salida obligatoria: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem y LastDataUpdate deben estar rellenados en cada fila de evento. Las columnas recomendadas son AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType y TicketTags.
Filtros: Aplique el intervalo de fechas de análisis requerido, el alcance de la cuenta o marca y cualquier filtro específico de la empresa solo después de confirmar la propiedad exportada correspondiente. No aplique filtros basados en nombres de campos no compatibles o no verificados.
Rendimiento: Procese el JSON de forma incremental siempre que sea posible, evite cargar toda la exportación de la cuenta en memoria, indexe los identificadores de tickets y auditorías, y escriba archivos intermedios normalizados antes de generar el registro de eventos final. Las exportaciones grandes pueden requerir una partición 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 capacidad de exportación, almacenamiento local para la exportación completa y un entorno capaz de analizar JSON y escribir CSV UTF-8.
Protección de datos: Considere potencialmente sensibles los datos de solicitantes, agentes, organizaciones, comentarios y tickets. Almacene los archivos de origen y transformados de acuerdo con los requisitos de conservación, control de acceso y privacidad de su organización.

a 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()

¿Listo para comenzar?

Comience hoy mismo a optimizar su proceso de solicitudes de servicio. Aproveche este Template de datos para descubrir cuellos de botella e impulsar 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 ahora.

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

Iniciar la 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 la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

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

Pasos

Configuración

a Consulta de ejemplo config

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

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

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

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

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

Atributos de la gestión de solicitudes de servicio

Actividades de la gestión de solicitudes de servicio

Guías de extracción

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

Pasos

Configuración

a Consulta de ejemplo config

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

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

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

Valoramos su privacidad