> Mejora Continua de Procesos > Servicio al Cliente > Zendesk Support > Plantilla de Datos

Su Plantilla de Datos de Servicio al Cliente

Zendesk Support

Atributos de Servicio al Cliente (19) Actividades de Servicio al Cliente (14) Guías de Extracción (4)

Su Plantilla de Datos de Servicio al Cliente

Esta plantilla le ayuda a recopilar los datos adecuados para analizar su proceso de servicio al cliente. Describe los atributos de datos esenciales a recolectar, las actividades clave a seguir y proporciona orientación práctica sobre cómo extraer esta información. Usando esta guía, puede construir un registro de eventos robusto para descubrir insights y mejorar sus operaciones de servicio.

Atributos recomendados para recopilar
Actividades clave a rastrear para su proceso de servicio al cliente
Guía de extracción para Zendesk Support

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de Servicio al Cliente

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis integral del servicio al cliente.

5 Requerido 7 Recomendado 7 Opcional

	Nombre	Descripción
	Hora de Inicio StartTime	El timestamp 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, captura cuándo se añadió un comentario de cliente, cuándo se asignó un agente o cuándo el estado del ticket cambió a 'Resuelto'. Esta marca de tiempo es fundamental para el 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 eventos, calcular duraciones y analizar la línea de tiempo del proceso de solicitud de servicio. Dónde obtener API de Auditorías de Tickets de Zendesk, campo `created_at` para cada evento en el rastro de auditoría. Ejemplos 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Solicitud de Servicio ServiceRequest	El identificador único para cada solicitud de servicio al cliente, también conocido como ticket o caso.
Descripción La Solicitud de Servicio es el identificador de caso principal 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á vinculada a este ID único. En el process mining, analizar los eventos agrupados por la Solicitud de Servicio permite una vista completa de extremo a extremo del recorrido del servicio al 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 Este es el ID de Caso esencial que conecta todos los pasos del proceso, permitiendo la reconstrucción y el análisis de cada recorrido individual de servicio al cliente. Dónde obtener API de Tickets de Zendesk, campo `id`. Ejemplos 102451287415332
	Nombre de la Actividad ActivityName	El nombre del evento o tarea específica que ocurrió dentro del ciclo de vida de la solicitud de servicio.
Descripción El Nombre de la Actividad describe un solo paso o hito en el proceso de servicio al cliente, como 'Solicitud de Servicio Creada', 'Solicitud Asignada al Agente' o 'Solicitud de Servicio Resuelta'. Estos eventos tienen una marca de tiempo y forman la secuencia de acciones para cada solicitud de servicio. Este atributo es crítico para visualizar el flujo del proceso, descubrir variantes de proceso y analizar la frecuencia y el orden de los eventos. Permite a los analistas comprender qué acciones se están realizando e identificar rutas comunes, cuellos de botella y desviaciones del procedimiento estándar. Por qué es importante Este atributo define los pasos del proceso, permitiendo la visualización del mapa de proceso y el análisis de los flujos y variaciones del proceso. Dónde obtener Derivado de los registros de auditoría de tickets de Zendesk o de los flujos de eventos que registran cambios y acciones. Ejemplos Solicitud de Servicio CreadaSolicitud Asignada al AgentePrimera Respuesta Pública del Agente EnviadaSolicitud de Servicio Resuelta
	Source System SourceSystem	El sistema de registro del que se extrajeron los `datos`.
Descripción Este atributo especifica el sistema de origen de los datos de la solicitud de servicio, que en este caso es Zendesk Support. Ayuda en la gobernanza y el linaje de los datos, especialmente al combinar datos de múltiples sistemas. En el análisis, asegura que los datos se atribuyan correctamente a su fuente, lo cual es importante para mantener la integridad de los datos y comprender el contexto del proceso, particularmente en entornos multisistema. Por qué es importante Identifica el origen de los datos, lo cual es crucial para la gobernanza de datos y para distinguir los datos de proceso en entornos integrados. Dónde obtener Este es un valor estático añadido durante el proceso de extracción de datos para etiquetar el origen de los datos. Ejemplos Zendesk Support
	Última actualización de datos LastDataUpdate	El timestamp de la actualización de datos o extracción más reciente 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 que se analizan. Conocer la última hora de actualización es crucial para que los analistas y usuarios de negocio entiendan si están viendo la información de proceso más actual. Ayuda a gestionar las expectativas sobre la recencia de los datos y es vital para fines de informes y monitoreo. Por qué es importante Aporta claridad sobre la actualidad de los datos, asegurando que los usuarios entiendan cuán reciente es el análisis del proceso. Dónde obtener Este es un campo de metadatos generado y almacenado durante el proceso de extracción de datos, que registra la marca de tiempo del trabajo de extracción. Ejemplos 2023-10-27T02:00:00Z
	¿Se incumplió el SLA? IsSlaBreached	Un indicador booleano que señala si el tiempo de resolución de la solicitud de servicio excedió su objetivo de SLA.
Descripción Este atributo calculado es un simple indicador verdadero o falso que muestra si una solicitud de servicio no cumplió con su Acuerdo de Nivel de Servicio definido para el tiempo de resolución. Se deriva comparando la duración de resolución real con el objetivo de SLA planificado. Este indicador simplifica el análisis de cumplimiento de SLA. Es el punto de datos central para el dashboard 'Rendimiento de cumplimiento de SLA' y el KPI 'Tasa de cumplimiento de SLA', permitiendo una agregación y visualización rápidas de cuántas solicitudes cumplen los objetivos de servicio frente a cuántas no. Por qué es importante Proporciona un resultado binario y claro para el rendimiento del SLA en cada caso, simplificando la monitorización del cumplimiento y la elaboración de informes. Dónde obtener Calculado durante la transformación de datos al comparar el tiempo total de resolución con el SlaTargetResolutionTime. Ejemplos truefalse
	`Tiempo de resolución` ServiceRequestResolutionTime	El tiempo total transcurrido desde que se creó una solicitud de servicio hasta que se resolvió finalmente.
