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

Su Template de datos de atención al cliente

Zendesk Support

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

Su Template de datos de atención al cliente

Esta plantilla le ayuda a recopilar los datos adecuados para analizar su proceso de atención al cliente. Describe los atributos de datos esenciales que debe recopilar, las actividades clave que debe seguir y ofrece orientación práctica sobre cómo extraer esta información. Con esta guía, podrá crear un Registro de eventos sólido para descubrir información útil y mejorar sus operaciones de servicio.

Atributos recomendados para recopilar
Actividades clave que debe seguir en su proceso de atención al cliente
Guía de extracción para Zendesk Support

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

Descargar Template

Atributos de atención al cliente

Estos son los campos de datos recomendados para incluir en su registro de eventos y realizar un análisis exhaustivo de la atención al cliente.

5 Obligatorio 6 Recomendado 7 Opcional

	Nombre	Descripción
	Hora de inicio StartTime	La 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 hora exactas en que ocurrió una actividad específica. Por ejemplo, indica cuándo se añadió un comentario del cliente, cuándo se asignó un agente o cuándo el estado del ticket cambió a «Resolved». Esta marca de tiempo es fundamental para Process Mining, ya que establece el orden cronológico de los eventos. Se utiliza para calcular las duraciones entre actividades, medir los tiempos de ciclo, analizar el rendimiento frente a los SLA y comprender la dinámica temporal del proceso de servicio. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, calcular las 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	El identificador único de cada solicitud de servicio 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 única consulta o problema del cliente, desde su creación hasta la resolución final. 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, de principio a fin, del recorrido del cliente. Es la base para calcular métricas clave, como el tiempo total de resolución, identificar desviaciones del proceso y comprender el ciclo de vida de cada problema del cliente. Por qué es importante Es el Case ID esencial que conecta todos los pasos del proceso y permite reconstruir y analizar el recorrido individual de cada cliente en el servicio. Dónde obtenerlo API Zendesk Tickets, campo `id`. Ejemplos 102451287415332
	Nombre de la actividad ActivityName	El nombre del evento o la tarea específicos que ocurrieron durante el ciclo de vida de la solicitud de servicio.
Descripción El nombre de la actividad describe un paso o hito individual del proceso de servicio al cliente, como «Solicitud de servicio creada», «Solicitud asignada a un agente» o «Solicitud de servicio resuelta». Estos eventos incluyen 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 del proceso y analizar la frecuencia y el orden de los eventos. Permite a los analistas comprender qué acciones se realizan e identificar rutas habituales, cuellos de botella y desviaciones del procedimiento estándar. Por qué es importante Este atributo define los pasos del proceso y permite visualizar el mapa del proceso y analizar los flujos y las variaciones del proceso. Dónde obtenerlo Se deriva de los registros de auditoría de tickets de Zendesk o de flujos de eventos que registran cambios y acciones. Ejemplos Solicitud de servicio creadaSolicitud asignada a un agentePrimera respuesta pública del agente enviadaSolicitud de servicio resuelta
	Sistema de origen SourceSystem	El 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 al combinar datos de varios sistemas. En el análisis, garantiza que los datos se atribuyan correctamente a su origen, algo importante para mantener su integridad y comprender el contexto del proceso, especialmente en entornos con varios sistemas. Por qué es importante Identifica el origen de los datos, un aspecto fundamental para la gobernanza de datos y para distinguir los datos del proceso en entornos integrados. Dónde obtenerlo Es un valor estático que se añade durante la extracción de datos para indicar su origen. Ejemplos Zendesk Support
	Última actualización de datos LastDataUpdate	La marca de tiempo de la actualización o extracción más reciente de datos del sistema de origen.
Descripción Este atributo indica la última vez que el conjunto de datos se actualizó desde Zendesk Support. Proporciona contexto sobre la actualidad de los datos analizados. Conocer la hora de la última actualización es fundamental para que los analistas y usuarios de negocio sepan si están consultando la información más reciente del proceso. Ayuda a gestionar las expectativas sobre la antigüedad de los datos y es esencial para la generación de informes y la supervisión. Por qué es importante Aporta claridad sobre la actualidad de los datos y garantiza que los usuarios comprendan qué tan reciente es el análisis del proceso. Dónde obtenerlo Es un campo de metadatos generado y almacenado durante la extracción de datos que registra la marca de tiempo del trabajo de extracción. Ejemplos 2023-10-27T02:00:00Z
	Agente asignado AssignedAgent	El nombre o ID del agente de servicio al cliente asignado para gestionar la solicitud de servicio.
