> Mejora continua de procesos > Atención al cliente > Zendesk Support > Template de datos

Su Template de datos de servicio al cliente

Zendesk Support

Atributos del servicio al cliente(18) Actividades del servicio al cliente(14) Guías de extracción(4)

Su Template de datos de servicio al cliente

Este Template le ayuda a recopilar los datos adecuados para analizar el proceso de atención al cliente. Incluye los atributos de datos esenciales, las actividades clave que conviene seguir y recomendaciones prácticas para extraer esta información. Con esta guía, podrá crear un Registro de eventos completo para obtener información y mejorar las operaciones de servicio.

Atributos recomendados para recopilar
Actividades clave para seguir en el proceso de atención al cliente
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 del servicio al cliente

Estos son los campos de datos recomendados para incluir en el Registro de eventos y realizar un análisis completo del servicio al cliente.

5 Obligatorio 6 Recomendado 7 Opcional

	Nombre	Descripción
	Hora de inicio StartTime	Marca de tiempo que indica cuándo comenzó una actividad o un evento.
Descripción La hora de inicio, o marca de tiempo del evento, registra la fecha y la hora exactas en que se produjo una actividad concreta. Por ejemplo, indica cuándo se añadió un comentario de un cliente, cuándo se asignó un agente o cuándo cambió el estado del ticket a 'Resuelto'. Esta marca de tiempo es fundamental para Process Mining, ya que establece el orden cronológico de los eventos. Se utiliza para calcular la duración entre actividades, medir los tiempos de ciclo, analizar el rendimiento con respecto a los SLA y comprender la evolución temporal del proceso de atención. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, calcular duraciones y analizar la cronología del proceso de solicitud de servicio. Dónde obtenerlo API Zendesk Ticket Audits, campo `created_at` de cada evento del registro de auditoría. Ejemplos 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Solicitud de servicio ServiceRequest	Identificador único de cada solicitud de atención al cliente, también conocida como ticket o caso.
Descripción La solicitud de servicio es el identificador principal del caso que vincula todas las actividades relacionadas con una consulta o un problema de un cliente, desde su creación hasta su resolución definitiva. Cada interacción, actualización o acción interna está asociada a este ID único. En Process Mining, analizar los eventos agrupados por solicitud de servicio permite obtener una visión completa del recorrido de atención al cliente. Este identificador es la base para calcular métricas clave, como el tiempo total de resolución, detectar desviaciones del proceso y comprender el ciclo de vida de cada problema del cliente. Por qué es importante Este es el ID del caso esencial que conecta todos los pasos del proceso y permite reconstruir y analizar cada recorrido individual de atención al cliente. Dónde obtenerlo API Zendesk Tickets, campo `id`. Ejemplos 102451287415332
	Nombre de la actividad ActivityName	Nombre del evento o la tarea específicos que se produjeron durante el ciclo de vida de la solicitud de servicio.
Descripción El nombre de la actividad describe un paso o hito del proceso de atención al cliente, como 'Solicitud de servicio creada', 'Solicitud asignada a un agente' o 'Solicitud de servicio resuelta'. Estos eventos tienen una marca de tiempo y forman la secuencia de acciones de cada solicitud de servicio. Este atributo es fundamental para visualizar el flujo del proceso, descubrir variantes y analizar la frecuencia y el orden de los eventos. Permite comprender qué acciones se realizan e identificar las rutas habituales, los cuellos de botella y las desviaciones del procedimiento estándar. Por qué es importante Este atributo define los pasos del proceso y permite visualizar el mapa de procesos y analizar los flujos y las variaciones. Dónde obtenerlo Se obtiene de los registros de auditoría de tickets de Zendesk o de los flujos de eventos que registran cambios y acciones. Ejemplos Solicitud de servicio creadaSolicitud asignada a un agentePrimera respuesta pública de un agente enviadaSolicitud de servicio resuelta
	Sistema de origen SourceSystem	Sistema de registro del que se extrajeron los datos.
Descripción Este atributo especifica el sistema de origen de los datos de las solicitudes de servicio, que en este caso es Zendesk Support. Ayuda a gestionar la gobernanza y la trazabilidad de los datos, especialmente cuando se combinan datos de varios sistemas. En el análisis, permite atribuir correctamente los datos a su origen, algo importante para mantener su integridad y comprender el contexto del proceso, sobre todo en entornos con varios sistemas. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza y para distinguir los datos de procesos en entornos integrados. Dónde obtenerlo Es un valor estático que se añade durante la extracción para indicar el origen de los datos. Ejemplos Zendesk Support
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la actualización o extracción más reciente de los datos del sistema de origen.
Descripción Este atributo indica cuándo se actualizó por última vez el conjunto de datos desde Zendesk Support. Permite saber qué tan recientes son los datos analizados. Conocer la fecha de la última actualización es fundamental para que analistas y usuarios de negocio sepan si están consultando la información más reciente sobre el proceso. Ayuda a establecer expectativas sobre la actualidad de los datos y es esencial para la generación de informes y el seguimiento. Por qué es importante Indica la actualidad de los datos para que los usuarios sepan qué tan reciente es el análisis del proceso. Dónde obtenerlo Este campo de metadatos se genera y almacena durante la extracción de datos, y registra la marca de tiempo del proceso de extracción. Ejemplos 2023-10-27T02:00:00Z
	¿Se incumplió el SLA? IsSlaBreached	Indicador booleano que señala si el tiempo de resolución de la solicitud de servicio superó el objetivo del SLA.
Descripción Este atributo calculado es un indicador sencillo de verdadero o falso que muestra si una solicitud de servicio no cumplió el tiempo de resolución establecido en su acuerdo de nivel de servicio. Se obtiene al comparar el tiempo real de resolución con el objetivo del SLA. El indicador simplifica el análisis del cumplimiento de los SLA. Es el dato principal del Dashboard «Rendimiento del cumplimiento de los SLA» y del KPI «Tasa de cumplimiento de los SLA», ya que permite agrupar y visualizar rápidamente cuántas solicitudes cumplen los objetivos de servicio y cuántas no. Por qué es importante Muestra de forma clara y binaria el resultado del SLA en cada caso, lo que facilita el seguimiento y la elaboración de informes de cumplimiento. Dónde obtenerlo Se calcula durante la transformación de datos, comparando el tiempo total de resolución con SlaTargetResolutionTime. Ejemplos truefalse
	Agente asignado AssignedAgent	Nombre o ID del agente de atención al cliente asignado a la solicitud de servicio.