Descripción Esta métrica mide la duración de extremo a extremo de una solicitud de servicio. Se calcula como la diferencia entre la marca de tiempo de la actividad 'Solicitud de Servicio Resuelta' y la actividad 'Solicitud de Servicio Creada'. Este es uno de los KPI más importantes para cualquier proceso de servicio al cliente. Es la métrica principal para el dashboard 'Análisis del tiempo de resolución de solicitudes de servicio' y el KPI 'Tiempo Promedio de Resolución de Solicitudes de Servicio'. Analizar esta duración ayuda a identificar retrasos sistémicos y medir la eficiencia general del proceso de soporte. Por qué es importante Mide la duración del caso de principio a fin, un KPI crítico para evaluar la eficiencia general del proceso y la experiencia del cliente. Dónde obtener Calculado al restar la marca de tiempo de creación de la marca de tiempo de resolución final para cada Solicitud de Servicio. Ejemplos 720086400172800
	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 dado. Puede cambiar a lo largo del 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 del agente. Soporta el dashboard 'Carga de trabajo y eficiencia del agente' al permitir comparaciones de tiempos de manejo y volúmenes de casos entre diferentes agentes, ayudando a identificar oportunidades de capacitación y asegurar cargas de trabajo equilibradas. Por qué es importante Rastrea qué agente realizó una acción, permitiendo el análisis del rendimiento individual, la distribución de la carga de trabajo y la asignación de recursos. Dónde obtener API de Tickets de Zendesk, campo `assignee_id`. Los detalles del usuario se pueden recuperar de la API de Usuarios. Ejemplos John SmithJane DoeSupportBot
	Canal de Comunicación CommunicationChannel	El canal a través del cual se envió la solicitud de servicio o se produjo la comunicación.
Descripción Este atributo identifica el método de comunicación utilizado, como correo electrónico, formulario web, chat o teléfono. Refleja cómo interactúan los clientes con la mesa de servicio. Comprender el uso del canal es importante para la planificación de recursos y la mejora de la experiencia del cliente. El dashboard 'Resumen del uso del canal de comunicación' analiza estos datos para ver qué canales son los más populares y si ciertos canales están asociados con tiempos de resolución más largos o diferentes rutas de proceso. Puede ayudar a decidir dónde invertir en mejoras del servicio o automatización. Por qué es importante Muestra cómo interactúan clientes y agentes, permitiendo el análisis de la eficiencia del canal y su impacto en el proceso y la experiencia del cliente. Dónde obtener API de Tickets de Zendesk, campo `via.channel`. Ejemplos webemailapichat
	Prioridad Priority	El nivel de prioridad asignado a la solicitud de servicio, como 'Baja', 'Normal', 'Alta' o 'Urgente'.
Descripción La Prioridad indica la urgencia de una solicitud de servicio y a menudo influye en su posición en la cola y 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 de rendimiento y SLA. El dashboard 'Análisis del tiempo de resolución de solicitudes de servicio' utiliza la prioridad para segmentar datos, revelando si las solicitudes de alta prioridad se gestionan más rápido que las de menor prioridad y si los recursos se asignan eficazmente según las necesidades del negocio. Por qué es importante Indica la urgencia de una solicitud, lo cual es crítico para analizar el cumplimiento del SLA y asegurar que los problemas críticos se aborden con prontitud. Dónde obtener API de Tickets de Zendesk, campo `priority`. Ejemplos BajoNormalAltoUrgente
	Tiempo de Resolución Objetivo del SLA SlaTargetResolutionTime	La duración objetivo dentro de la cual se espera que se resuelva una solicitud de servicio, basándose en su política de SLA.
Descripción Este atributo define el objetivo del Acuerdo de Nivel de Servicio (SLA) para resolver un ticket. Este objetivo es a menudo dinámico y depende de factores como la prioridad de la solicitud, el tipo o el plan de servicio del cliente. Este es un atributo fundamental para el dashboard 'Rendimiento del cumplimiento de SLA'. Sirve como el punto de referencia contra el cual se mide el tiempo de resolución real. Analizar el rendimiento frente a este objetivo ayuda a cuantificar la calidad de la entrega del servicio y asegura que se cumplan las obligaciones contractuales con los clientes. Por qué es importante Define la promesa de servicio al cliente, actuando como el punto de referencia para medir el rendimiento a tiempo y el cumplimiento del SLA. Dónde obtener Derivado de las políticas de SLA aplicadas a un ticket. Esta información está disponible a través de la API de Métricas de Tickets de Zendesk. Ejemplos 144002880086400
	Tipo de Solicitud de Servicio ServiceRequestType	La clasificación de la solicitud de servicio, como 'Pregunta', 'Incidente', 'Problema' o 'Tarea'.
Descripción Este atributo categoriza la solicitud de servicio según su naturaleza. Esta clasificación se establece típicamente cuando se crea o se clasifica la solicitud y ayuda a determinar el flujo de trabajo y la prioridad adecuados. En el análisis, la segmentación por Tipo de Solicitud de Servicio es fundamental. Permite comparar los tiempos de resolución, las tasas de escalación y los flujos de proceso para diferentes tipos de problemas, como se muestra en dashboards como 'Análisis del tiempo de resolución de solicitudes de servicio' y 'Tasa y causas de escalación interna'. Esto ayuda a identificar si ciertos tipos de solicitudes son más problemáticos o ineficientes de manejar. Por qué es importante Categoriza las solicitudes para permitir la comparación de rendimiento y el análisis entre diferentes tipos de problemas, lo cual es crucial para la mejora dirigida de procesos. Dónde obtener API de Tickets de Zendesk, campo `type`. Ejemplos PreguntaIncidenteProblemaTask
	¿Se reabrió? IsReopened	Un indicador booleano que señala si una solicitud de servicio fue reabierta después de ser marcada como resuelta.