Descripción Este atributo identifica al agente específico responsable de una actividad o de la solicitud de servicio en un momento determinado. Puede cambiar durante el ciclo de vida si la solicitud se reasigna. Analizar por agente asignado es clave para comprender la carga de trabajo, el rendimiento y la eficiencia de los agentes. Es compatible con el Dashboard «Agent Workload and Efficiency», ya que permite comparar los tiempos de gestión y el volumen de casos entre distintos agentes, identificar oportunidades de capacitación y equilibrar las cargas 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 pueden obtenerse de la API Users. Ejemplos John SmithJane DoeSupportBot
	Canal de comunicación CommunicationChannel	El 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 servicio. Comprender el uso de los canales es importante para planificar los recursos y mejorar la experiencia del cliente. El Dashboard «Communication Channel Usage Overview» analiza estos datos para determinar qué canales son más populares y si algunos se relacionan con tiempos de resolución más largos o con rutas de proceso diferentes. Puede ayudar a decidir dónde invertir en mejoras del servicio o automatización. Por qué es importante Muestra cómo interactúan los clientes y los agentes y permite analizar la eficiencia de los canales y su impacto en el proceso y la experiencia del cliente. Dónde obtenerlo API Zendesk Tickets, campo `via.channel`. Ejemplos webcorreo electrónicoAPIchat
	Prioridad Priority	El nivel de prioridad asignado a la solicitud de servicio, como «Low», «Normal», «High» o «Urgent».
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 a los agentes a centrarse primero en los problemas más críticos. Este atributo es esencial para el análisis del rendimiento y de los SLA. El Dashboard «Service Request Resolution Time Analysis» utiliza la prioridad para segmentar los datos y mostrar si las solicitudes de alta prioridad se gestionan más rápido que las de menor prioridad, así como si los recursos se asignan eficazmente según las necesidades del negocio. Por qué es importante Indica la urgencia de una solicitud, un aspecto fundamental para analizar el cumplimiento de los SLA y garantizar que los problemas críticos se atiendan con rapidez. Dónde obtenerlo API Zendesk Tickets, campo `priority`. Ejemplos BajaNormalAltaUrgente
	Se ha incumplido 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, verdadero o falso, que muestra si una solicitud de servicio no cumplió el Acuerdo de Nivel de Servicio definido para el tiempo de resolución. Se obtiene comparando la duración real de la resolución con el objetivo planificado del SLA. Este indicador simplifica el análisis del cumplimiento del SLA. Es el dato central del Dashboard «Rendimiento del cumplimiento del SLA» y del KPI «Tasa de cumplimiento del SLA», ya que permite agregar y visualizar rápidamente cuántas solicitudes cumplen los objetivos de servicio y cuántas no. Por qué es importante Proporciona un resultado binario claro sobre el rendimiento del SLA en cada caso y simplifica la supervisión y los 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
	Tiempo objetivo de resolución del SLA SlaTargetResolutionTime	La duración objetivo en la que se espera resolver una solicitud de servicio, según su política de SLA.
Descripción Este atributo define el objetivo del Acuerdo de Nivel de Servicio (SLA) para resolver un ticket. A menudo, este objetivo es 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 «SLA Compliance Performance». Sirve como referencia para comparar el tiempo real de resolución. Analizar el rendimiento frente a este objetivo ayuda a cuantificar la calidad de la prestación del servicio y garantizar el cumplimiento de las obligaciones contractuales con los clientes. Por qué es importante Define el compromiso de servicio con el cliente y actúa como referencia para medir el rendimiento dentro del plazo y el cumplimiento del SLA. Dónde obtenerlo Se deriva de las políticas de SLA aplicadas a un ticket. Esta información está disponible mediante la API Zendesk Ticket Metrics. Ejemplos 144002880086400
	Tipo de solicitud de servicio ServiceRequestType	La clasificación de la solicitud de servicio, como «Question», «Incident», «Problem» o «Task».
Descripción Este atributo categoriza la solicitud de servicio según su naturaleza. Normalmente se establece cuando se crea o clasifica la solicitud y ayuda a determinar el Workflow 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 del proceso para distintos tipos de problemas, como se muestra en los Dashboards «Service Request Resolution Time Analysis» e «Internal Escalation Rate & Causes». Esto ayuda a identificar si ciertos tipos de solicitudes son más problemáticos o menos eficientes de gestionar. Por qué es importante Categoriza las solicitudes para comparar y analizar el rendimiento de distintos tipos de problemas, algo fundamental para mejorar el proceso de forma específica. Dónde obtenerlo API Zendesk Tickets, campo `type`. Ejemplos PreguntaIncidenteProblemaTarea
	Categoría de producto o servicio ProductServiceCategory	El producto, servicio o funcionalidad específicos a los que se refiere la solicitud del cliente.