Descripción Este atributo identifica al agente responsable de una actividad o de la solicitud de servicio en un momento determinado. Puede cambiar durante el ciclo de vida si se reasigna la solicitud. Analizar los datos por agente asignado es clave para comprender la carga de trabajo, el rendimiento y la eficiencia del personal de atención. Este atributo permite usar el Dashboard 'Carga de trabajo y eficiencia de los agentes' para comparar los tiempos de gestión y el volumen de casos entre agentes, detectar oportunidades de formación y equilibrar la carga de trabajo. Por qué es importante Registra qué agente realizó una acción y permite analizar el rendimiento individual, la distribución de la carga de trabajo y la asignación de recursos. Dónde obtenerlo API Zendesk Tickets, campo `assignee_id`. Los datos del usuario se pueden obtener de la API Users. Ejemplos John SmithJane DoeSupportBot
	Canal de comunicación CommunicationChannel	Canal por el que se envió la solicitud de servicio o se produjo la comunicación.
Descripción Este atributo identifica el medio de comunicación utilizado, como el correo electrónico, un formulario web, el chat o el teléfono. Refleja cómo interactúan los clientes con la mesa de ayuda. Conocer el uso de cada canal es importante para planificar los recursos y mejorar la experiencia del cliente. El Dashboard «Resumen del uso de los canales de comunicación» analiza estos datos para mostrar cuáles son los canales más utilizados y si alguno se relaciona con tiempos de resolución más largos o con distintas rutas del proceso. Esta información puede ayudar a decidir dónde invertir para mejorar el servicio o incorporar automatización. Por qué es importante Muestra cómo interactúan los clientes y los agentes, y permite analizar la eficiencia de cada canal y su efecto en el proceso y la experiencia del cliente. Dónde obtenerlo API de tickets de Zendesk, campo `via.channel`. Ejemplos webcorreo electrónicoAPIchat
	Prioridad Priority	Nivel de prioridad asignado a la solicitud de servicio, por ejemplo, 'Baja', 'Normal', 'Alta' o 'Urgente'.
Descripción La prioridad indica la urgencia de una solicitud de servicio y suele influir en su posición en la cola y en el tiempo objetivo de resolución. Ayuda al personal de atención a centrarse primero en los problemas más críticos. Este atributo es esencial para analizar el rendimiento y los SLA. El Dashboard 'Análisis del tiempo de resolución de solicitudes de servicio' utiliza la prioridad para segmentar los datos y mostrar si las solicitudes de prioridad alta se atienden más rápido que las de prioridad baja, y si los recursos se asignan de acuerdo con las necesidades del negocio. Por qué es importante Indica la urgencia de una solicitud, un dato clave para analizar el cumplimiento de los SLA y garantizar que los problemas críticos se atiendan con rapidez. Dónde obtenerlo API de tickets de Zendesk, campo `priority`. Ejemplos BajaNormalAltaUrgente
	Tiempo objetivo de resolución del SLA SlaTargetResolutionTime	Tiempo previsto para resolver una solicitud de servicio según la política de SLA correspondiente.
Descripción Este atributo define el objetivo del acuerdo de nivel de servicio (SLA) para resolver un ticket. El objetivo suele ser dinámico y depende de factores como la prioridad o el tipo de solicitud, o el plan de servicio del cliente. Es un atributo fundamental para el Dashboard «Rendimiento del cumplimiento de los SLA». Sirve como referencia para medir el tiempo real de resolución. Comparar el rendimiento con este objetivo permite cuantificar la calidad del servicio y comprobar si se cumplen las obligaciones contractuales con los clientes. Por qué es importante Define el compromiso de servicio con el cliente y sirve de referencia para medir el cumplimiento de los plazos y de los SLA. Dónde obtenerlo Se obtiene de las políticas de SLA aplicadas al ticket. Esta información está disponible a través de la API de métricas de tickets de Zendesk. Ejemplos 144002880086400
	Tipo de solicitud de servicio ServiceRequestType	Clasificación de la solicitud de servicio, por ejemplo, 'Pregunta', 'Incidente', 'Problema' o 'Tarea'.
Descripción Este atributo clasifica la solicitud de servicio según su naturaleza. Normalmente, esta clasificación se establece al crear o clasificar la solicitud y ayuda a determinar el flujo de trabajo y la prioridad adecuados. En el análisis, segmentar por tipo de solicitud de servicio es fundamental. Permite comparar los tiempos de resolución, las tasas de escalamiento y los flujos de proceso de distintos tipos de problemas, como se muestra en Dashboards como 'Análisis del tiempo de resolución de solicitudes de servicio' y 'Tasa y causas de escalamiento interno'. Esto ayuda a detectar si ciertos tipos de solicitudes son más problemáticos o difíciles de gestionar. Por qué es importante Clasifica las solicitudes para comparar el rendimiento y analizar distintos tipos de problemas, algo fundamental para aplicar mejoras específicas en los procesos. Dónde obtenerlo API Zendesk Tickets, campo `type`. Ejemplos PreguntaIncidenteProblemaTarea
	¿Se reabrió? IsReopened	Indicador booleano que señala si una solicitud de servicio se volvió a abrir después de marcarse como resuelta.
Descripción Este atributo es un indicador que pasa a ser verdadero si una solicitud de servicio vuelve al estado abierto después de haberse marcado como resuelta o cerrada. Señala que la resolución inicial no fue suficiente. Este indicador es fundamental para hacer un seguimiento del retrabajo y de los casos que no se resuelven en el primer contacto. Permite analizar el Dashboard «Tendencias de solicitudes de servicio reabiertas» y el KPI «Tasa de reapertura de solicitudes de servicio», ya que facilita el recuento y el análisis de los casos que requieren atención adicional, a menudo señal de problemas subyacentes. Por qué es importante Identifica el retrabajo y las resoluciones fallidas, y ayuda a medir la calidad y la eficacia de las soluciones ofrecidas. Dónde obtenerlo Se calcula durante la transformación de datos comprobando si el estado de un ticket cambia de «resuelto» o «cerrado» a «abierto». Ejemplos truefalse
	Calificación de satisfacción SatisfactionRating	Puntuación de satisfacción que el cliente proporciona una vez resuelta la solicitud de servicio.
Descripción Este atributo recoge la retroalimentación del cliente sobre su experiencia con el servicio. Por lo general, se obtiene mediante una encuesta después de resolver el ticket. Las respuestas habituales incluyen «Bueno», «Malo» o una puntuación numérica. Es una medida directa de la percepción del cliente y un indicador clave de resultados. Se utiliza para calcular el KPI «Puntuación de satisfacción del cliente». Analizar las calificaciones de satisfacción junto con datos del proceso, como el tiempo de resolución o el número de interacciones con agentes, puede revelar qué prácticas del proceso ofrecen mejores resultados para los clientes. Por qué es importante Mide directamente la retroalimentación del cliente sobre el servicio recibido y relaciona el rendimiento del proceso con los resultados para el cliente. Dónde obtenerlo API de tickets de Zendesk, campo `satisfaction_rating.score`. Ejemplos buenomaloofrecido
	Categoría de producto o servicio ProductServiceCategory	Producto, servicio o función específicos sobre los que trata la solicitud del cliente.