Descripción Este atributo es un indicador que se vuelve verdadero si una solicitud de servicio vuelve a un estado abierto después de haber sido previamente establecida como resuelta o cerrada. Señala que la resolución inicial no fue suficiente. Este indicador es crucial para rastrear el retrabajo y las fallas en la resolución en el primer contacto. Soporta directamente el dashboard 'Tendencias de Solicitudes de Servicio Reabiertas' y el KPI 'Tasa de Reapertura de Solicitudes de Servicio' al facilitar el recuento y análisis de los casos que requieren atención adicional, lo que a menudo indica problemas subyacentes más profundos. Por qué es importante Identifica retrabajos y resoluciones fallidas, ayudando a medir la calidad y efectividad de las soluciones proporcionadas. Dónde obtener Calculado durante la transformación de datos al verificar si el estado de un ticket cambia de 'resuelto' o 'cerrado' de nuevo a 'abierto'. Ejemplos truefalse
	Calificación de Satisfacción SatisfactionRating	La puntuación de satisfacción proporcionada por el cliente después de que se resolvió la solicitud de servicio.
Descripción Este atributo captura la retroalimentación del cliente sobre su experiencia de servicio, típicamente recopilada a través de una encuesta después de que el ticket se resuelve. Las calificaciones comunes incluyen 'Bueno', 'Malo' o una puntuación numérica. Esta es una medida directa del sentimiento del cliente y una métrica de resultado clave. Se utiliza para calcular el KPI 'Puntuación de Sentimiento del Cliente'. Analizar las calificaciones de satisfacción junto con los 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 la retroalimentación del cliente sobre el servicio proporcionado, vinculando el rendimiento del proceso con los resultados del cliente. Dónde obtener API de Tickets de Zendesk, campo `satisfaction_rating.score`. Ejemplos buenomalofrecido
	Categoría de Producto/Servicio ProductServiceCategory	El producto, servicio o característica específica sobre la que trata la solicitud del cliente.
Descripción Este atributo proporciona un contexto detallado al categorizar la solicitud de servicio basándose en un producto o área de servicio. A menudo es establecido manualmente por un agente o automáticamente según el contenido de la solicitud. Esta categorización es vital para los dashboards 'Precisión de la categorización de solicitudes' y 'Desglose del tiempo de ciclo de investigación'. Permite un análisis en profundidad sobre qué productos generan la mayoría de las solicitudes de soporte, cuáles son los más complejos de resolver y si la categorización inicial se alinea con la solución final, ayudando a mejorar el enrutamiento y la formación de los agentes. Por qué es importante Vincula las solicitudes a áreas de negocio, productos o servicios específicos, permitiendo un análisis enfocado en las áreas problemáticas y su impacto en el proceso. Dónde obtener Este es típicamente un campo de ticket personalizado en Zendesk. El nombre exacto del campo depende de la configuración específica de Zendesk. Ejemplos App 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 el cierre de la solicitud.
Descripción El Código de Resolución proporciona información estructurada sobre el resultado de una solicitud de servicio. Los ejemplos incluyen 'Resuelto por el Agente', 'Duplicado', 'No se requiere acción' o 'Problema conocido'. Ofrece más contexto que un simple estado 'Cerrado'. Este atributo es particularmente valioso para el análisis de la causa raíz. Para el dashboard 'Tendencias de Solicitudes de Servicio Reabiertas', analizar las tasas de reapertura por código de resolución puede revelar si ciertos tipos de soluciones son menos efectivas, llevando a los clientes a necesitar volver a contactar con el soporte. Por qué es importante Ofrece información sobre el resultado de una solicitud de servicio, lo cual es crucial para el análisis de la causa raíz y para entender por qué las solicitudes se reabren. Dónde obtener Este es típicamente un campo de ticket personalizado en Zendesk. El nombre exacto del campo depende de la configuración específica de Zendesk. Ejemplos Resolución en el Primer ContactoEscalado a Nivel 2Esperando ClienteError de Producto
	Conteo de Solicitudes de Información InformationRequestCount	El número total de veces que se solicitó información al cliente para una única solicitud de servicio.
Descripción Esta métrica calculada cuenta las ocurrencias de la actividad 'Información solicitada al cliente' para cada solicitud de servicio. Un recuento alto sugiere que los agentes no están recopilando toda la información necesaria de antemano. 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 para la formación de los agentes. Reducir el número de veces que se solicita información puede acortar significativamente 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, destacando ineficiencias que prolongan los tiempos de resolución y degradan la experiencia del cliente. Dónde obtener Calculado al contar el número de eventos donde el ActivityName es 'Información Solicitada al Cliente' para cada Solicitud de Servicio. Ejemplos 013
	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 enrutarse a grupos específicos basándose en habilidades, área de producto o idioma. Analizar por Grupo de Agentes ayuda a comprender el rendimiento a nivel de equipo, la distribución de la carga de trabajo y los patrones de escalación entre equipos. Proporciona una vista de nivel superior que el análisis de agentes individuales y puede ayudar a identificar problemas sistémicos dentro de departamentos o funciones específicas. Por qué es importante Rastrea la responsabilidad del equipo, permitiendo el análisis del rendimiento del grupo, las transferencias entre equipos y la asignación de recursos en diferentes niveles o especialidades de soporte. Dónde obtener API de Tickets de Zendesk, campo `group_id`. Los detalles del grupo se pueden recuperar de la API de Grupos. Ejemplos Soporte Nivel 1Soporte TécnicoFacturación
	Hora de Finalización EndTime	La marca de tiempo que indica cuándo se completó una actividad o evento.