Descripción Este atributo aporta contexto detallado al categorizar la solicitud de servicio según un producto o área de servicio. A menudo lo establece manualmente un agente o se determina automáticamente a partir del contenido de la solicitud. Esta categorización es fundamental para los Dashboards «Request Categorization Accuracy» e «Investigation Cycle Time Breakdown». Permite analizar en profundidad qué productos generan más solicitudes de soporte, cuáles son más complejos de resolver y si la categorización inicial coincide con la solución final, lo que ayuda a mejorar el enrutamiento y la capacitación de los agentes. Por qué es importante Vincula las solicitudes con áreas de negocio, productos o servicios específicos y permite analizar de forma focalizada las áreas problemáticas y su impacto en el proceso. Dónde obtenerlo Normalmente es un campo personalizado del ticket en Zendesk. El nombre exacto del campo depende de la configuración específica de Zendesk. Ejemplos Aplicación móvilGestión de suscripcionesIntegración de APIHardware
	Código de resolución ResolutionCode	Un 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 proporciona información estructurada sobre el resultado de una solicitud de servicio. Algunos ejemplos son «Solved by Agent», «Duplicate», «No Action Needed» o «Known Issue». Ofrece más contexto que un simple estado «Closed». Este atributo es especialmente valioso para el análisis de causas raíz. En el Dashboard «Reopened Service Request Trends», analizar las tasas de reapertura por código de resolución puede revelar si ciertos tipos de soluciones son menos eficaces y hacen que los clientes tengan que volver a contactar con el soporte. Por qué es importante Aporta información sobre el resultado de una solicitud de servicio, algo fundamental para el análisis de causas raíz y para comprender por qué se reabren las solicitudes. Dónde obtenerlo Normalmente es un campo personalizado del ticket en Zendesk. El nombre exacto del campo depende de la configuración específica de Zendesk. Ejemplos Resolución en el primer contactoEscalado al nivel 2A la espera del clienteError del producto
	Grupo de agentes AgentGroup	El grupo o equipo de soporte al que se asigna la solicitud de servicio.
Descripción Este atributo representa al equipo de agentes responsable de la solicitud de servicio. Las solicitudes suelen dirigirse a grupos específicos según las competencias, el área de producto o el idioma. Analizar por grupo de agentes ayuda a comprender el rendimiento de los equipos, la distribución de la carga de trabajo y los patrones de escalamiento entre equipos. Ofrece una visión de nivel superior a la del análisis individual de agentes y puede ayudar a identificar problemas sistémicos en departamentos o funciones concretos. Por qué es importante Registra la responsabilidad del equipo y permite analizar el rendimiento de los grupos, las transferencias entre equipos y la asignación de recursos entre distintos niveles o especialidades de soporte. Dónde obtenerlo API Zendesk Tickets, campo `group_id`. Los datos del grupo pueden obtenerse de la API Groups. Ejemplos Soporte de nivel 1Soporte técnicoFacturación
	Hora de finalización EndTime	La marca de tiempo que indica cuándo se completó una actividad o un evento.
Descripción La hora de finalización representa el momento en que se completa una actividad. En muchas estructuras de registros de eventos, la hora de inicio de la actividad siguiente puede servir como hora de finalización de la actividad actual. En actividades basadas en estados, como «Agent Investigates Issue», 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 consumen más tiempo y proporciona la base para un análisis detallado de los cuellos de botella y de 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 el StartTime del evento posterior 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 las apariciones de la actividad «Información solicitada al cliente» para cada solicitud de servicio. Un número elevado sugiere que los agentes no recopilan toda la información necesaria desde el principio. Este atributo se utiliza en el Dashboard «Análisis de solicitudes de información repetidas». El seguimiento de este recuento ayuda a identificar ineficiencias del proceso y áreas de formación para los agentes. Reducir el número de solicitudes de información puede acortar considerablemente los tiempos de resolución y mejorar la experiencia del cliente. Por qué es importante Cuantifica la comunicación de ida y vuelta con el cliente y pone de relieve las ineficiencias que prolongan los tiempos de resolución y deterioran la experiencia del cliente. Dónde obtenerlo Se calcula contando el número de eventos cuyo ActivityName es «Information Requested From Customer» para cada Service Request. Ejemplos 013
	Se ha reabierto IsReopened	Indicador booleano que señala si una solicitud de servicio se reabrió después de marcarse como resuelta.
Descripción Este atributo es un indicador que pasa a verdadero si una solicitud de servicio vuelve a un 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 realizar un seguimiento del retrabajo y de los fallos de resolución en el primer contacto. Contribuye directamente al Dashboard «Tendencias de solicitudes de servicio reabiertas» y al 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, lo que suele indicar problemas subyacentes más profundos. Por qué es importante Identifica el retrabajo y las resoluciones fallidas, y ayuda a medir la calidad y la eficacia de las soluciones proporcionadas. Dónde obtenerlo Se calcula durante la transformación de datos comprobando si el estado de un ticket cambia de «resolved» o «closed» a «open». Ejemplos truefalse
	Valoración de satisfacción SatisfactionRating	La puntuación de satisfacción proporcionada por el cliente después de resolver la solicitud de servicio.
Descripción Este atributo recoge los comentarios del cliente sobre su experiencia con el servicio, normalmente mediante una encuesta después de resolver el ticket. Las valoraciones 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 percepción del cliente». Analizar las valoraciones de satisfacción junto con datos del proceso, como el tiempo de resolución o el número de interacciones del agente, puede revelar qué comportamientos del proceso conducen a mejores resultados para el cliente. Por qué es importante Mide directamente los comentarios del cliente sobre el servicio prestado y relaciona el rendimiento del proceso con los resultados para el cliente. Dónde obtenerlo Zendesk Tickets API, campo `satisfaction_rating.score`. Ejemplos buenomaloofrecido

Obligatorio Recomendado Opcional

Actividades de atención al cliente

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

6 Recomendado 8 Opcional

	Actividad	Descripción
	Información solicitada al cliente	Ocurre 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á esperando a una persona externa.