Descripción Este atributo aporta contexto detallado al clasificar la solicitud de servicio según el producto o el área de servicio correspondiente. A menudo, un agente lo asigna manualmente o se determina automáticamente a partir del contenido de la solicitud. Esta clasificación es fundamental para los Dashboards «Precisión de la categorización de solicitudes» y «Desglose del tiempo de ciclo de investigación». Permite analizar en detalle qué productos generan más solicitudes de soporte, cuáles son más complejos de resolver y si la clasificación inicial coincide con la solución final. Esta información ayuda a mejorar el enrutamiento y la formación de los agentes. Por qué es importante Relaciona las solicitudes con áreas de negocio, productos o servicios concretos, lo que permite centrarse en los problemas y analizar su efecto en el proceso. Dónde obtenerlo Suele ser un campo personalizado del ticket en Zendesk. El nombre exacto depende de la configuración de Zendesk. Ejemplos Aplicación móvilGestión de suscripcionesIntegración de APIHardware
	Código de resolución ResolutionCode	Código o categoría que indica el motivo de la resolución final o del cierre de la solicitud.
Descripción El código de resolución aporta información estructurada sobre el resultado de una solicitud de servicio. Algunos ejemplos son «Resuelto por un agente», «Duplicado», «No requiere ninguna acción» o «Problema conocido». Ofrece más contexto que un simple estado «Cerrado». Este atributo resulta especialmente útil para analizar las causas raíz. En el Dashboard «Tendencias de solicitudes de servicio reabiertas», analizar la tasa de reapertura según el código de resolución puede revelar si algunas soluciones son menos eficaces y hacen que los clientes vuelvan a contactar con el equipo de soporte. Por qué es importante Aporta información sobre el resultado de una solicitud de servicio, fundamental para analizar las causas raíz y entender por qué se vuelven a abrir las solicitudes. Dónde obtenerlo Suele ser un campo personalizado del ticket en Zendesk. El nombre exacto depende de la configuración de Zendesk. Ejemplos Resolución en el primer contactoEscalado al nivel 2En espera del clienteError del producto
	Grupo de agentes AgentGroup	Grupo o equipo de soporte al que se asigna la solicitud de servicio.
Descripción Este atributo identifica al equipo de agentes responsable de la solicitud de servicio. A menudo, las solicitudes se asignan a grupos específicos según sus conocimientos, el área del producto o el idioma. El análisis por grupo de agentes permite conocer el rendimiento de cada equipo, la distribución de la carga de trabajo y los patrones de escalado entre equipos. Ofrece una perspectiva más amplia que el análisis de cada agente y puede ayudar a detectar problemas sistémicos en departamentos o funciones concretos. Por qué es importante Registra qué equipo es responsable y permite analizar el rendimiento de los grupos, los traspasos entre equipos y la asignación de recursos entre distintos niveles o especialidades de soporte. Dónde obtenerlo API de tickets de Zendesk, campo `group_id`. Los detalles de los grupos se pueden consultar en la API de grupos. Ejemplos Soporte de nivel 1Soporte técnicoFacturación
	Hora de fin EndTime	Marca de tiempo que indica cuándo finalizó una actividad o un evento.
Descripción La hora de fin indica cuándo se completó una actividad. En muchas estructuras de registros de eventos, la hora de inicio de la siguiente actividad puede servir como hora de fin de la actividad actual. En actividades basadas en estados, como 'Agente investiga el problema', indica cuándo terminó ese estado. Este atributo es esencial para calcular la duración exacta de las actividades, un componente central del análisis del rendimiento. Ayuda a identificar los pasos que más tiempo consumen y sirve de base para analizar en detalle los cuellos de botella y calcular la eficiencia de los recursos. Por qué es importante Permite calcular la duración de las actividades, algo fundamental para identificar cuellos de botella y medir el rendimiento. Dónde obtenerlo A menudo, se obtiene tomando la hora de inicio del siguiente evento de la secuencia para una solicitud de servicio determinada. Ejemplos 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Número de solicitudes de información InformationRequestCount	Número total de veces que se solicitó información al cliente para una misma solicitud de servicio.
Descripción Esta métrica calculada cuenta cuántas veces se produjo la actividad «Se solicitó información al cliente» en cada solicitud de servicio. Un recuento elevado puede indicar que los agentes no recopilan toda la información necesaria desde el principio. Este atributo se utiliza en el Dashboard «Análisis de solicitudes repetidas de información». El seguimiento de este recuento ayuda a detectar ineficiencias en el proceso y necesidades de formación de los agentes. Reducir las solicitudes de información puede acortar considerablemente los tiempos de resolución y mejorar la experiencia del cliente. Por qué es importante Cuantifica los intercambios de información con el cliente y pone de manifiesto las ineficiencias que alargan los tiempos de resolución y perjudican la experiencia del cliente. Dónde obtenerlo Se calcula contando los eventos cuya ActivityName es «Information Requested From Customer» para cada solicitud de servicio. Ejemplos 013

Obligatorio Recomendado Opcional

Actividades del servicio al cliente

Estos son los pasos e hitos clave del proceso que conviene registrar para descubrir con precisión cómo funciona la atención al cliente.

6 Recomendado 8 Opcional

	Actividad	Descripción
	Información solicitada al cliente	Se produce cuando un agente necesita más información del cliente para continuar y cambia el estado del ticket a 'pending'. Este cambio de estado indica explícitamente que el proceso está a la espera de una respuesta externa.
Por qué es importante Esta actividad pone de manifiesto la dependencia del cliente y pausa los contadores internos del SLA. Si se repite varias veces en un mismo ticket, puede indicar que la recopilación inicial de información fue incompleta y prolongar el tiempo de resolución. Dónde obtenerlo Este es un cambio de estado explícito registrado en la API Ticket Audits de Zendesk. Se captura cuando el campo 'status' cambia a 'pending'. Capturar Identifique los eventos 'Change' en Ticket Audits que establecen el estado del ticket como 'pending'. Tipo de evento explicit
	Solicitud asignada a un agente	Este evento indica que la solicitud de servicio se asignó a un agente específico para su gestión. La asignación puede realizarse automáticamente según las reglas de enrutamiento o manualmente por un líder de equipo o un agente.
Por qué es importante La asignación es un hito clave para la rendición de cuentas y la gestión de la carga de trabajo. Analizar el tiempo hasta la asignación y los patrones de reasignación permite detectar cuellos de botella en la clasificación y distribución de solicitudes. Dónde obtenerlo Este es un evento 'Change' explícito en la API Ticket Audits de Zendesk. Se registra cada vez que se completa o modifica el campo 'assignee_id'. Capturar Realice un seguimiento de los cambios en el campo 'assignee_id' del registro Ticket Audits. Tipo de evento explicit
	Solicitud de servicio cerrada	Esta es la actividad final, que marca el cierre definitivo de la solicitud de servicio. Suele producirse automáticamente cuando transcurre un periodo determinado desde que el ticket se marcó como 'solved', siempre que el cliente no haya respondido.