Descripción La Hora de Finalización representa el tiempo de finalización de una actividad. En muchas estructuras de registro de eventos, la Hora de Inicio de la siguiente actividad puede servir como la Hora de Finalización de la actual. Para actividades basadas en estados como 'Agente investiga problema', marca cuándo concluyó ese estado. Este atributo es esencial para calcular la duración precisa de las actividades, que es un componente central del análisis de rendimiento. Ayuda a identificar qué pasos consumen más tiempo y proporciona la base para un análisis detallado de cuellos de botella y cálculos de eficiencia de recursos. Por qué es importante Permite el cálculo de la duración de las actividades, lo cual es crítico para identificar cuellos de botella y medir el rendimiento. Dónde obtener Esto a menudo se deriva tomando el StartTime del evento subsiguiente en la secuencia para una Solicitud de Servicio dada. Ejemplos 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z

Requerido Recomendado Opcional

Actividades de Servicio al Cliente

Estos son los pasos clave del proceso y los hitos a capturar en su registro de eventos para un descubrimiento preciso del proceso de servicio al cliente.

6 Recomendado 8 Opcional

	Actividad	Descripción
	Información Solicitada al Cliente	Ocurre cuando un agente requiere más información de un cliente para continuar y cambia el estado del ticket a 'pendiente'. Este cambio de estado indica explícitamente que el proceso ahora está a la espera de una parte externa.
Por qué es importante Esta actividad destaca las dependencias del cliente y pausa los tiempos de SLA internos. Las instancias frecuentes o repetidas en un solo ticket pueden indicar una recopilación de información inicial incompleta y llevar a tiempos de resolución más largos. Dónde obtener Este es un evento de cambio de estado explícito registrado en la API de Auditorías de Tickets de Zendesk. Se captura cuando el campo 'status' cambia a 'pendiente'. Capturar Identifique eventos de 'Cambio' en las Auditorías de Tickets donde el estado del ticket se establece en 'pendiente'. Tipo de evento explicit
	Solicitud Asignada al Agente	Este evento significa que la solicitud de servicio ha sido asignada a un agente específico para su manejo. Puede ocurrir automáticamente basándose en reglas de enrutamiento o manualmente por un líder de equipo o agente.
Por qué es importante La asignación es un hito crítico para la rendición de cuentas y la gestión de la carga de trabajo. Analizar el tiempo de asignación y los patrones de reasignación revela cuellos de botella en el proceso de triaje y distribución. Dónde obtener Este es un evento de 'Cambio' explícito en la API de Auditorías de Tickets de Zendesk, registrado cada vez que el campo 'assignee_id' se rellena o se cambia. Capturar Rastree los cambios en el campo 'assignee_id' en el registro de Auditorías de Tickets. Tipo de evento explicit
	Solicitud de Servicio Cerrada	Esta es la actividad final, que marca el cierre permanente de la solicitud de servicio. Esto suele ocurrir automáticamente después de que ha transcurrido un período de tiempo establecido desde que el ticket se marcó como 'resuelto', sin nuevas respuestas del cliente.
Por qué es importante Como el evento final definitivo, cierra el ciclo de vida del ticket. El tiempo desde 'resuelto' hasta 'cerrado' representa la ventana para posibles reaperturas, y el evento 'cerrado' confirma que la resolución fue aceptada. Dónde obtener Este es un cambio de estado explícito registrado en la API de Auditorías de Tickets de Zendesk cuando el campo 'status' se establece en 'cerrado'. Capturar Identifique eventos de 'Cambio' en las Auditorías de Tickets donde el estado del ticket se establece en 'cerrado'. 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 correo electrónico, formulario web o chat. Este evento es registrado explícitamente por el sistema con un ID de ticket único y una marca de tiempo en el momento de la creación.
Por qué es importante Como evento de inicio principal, es esencial para calcular la duración total del caso y analizar los volúmenes de solicitudes entrantes a lo largo del tiempo. Sirve como base para medir indicadores clave de rendimiento como el tiempo hasta la primera respuesta y el tiempo total de resolución. Dónde obtener Este es un evento explícito capturado en la API de Auditorías de Tickets de Zendesk. Corresponde al evento 'Crear' para un ticket, proporcionando la marca de tiempo de creación inicial. Capturar Capturado del evento de creación de ticket en el registro de Auditorías de Tickets. Tipo de evento explicit
	Solicitud de Servicio Reabierta	Esta actividad ocurre si un cliente responde a un ticket que está en estado 'resuelto'. Zendesk cambia automáticamente el estado de nuevo a 'abierto', indicando que el problema no se resolvió por completo.
Por qué es importante Las reaperturas son un indicador crítico de fallas en la Resolución en el Primer Contacto y de una calidad de solución deficiente. Analizar la frecuencia y las razones de los tickets reabiertos ayuda a identificar áreas para mejorar la formación de los agentes y los procedimientos de resolución. Dónde obtener Este es un cambio de estado explícito en la API de Auditorías de Tickets, capturado cuando el 'status' pasa de 'resuelto' a 'abierto'. Capturar Rastree los eventos de 'Cambio' de estado de 'resuelto' a 'abierto'. Tipo de evento explicit
	Solicitud de Servicio Resuelta	Un agente marca la solicitud de servicio como 'resuelta' después de proporcionar una solución al cliente. Este es un estado temporal, ya que el ticket puede ser reabierto por una respuesta del cliente antes de ser cerrado permanentemente.