Por qué es importante Esta actividad pone de manifiesto las dependencias del cliente y pausa los relojes internos del SLA. Las apariciones frecuentes o repetidas en un mismo ticket pueden indicar que la recopilación inicial de información fue incompleta y provocar tiempos de resolución más largos. Dónde obtenerlo Es un evento explícito de cambio de estado registrado en la API Ticket Audits de Zendesk. Se captura cuando el campo «status» cambia a «pending». Recopilar Identifique los eventos «Change» en Ticket Audits en los que el estado del ticket se establezca 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. Puede ocurrir automáticamente según las reglas de enrutamiento o de forma manual por parte de un líder de equipo o un agente.
Por qué es importante La asignación es un hito fundamental para garantizar la responsabilidad y gestionar la carga de trabajo. Analizar el tiempo hasta la asignación y los patrones de reasignación permite detectar cuellos de botella en el proceso de clasificación y distribución. Dónde obtenerlo Es un evento explícito «Change» en la API Ticket Audits de Zendesk, registrado cada vez que el campo «assignee_id» se completa o cambia. Recopilar 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 y marca el cierre permanente de la solicitud de servicio. Normalmente ocurre de forma automática después de que transcurre un periodo establecido desde que el ticket se marcó como «solved», siempre que el cliente no envíe nuevas respuestas.
Por qué es importante Como evento de finalización definitivo, cierra el ciclo de vida del ticket. El tiempo entre «solved» y «closed» representa el periodo en el que podría reabrirse, y el evento «closed» confirma que se aceptó la resolución. Dónde obtenerlo Es un cambio de estado explícito registrado en la API Ticket Audits de Zendesk cuando el campo «status» se establece como «closed». Recopilar Identifique los eventos «Change» en Ticket Audits en los que el estado del ticket se establezca como «closed». Tipo de evento explicit
	Solicitud de servicio creada	Esta actividad marca el inicio del proceso de servicio al cliente, cuando se genera un nuevo ticket en Zendesk desde cualquier canal, como el correo electrónico, un formulario web o el chat. El sistema registra explícitamente este evento con un ID de ticket único y una marca de tiempo en el momento de su creación.
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 entrantes 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 capturado en la API Ticket Audits de Zendesk. Corresponde al evento «Create» de un ticket y proporciona la marca de tiempo inicial de creación. Recopilar Capturado a partir del evento de creación del ticket en el registro Ticket Audits. Tipo de evento explicit
	Solicitud de servicio reabierta	Esta actividad ocurre si un cliente responde a un ticket que tiene el 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 fundamental de fallos en la resolución en el primer contacto y de una calidad deficiente de las soluciones. Analizar la frecuencia y los motivos de los tickets reabiertos ayuda a identificar áreas de mejora en la capacitación de los agentes y los procedimientos de resolución. Dónde obtenerlo Es un cambio de estado explícito en la API Ticket Audits, capturado cuando «status» pasa de «solved» a «open». Recopilar Realice un seguimiento de los eventos «Change» de 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 proporcionar una solución al cliente. Es un estado temporal, ya que el cliente puede reabrir el ticket al responder antes de que se cierre de forma permanente.
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 ha terminado y proporciona una base para analizar el retrabajo si el ticket se reabre. Dónde obtenerlo Es un cambio de estado explícito registrado en la API Ticket Audits de Zendesk cuando el campo «status» se establece como «solved». Recopilar Identifique los eventos «Change» en Ticket Audits en los que el estado del ticket se establezca como «solved». Tipo de evento explicit
	Confirmación inicial enviada	Representa la primera respuesta automatizada enviada al cliente para confirmar que su solicitud se recibió. Normalmente, un trigger de Zendesk gestiona esta acción y envía una notificación por correo electrónico basada en una plantilla inmediatamente después de crear el ticket.
Por qué es importante El seguimiento de esta actividad es fundamental para medir la capacidad de respuesta inicial y gestionar las expectativas de los clientes. 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 su autor es un usuario automatizado o si se produce pocos segundos después de crear el ticket. Puede identificarse mediante el análisis del flujo Ticket Comments. Recopilar Identifique el primer comentario público creado por una automatización o un trigger inmediatamente después de crear el ticket. Tipo de evento inferred
	El cliente respondió	Este evento se activa cuando un cliente responde a un ticket, normalmente uno que estaba en estado «pending». Zendesk cambia automáticamente el estado del ticket de «pending» a «open», lo que indica que el agente puede reanudar el trabajo.