Por qué es importante Como evento de fin definitivo, completa el ciclo de vida del ticket. El tiempo entre 'solved' y 'closed' representa el periodo durante el cual el ticket puede reabrirse, y el evento 'closed' confirma que se aceptó la resolución. Dónde obtenerlo Este es un cambio de estado explícito registrado en la API Ticket Audits de Zendesk cuando el campo 'status' se establece como 'closed'. Capturar Identifique los eventos 'Change' en Ticket Audits que establecen el estado del ticket como 'closed'. Tipo de evento explicit
	Solicitud de servicio creada	Esta actividad marca el inicio del proceso de atención al cliente, cuando se crea un nuevo ticket en Zendesk desde cualquier canal, como el correo electrónico, un formulario web o el chat. Al crearse, el sistema registra explícitamente el evento con un ID de ticket único y una marca de tiempo.
Por qué es importante Como evento de inicio principal, es esencial para calcular la duración total del caso y analizar el volumen de solicitudes recibidas a lo largo del tiempo. Sirve como referencia para medir indicadores clave de rendimiento, como el tiempo hasta la primera respuesta y el tiempo total de resolución. Dónde obtenerlo Este es un evento explícito registrado en la API Ticket Audits de Zendesk. Corresponde al evento 'Create' de un ticket e indica la marca de tiempo inicial de su creación. Capturar Se obtiene del evento de creación del ticket en el registro Ticket Audits. Tipo de evento explicit
	Solicitud de servicio reabierta	Esta actividad se produce cuando un cliente responde a un ticket con estado 'solved'. Zendesk cambia automáticamente el estado a 'open', lo que indica que el problema no se resolvió por completo.
Por qué es importante Las reaperturas son un indicador clave de que no se resolvió el problema en el primer contacto y de que la calidad de la solución fue deficiente. Analizar la frecuencia y los motivos de las reaperturas ayuda a detectar oportunidades para mejorar la formación del personal de atención y los procedimientos de resolución. Dónde obtenerlo Este es un cambio de estado explícito en la API Ticket Audits, que se registra cuando el campo 'status' cambia de 'solved' a 'open'. Capturar Realice un seguimiento de los eventos 'Change' que cambian el estado de 'solved' a 'open'. Tipo de evento explicit
	Solicitud de servicio resuelta	Un agente marca la solicitud de servicio como 'solved' después de ofrecer una solución al cliente. Es un estado temporal, ya que el cliente puede reabrir el ticket si responde antes de que se cierre definitivamente.
Por qué es importante Este es el hito principal para medir el tiempo de resolución y la eficiencia del agente. Indica el momento en que el agente considera que el trabajo está terminado y permite analizar el retrabajo si se reabre el ticket. Dónde obtenerlo Este es un cambio de estado explícito registrado en la API Ticket Audits de Zendesk cuando el campo 'status' se establece como 'solved'. Capturar Identifique los eventos 'Change' en Ticket Audits que establecen el estado del ticket como 'solved'. Tipo de evento explicit
	Calificación de satisfacción recibida	Este evento se produce cuando el cliente responde a la encuesta de satisfacción con una calificación, como 'Bueno' o 'Malo'. La calificación y cualquier comentario asociado quedan registrados en el ticket.
Por qué es importante La retroalimentación directa de los clientes es muy valiosa para medir la calidad del servicio y su percepción. Analizar estas calificaciones en el contexto del flujo del proceso permite relacionar actividades o agentes concretos con los resultados. Dónde obtenerlo Se captura como un evento 'Change' en la API Ticket Audits cuando el campo 'satisfaction_rating' se completa con la calificación y el comentario del cliente. Capturar Filtre los registros Ticket Audit para encontrar cambios en el campo 'satisfaction_rating'. Tipo de evento explicit
	Cliente respondió	Este evento se activa cuando un cliente responde a un ticket, normalmente cuando está en estado 'pending'. Zendesk cambia automáticamente el estado del ticket de 'pending' a 'open', lo que indica que el agente puede retomar el trabajo.
Por qué es importante Esta actividad marca el fin de un tiempo de espera y permite que el proceso continúe. Analizar cuánto tardan los clientes en responder puede aportar información sobre la claridad de las solicitudes de los agentes. Dónde obtenerlo Este evento corresponde a un nuevo comentario público del usuario final, que activa un cambio de estado explícito de 'pending' a 'open' en la API Ticket Audits. Capturar Realice un seguimiento de los eventos 'Change' que cambian el estado de 'pending' a 'open' o identifique los nuevos comentarios públicos de un usuario final. Tipo de evento explicit
	Encuesta de satisfacción enviada	Indica el momento en que se envía automáticamente al cliente una encuesta de satisfacción (CSAT). Suele ocurrir poco después de que el ticket se marque como resuelto.
Por qué es importante Esta actividad inicia el ciclo de retroalimentación del cliente. Saber cuándo se envían las encuestas y si llegan a enviarse es importante para contextualizar las puntuaciones de satisfacción y medir la eficacia del programa de retroalimentación. Dónde obtenerlo Puede inferirse a partir de un registro de automatización o de una etiqueta específica que se añada al ticket. La sección 'satisfaction_rating' de la API Ticket Audits también registra cuándo se ofreció la encuesta. Capturar Busque etiquetas como 'csat_sent' o utilice la marca de tiempo del momento en que se ofreció la encuesta de satisfacción. Tipo de evento inferred
	Escalamiento interno activado	Representa la transferencia de una solicitud de servicio a otro equipo interno o a un nivel de soporte superior. Normalmente, se infiere cuando cambia el grupo asignado al ticket.
Por qué es importante Registrar las escalaciones es clave para detectar debilidades en los procesos, carencias de conocimientos en el soporte de primera línea y tipos de solicitudes complejas. Una tasa alta de escalaciones puede indicar la necesidad de mejorar la formación o la documentación de procesos. Dónde obtenerlo Se infiere a partir de un evento 'Change' en la API Ticket Audits cuando se modifica el campo 'group_id'. Un cambio de grupo indica una transferencia entre equipos. Capturar Supervise los cambios en el campo 'group_id' del registro Ticket Audits. Tipo de evento inferred
	Incumplimiento del SLA	Esta actividad marca el momento en que una solicitud de servicio incumple un acuerdo de nivel de servicio definido, como el tiempo de primera respuesta o el tiempo de resolución. El evento se calcula comparando las marcas de tiempo de la actividad del ticket con las políticas del SLA.
Por qué es importante Los incumplimientos del SLA afectan directamente a la satisfacción del cliente y al cumplimiento de los contratos. Analizar cuándo y por qué se producen es fundamental para detectar demoras sistémicas, falta de recursos u objetivos de rendimiento poco realistas. Dónde obtenerlo Este dato puede obtenerse de la API Ticket Metrics de Zendesk, que almacena las marcas de tiempo de incumplimiento del SLA ('breached_at'). También puede calcularse comparando las marcas de tiempo de los eventos del ticket con las reglas del SLA definidas. Capturar Utilice la marca de tiempo 'breached_at' de la API Ticket Metrics o calcule el incumplimiento comparando el tiempo de resolución con el tiempo establecido en la política del SLA. Tipo de evento calculated
	Primera confirmación enviada	Representa la primera respuesta automática que se envía al cliente para confirmar que se recibió su solicitud. Normalmente, un activador de Zendesk envía una notificación por correo electrónico con una plantilla justo después de crear el ticket.