Por qué es importante Este es el hito principal para medir el tiempo de resolución y la eficiencia del agente. Significa el punto en el que el agente cree que el trabajo está completo, proporcionando una base para analizar el retrabajo si el ticket se reabre. Dónde obtener Este es un cambio de estado explícito registrado en la API de Auditorías de Tickets de Zendesk cuando el campo 'status' se establece en 'resuelto'. Capturar Identifique eventos de 'Cambio' en las Auditorías de Tickets donde el estado del ticket se establece en 'resuelto'. Tipo de evento explicit
	Acuse de Recibo Inicial Enviado	Representa la primera respuesta automatizada enviada al cliente, confirmando que su solicitud ha sido recibida. Esto suele gestionarse mediante un trigger de Zendesk que envía una notificación por correo electrónico predefinida inmediatamente después de la creación del ticket.
Por qué es importante El seguimiento de esta actividad es crucial para medir la capacidad de respuesta inicial y gestionar las expectativas del cliente. El tiempo entre la creación de la solicitud y este acuse de recibo es una métrica clave para la satisfacción del cliente. Dónde obtener Inferido del primer comentario público en el ticket si su autor es un usuario automatizado o si ocurre a los pocos segundos de la creación del ticket. Esto puede identificarse analizando el flujo de Comentarios del Ticket. Capturar Identifique el primer comentario público creado por una automatización o un disparador inmediatamente después de la creación del ticket. Tipo de evento inferred
	Calificación de Satisfacción Recibida	Este evento ocurre cuando el cliente envía su respuesta a la encuesta de satisfacción, proporcionando una calificación como 'Bueno' o 'Malo'. La calificación y cualquier comentario asociado se registran contra el ticket.
Por qué es importante La retroalimentación directa del cliente es invaluable para medir la calidad del servicio y el sentimiento del cliente. Analizar estas calificaciones en el contexto del flujo del proceso ayuda a correlacionar actividades o agentes específicos con los resultados. Dónde obtener Capturado como un evento de 'Cambio' en la API de Auditorías de Tickets cuando el campo 'satisfaction_rating' se rellena con la puntuación y el comentario del cliente. Capturar Filtre los registros de Auditoría de Tickets para cambios en el campo 'satisfaction_rating'. Tipo de evento explicit
	Cliente Respondió	Este evento se activa cuando un cliente responde a un ticket, típicamente uno que estaba en estado 'pendiente'. Zendesk transiciona automáticamente el estado del ticket de 'pendiente' de nuevo a 'abierto', señalando que el agente puede reanudar el trabajo.
Por qué es importante Esta actividad marca el final de un tiempo de espera y es un disparador para que el proceso continúe. Analizar el tiempo que tardan los clientes en responder puede proporcionar información sobre la claridad de las solicitudes de los agentes. Dónde obtener Este evento corresponde a un nuevo comentario público del usuario final, lo que desencadena un cambio de estado explícito de 'pendiente' a 'abierto' en la API de Auditorías de Tickets. Capturar Rastree los eventos de 'Cambio' de estado de 'pendiente' a 'abierto' o identifique 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 una encuesta de satisfacción del cliente (CSAT) al cliente. Esto suele ocurrir poco tiempo después de que el ticket se marca como resuelto.
Por qué es importante Esta actividad inicia el ciclo de retroalimentación del cliente. Comprender cuándo y si se envían las encuestas es importante para contextualizar las puntuaciones de satisfacción y medir la eficacia del programa de retroalimentación. Dónde obtener Esto puede inferirse de un registro de automatización o mediante la adición de una etiqueta específica al ticket. La sección 'satisfaction_rating' en la API de Auditorías de Tickets también registra cuándo se ofreció la encuesta. Capturar Busque etiquetas como 'csat_sent' o utilice la marca de tiempo de cuando se ofreció la calificación de satisfacción. Tipo de evento inferred
	Escalación Interna Activada	Representa la transferencia de una solicitud de servicio a un equipo interno diferente o a un nivel de soporte superior. Esto se infiere típicamente cuando se cambia el grupo asignado del ticket.
Por qué es importante El seguimiento de las escalaciones es clave para identificar debilidades del proceso, brechas de conocimiento en el soporte de primera línea y tipos de solicitudes complejas. Las altas tasas de escalación pueden indicar la necesidad de una mejor formación o documentación de procesos. Dónde obtener Inferido de un evento de 'Cambio' en la API de Auditorías de Tickets donde se modifica el campo 'group_id'. Un cambio de grupo significa un traspaso entre equipos. Capturar Monitoree los cambios en el campo 'group_id' en el registro de Auditorías de Tickets. Tipo de evento inferred
	Incumplimiento de SLA Ocurrido	Esta actividad marca el momento en que una solicitud de servicio no cumple con un Acuerdo de Nivel de Servicio predefinido, como el tiempo de primera respuesta o el tiempo de resolución. Este evento se calcula basándose en las marcas de tiempo de la actividad del ticket comparadas con las políticas de SLA.
Por qué es importante Los incumplimientos de SLA impactan directamente la satisfacción del cliente y el cumplimiento contractual. Analizar cuándo y por qué ocurren es crítico para identificar retrasos sistémicos, escasez de recursos u objetivos de rendimiento poco realistas. Dónde obtener Esto puede obtenerse de la API de Métricas de Tickets de Zendesk, que almacena las marcas de tiempo de incumplimiento de SLA ('breached_at'). Alternativamente, se puede calcular comparando las marcas de tiempo de los eventos del ticket con las reglas de SLA definidas. Capturar Use la marca de tiempo 'breached_at' de la API de Métricas de Tickets o calcule comparando el tiempo de resolución con el tiempo de la política de SLA. Tipo de evento calculated
	Primera Respuesta Pública del Agente Enviada	Esta actividad marca la primera vez que un agente envía un comentario público al cliente, a diferencia de un acuse de recibo automático. Este evento es un indicador crucial del compromiso inicial del agente con el problema del cliente.