Por qué es importante Esta actividad marca el final del 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. Recopilar Realice un seguimiento de los eventos «Change» de 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	Representa el momento en que se envía automáticamente al cliente una encuesta de satisfacción (CSAT). Normalmente ocurre poco después de que el ticket se marque como «solved».
Por qué es importante Esta actividad inicia el ciclo de comentarios del cliente. Comprender cuándo se envían las encuestas y si se envían es importante para contextualizar las puntuaciones de satisfacción y medir la eficacia del programa de comentarios. Dónde obtenerlo Puede inferirse a partir de un registro de automatización o de la adición de una etiqueta específica al ticket. La sección «satisfaction_rating» de la API Ticket Audits también registra cuándo se ofreció la encuesta. Recopilar Busque etiquetas como «csat_sent» o utilice la marca de tiempo del momento en que se ofreció la valoración 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 superior de soporte. Normalmente se infiere cuando cambia el grupo asignado al ticket.
Por qué es importante El seguimiento de los escalamientos es clave para identificar debilidades del proceso, carencias de conocimiento en el soporte de primera línea y tipos de solicitudes complejas. Una tasa elevada de escalamientos puede indicar la necesidad de mejorar la capacitación o la documentación del proceso. 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. Recopilar Supervise los cambios en el campo «group_id» del registro Ticket Audits. Tipo de evento inferred
	Primera respuesta pública del agente enviada	Esta actividad marca la primera ocasión en que un agente envía un comentario público al cliente, a diferencia de una confirmación automatizada. Es un indicador fundamental de la primera interacción del agente con el problema del cliente.
Por qué es importante Este es un hito clave para medir el SLA de «First Reply Time», un indicador fundamental de la capacidad de respuesta del servicio. Distingue la comunicación automatizada del inicio de la investigación y la asistencia activa a cargo 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. Recopilar Revise los comentarios del ticket, filtre los comentarios públicos de los agentes y seleccione el que tenga la marca de tiempo más antigua. Tipo de evento inferred
	Se produjo un incumplimiento del SLA	Esta actividad marca el momento en que una solicitud de servicio no cumple un Acuerdo de Nivel de Servicio predefinido, 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 de SLA.
Por qué es importante Los incumplimientos del SLA afectan directamente la satisfacción del cliente y el cumplimiento contractual. Analizar cuándo y por qué ocurren es fundamental para identificar retrasos sistémicos, falta de recursos u objetivos de rendimiento poco realistas. Dónde obtenerlo Puede obtenerse de la API Ticket Metrics de Zendesk, que almacena las marcas de tiempo de incumplimiento del SLA («breached_at»). Como alternativa, puede calcularse comparando las marcas de tiempo de los eventos del ticket con las reglas de SLA definidas. Recopilar Utilice la marca de tiempo «breached_at» de la API Ticket Metrics o calcúlela comparando el tiempo de resolución con el tiempo establecido en la política de SLA. Tipo de evento calculated
	Solicitud categorizada y priorizada	Esta actividad ocurre cuando un agente o una automatización establece o actualiza campos del ticket, como el tipo, la categoría y la prioridad. Este paso se registra como un evento de cambio en el historial del ticket.
Por qué es importante Una categorización y priorización adecuadas son fundamentales para dirigir las solicitudes y asignar los recursos de forma eficiente. Analizar esta actividad ayuda a determinar la precisión de la clasificación inicial y su impacto en los tiempos de resolución. Dónde obtenerlo Se captura 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 categorización. Recopilar Filtre los registros Ticket Audit para encontrar el primer evento «Change» en los campos clave de categorización después de la creación. Tipo de evento explicit
	Valoración de satisfacción recibida	Este evento ocurre cuando el cliente envía su respuesta a la encuesta de satisfacción, con una valoración como «Good» o «Bad». La valoración y cualquier comentario asociado se registran en el ticket.