Por qué es importante Registrar esta actividad es fundamental para medir la rapidez de la respuesta inicial y gestionar las expectativas del cliente. El tiempo entre la creación de la solicitud y esta confirmación es una métrica clave para la satisfacción del cliente. Dónde obtenerlo Se infiere a partir del primer comentario público del ticket si lo publicó un usuario automatizado o si se registró pocos segundos después de crear el ticket. Puede identificarse mediante el análisis del flujo Ticket Comments. Capturar Identifique el primer comentario público creado por una automatización o un activador inmediatamente después de crear el ticket. Tipo de evento inferred
	Primera respuesta pública de un agente enviada	Esta actividad marca la primera vez que un agente envía un comentario público al cliente, a diferencia de una confirmación automática. Es un indicador clave de la primera intervención del agente en el problema del cliente.
Por qué es importante Este hito es clave para medir el SLA de 'First Reply Time', un indicador fundamental de la rapidez del servicio. Distingue las comunicaciones automáticas del inicio de la investigación y la atención activa por parte de una persona. Dónde obtenerlo Se identifica buscando el primer comentario público en el flujo Ticket Comments cuyo autor sea un agente humano, no un usuario del sistema automatizado. Capturar Revise los comentarios de los tickets, filtre los comentarios públicos de agentes y seleccione el que tenga la marca de tiempo más antigua. Tipo de evento inferred
	Solicitud clasificada y priorizada	Esta actividad se produce cuando un agente o una automatización establece o actualiza campos del ticket, como el tipo, la categoría y la prioridad. Este paso queda registrado como un evento de cambio en el historial del ticket.