Por qué es importante Este es un hito clave para medir el SLA de 'Tiempo de Primera Respuesta', un indicador crítico de la capacidad de respuesta del servicio. Separa la comunicación automatizada del inicio de la investigación y el soporte activo, dirigido por humanos. Dónde obtener Identificado al encontrar el primer comentario público en el flujo de Comentarios del Ticket donde el autor es un agente humano (no un usuario de sistema automatizado). Capturar Escanee los comentarios del ticket, filtrando los comentarios públicos de los agentes y seleccionando el que tenga la marca de tiempo más temprana. Tipo de evento inferred
	Solicitud Categorizada y Priorizada	Esta actividad ocurre cuando un agente o una automatización establece o actualiza campos del ticket como tipo, categoría y 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 vitales para un enrutamiento eficiente y la asignación de recursos. Analizar esta actividad ayuda a determinar la precisión del triaje inicial y su impacto en los tiempos de resolución. Dónde obtener Capturado de la API de Auditorías de Tickets de Zendesk como eventos de 'Cambio'. Se puede identificar buscando la primera actualización de campos como 'prioridad', 'tipo' o campos personalizados relacionados con la categorización. Capturar Filtre los registros de Auditoría de Tickets para el primer evento de 'Cambio' en los campos clave de categorización después de la creación. Tipo de evento explicit

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Navegue a Zendesk Explore: Inicie sesión en su instancia de Zendesk y abra el producto Explore haciendo clic en el icono del lanzador de productos en la barra superior y seleccionando Explore.
Crear una Nueva Consulta: En Explore, haga clic en el icono de Consultas en la barra lateral izquierda, luego haga clic en el botón "Nueva consulta" en la parte superior derecha.
Seleccione el Conjunto de Datos: En la ventana "Elegir un conjunto de datos", seleccione el conjunto de datos Support: Tickets. Este conjunto de datos contiene los atributos principales de los tickets y las marcas de tiempo clave de los eventos.
Agregar Métricas: En el constructor de consultas, vaya al panel "Métricas" y haga clic en "Agregar". Seleccione COUNT(Tickets). Esto ayuda a validar el volumen de datos.
Agregar Atributos a las Filas: Vaya al panel "Filas" y haga clic en "Agregar". Añada los siguientes atributos. Estos formarán las columnas base de su exportación en formato ancho.
- Ticket ID (Este es su Identificador de 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)
Agregar Marcas de Tiempo de Actividad a las Filas: Agregue los siguientes atributos de marca de tiempo al panel "Filas". Cada uno de ellos representa una actividad potencial. Algunas actividades requieren la creación de un atributo calculado personalizado.
- Ticket created - Timestamp: Para Service Request Created y 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.
Crear Atributos Calculados Personalizados para Otras Actividades: Algunas actividades se basan en cambios de campo específicos y requieren la creación de atributos personalizados para capturar su marca de tiempo. Vaya al menú Cálculos (icono de calculadora) y seleccione "Atributo calculado estándar". Cree un atributo para cada una de las siguientes actividades. Deberá encontrar 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, agregue este nuevo atributo al panel "Filas" 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. Agréguelo a "Filas" 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. Agréguelo a "Filas" y establezca el agregador en MIN.
- Nombre: Timestamp - Escalated. Fórmula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Agréguelo a "Filas" y establezca el agregador en MIN.
- Nombre: Timestamp - SLA Breach. Fórmula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Agréguelo a "Filas" y establezca el agregador en MIN.
Filtrar los Datos: Vaya al panel "Filtros" y haga clic en "Agregar". Agregue un filtro para Ticket created - Date y seleccione un rango de fechas apropiado, como los últimos 3 a 6 meses, para mantener el conjunto de datos manejable.
Ejecutar y Exportar el Informe: Haga clic en "Guardar" para ejecutar la consulta. Una vez que la tabla muestre los datos, haga clic en el botón "Exportar" y elija su formato preferido, como CSV o Excel.
Transformar Datos a Formato de Registro de Eventos: El archivo exportado está en un formato "ancho" donde cada fila es un ticket y cada columna es una marca de tiempo de evento. Debe transformar esto a un formato "largo" para el Process Mining. Utilice una herramienta como Microsoft Excel (con la función Despivotar de Power Query), Python o cualquier otra herramienta de preparación de datos.
- Para cada fila (ticket), cree múltiples filas nuevas, una para cada columna de marca de tiempo no vacía.
- La tabla final debe tener columnas como ServiceRequest, ActivityName, StartTime y los otros atributos, que se duplicarán para cada actividad de una solicitud de servicio dada.

Configuración