Por qué es importante Los comentarios directos de los clientes son invaluables para medir la calidad del servicio y su percepción. Analizar estas valoraciones en el contexto del flujo del proceso ayuda a relacionar actividades o agentes específicos 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 puntuación y el comentario del cliente. Recopilar Filtre los registros Ticket Audit para encontrar cambios en el campo «satisfaction_rating». Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Vaya a Zendesk Explore: Inicie sesión en su instancia de Zendesk y abra el producto Explore. Para ello, haga clic en el icono del selector de productos de la barra superior y seleccione Explore.
Cree una consulta nueva: En Explore, haga clic en el icono Queries de la barra lateral izquierda y, a continuación, 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. Este conjunto contiene los atributos principales de los tickets y las marcas de tiempo de los eventos clave.
Añada métricas: En el generador de consultas, vaya al panel "Metrics" y haga clic en "Add". Seleccione COUNT(Tickets). Esto ayuda a 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. Estas serán las columnas base de la exportación en formato ancho.
- Ticket ID (este 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 crear atributos personalizados para capturar su marca de tiempo. Vaya al menú Calculations, representado por el icono de calculadora, y seleccione "Standard calculated attribute". Cree un atributo para cada una de las siguientes actividades. Deberá buscar 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 nuevo 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 establezca el agregador en 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 establezca el agregador en MIN.
- Nombre: Timestamp - Escalated. Fórmula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Añádalo a "Rows" y establezca el agregador en MIN.
- Nombre: Timestamp - SLA Breach. Fórmula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Añádalo a "Rows" y establezca el agregador en 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 de fechas adecuado, como los últimos 3 a 6 meses, para mantener un conjunto de datos manejable.
Ejecute y exporte el informe: Haga clic en "Save" para ejecutar la consulta. Cuando la tabla muestre los datos, 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 está en formato "ancho", donde cada fila representa un ticket y cada columna, la marca de tiempo de un evento. Debe transformarlo a un formato "largo" para Process Mining. Utilice una herramienta como Microsoft Excel, con la función Unpivot de Power Query, Python u otra herramienta de preparación de datos.
- Para cada fila, es decir, cada 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 duplicarán para cada actividad de una determinada solicitud de servicio.

Configuración

Conjunto de datos: El conjunto 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 al menos el rol de Editor o Administrador en Zendesk Explore para crear y guardar consultas.
Intervalo de fechas: Es fundamental establecer un filtro de intervalo de fechas en Ticket created - Date. Se recomienda utilizar entre 3 y 6 meses de datos para equilibrar la información obtenida y el rendimiento. Exportar millones de tickets puede ser lento 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 capturar las marcas de tiempo de eventos que no son atributos predeterminados, como cambios de estado o escalamientos. Asegúrese de tener permisos para crear estos atributos.

a 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, después, 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 nuevo. Copie el token generado y guárdelo de forma segura, 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 realizar 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 actualice las variables de marcador de posición de la parte superior: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y API_TOKEN, con los datos y las credenciales específicos de su instancia de Zendesk.
Defina el periodo de extracción: Busque la variable START_TIMESTAMP en el script. Este valor determina la fecha histórica inicial para la extracción de datos. Debe ser una marca de tiempo Unix. Para un análisis inicial, se recomienda utilizar un valor correspondiente a los últimos 3 a 6 meses.
Ejecute el script: Abra un terminal o 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 imprimirá actualizaciones de progreso en la consola e indicará el número de tickets procesados. El tiempo total de ejecución dependerá del volumen de datos extraídos y de los límites de frecuencia que aplique Zendesk a la API. El script incluye una lógica básica para gestionar las respuestas de límite de frecuencia.
Obtenga el Registro de eventos: Cuando finalice correctamente, el script creará un archivo llamado zendesk_event_log.csv en el mismo directorio. Este archivo contiene el Registro de eventos estructurado, listo para el análisis.
Prepárese para la carga: Abra el archivo zendesk_event_log.csv para comprobar que se ha generado correctamente. Verifique que las columnas coincidan con los atributos requeridos: ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. El archivo ya está listo para cargarlo en la herramienta de Process Mining.

Configuración

Credenciales de la API: El script requiere un subdominio de Zendesk válido, 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 permisos para leer tickets, auditorías de tickets, usuarios y métricas de tickets.
Intervalo de fechas: La fecha inicial 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 periodo más corto, como 3 meses, para validar el resultado y el rendimiento del script antes de intentar una extracción histórica más amplia.
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 número de tickets, ya que está diseñada para la exportación masiva de datos y evita problemas habituales de paginación.
Rendimiento y límites de frecuencia: Zendesk aplica límites de frecuencia de la API que varían según el plan de suscripción. El script incluye una lógica integrada 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. Es necesario disponer de acceso de administrador a la instancia de Zendesk de destino para generar el token de API requerido.

a 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 permite acceder a la API de exportaciones incrementales y que la identidad de integración tiene permiso para leer tickets, eventos de tickets, usuarios, grupos, comentarios, valoraciones de satisfacción y datos de SLA cuando esas funciones estén habilitadas. Confirme el subdominio de la cuenta y el método de autenticación mediante la configuración aprobada por su organización.
Seleccione una hora de inicio de extracción que cubra el periodo de análisis requerido. Las exportaciones incrementales de tickets utilizan una marca de tiempo Unix y devuelven los registros creados o actualizados desde ese momento. Para una carga histórica completa, utilice [Configure based on your system] como hora de inicio inicial y conserve la hora de finalización devuelta para las ejecuciones incrementales posteriores. Para el análisis habitual, utilice un intervalo de 3 a 6 meses cuando el historial operativo disponible sea suficiente.
Ejecute el script de extracción de Python con el subdominio de Zendesk, las credenciales de autenticación, la marca de tiempo inicial y los filtros opcionales específicos de su empresa configurados. El script solicita datos incrementales de tickets, sigue la paginación y almacena los registros sin procesar de los tickets y los detalles de eventos disponibles antes de la transformación.
Recupere el historial de auditoría o de eventos de cada ticket cuando la respuesta incremental del ticket no contenga suficiente información sobre cambios de campos, asignaciones, comentarios o estados. Utilice únicamente los recursos de la API de Zendesk habilitados y autorizados en su cuenta. 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 valor nuevo cuando se devuelvan.
Normalice las marcas de tiempo a UTC y convierta las marcas de tiempo Unix o los valores ISO 8601 a una representación de fecha y hora coherente. Ordene los registros de origen por ServiceRequest, marca de tiempo del evento e identificador del evento de origen. Elimine duplicados utilizando el identificador de origen estable más específico disponible, como un identificador de auditoría o 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 persona asignada; First Agent Public Reply Sent a partir del primer comentario público válido del 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 de grupo asignado; SLA Breach Occurred a partir de una marca de tiempo de incumplimiento del 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 evento verificado de envío de encuesta; Satisfaction Rating Received a partir de una valoración enviada; y Service Request Closed a partir de una transición a cerrado o de un evento verificado de cierre permanente.
Rellene las columnas obligatorias ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. Rellene las columnas recomendadas AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached cuando el origen proporcione valores fiables. Utilice valores nulos para los atributos opcionales no disponibles en lugar de inventar valores.
Aplique los filtros específicos de la empresa que hayan sido aprobados después de la extracción y antes de la exportación. Conserve los identificadores y las marcas de tiempo del 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 tenga 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, conserve una aparición de actividad por fila y cargue el archivo mediante el proceso de importación configurado de ProcessMind.

Configuración

Método de extracción: API de exportaciones incrementales de Zendesk para extraer tickets en grandes volúmenes. El script debe solicitar datos desde una marca de tiempo Unix inicial persistida, seguir la paginación, respetar los límites de frecuencia y conservar la marca de tiempo final 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 las credenciales directamente en el control de versiones.
Intervalo de fechas: Utilice entre 3 y 6 meses para el análisis habitual del proceso. Para la carga inicial, seleccione una hora de inicio anterior al periodo de proceso requerido, ya que las actividades de tickets creados antes pueden producirse durante la ventana de análisis. Para las cargas incrementales, utilice el punto de control de la extracción correcta anterior con un pequeño solapamiento para protegerse frente a actualizaciones tardías y, después, elimine duplicados mediante los identificadores de origen.
Filtros: Aplique únicamente filtros compatibles con los recursos de Zendesk disponibles en su cuenta, como filtros aprobados por organización, grupo, marca, tipo de ticket, estado o campos personalizados. Los filtros específicos de la empresa deben configurarse según su sistema. No dé por hecho que Zendesk contiene un código de empresa o un tipo de documento.
Columnas de salida obligatorias: ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate.
Columnas de salida recomendadas: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached.
Detalle de los eventos: Los registros incrementales de tickets por sí solos pueden no mostrar todas las transiciones históricas. Recupere las auditorías de tickets, los comentarios, los registros de satisfacción y los eventos de SLA autorizados según sea necesario. Genere cada actividad requerida explícitamente como una fila.
Configuración del SLA: Utilice la política de SLA real y las marcas de tiempo de incumplimiento devueltas por la cuenta cuando estén disponibles. Si calcula el estado de incumplimiento, documente la política, el horario laboral, las pausas y la zona horaria utilizados. No calcule un incumplimiento únicamente a partir del tiempo transcurrido del reloj cuando se apliquen reglas de horario laboral.
Rendimiento: Procese las páginas de forma incremental, transmita o agrupe los registros, almacene en caché los detalles de los tickets, utilice concurrencia limitada, respete las respuestas de límite de frecuencia de Zendesk y guarde puntos de control después de procesar correctamente cada página. Evite solicitar repetidamente todo el historial.
Conservació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 conciliaciones y nuevas ejecuciones.
Requisitos previos: Acceso a la API de Zendesk, permisos para leer los recursos relevantes 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 del SLA. La disponibilidad de las funciones depende del plan de Zendesk y de la configuración de la cuenta.

a 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 el conector puede replicar los tickets, eventos o auditorías de tickets, comentarios, usuarios, grupos, valoraciones de satisfacción, datos de SLA y resultados de activadores o automatizaciones disponibles en su cuenta de Zendesk.
Cree una integración de API de Zendesk mediante el método de autenticación compatible con su organización y con el conector seleccionado. Conceda únicamente los permisos de lectura necesarios para los datos de tickets, auditorías, comentarios, usuarios, grupos, satisfacción y SLA. Almacene 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 de Zendesk necesarios en el almacén de datos de destino. Utilice los objetos de origen generados por el conector en lugar de asumir nombres fijos de tablas o columnas. Registre las correspondencias reales entre objetos y campos en la documentación del proyecto como [Your table name] y [Your column name] cuando el conector utilice nombres específicos de la cuenta.
Configure la extracción incremental mediante la marca de tiempo de actualización, el cursor o el mecanismo de seguimiento de cambios compatible con el sistema de origen. Incluya los datos históricos del periodo de análisis seleccionado, normalmente de tres a seis meses, y conserve el identificador del evento o auditoría de origen para poder eliminar duplicados en 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 valoraciones de satisfacción, los registros de SLA y cualquier registro de activadores o automatizaciones específico del conector. Conserve, siempre que estén disponibles, la marca de tiempo original de origen, 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 valor nuevo.
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 automatizada que cumpla los criterios, a Initial Acknowledgment Sent; los cambios de tipo, categoría o prioridad, a Request Categorized And Prioritized; los cambios de responsable, a Request Assigned To Agent; la primera respuesta pública del agente que cumpla los criterios, 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 o evento observado de incumplimiento de SLA, 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 valoración enviada, a Satisfaction Rating Received; y una transición permanente a cerrado, a Service Request Closed.
No cree filas inferidas únicamente a partir del estado actual del ticket o del tiempo transcurrido. Si el origen no expone explícitamente un envío de encuesta, un incumplimiento de SLA, un acuse automatizado o un cierre permanente, deje esa actividad ausente o utilice una fuente independiente documentada que la registre de forma explícita. ProcessMind lee el registro de eventos tal como está y no deriva eventos faltantes.
Elimine los duplicados utilizando el identificador del evento o auditoría de origen cuando esté disponible. Si no existe un identificador estable, utilice una clave compuesta documentada que contenga ServiceRequest, ActivityName, StartTime, actor y el identificador del registro de origen. Conserve las apariciones 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 obligatorias ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. Añada AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached cuando el origen las proporcione. Utilice un estándar coherente de marcas de tiempo UTC y conserve la regla de conversión de la zona horaria de origen.
Exporte el registro de eventos final como un CSV compatible con ProcessMind o cárguelo en la ubicación de ingesta configurada de ProcessMind. Asegúrese de que cada aparición de una actividad esté representada por una fila, que ServiceRequest sea el identificador del caso, que ActivityName contenga las etiquetas exactas de las actividades, que StartTime sea una marca de tiempo válida y que los atributos obligatorios estén presentes en cada fila de salida cuando sea técnicamente posible.

Configuración

Alcance del conector y del origen: Configure la herramienta ETL o ELT comercial seleccionada para Zendesk Support y elija los objetos de origen que expongan tickets, auditorías o eventos de tickets, comentarios, usuarios, grupos, valoraciones 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, por lo que debe utilizar el catálogo real del conector en lugar de 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 el acceso a la API, las funciones necesarias del plan de Zendesk y cualquier licencia del conector estén habilitados.
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 origen. Programe una carga histórica inicial seguida de cargas incrementales frecuentes. Incluya una ventana de revisión para comentarios, valoraciones, resultados de SLA y actualizaciones de tickets que lleguen con retraso.
Filtros de actividad: Filtre los registros de origen según el periodo de análisis seleccionado y la instancia de Zendesk Support correspondiente. No filtre únicamente por el estado actual del ticket, ya que las actividades históricas pueden pertenecer a tickets cuyo estado actual haya cambiado.
Filtros de empresa o cuenta: Si el conector expone varias instancias, marcas, organizaciones o unidades de negocio de Zendesk, aplique el filtro de empresa o cuenta aprobado utilizando el campo real del conector. No dé por supuesto que existe un campo Company Code.
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 obligatorios de ActivityName. Exija evidencia explícita del origen para cada fila generada.
Identificación del acuse: Configure la correspondencia con Initial Acknowledgment Sent únicamente cuando el origen identifique una primera respuesta automatizada o una notificación equivalente generada por un activador. No clasifique la respuesta de un agente como acuse automatizado sin evidencia del origen.
Gestión de SLA: Utilice registros explícitos de incumplimiento de SLA o resultados de SLA expuestos por el conector. Almacene la duración objetivo en SlaTargetResolutionTime y el resultado del incumplimiento en IsSlaBreached. No calcule un incumplimiento a partir del tiempo transcurrido, salvo que estén disponibles el calendario del SLA, la política, el horario laboral y el objetivo, y que el cálculo esté documentado.
Rendimiento: Limite la carga inicial por fecha, proyecte únicamente 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 de eventos normalizado después de la ingesta de datos sin procesar. Evite analizar repetidamente todo el historial de tickets.
Calidad de 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 sustituya los datos faltantes de agente, categoría, prioridad, SLA o canal por valores inventados.
Marca de tiempo de actualización: Establezca LastDataUpdate con la marca de tiempo de la ejecución de extracción o transformación completada, utilizando una única zona horaria y un formato coherente en todo el registro de eventos.

a 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;

¿Listo para empezar?

Empiece hoy mismo a optimizar su servicio de atención al cliente preparando sus datos con esta plantilla. Descubra información valiosa e impulse la eficiencia de sus operaciones en Zendesk Support.

Volver a la guía de mejora Descargar Template

Elimine los cuellos de botella de la atención al cliente y aumente el CSAT ahora

Evite los contactos repetidos. Alcance un 80 % de FCR y eleve la satisfacción del cliente.

Iniciar la prueba gratuita

No se requiere tarjeta de crédito

Su Template de datos de atención al cliente

Su Template de datos de atención al cliente

Atributos de atención al cliente

Actividades de atención al cliente

Guías de extracción

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

Pasos

Configuración

a Consulta de ejemplo config

Script de Python mediante la API REST de Zendesk Support

Pasos

Configuración

a Consulta de ejemplo python

API de exportaciones incrementales de Zendesk para datos masivos

Pasos

Configuración

a Consulta de ejemplo python

Conector de una herramienta ETL de terceros para Zendesk

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para empezar?

Elimine los cuellos de botella de la atención al cliente y aumente el CSAT ahora

Su Template de datos de atención al cliente

Su Template de datos de atención al cliente

Atributos de atención al cliente

Actividades de atención al cliente

Guías de extracción

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

Pasos

Configuración

a Consulta de ejemplo config

Script de Python mediante la API REST de Zendesk Support

Pasos

Configuración

a Consulta de ejemplo python

API de exportaciones incrementales de Zendesk para datos masivos

Pasos

Configuración

a Consulta de ejemplo python

Conector de una herramienta ETL de terceros para Zendesk

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para empezar?

Elimine los cuellos de botella de la atención al cliente y aumente el CSAT ahora

Valoramos su privacidad