Por qué es importante Clasificar y priorizar correctamente es fundamental para asignar las solicitudes y los recursos de forma eficiente. Analizar esta actividad ayuda a evaluar la precisión de la clasificación inicial y su impacto en los tiempos de resolución. Dónde obtenerlo Se registra en la API Ticket Audits de Zendesk como eventos 'Change'. Puede identificarse buscando la primera actualización de campos como 'priority', 'type' o campos personalizados relacionados con la clasificación. Capturar Filtre los registros Ticket Audit para encontrar el primer evento 'Change' en los campos clave de clasificación posterior a la creación. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Abra Zendesk Explore: Inicie sesión en su instancia de Zendesk y abra Explore. Para ello, haga clic en el icono del selector de productos en la barra superior y seleccione Explore.
Cree una consulta: En Explore, haga clic en el icono Queries de la barra lateral izquierda y, luego, en el botón "New query" de la esquina superior derecha.
Seleccione el conjunto de datos: En la ventana "Choose a dataset", seleccione el conjunto de datos Support: Tickets. Incluye los principales atributos de los tickets y las marcas de tiempo clave de los eventos.
Añada métricas: En el generador de consultas, vaya al panel "Metrics" y haga clic en "Add". Seleccione COUNT(Tickets). Esto le permitirá validar el volumen de datos.
Añada atributos a las filas: Vaya al panel "Rows" y haga clic en "Add". Añada los siguientes atributos, que formarán las columnas base de la exportación en formato ancho.
- Ticket ID (es el identificador del caso, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Añada las marcas de tiempo de las actividades a las filas: Añada los siguientes atributos de marca de tiempo al panel "Rows". Cada uno representa una posible actividad. Para algunas actividades, deberá crear un atributo calculado personalizado.
- Ticket created - Timestamp: para Service Request Created e Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: para Request Assigned To Agent.
- First reply time - Timestamp: para First Agent Public Reply Sent.
- Ticket solved - Timestamp: para Service Request Resolved y Satisfaction Survey Sent.
- Ticket reopened - Timestamp: para Service Request Reopened.
- Satisfaction rating received - Timestamp: para Satisfaction Rating Received.
- Ticket closed - Timestamp: para Service Request Closed.
Cree atributos calculados personalizados para otras actividades: Algunas actividades se basan en cambios específicos de campos y requieren atributos personalizados para registrar su marca de tiempo. Vaya al menú Calculations (icono de calculadora) y seleccione "Standard calculated attribute". Cree un atributo para cada una de las siguientes actividades. Deberá identificar los nombres exactos de los campos y valores en su instancia de Zendesk.
- Nombre: Timestamp - Categorized and Prioritized. Fórmula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Después de crearlo, añada este atributo al panel "Rows" y cambie su agregador a MIN.
- Nombre: Timestamp - Info Requested. Fórmula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Añádalo a "Rows" y configure el agregador como MIN.
- Nombre: Timestamp - Customer Responded. Fórmula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Añádalo a "Rows" y configure el agregador como MIN.
- Nombre: Timestamp - Escalated. Fórmula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Añádalo a "Rows" y configure el agregador como MIN.
- Nombre: Timestamp - SLA Breach. Fórmula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Añádalo a "Rows" y configure el agregador como MIN.
Filtre los datos: Vaya al panel "Filters" y haga clic en "Add". Añada un filtro para Ticket created - Date y seleccione un intervalo adecuado, por ejemplo, los últimos 3 a 6 meses, para mantener un volumen de datos manejable.
Ejecute y exporte el informe: Haga clic en "Save" para ejecutar la consulta. Cuando aparezcan los datos en la tabla, haga clic en el botón "Export" y elija el formato que prefiera, como CSV o Excel.
Transforme los datos al formato de Registro de eventos: El archivo exportado tiene un formato "ancho": cada fila corresponde a un ticket y cada columna, a la marca de tiempo de un evento. Para Process Mining, debe transformarlo a un formato "largo". Puede utilizar Microsoft Excel (con la función Anular dinamización de Power Query), Python u otra herramienta de preparación de datos.
- Para cada fila (ticket), cree varias filas nuevas, una por cada columna de marca de tiempo que no esté vacía.
- La tabla final debe incluir columnas como ServiceRequest, ActivityName, StartTime y los demás atributos, que se repetirán para cada actividad de una solicitud de servicio.

Configuración

Conjunto de datos: El conjunto de datos principal que debe utilizar es Support: Tickets. Permite acceder a la mayoría de las propiedades de los tickets y a las marcas de tiempo clave en una sola consulta.
Permisos: Necesita, como mínimo, un rol de Editor o Admin en Zendesk Explore para crear y guardar consultas.
Intervalo de fechas: Es fundamental aplicar un filtro de fechas a Ticket created - Date. Se recomienda un intervalo de 3 a 6 meses para equilibrar el nivel de información y el rendimiento. La exportación de millones de tickets puede ser lenta o fallar.
Filtros de consulta: Considere añadir filtros para propiedades específicas de los tickets, como Ticket brand, Ticket form o Ticket group, para centrar el análisis en un servicio o equipo concreto.
Atributos calculados: Este método depende en gran medida de la creación de atributos calculados estándar para registrar marcas de tiempo de eventos que no son atributos predeterminados, como cambios de estado o escalaciones. Asegúrese de tener permiso para crear estos atributos.

Consulta de ejemplo config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Pasos

Prepare el acceso a la API de Zendesk: Inicie sesión en Zendesk como administrador. Vaya al Centro de administración y, luego, a Apps e integraciones > APIs > Zendesk API. En la pestaña Settings, asegúrese de que Token Access esté habilitado. Haga clic en 'Add API token' para crear un token. Guárdelo en un lugar seguro, ya que no volverá a mostrarse.
Configure el entorno de Python: Asegúrese de tener instalada la versión 3.6 o posterior de Python. Instale la biblioteca requests, necesaria para enviar solicitudes HTTP a la API de Zendesk. Puede instalarla desde la línea de comandos con pip install requests.
Configure el script de Python: Guarde el script de Python proporcionado en un archivo, por ejemplo, extract_zendesk_log.py. Abra el archivo en un editor de texto y sustituya las variables de ejemplo de la parte superior (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y API_TOKEN) por los datos y credenciales de su instancia de Zendesk.
Defina el período de extracción: Busque la variable START_TIMESTAMP en el script. Este valor determina la fecha histórica desde la que se extraerán los datos y debe ser una marca de tiempo Unix. Para un análisis inicial, se recomienda utilizar un valor que corresponda a los últimos 3 a 6 meses.
Ejecute el script: Abra una terminal o un símbolo del sistema, vaya al directorio donde guardó el script y ejecútelo con el comando python extract_zendesk_log.py.
Supervise la ejecución: El script mostrará en la consola el progreso y la cantidad de tickets procesados. El tiempo total dependerá del volumen de datos y de los límites de solicitudes de la API de Zendesk. El script incluye una lógica básica para gestionar las respuestas que indican que se alcanzó un límite.
Obtenga el Registro de eventos: Si la ejecución finaliza correctamente, se creará el archivo zendesk_event_log.csv en el mismo directorio. Contiene el Registro de eventos estructurado y listo para el análisis.
Prepare el archivo para cargarlo: Abra zendesk_event_log.csv y compruebe que se haya generado correctamente. Verifique que las columnas coincidan con los atributos requeridos: ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. El archivo ya está listo para cargarse en la herramienta de Process Mining.

Configuración

Credenciales de la API: El script requiere un subdominio válido de Zendesk, la dirección de correo electrónico de un agente o administrador y un token de API activo. El usuario asociado a las credenciales debe tener permiso para leer tickets, auditorías de tickets, usuarios y métricas de tickets.
Intervalo de fechas: La fecha de inicio de la extracción se controla mediante la variable START_TIMESTAMP del script, que debe ser una marca de tiempo Unix. Se recomienda comenzar con un período más corto, por ejemplo, 3 meses, para validar el resultado y el rendimiento del script antes de extraer un historial más amplio.
API de exportación incremental: Esta solución utiliza la API de exportación incremental de Zendesk. Es el método más eficiente y recomendado para obtener un gran volumen de tickets, ya que está diseñado para exportar datos en bloque y evita los problemas habituales de paginación.
Rendimiento y límites de solicitudes: Zendesk aplica límites de solicitudes a la API que varían según el plan de suscripción. El script incluye una lógica para pausar la ejecución cuando se alcanza un límite, según el encabezado Retry-After que devuelve la API. En instancias muy grandes, la extracción puede tardar varias horas.
Requisitos previos: Este método de extracción requiere un entorno funcional de Python 3.6 o posterior y la biblioteca externa requests. Para generar el token de API necesario, se requiere acceso de administrador a la instancia de Zendesk de destino.

Consulta de ejemplo python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

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

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

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

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Pasos

Confirme que su cuenta de Zendesk Support permita acceder a la API de exportaciones incrementales y que la identidad de integración tenga permiso para leer tickets, eventos de tickets, usuarios, grupos, comentarios, calificaciones de satisfacción y datos de SLA, si esas funciones están habilitadas. Confirme el subdominio de la cuenta y el método de autenticación mediante la configuración aprobada de su organización.
Seleccione una hora de inicio de extracción que cubra el período de análisis requerido. Las exportaciones incrementales de tickets utilizan una marca de tiempo Unix y devuelven los registros creados o actualizados a partir de ese momento. Para cargar todo el historial, utilice [Configure based on your system] como hora de inicio inicial y guarde la hora de finalización devuelta para las siguientes ejecuciones incrementales. Para los análisis habituales, utilice un período de 3 a 6 meses si el historial operativo es suficiente.
Ejecute el script de extracción de Python con el subdominio de Zendesk, las credenciales de autenticación, la marca de tiempo de inicio y los filtros opcionales específicos de su empresa. El script solicita los datos incrementales de tickets, recorre las páginas y almacena los registros sin procesar de los tickets y los detalles de eventos disponibles antes de transformarlos.
Recupere el historial de auditoría o eventos de cada ticket cuando la respuesta de la exportación incremental no incluya suficientes detalles sobre cambios de campos, asignaciones, comentarios o estados. Utilice únicamente los recursos de la API de Zendesk habilitados y autorizados en su cuenta. Cuando estén disponibles, conserve el ID del ticket de origen, el ID de auditoría, el ID del comentario, la marca de tiempo del evento, el actor, el nombre del campo, el valor anterior y el nuevo valor.
Normalice las marcas de tiempo a UTC y convierta las marcas de tiempo Unix o los valores ISO 8601 a un formato de fecha y hora uniforme. Ordene los registros de origen por ServiceRequest, marca de tiempo del evento e identificador del evento de origen. Elimine duplicados mediante el identificador estable más específico disponible, como el ID de auditoría o de comentario.
Cree filas explícitas del Registro de eventos para las 14 actividades requeridas. No espere que ProcessMind infiera actividades a partir de cambios de estado o valores de campos. Genere Service Request Created a partir de la creación del ticket; Initial Acknowledgment Sent a partir de una primera respuesta automática verificada; Request Categorized And Prioritized a partir de cambios de categoría, tipo o prioridad; Request Assigned To Agent a partir de cambios de agente asignado; First Agent Public Reply Sent a partir del primer comentario público válido de un agente; Information Requested From Customer a partir de una transición a pendiente asociada a una solicitud de información; Customer Responded a partir de una respuesta válida del cliente; Internal Escalation Triggered a partir de un cambio del grupo asignado; SLA Breach Occurred a partir de una marca de tiempo de incumplimiento de SLA verificada o de un incumplimiento calculado explícitamente; Service Request Resolved a partir de una transición a resuelto; Service Request Reopened a partir de una transición de resuelto a abierto causada por una respuesta del cliente; Satisfaction Survey Sent a partir de un envío de encuesta verificado; Satisfaction Rating Received a partir de una calificación enviada; y Service Request Closed a partir de una transición a cerrado o de un evento verificado de cierre permanente.
Complete las columnas requeridas ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. Complete las columnas recomendadas AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached cuando el origen proporcione valores fiables. Para los atributos opcionales no disponibles, utilice valores nulos en lugar de inventar datos.
Aplique los filtros específicos de la empresa que se hayan aprobado después de la extracción y antes de la exportación. Conserve los identificadores de origen sin procesar y las marcas de tiempo de origen en una copia interna de preparación para poder auditar y repetir las decisiones sobre los eventos.
Valide el número de filas, la cobertura de actividades, el orden de las marcas de tiempo, la gestión de duplicados y la población de atributos. Confirme que cada fila generada incluya ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate.
Exporte el Registro de eventos transformado como CSV UTF-8 u otro formato tabular compatible con ProcessMind. Asegúrese de que los nombres de las columnas coincidan exactamente con los nombres de atributos requeridos, de que cada fila represente una sola ocurrencia de actividad y de que el archivo se cargue mediante el proceso de importación de ProcessMind configurado.

Configuración

Método de extracción: API de exportaciones incrementales de Zendesk para extraer grandes volúmenes de tickets. El script debe solicitar datos a partir de una marca de tiempo Unix guardada, recorrer las páginas, respetar los límites de solicitudes y guardar la hora de finalización devuelta para la siguiente ejecución.
Autenticación: Configure el método de autenticación de Zendesk aprobado, el subdominio de la cuenta, las credenciales y los permisos de la API de acuerdo con la política de seguridad de su organización. No incluya credenciales directamente en el control de versiones.
Intervalo de fechas: Utilice de 3 a 6 meses para los análisis habituales de procesos. Para la carga inicial, elija una hora de inicio anterior al período del proceso que necesita analizar, ya que pueden producirse actividades durante ese período en tickets creados antes. Para las cargas incrementales, utilice el punto de control de la última extracción correcta con un pequeño margen de solapamiento para cubrir actualizaciones tardías y, luego, elimine duplicados mediante los identificadores de origen.
Filtros: Aplique únicamente filtros compatibles con los recursos de Zendesk disponibles en su cuenta, como los filtros aprobados por organización, grupo, marca, tipo de ticket, estado o campos personalizados. Configure los filtros específicos de la empresa según su sistema. No dé por sentado que Zendesk incluye un código de empresa o un tipo de documento.
Columnas de salida requeridas: ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate.
Columnas de salida recomendadas: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached.
Detalles de los eventos: Es posible que los registros incrementales de tickets no incluyan todas las transiciones históricas. Cuando sea necesario, recupere las auditorías de tickets, los comentarios, los registros de satisfacción y los eventos de SLA autorizados. Genere explícitamente una fila para cada actividad requerida.
Configuración de SLA: Cuando estén disponibles, utilice la política de SLA real y las marcas de tiempo de incumplimiento que devuelve la cuenta. Si calcula el estado de incumplimiento, documente la política, el horario laboral, las pausas y la zona horaria utilizados. Si se aplican reglas de horario laboral, no calcule el incumplimiento basándose únicamente en el tiempo transcurrido según el reloj.
Rendimiento: Procese las páginas de forma incremental, transmita los registros o trabaje por lotes, almacene en caché los detalles de los tickets, limite la concurrencia, respete las respuestas de Zendesk sobre los límites de solicitudes y guarde el progreso después de procesar correctamente cada página. Evite solicitar repetidamente todo el historial.
Retención de datos: Conserve las respuestas sin procesar de la API, los puntos de control de extracción, los metadatos de las solicitudes y los registros de transformación para facilitar la conciliación y las nuevas ejecuciones.
Requisitos previos: Acceso a la API de Zendesk, permiso para leer los recursos pertinentes de tickets y eventos, auditoría de tickets y comentarios habilitados cuando sean necesarios, acceso a los datos de satisfacción si se requieren actividades de CSAT y acceso a los datos de SLA si se requieren actividades de incumplimiento de SLA. La disponibilidad de las funciones depende del plan y la configuración de la cuenta de Zendesk.

Consulta de ejemplo python

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

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        response = session.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_params, timeout=60)
            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
                time.sleep(max(retry_after, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Pasos

Seleccione una plataforma ETL o ELT comercial que ofrezca un conector compatible con Zendesk Support y confirme que pueda replicar los tickets, los eventos o auditorías de tickets, los comentarios, los usuarios, los grupos, las calificaciones de satisfacción, los datos de SLA y los resultados de activadores o automatizaciones disponibles en su cuenta de Zendesk.
Configure una integración de la API de Zendesk con el método de autenticación aprobado por su organización y compatible con el conector elegido. Conceda únicamente los permisos de lectura necesarios para los datos de tickets, auditorías, comentarios, usuarios, grupos, satisfacción y SLA. Guarde la cadena de conexión y las credenciales en el almacén seguro de credenciales de la herramienta.
Configure el conector para replicar los objetos requeridos de Zendesk en el almacén de datos de destino. Utilice los objetos de origen que genere el conector, en lugar de dar por sentados nombres fijos para las tablas o columnas. Si el conector utiliza nombres específicos de la cuenta, registre los nombres reales de los objetos y las correspondencias de campos en la documentación del proyecto como [Your table name] y [Your column name].
Configure la extracción incremental mediante la marca de tiempo de actualización, el cursor o el mecanismo de seguimiento de cambios que admita el sistema de origen. Incluya los datos históricos del período de análisis seleccionado, normalmente de tres a seis meses, y conserve el identificador del evento o de auditoría de origen para eliminar duplicados de las actualizaciones repetidas.
Cree un modelo de preparación normalizado que combine los registros de tickets con el historial de tickets, los registros de auditoría o eventos, los comentarios, los usuarios, los grupos, las calificaciones de satisfacción, los registros de SLA y cualquier registro de activadores o automatizaciones específico del conector. Siempre que estén disponibles, conserve la marca de tiempo original, el identificador del registro de origen, el identificador del ticket, el identificador del actor, el tipo de evento, el nombre del campo, el valor anterior y el nuevo valor.
Cree una transformación de eventos que genere una fila por cada actividad observada explícitamente. Asigne la creación del ticket a Service Request Created; la primera respuesta automática válida a Initial Acknowledgment Sent; los cambios de tipo, categoría o prioridad a Request Categorized And Prioritized; los cambios de agente asignado a Request Assigned To Agent; la primera respuesta pública válida de un agente a First Agent Public Reply Sent; una transición a pendiente asociada a una solicitud de información a Information Requested From Customer; una respuesta del cliente a Customer Responded; los cambios de grupo a Internal Escalation Triggered; un registro observado de incumplimiento de SLA o un evento de incumplimiento a SLA Breach Occurred; las transiciones a resuelto a Service Request Resolved; las transiciones de resuelto a abierto causadas por una respuesta del cliente a Service Request Reopened; el envío observado de una encuesta a Satisfaction Survey Sent; una calificación enviada a Satisfaction Rating Received; y una transición permanente a cerrado a Service Request Closed.
No genere filas inferidas únicamente a partir del estado actual del ticket o del tiempo transcurrido. Si el origen no muestra explícitamente el envío de una encuesta, el incumplimiento de SLA, una confirmación automática o un evento de cierre permanente, omita esa actividad o utilice una fuente de datos independiente y documentada que la registre explícitamente. ProcessMind utiliza el Registro de eventos tal como está y no deduce los eventos que faltan.
Elimine los eventos duplicados mediante el identificador del evento o de auditoría de origen, cuando esté disponible. Si no hay un identificador estable, utilice una clave compuesta documentada que incluya ServiceRequest, ActivityName, StartTime, el actor y el identificador del registro de origen. Conserve las ocurrencias legítimas múltiples de actividades como Customer Responded, Information Requested From Customer, Internal Escalation Triggered y Service Request Reopened.
Complete las columnas de salida requeridas ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. Añada AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached cuando el origen proporcione esos datos. Utilice marcas de tiempo UTC de forma uniforme y conserve la regla de conversión de la zona horaria de origen.
Exporte el Registro de eventos final como un archivo CSV compatible con ProcessMind o cárguelo en la ubicación de ingesta de ProcessMind configurada. Asegúrese de que cada fila represente una sola ocurrencia de actividad, de que ServiceRequest sea el identificador del caso, de que ActivityName contenga las etiquetas exactas de las actividades, de que StartTime sea una marca de tiempo válida y de que todas las filas incluyan los atributos requeridos cuando estén técnicamente disponibles.

Configuración

Alcance del conector y los datos de origen: Configure la herramienta ETL o ELT comercial seleccionada para Zendesk Support y elija los objetos de origen que incluyan tickets, auditorías o eventos de tickets, comentarios, usuarios, grupos, calificaciones de satisfacción, información de SLA y resultados de automatizaciones o activadores. Los nombres de los objetos varían según el conector y la cuenta; utilice el catálogo real del conector, no nombres de tablas supuestos.
Autenticación y autorización: Utilice la opción de autenticación de Zendesk aprobada por su organización. Conceda acceso de lectura a todos los objetos de origen seleccionados, incluidos los eventos históricos de tickets y los datos de satisfacción del cliente. Confirme que estén habilitados el acceso a la API, las funciones necesarias del plan de Zendesk y las licencias del conector que correspondan.
Intervalo de fechas: Comience con un historial de tres a seis meses. Amplíe el intervalo solo después de validar las cuotas de la API, la capacidad del almacén de datos, el volumen de eventos y la disponibilidad de registros históricos de auditoría, SLA y satisfacción.
Carga incremental: Priorice el cursor nativo del conector, el seguimiento de cambios o la marca de tiempo de actualización del sistema de origen. Programe una carga histórica inicial y, después, cargas incrementales frecuentes. Incluya un período retrospectivo para cubrir comentarios, calificaciones, resultados de SLA y actualizaciones de tickets que lleguen con retraso.
Filtros de actividad: Filtre los registros de origen según el período de análisis seleccionado y la instancia de Zendesk Support pertinente. No filtre únicamente por el estado actual del ticket, ya que las actividades históricas pueden corresponder a tickets cuyo estado actual haya cambiado.
Filtros de empresa o cuenta: Si el conector muestra varias instancias de Zendesk, marcas, organizaciones o unidades de negocio, aplique el filtro aprobado para la empresa o la cuenta mediante el campo real del conector. No dé por sentado que existe un campo de código de empresa.
Asignación de eventos: Mantenga una tabla de correspondencias explícita entre el tipo de evento de origen, el nombre del campo, la transición de estado, el tipo de actor y el indicador de automatización, y los 14 valores requeridos de ActivityName. Exija evidencia explícita en los datos de origen para cada fila generada.
Identificación de confirmaciones: Configure la correspondencia para Initial Acknowledgment Sent únicamente cuando el origen identifique una primera respuesta automática o una notificación equivalente generada por un activador. No clasifique la respuesta de un agente como una confirmación automática sin evidencia en los datos de origen.
Gestión de SLA: Utilice los registros explícitos de incumplimiento de SLA o los resultados de SLA que exponga el conector. Guarde la duración objetivo en SlaTargetResolutionTime y el resultado del incumplimiento en IsSlaBreached. No calcule un incumplimiento a partir del tiempo transcurrido, salvo que disponga del calendario de SLA, la política, el horario laboral y el objetivo, y documente el cálculo.
Rendimiento: Limite la carga inicial por fecha, incluya solo las columnas necesarias, utilice la replicación incremental, habilite la partición o agrupación del almacén de datos por ServiceRequest y StartTime cuando sea compatible, y materialice el modelo normalizado de eventos después de ingerir los datos sin procesar. Evite volver a recorrer todo el historial de tickets repetidamente.
Calidad de los datos: Conserve los identificadores y las marcas de tiempo de origen, normalice las marcas de tiempo a UTC, estandarice los valores booleanos y mantenga los valores nulos cuando el origen no proporcione un atributo. No invente datos para completar información faltante sobre agentes, categorías, prioridades, SLA o canales.
Marca de tiempo de actualización: Asigne a LastDataUpdate la marca de tiempo de la ejecución de extracción o transformación completada, utilizando una zona horaria y un formato uniformes en todo el Registro de eventos.

Consulta de ejemplo config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

¿Todo listo para empezar?

Comience hoy a optimizar el servicio al cliente preparando sus datos con esta plantilla. Obtenga información valiosa y mejore la eficiencia de sus operaciones de Zendesk Support.

Volver a la guía de mejora

Descargar Template

Elimine los cuellos de botella en la atención al cliente y mejore el CSAT desde hoy

Evite los contactos repetidos. Alcance un 80 % de resolución en el primer contacto (FCR) y aumente la satisfacción del cliente.

Comience su prueba gratuita

No se requiere tarjeta de crédito

Su Template de datos de servicio al cliente

Su Template de datos de servicio al cliente

Atributos del servicio al cliente

Actividades del servicio al cliente

Guías de extracción

Interfaz de Zendesk Explore para generar informes y exportar datos

Pasos

Configuración

Consulta de ejemplo config

Script de Python con la API REST de Zendesk Support

Pasos

Configuración

Consulta de ejemplo python

API de exportaciones incrementales de Zendesk para datos en bloque

Pasos

Configuración

Consulta de ejemplo python

Conector de una herramienta ETL de terceros para Zendesk

Pasos

Configuración

Consulta de ejemplo config

¿Todo listo para empezar?

Elimine los cuellos de botella en la atención al cliente y mejore el CSAT desde hoy