Conjunto de Datos: El conjunto de datos principal a utilizar es Support: Tickets. Esto 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 un rol de Editor o Administrador en Zendesk Explore para crear y guardar consultas.
Rango de Fechas: Es crucial establecer un filtro de rango de fechas en Ticket created - Date. Se recomienda un rango de 3 a 6 meses de datos para equilibrar la información con el rendimiento. Exportar millones de tickets puede ser lento o fallar.
Filtros de Consulta: Considere agregar filtros para propiedades de tickets específicas como Ticket brand, Ticket form o Ticket group para enfocar el análisis en un servicio o equipo particular.
Atributos Calculados: Este método se basa en gran medida en la creación de atributos calculados estándar para capturar marcas de tiempo para eventos que no son atributos predeterminados, como cambios de estado o escalaciones. Asegúrese de tener los 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. Navegue al Centro de Administración, luego vaya a Aplicaciones e integraciones > APIs > API de Zendesk. En la pestaña Configuración, asegúrese de que el Acceso con Token esté habilitado. Haga clic en 'Añadir token de API' para crear un nuevo token. Copie de forma segura el token generado, ya que no se mostrará de nuevo.
Configure el Entorno Python: Asegúrese de tener Python 3.6 o superior instalado. Instale la biblioteca requests, que es necesaria para realizar solicitudes HTTP a la API de Zendesk. Puede instalarla usando la línea de comandos: pip install requests.
Configure el Script de Python: Guarde el script de Python proporcionado en un archivo, como extract_zendesk_log.py. Abra el archivo en un editor de texto y actualice las variables de marcador de posición en la parte superior: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y API_TOKEN con los detalles y credenciales específicos de su instancia de Zendesk.
Defina el Período de Extracción: Localice la variable START_TIMESTAMP dentro del script. Este valor determina la fecha de inicio histórica para la extracción de datos. Debe ser una marca de tiempo de época Unix. Para un análisis inicial, se recomienda un valor correspondiente a los últimos 3 a 6 meses.
Ejecute el Script: Abra un terminal o símbolo del sistema, navegue al directorio donde guardó el script y ejecútelo usando el comando: python extract_zendesk_log.py.
Monitoree la Ejecución: El script imprimirá actualizaciones de progreso en la consola, indicando el número de tickets procesados. El tiempo total de ejecución dependerá del volumen de datos que se estén extrayendo y de cualquier limitación de tasa de API impuesta por Zendesk. El script incluye lógica básica para manejar las respuestas de límite de tasa.
Recupere el Registro de Eventos: Una vez completado con éxito, 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.
Prepare para la Carga: Abra el archivo zendesk_event_log.csv para asegurarse de que se generó correctamente. Verifique que las columnas coincidan con los atributos requeridos: ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. El archivo está ahora listo para ser cargado en la herramienta de Process Mining.

Configuración

Credenciales de API: El script requiere un subdominio válido de Zendesk, la dirección de correo electrónico de un agente o usuario administrador, y un token de API activo. El usuario asociado con las credenciales debe tener permisos para leer tickets, auditorías de tickets, usuarios y métricas de tickets.
Rango de Fechas: La fecha de inicio de la extracción se controla mediante la variable START_TIMESTAMP en el script, que debe ser una marca de tiempo de época Unix. Es aconsejable comenzar con un período más corto, como 3 meses, para validar la salida y el rendimiento del script antes de intentar una extracción de datos históricos más grande.
API de Exportación Incremental: Esta solución utiliza la API de Exportación Incremental de Zendesk. Este es el método más eficiente y recomendado para obtener un gran número de tickets, ya que está diseñado para la exportación masiva de datos y evita los problemas comunes de paginación.
Rendimiento y Limitación de Tasa: Zendesk aplica límites de tasa de API que varían según el plan de suscripción. El script tiene una lógica incorporada para pausar la ejecución cuando se alcanza un límite de tasa, basándose en el encabezado Retry-After devuelto por la API. Para instancias muy grandes, la extracción puede tardar varias horas.
Requisitos Previos: Este método de extracción requiere un entorno de Python 3.6+ funcional y la biblioteca externa requests. Es necesario tener 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

Prepare el Acceso a la API de Zendesk: Inicie sesión en Zendesk como administrador. Navegue al Centro de Administración, luego vaya a Aplicaciones e integraciones > APIs > API de Zendesk. En la pestaña Configuración, asegúrese de que el Acceso con Token esté habilitado. Haga clic en 'Añadir token de API' para crear un nuevo token. Copie de forma segura el token generado, ya que no se mostrará de nuevo.
Configure el Entorno Python: Asegúrese de tener Python 3.6 o superior instalado. Instale la biblioteca requests, que es necesaria para realizar solicitudes HTTP a la API de Zendesk. Puede instalarla usando la línea de comandos: pip install requests.
Configure el Script de Python: Guarde el script de Python proporcionado en un archivo, como extract_zendesk_log.py. Abra el archivo en un editor de texto y actualice las variables de marcador de posición en la parte superior: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y API_TOKEN con los detalles y credenciales específicos de su instancia de Zendesk.
Defina el Período de Extracción: Localice la variable START_TIMESTAMP dentro del script. Este valor determina la fecha de inicio histórica para la extracción de datos. Debe ser una marca de tiempo de época Unix. Para un análisis inicial, se recomienda un valor correspondiente a los últimos 3 a 6 meses.
Ejecute el Script: Abra un terminal o símbolo del sistema, navegue al directorio donde guardó el script y ejecútelo usando el comando: python extract_zendesk_log.py.
Monitoree la Ejecución: El script imprimirá actualizaciones de progreso en la consola, indicando el número de tickets procesados. El tiempo total de ejecución dependerá del volumen de datos que se estén extrayendo y de cualquier limitación de tasa de API impuesta por Zendesk. El script incluye lógica básica para manejar las respuestas de límite de tasa.
Recupere el Registro de Eventos: Una vez completado con éxito, 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.
Prepare para la Carga: Abra el archivo zendesk_event_log.csv para asegurarse de que se generó correctamente. Verifique que las columnas coincidan con los atributos requeridos: ServiceRequest, ActivityName, StartTime, SourceSystem y LastDataUpdate. El archivo está ahora listo para ser cargado en la herramienta de Process Mining.

Configuración

Credenciales de API: El script requiere un subdominio válido de Zendesk, la dirección de correo electrónico de un agente o usuario administrador, y un token de API activo. El usuario asociado con las credenciales debe tener permisos para leer tickets, auditorías de tickets, usuarios y métricas de tickets.
Rango de Fechas: La fecha de inicio de la extracción se controla mediante la variable START_TIMESTAMP en el script, que debe ser una marca de tiempo de época Unix. Es aconsejable comenzar con un período más corto, como 3 meses, para validar la salida y el rendimiento del script antes de intentar una extracción de datos históricos más grande.
API de Exportación Incremental: Esta solución utiliza la API de Exportación Incremental de Zendesk. Este es el método más eficiente y recomendado para obtener un gran número de tickets, ya que está diseñado para la exportación masiva de datos y evita los problemas comunes de paginación.
Rendimiento y Limitación de Tasa: Zendesk aplica límites de tasa de API que varían según el plan de suscripción. El script tiene una lógica incorporada para pausar la ejecución cuando se alcanza un límite de tasa, basándose en el encabezado Retry-After devuelto por la API. Para instancias muy grandes, la extracción puede tardar varias horas.
Requisitos Previos: Este método de extracción requiere un entorno de Python 3.6+ funcional y la biblioteca externa requests. Es necesario tener 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

Navegue a Zendesk Explore: Inicie sesión en su instancia de Zendesk y abra el producto Explore haciendo clic en el icono del lanzador de productos en la barra superior y seleccionando Explore.
Crear una Nueva Consulta: En Explore, haga clic en el icono de Consultas en la barra lateral izquierda, luego haga clic en el botón "Nueva consulta" en la parte superior derecha.
Seleccione el Conjunto de Datos: En la ventana "Elegir un conjunto de datos", seleccione el conjunto de datos Support: Tickets. Este conjunto de datos contiene los atributos principales de los tickets y las marcas de tiempo clave de los eventos.
Agregar Métricas: En el constructor de consultas, vaya al panel "Métricas" y haga clic en "Agregar". Seleccione COUNT(Tickets). Esto ayuda a validar el volumen de datos.
Agregar Atributos a las Filas: Vaya al panel "Filas" y haga clic en "Agregar". Añada los siguientes atributos. Estos formarán las columnas base de su exportación en formato ancho.
- Ticket ID (Este es su Identificador de 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)
Agregar Marcas de Tiempo de Actividad a las Filas: Agregue los siguientes atributos de marca de tiempo al panel "Filas". Cada uno de ellos representa una actividad potencial. Algunas actividades requieren la creación de un atributo calculado personalizado.
- Ticket created - Timestamp: Para Service Request Created y 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.
Crear Atributos Calculados Personalizados para Otras Actividades: Algunas actividades se basan en cambios de campo específicos y requieren la creación de atributos personalizados para capturar su marca de tiempo. Vaya al menú Cálculos (icono de calculadora) y seleccione "Atributo calculado estándar". Cree un atributo para cada una de las siguientes actividades. Deberá encontrar 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, agregue este nuevo atributo al panel "Filas" 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. Agréguelo a "Filas" 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. Agréguelo a "Filas" y establezca el agregador en MIN.
- Nombre: Timestamp - Escalated. Fórmula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Agréguelo a "Filas" y establezca el agregador en MIN.
- Nombre: Timestamp - SLA Breach. Fórmula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Agréguelo a "Filas" y establezca el agregador en MIN.
Filtrar los Datos: Vaya al panel "Filtros" y haga clic en "Agregar". Agregue un filtro para Ticket created - Date y seleccione un rango de fechas apropiado, como los últimos 3 a 6 meses, para mantener el conjunto de datos manejable.
Ejecutar y Exportar el Informe: Haga clic en "Guardar" para ejecutar la consulta. Una vez que la tabla muestre los datos, haga clic en el botón "Exportar" y elija su formato preferido, como CSV o Excel.
Transformar Datos a Formato de Registro de Eventos: El archivo exportado está en un formato "ancho" donde cada fila es un ticket y cada columna es una marca de tiempo de evento. Debe transformar esto a un formato "largo" para el Process Mining. Utilice una herramienta como Microsoft Excel (con la función Despivotar de Power Query), Python o cualquier otra herramienta de preparación de datos.
- Para cada fila (ticket), cree múltiples filas nuevas, una para cada columna de marca de tiempo no vacía.
- La tabla final debe tener columnas como ServiceRequest, ActivityName, StartTime y los otros atributos, que se duplicarán para cada actividad de una solicitud de servicio dada.

Configuración

Conjunto de Datos: El conjunto de datos principal a utilizar es Support: Tickets. Esto 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 un rol de Editor o Administrador en Zendesk Explore para crear y guardar consultas.
Rango de Fechas: Es crucial establecer un filtro de rango de fechas en Ticket created - Date. Se recomienda un rango de 3 a 6 meses de datos para equilibrar la información con el rendimiento. Exportar millones de tickets puede ser lento o fallar.
Filtros de Consulta: Considere agregar filtros para propiedades de tickets específicas como Ticket brand, Ticket form o Ticket group para enfocar el análisis en un servicio o equipo particular.
Atributos Calculados: Este método se basa en gran medida en la creación de atributos calculados estándar para capturar marcas de tiempo para eventos que no son atributos predeterminados, como cambios de estado o escalaciones. Asegúrese de tener los 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`

Su Plantilla de Datos de Servicio al Cliente

Su Plantilla de Datos de Servicio al Cliente

Atributos de Servicio al Cliente

Actividades de Servicio al Cliente

Guías de Extracción

UI de Zendesk Explore para Informes y Exportación de Datos

Pasos

Configuración

a Consulta de ejemplo config

Script de Python usando 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 Herramienta ETL de Terceros para Zendesk

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Elimine Cuellos de Botella en Servicio al Cliente, Impulse el CSAT Ahora

Su Plantilla de Datos de Servicio al Cliente

Su Plantilla de Datos de Servicio al Cliente

Atributos de Servicio al Cliente

Actividades de Servicio al Cliente

Guías de Extracción

UI de Zendesk Explore para Informes y Exportación de Datos

Pasos

Configuración

a Consulta de ejemplo config

Script de Python usando 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 Herramienta ETL de Terceros para Zendesk

Pasos

Configuración

a Consulta de ejemplo config

Valoramos su privacidad

¿Listo para comenzar?

Elimine Cuellos de Botella en Servicio al Cliente, Impulse el CSAT Ahora