> Mejora Continua de Procesos > Gestión de Incidentes > Zendesk Support > Plantilla de Datos

Su `Plantilla` de `Datos` para la Gestión de Incidentes

Zendesk Support

Atributos de Gestión de Incidentes (24) Actividades de Gestión de Incidentes (13) Guías de Extracción (4)

Su `Plantilla` de `Datos` para la Gestión de Incidentes

Esta plantilla proporciona una visión general estructurada de los datos esenciales requeridos para analizar eficazmente su proceso de gestión de incidentes. Describe los atributos clave a recopilar, las actividades críticas a rastrear e incluye orientación práctica para extraer estos datos de Zendesk Support. Úsela para asegurar que su proyecto de Process Mining comience con un conjunto de datos robusto y completo.

Atributos recomendados para recopilar
Actividades clave para mapear el proceso
Guía práctica de extracción de datos

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

Descargar Plantilla

Atributos de Gestión de Incidentes

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis exhaustivo de su proceso de gestión de incidentes.

5 Requerido 7 Recomendado 12 Opcional

	Nombre	Descripción
	ID de Incidente TicketId	El identificador único generado por el sistema para cada ticket de incidente.
Descripción El ID del Incidente es la clave principal que identifica de forma única cada caso de incidente dentro de Zendesk Support. Sirve como CaseId para el Process Mining, vinculando todas las actividades relacionadas, cambios de estado y comunicaciones desde el momento en que se crea el incidente hasta su cierre. En el análisis, este ID es crucial para reconstruir el viaje de principio a fin de cada incidente. Permite la agregación de datos de eventos para rastrear métricas como el tiempo total de resolución, el número de traspasos y el cumplimiento de los acuerdos de nivel de servicio para casos individuales. Al agrupar los eventos por este ID, los analistas pueden visualizar los flujos de proceso, identificar rutas comunes y detectar desviaciones del procedimiento estándar. Por qué es importante Este es el identificador esencial que conecta todos los eventos a un solo incidente, haciendo posible rastrear todo el ciclo de vida y analizar el rendimiento del proceso con precisión. Dónde obtener API de Tickets de Zendesk (/api/v2/tickets/{id}), campo id. Ejemplos 19428230113521941055
	Timestamp del Evento EventTimestamp	La fecha y hora exactas en que ocurrió la actividad.
Descripción Esta marca de tiempo registra el momento preciso en que ocurrió un evento en el ciclo de vida del incidente, como cuando se añadió un comentario o se cambió el estado. Proporciona el orden cronológico para todas las actividades dentro de un caso. Este atributo es fundamental para cualquier análisis de Process Mining basado en el tiempo. Se utiliza para calcular los tiempos de ciclo entre actividades, identificar tiempos de espera, medir la duración total del caso y analizar el rendimiento del proceso en diferentes períodos de tiempo. Las marcas de tiempo precisas son esenciales para crear un mapa de proceso animado que muestre el flujo de casos a lo largo del tiempo y para construir dashboards de rendimiento que rastreen KPIs como el tiempo promedio de resolución. Por qué es importante Las marcas de tiempo proporcionan el contexto cronológico para todas las actividades, permitiendo el cálculo de duraciones, la identificación de cuellos de botella y el análisis del rendimiento del proceso a lo largo del tiempo. Dónde obtener API de Auditorías de Tickets de Zendesk (/api/v2/tickets/{ticket_id}/audits), campo created_at para cada evento de auditoría. Ejemplos 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Actividad ActivityName	El nombre de la actividad o evento de negocio que ocurrió en un punto específico del ciclo de vida del incidente.
Descripción Este atributo describe un paso o acción específica tomada dentro del proceso de gestión de incidentes, como 'Incidente Creado', 'Ticket Asignado al Agente' o 'Incidente Resuelto'. Estas actividades se derivan del registro de eventos o de los datos del rastro de auditoría de Zendesk, donde se registran los cambios del sistema. En Process Mining, la secuencia de estas actividades forma el mapa de proceso, que es la base de todo análisis. Al analizar el flujo de actividades, las organizaciones pueden descubrir las rutas reales que toman los incidentes, identificar cuellos de botella entre pasos, medir los ciclos de retrabajo (por ejemplo, reabrir un ticket resuelto) y verificar la conformidad con un proceso estándar definido. Por qué es importante La secuencia de actividades define el flujo de proceso, que es el núcleo del análisis de Process Mining para identificar ineficiencias, desviaciones y oportunidades de mejora. Dónde obtener Derivado de eventos en la API de Auditorías de Tickets de Zendesk. Por ejemplo, un evento de Cambio en el campo de estado podría mapearse a 'Estado Cambiado'. Ejemplos Incidente CreadoIncidente Asignado a AgenteEstado cambiado a PendienteIncidente ResueltoIncidente Cerrado
	Source System SourceSystem	El sistema del que se extrajeron los datos del incidente.
Descripción Este atributo identifica el origen de los datos del proceso. Para esta vista, el valor sería estático, por ejemplo, 'Zendesk Support', indicando que todos los eventos y atributos se obtuvieron de ese sistema. En entornos donde se combinan datos de múltiples sistemas, este campo es crítico para distinguir entre diferentes fuentes de datos. Ayuda a asegurar la integridad de los datos y permite un análisis específico de la fuente, como comparar el proceso de gestión de incidentes en Zendesk con otra herramienta ITSM. Por qué es importante Identifica el origen de los datos, lo cual es crucial para la gobernanza de datos y para análisis que combinan datos de múltiples sistemas fuente. Dónde obtener Valor estático establecido durante la transformación de datos para identificar el origen de los datos. Ejemplos Zendesk SupportZendesk
	Última actualización de datos LastDataUpdate	La marca de tiempo que indica cuándo se actualizaron por última vez los datos para este proceso.
Descripción Este atributo registra la fecha y hora de la extracción o actualización de datos más reciente del sistema de origen. Típicamente es un valor único aplicado a todo el conjunto de datos de un ciclo de actualización dado. Esta información es vital para la gobernanza de datos y para los usuarios del análisis de Process Mining. Proporciona contexto sobre la frescura de los datos, ayudando a los analistas a entender si están viendo la información más actual disponible. Esto es particularmente importante para monitorear el rendimiento operativo y tomar decisiones oportunas basadas en el análisis. Por qué es importante Proporciona un contexto crucial sobre la frescura de los datos, asegurando que los usuarios entiendan cuán actual es el análisis y cuándo se obtuvieron los datos por última vez. Dónde obtener Marca de tiempo generada por el proceso ETL/pipeline de datos al finalizar la actualización de datos. Ejemplos 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente Asignado Assignee	El agente de soporte individual actualmente asignado para gestionar el incidente.
Descripción Este atributo identifica al agente específico responsable del incidente en un momento dado. Los cambios en el asignado son eventos críticos que significan un traspaso de trabajo de una persona a otra. Analizar el agente asignado ayuda a comprender la distribución de la carga de trabajo, el rendimiento individual y los patrones de colaboración. El seguimiento de los cambios en este campo es esencial para calcular el KPI de 'Traspasos Promedio por Incidente' y para identificar situaciones en las que los incidentes se pasan con frecuencia, lo que puede indicar lagunas de conocimiento o un enrutamiento ineficiente. Por qué es importante Identifica al agente responsable, permitiendo el análisis de la carga de trabajo y el seguimiento de las transferencias, lo cual es crucial para identificar ineficiencias en el proceso. Dónde obtener API de Tickets de Zendesk, campo assignee_id. Los cambios se registran en la API de Auditorías de Tickets. Ejemplos John SmithJane DoeAutomatización del Service Desk
	Canal de Reporte Channel	El canal a través del cual se reportó inicialmente el incidente, como 'Email', 'Web' o 'API'.
Descripción Este atributo captura el método utilizado por el usuario final o el sistema para crear el ticket de incidente. Comprender el canal es importante para analizar las fuentes de incidentes y adaptar el proceso de soporte en consecuencia. Analizar los incidentes por canal puede revelar diferentes patrones. Por ejemplo, los incidentes reportados por teléfono podrían tener tiempos de resolución más cortos en comparación con los de correo electrónico. Esta información respalda el dashboard de 'Volumen de Incidentes Procesados' y ayuda en la planificación de recursos y los esfuerzos de optimización de canales. Por qué es importante Ayuda a analizar los volúmenes de incidentes y el rendimiento del proceso por fuente, permitiendo mejoras de proceso específicas del canal y asignación de recursos. Dónde obtener API de Tickets de Zendesk, campo via.channel. Ejemplos webemailapiteléfono
	Estado de SLA SlaStatus	El estado actual del Acuerdo de Nivel de Servicio (SLA) para el incidente.
Descripción Este atributo indica si un incidente está en camino de cumplir sus objetivos de SLA definidos, si ya los ha incumplido, o si los temporizadores de SLA están pausados. Zendesk rastrea automáticamente las métricas de SLA basadas en políticas configuradas. Este es un atributo crítico para el dashboard de 'Monitoreo de Cumplimiento de SLA'. Proporciona una medida directa del rendimiento frente a los compromisos de servicio. Al analizar cuándo y por qué se incumplen los SLA, las organizaciones pueden identificar debilidades del proceso y mejorar la fiabilidad del servicio. Apoya directamente el KPI de 'Tasa de Cumplimiento de SLA de Incidentes'. Por qué es importante Mide directamente el rendimiento frente a los compromisos de servicio, permitiendo el análisis de las violaciones de SLA y el monitoreo proactivo para mejorar el cumplimiento. Dónde obtener API de Métricas de Tickets de Zendesk (/api/v2/ticket_metrics.json), derivado de campos como sla_policy, breached_at, etc. Ejemplos ActivoPausadoIncumplidoCumplido
	Estado del Ticket TicketStatus	El estado del ticket de incidente en el momento del evento, como 'Abierto', 'Pendiente' o 'Resuelto'.
Descripción Este atributo refleja el estado del ticket de incidente en diferentes puntos de su ciclo de vida. Los estados estándar de Zendesk incluyen nuevo, abierto, pendiente, en espera, resuelto y cerrado. El seguimiento de los cambios en este campo es una forma principal de generar actividades para Process Mining. Analizar el estado del ticket es fundamental para comprender el proceso. Ayuda a identificar cuánto tiempo pasan los incidentes en ciertos estados, como 'Pendiente', lo que a menudo indica espera de respuesta del cliente. También es clave para definir la finalización del caso y calcular los tiempos de resolución. Por qué es importante El seguimiento de los cambios de estado es clave para comprender la progresión del proceso, identificar tiempos de espera y definir los puntos de inicio y fin del ciclo de vida del incidente. Dónde obtener API de Tickets de Zendesk, campo status. Los cambios se registran en la API de Auditorías de Tickets. Ejemplos newabiertopendienteresueltocerrado
	Grupo Asignado AssignedGroup	El equipo o grupo de soporte actualmente asignado al incidente.
Descripción Este atributo indica qué equipo es responsable del incidente. Los incidentes a menudo se mueven entre diferentes niveles de soporte o grupos especializados, por ejemplo, de 'Soporte N1' al 'Equipo de Red'. Esta es una dimensión crítica para analizar los traspasos de procesos e identificar cuellos de botella. Al monitorear cómo fluyen los incidentes entre grupos, los analistas pueden medir las dependencias entre equipos, calcular los tiempos de espera para equipos específicos y optimizar las reglas de enrutamiento. Apoya directamente el dashboard de 'Análisis de Traspasos y Retrabajo'. Por qué es importante Rastrea la propiedad del equipo, lo cual es esencial para analizar traspasos entre equipos, identificar cuellos de botella específicos del equipo y medir los tiempos de cola. Dónde obtener API de Tickets de Zendesk, campo group_id. Los cambios se registran en la API de Auditorías de Tickets. Ejemplos L1 SupportEquipo de Red L2Infraestructura L3Facturación
	Hora Fin del Evento EventEndTime	El timestamp que indica cuándo se completó una actividad.
Descripción La Hora de Fin del Evento marca la conclusión de una actividad. En los datos del registro de eventos, la hora de fin de una actividad a menudo se infiere como la hora de inicio de la siguiente actividad en la secuencia para ese caso. Para la última actividad en un caso, la hora de fin podría ser la misma que su hora de inicio. Este atributo es esencial para calcular la duración de las actividades individuales (ProcessingTime) y el tiempo de espera entre actividades. Esta información es la base para el análisis de cuellos de botella, permitiendo a los analistas ver no solo cuánto tiempo toma un paso, sino también cuánto tiempo estuvo el caso inactivo antes de que ese paso comenzara. Por qué es importante Permite el cálculo de las duraciones de las actividades y los tiempos de espera, lo cual es fundamental para realizar análisis detallados de cuellos de botella e identificar retrasos en el proceso. Dónde obtener Calculado como la hora de inicio del evento posterior dentro del mismo caso. La hora de finalización del último evento puede ser la misma que su hora de inicio o la hora de cierre del caso. Ejemplos 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Prioridad TicketPriority	El nivel de prioridad asignado al incidente, como 'Baja', 'Normal', 'Alta' o 'Urgente'.
Descripción La prioridad de un incidente determina la urgencia requerida para una respuesta y resolución. Es un factor clave en la priorización del trabajo y la asignación de recursos dentro del equipo de soporte. En el análisis de procesos, la prioridad se utiliza para segmentar incidentes y comparar sus flujos de proceso y rendimiento. Por ejemplo, los analistas pueden verificar si los incidentes 'Urgentes' se resuelven realmente más rápido que los de prioridad 'Baja'. También se utiliza para monitorear el cumplimiento de SLA, ya que los SLA a menudo se definen en función de los niveles de prioridad. El KPI de 'Tasa de Cambio de Prioridad' se basa en el seguimiento de los cambios en este campo. Por qué es importante Este atributo es crucial para segmentar el análisis, evaluar la efectividad de la priorización y monitorear el cumplimiento de SLA para diferentes niveles de urgencia. Dónde obtener API de Tickets de Zendesk, campo priority. Los cambios se registran en la API de Auditorías de Tickets. Ejemplos lownormalhighurgente
	Automatizado IsAutomated	Un indicador booleano que señala si una actividad fue realizada por un sistema automatizado o un agente humano.
Descripción Este atributo derivado ayuda a distinguir entre eventos ejecutados por usuarios humanos y aquellos realizados por automatizaciones del sistema, disparadores o integraciones de API. Típicamente se determina verificando si el autor de un evento es un usuario del sistema conocido. Comprender el nivel de automatización es crucial para el análisis de procesos moderno. Ayuda a evaluar la efectividad de las reglas de automatización, identificar tareas manuales que podrían automatizarse y medir el impacto de la automatización en la eficiencia y los tiempos de resolución. Este atributo puede usarse para comparar los flujos de proceso de actividades automatizadas versus manuales. Por qué es importante Distingue entre acciones humanas y del sistema, lo cual es esencial para analizar el impacto de la automatización en la eficiencia del proceso e identificar nuevas oportunidades de automatización. Dónde obtener Derivado al verificar si el autor del evento (author_id en la API de Auditorías de Tickets) corresponde a un sistema conocido o a un usuario de automatización. Ejemplos truefalse
	Calificación de Satisfacción SatisfactionRating	La calificación de satisfacción proporcionada por el usuario final después de que el incidente fue resuelto.
Descripción Este atributo captura la retroalimentación del cliente sobre su experiencia de soporte, típicamente recopilada a través de una encuesta después de que el ticket es resuelto. Las calificaciones comunes en Zendesk son 'Good' o 'Bad'. Aunque no es una medida directa de la eficiencia del proceso, las calificaciones de satisfacción proporcionan una métrica de resultado crítica. En Process Mining, esto puede correlacionarse con variantes del proceso para entender qué rutas de resolución conducen a una mayor satisfacción del cliente. Por ejemplo, ¿los incidentes con más traspasos reciben calificaciones más bajas? Por qué es importante Proporciona una métrica clave de resultado que puede correlacionarse con las características del proceso para entender cómo el rendimiento del proceso impacta la satisfacción del usuario. Dónde obtener API de Métricas de Tickets de Zendesk (/api/v2/ticket_metrics.json), campo satisfaction_rating.score. Ejemplos buenomalofrecidounoffered
	Categoría de Causa Raíz RootCauseCategory	La categoría de alto nivel de la causa raíz subyacente del incidente.
Descripción Este atributo se utiliza para clasificar la razón fundamental por la que ocurrió un incidente. Típicamente se captura hacia el final del ciclo de vida del incidente, a menudo como parte de un proceso de análisis post-mortem o de gestión de problemas, y se almacena en un campo personalizado. Estos datos son esenciales para el dashboard de 'Precisión en la Identificación de Causa Raíz' y el KPI de 'Cobertura de RCA'. Analizar incidentes por causa raíz ayuda a identificar problemas recurrentes, guiando los esfuerzos para implementar soluciones permanentes y reducir el volumen de incidentes futuros. Cambia el enfoque de la 'gestión reactiva de crisis' a la prevención proactiva de problemas. Por qué es importante Permite una gestión proactiva de problemas al categorizar las causas de los incidentes, ayudando a identificar tendencias y prevenir futuras ocurrencias. Dónde obtener Este es típicamente un campo de ticket personalizado. Verifique la configuración de Campos de Ticket en el Centro de Administración de Zendesk. Ejemplos Error de SoftwareFallo de HardwareError del UsuarioInterrupción de Red
	Duración del Caso CaseDuration	El tiempo total transcurrido desde la creación del incidente hasta su cierre final.
Descripción Esta métrica calculada representa el tiempo de ciclo de principio a fin para un solo incidente. Se calcula tomando la diferencia entre la marca de tiempo del primer evento (por ejemplo, 'Incidente Creado') y el último evento (por ejemplo, 'Incidente Cerrado'). La Duración del Caso es un Indicador Clave de Rendimiento (KPI) primario para la eficiencia general del proceso. Se utiliza mucho en dashboards para mostrar los tiempos de ciclo promedio, identificar casos de larga duración y analizar tendencias a lo largo del tiempo. Proporciona una medida de alto nivel de cuán rápido el proceso puede manejar y resolver incidentes. Por qué es importante Este es un KPI crítico para medir la velocidad general del proceso e identificar factores que contribuyen a tiempos de resolución largos. Dónde obtener Calculado encontrando la diferencia entre la marca de tiempo del último evento y el primer evento para cada ID de Incidente. Ejemplos 25920060480086400
	Es Resolución en el Primer Contacto IsFirstContactResolution	Un indicador booleano que es verdadero si el incidente fue resuelto por el primer agente o grupo asignado sin transferencias.
Descripción La Resolución en el Primer Contacto (FCR) es una métrica crítica para la eficiencia del centro de soporte y la satisfacción del cliente. Este atributo calculado marca los incidentes que se resolvieron sin ser reasignados a otro agente o equipo. La lógica típicamente verifica si el ticket alcanzó un estado 'Resuelto' mientras aún estaba asignado al agente y grupo iniciales. En la minería de procesos, esto permite el cálculo directo de la tasa de FCR y la comparación de las rutas de proceso de los incidentes de FCR frente a aquellos que requirieron escalamiento, ayudando a identificar oportunidades para empoderar al soporte de primera línea. Por qué es importante Mide directamente la eficiencia del punto de contacto de soporte inicial y ayuda a identificar oportunidades para adelantar la resolución en el proceso. Dónde obtener Indicador booleano calculado. Verdadero si el estado del ticket es 'resuelto' o 'cerrado' y solo hubo un único asignado o grupo asignado durante todo el ciclo de vida del incidente. Ejemplos truefalse
	Etiquetas Tags	Una lista de etiquetas aplicadas al incidente para categorización y contexto.
Descripción Las etiquetas son rótulos flexibles que se pueden añadir a los tickets para proporcionar contexto adicional o ayudar en la categorización y el enrutamiento. Pueden ser añadidas manualmente por agentes o automáticamente mediante disparadores y automatizaciones. Las etiquetas son una rica fuente de datos para el análisis de Process Mining. Pueden usarse para crear segmentos de análisis detallados, como filtrar incidentes relacionados con un lanzamiento de producto específico ('launch_q4') o una interrupción conocida ('outage_20231027'). Esta flexibilidad permite investigaciones profundas que van más allá de los campos de ticket estándar. Por qué es importante Ofrece una forma flexible de categorizar y filtrar incidentes, permitiendo un análisis detallado y contextual que no sería posible solo con los campos estándar. Dónde obtener API de Tickets de Zendesk, campo tags. Ejemplos vip_usernetwork_issueoutage_20231027billing_related
	Organización del Cliente Organization	La organización o empresa a la que pertenece el solicitante del incidente.
Descripción Este atributo vincula un incidente a la organización del cliente. Es esencial para entornos de soporte B2B donde los niveles de servicio y los procesos de soporte pueden variar según el cliente. Analizar los incidentes por organización permite a los equipos de soporte monitorear la salud del cliente, identificar problemas recurrentes que afectan a clientes específicos y asegurar que se cumplan las obligaciones contractuales. Es una dimensión clave para filtrar dashboards e informes y proporcionar una vista del rendimiento centrada en el cliente. Por qué es importante Permite el análisis específico del cliente, ayudando a monitorear los niveles de servicio, identificar tendencias para cuentas clave y gestionar las relaciones con los clientes de manera efectiva. Dónde obtener API de Tickets de Zendesk, campo organization_id. Ejemplos `Global Tech Inc.`Innovar SolucionesData Corp
	Recuento de Traspasos HandoffCount	El número total de veces que un incidente fue reasignado a un agente o grupo diferente.
Descripción Esta métrica calculada cuantifica el número de veces que se transfirió la responsabilidad de un incidente. Cada cambio en el campo Assignee o AssignedGroup incrementa este conteo para el caso. Los traspasos son una fuente común de ineficiencia y retraso en la gestión de incidentes. Un alto número de traspasos puede indicar reglas de enrutamiento poco claras, lagunas de conocimiento en los equipos de soporte o procesos excesivamente complejos. Esta métrica es la base para el KPI de 'Traspasos Promedio por Incidente' y es crucial para el dashboard de 'Análisis de Traspasos y Retrabajo'. Por qué es importante Cuantifica la fricción del proceso causada por las transferencias, ayudando a identificar ineficiencias de enrutamiento y lagunas de conocimiento que prolongan los tiempos de resolución. Dónde obtener Calculado contando el número de veces que el campo AssignedGroup o Assignee cambió para un incidente. Ejemplos 0135
	Remitente Submitter	El usuario final o sistema que reportó originalmente el incidente.
Descripción Este atributo identifica a la persona o entidad que creó el ticket. Es distinto del solicitante, ya que un agente podría crear un ticket en nombre de otra persona. En el análisis, el remitente se puede utilizar para entender quién está reportando problemas. Cuando se combina con datos de la organización, puede ayudar a identificar si clientes o grupos de usuarios específicos están experimentando un alto volumen de incidentes. Esto puede guiar iniciativas de soporte proactivo o esfuerzos de capacitación. Por qué es importante Identifica la fuente del informe de incidentes, que puede analizarse para encontrar patrones relacionados con usuarios específicos, departamentos o sistemas automatizados. Dónde obtener API de Tickets de Zendesk, campo submitter_id. Ejemplos alice.jones@example.combob.williams@example.comMonitor del Sistema
	Severidad Severity	El nivel de impacto que el incidente tiene en el negocio.
Descripción La Severidad define el impacto comercial de un incidente, a menudo junto con la prioridad para determinar la urgencia general. Típicamente se configura como un campo personalizado en Zendesk. Analizar la severidad ayuda a comprender la criticidad de los incidentes que se gestionan. Es una dimensión clave para segmentar datos en dashboards como 'Monitoreo de Cumplimiento de SLA' y 'Métricas de Efectividad de Priorización'. Comparar los flujos de proceso para diferentes niveles de severidad puede revelar si los incidentes de alta severidad se están manejando con la velocidad y los recursos adecuados. Por qué es importante Indica el impacto comercial de un incidente, permitiendo un análisis centrado en los problemas más críticos y asegurando que se resuelvan eficientemente. Dónde obtener Este es típicamente un campo personalizado. Verifique la configuración de Campos de Ticket en el Centro de Administración de Zendesk. Ejemplos 1 - Crítico2 - Alta3 - Medio4 - Baja
	Tiempo de Procesamiento ProcessingTime	La duración de una sola actividad, que representa el tiempo dedicado a trabajar activamente en una tarea.
Descripción Esta métrica mide el tiempo transcurrido desde el inicio de una actividad hasta su finalización. Se calcula como la diferencia entre EventEndTime y EventTimestamp para cada fila en el registro de eventos. El tiempo de procesamiento, también conocido como duración de la actividad, ayuda a diferenciar entre el tiempo de trabajo activo y el tiempo inactivo o de espera. En el dashboard de 'Resumen de Actividades con Cuello de Botella', los tiempos de procesamiento promedio altos para ciertas actividades pueden indicar tareas complejas y que consumen mucho tiempo. Esto es distinto del tiempo de espera, que representa los retrasos entre tareas. Por qué es importante Mide el tiempo de trabajo activo para actividades específicas, ayudando a identificar tareas que son intrínsecamente lentas y son candidatas a simplificación o automatización. Dónde obtener Calculado como la diferencia entre EventEndTime y EventTimestamp para cada actividad. Ejemplos 30018003600
	Tipo de Ticket TicketType	La clasificación del ticket, como 'Incidente', 'Problema', 'Pregunta' o 'Tarea'.
Descripción Este campo categoriza el ticket según la naturaleza de la solicitud. El proceso de gestión de incidentes se enfoca específicamente en tickets donde el tipo es 'Incidente', representando una interrupción no planificada o una reducción en la calidad de un servicio de TI. En el análisis, este atributo se utiliza principalmente como filtro para asegurar que solo los incidentes se incluyan en la vista del proceso. También puede usarse para un análisis ITSM más amplio para comparar los procesos de manejo de incidentes versus problemas o solicitudes de servicio. Por qué es importante Permite el filtrado de datos para centrarse específicamente en incidentes, asegurando que el análisis del proceso sea relevante para el ciclo de vida de la gestión de incidentes. Dónde obtener API de Tickets de Zendesk, campo type. Ejemplos incidenteproblemapreguntatarea

Requerido Recomendado Opcional

Actividades de Gestión de Incidentes

Estos son los pasos y hitos críticos del proceso a capturar en su registro de eventos para un descubrimiento y análisis precisos.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Estado Cambiado a Abierto	Indica que un agente ha comenzado a trabajar activamente en el incidente. Esta actividad se infiere típicamente del cambio del campo 'estado' del ticket de 'nuevo' a 'abierto', lo que significa el inicio de la fase de investigación y diagnóstico.
Por qué es importante Este evento marca la transición de la cola al trabajo activo. La duración que los tickets pasan en estado 'nuevo' antes de pasar a 'abierto' es una métrica clave para el tiempo de respuesta inicial. Dónde obtener Inferido del registro de auditoría del ticket identificando un evento de 'Cambio' donde el nuevo valor del campo 'estado' es 'abierto' y el valor anterior era 'nuevo'. Capturar Inferido de un cambio de campo de estado de 'nuevo' a 'abierto'. Tipo de evento inferred
	Incidente Asignado a Agente	Esta actividad ocurre cuando se asigna un ticket a un agente específico para su gestión. Este es un evento explícito registrado en el historial de auditoría del ticket y significa que un individuo ha asumido la propiedad.
Por qué es importante Este hito es esencial para medir el tiempo hasta la primera asignación y es la base para analizar traspasos, retrabajo y tasas de Resolución en el Primer Contacto (FCR). Dónde obtener Capturado del registro de auditoría del ticket cuando el campo 'assignee_id' se rellena o cambia. La primera asignación es un hito clave para el cálculo de KPI. Capturar Identificado por un evento de 'Cambio' para el campo 'assignee_id' en el registro de auditoría del ticket. Tipo de evento explicit
	Incidente Cerrado	Marca el fin final del ciclo de vida del incidente cuando el ticket se cierra permanentemente. En Zendesk, esto a menudo ocurre automáticamente después de un período de tiempo establecido desde que se resolvió, y se captura como un cambio de estado final.
Por qué es importante Esta es la actividad final definitiva para el proceso. La duración total del proceso se calcula desde 'Incidente Creado' hasta este evento, proporcionando una vista de principio a fin del tiempo de ciclo. Dónde obtener Capturado del registro de auditoría del ticket a través de un evento de 'Cambio' donde el nuevo valor del campo 'estado' se convierte en 'cerrado'. Capturar Identificado por un evento de 'Cambio' del campo 'status' a 'closed'. Tipo de evento explicit
	Incidente Creado	Marca el inicio del ciclo de vida del incidente cuando se crea un nuevo ticket en Zendesk. Este evento se captura explícitamente a través del registro de auditoría de creación de tickets de Zendesk, sirviendo como punto de partida para cada caso.
Por qué es importante Esta es la actividad de inicio principal. Analizar el tiempo desde este evento hasta otros es crucial para medir la duración general del ciclo de vida del ticket y los tiempos de respuesta iniciales. Dónde obtener Este es un evento explícito capturado en los registros de auditoría de tickets de Zendesk. Cada nuevo ticket genera un evento de 'Creación' con su marca de tiempo correspondiente. Capturar Directamente del evento de creación de ticket en el registro de auditoría. Tipo de evento explicit
	Incidente Resuelto	Este hito clave ocurre cuando un agente ha implementado una solución y marca el ticket como 'resuelto'. Esta es una acción explícita, capturada como un cambio de estado en el registro de auditoría del ticket.
Por qué es importante Esta es la actividad de resolución principal y un punto crítico para medir el tiempo de resolución. El tiempo entre este evento e 'Incidente Cerrado' representa el período de confirmación del usuario o cierre automático. Dónde obtener Capturado del registro de auditoría del ticket a través de un evento de 'Cambio' donde el nuevo valor del campo 'estado' se convierte en 'resuelto'. Capturar Identificado por un evento de 'Cambio' del campo 'status' a 'solved'. Tipo de evento explicit
	Ticket Reasignado	Ocurre cuando la propiedad de un ticket se transfiere de un agente o grupo a otro después de la asignación inicial. Este es un evento explícito rastreado en el historial de auditoría del ticket.
Por qué es importante Las reasignaciones son críticas para analizar traspasos y retrabajo. Una alta frecuencia de reasignaciones a menudo apunta a un enrutamiento inicial incorrecto, problemas complejos o cuellos de botella en el proceso. Dónde obtener Capturado del registro de auditoría del ticket identificando un evento de 'Cambio' en el campo 'assignee_id' o 'group_id' después de que se pobló por primera vez. Capturar Identificado por un evento de 'Cambio' posterior para el campo 'assignee_id' o 'group_id'. Tipo de evento explicit
	Estado cambiado a Pendiente	Indica que el proceso está en pausa mientras se espera una respuesta del solicitante. Este evento se infiere del cambio del campo 'estado' del ticket a 'pendiente'.
Por qué es importante Esta actividad es crucial para calcular el Tiempo de Espera de Confirmación del Usuario. Las largas duraciones en este estado pueden inflar significativamente el tiempo total de resolución y resaltar los retrasos en la comunicación. Dónde obtener Inferido del registro de auditoría del ticket identificando un evento de 'Cambio' donde el nuevo valor del campo 'estado' es 'pendiente'. Capturar Inferido de un cambio de campo de estado a 'pendiente'. Tipo de evento inferred
	Nota Interna Añadida	Esta actividad significa colaboración interna, donde un agente añade una nota privada al ticket para otros miembros del equipo. Esto se captura explícitamente cuando un comentario se marca como no público.
Por qué es importante El análisis de notas internas puede proporcionar información sobre problemas complejos que requieren colaboración, pero un número excesivo puede indicar lagunas de conocimiento o ineficiencias en el proceso. Dónde obtener Capturado de los datos de comentarios del ticket. Un comentario se identifica como una nota interna cuando su atributo 'público' es falso. Capturar Evento registrado cuando se añade un nuevo comentario con 'public: false' al ticket. Tipo de evento explicit
	Objetivo de SLA Incumplido	Marca el momento en que un ticket no ha cumplido un Acuerdo de Nivel de Servicio definido, como el tiempo de primera respuesta o el tiempo de resolución. Este evento se calcula basándose en las definiciones de la política de SLA y las marcas de tiempo de actualización del ticket.
Por qué es importante Este evento apoya directamente el monitoreo del cumplimiento de SLA. Identificar cuándo y por qué ocurren los incumplimientos es fundamental para mejorar la fiabilidad del servicio y la confianza del cliente. Dónde obtener Este es un evento calculado. Se puede derivar analizando los datos de 'sla_policy_metrics' asociados con un ticket, utilizando la marca de tiempo 'breached_at' para cada objetivo de SLA. Capturar Derivado de la marca de tiempo 'breached_at' dentro de los datos métricos de SLA del ticket. Tipo de evento calculated
	Prioridad Establecida	Se define el nivel de prioridad de un incidente (ej., Baja, Normal, Alta, Urgente). Esto se registra como un evento de cambio explícito y dicta la urgencia y el tiempo de respuesta requerido para el ticket.
Por qué es importante El seguimiento de cuándo y cómo se establece la prioridad es vital para el dashboard de 'Métricas de Efectividad de Priorización', asegurando que los problemas críticos se aborden rápidamente. Dónde obtener Capturado de un evento de 'Cambio' en el campo 'prioridad' dentro del registro de auditoría del ticket. Los cambios posteriores también se pueden rastrear para medir el KPI de Tasa de Cambio de Prioridad. Capturar Identificado por un evento de 'Cambio' para el campo 'priority' en el registro de auditoría del ticket. Tipo de evento explicit
	Respuesta Pública Enviada	Representa una comunicación enviada por un agente de soporte al usuario final. Este es un evento explícito en Zendesk, capturado cada vez que se añade un comentario público al ticket.
Por qué es importante El seguimiento de las respuestas públicas es importante para comprender la frecuencia de la comunicación y puede ser una parte clave de la línea de tiempo al analizar los retrasos en la confirmación del usuario. Dónde obtener Capturado de los datos de comentarios del ticket. Un comentario se identifica como público cuando su atributo 'público' es verdadero. Capturar Evento registrado cuando se añade un nuevo comentario con 'public: true' al ticket. Tipo de evento explicit
	Satisfacción del Usuario Calificada	Representa el momento en que el usuario final proporciona una calificación de satisfacción por el soporte recibido. Este es un evento explícito capturado en Zendesk después de que un ticket es resuelto.
Por qué es importante El análisis de las calificaciones de satisfacción proporciona retroalimentación crucial sobre el rendimiento del agente y la efectividad del proceso, vinculando las métricas del proceso con los resultados del cliente. Dónde obtener Capturado de los datos de calificaciones de satisfacción asociados con el ticket. Esto típicamente incluye una puntuación ('buena' o 'mala') y un comentario opcional. Capturar Evento registrado cuando se envía una calificación de satisfacción para el ticket. Tipo de evento explicit
	Ticket Asignado al Grupo	Representa el enrutamiento inicial o la clasificación de un incidente a un grupo de soporte específico. Este es típicamente el primer paso para asignar responsabilidad y se registra como un evento de cambio explícito en el historial de auditoría del ticket.
Por qué es importante El seguimiento de las asignaciones de grupo ayuda a analizar la eficiencia del proceso de clasificación inicial e identificar retrasos antes de que un ticket sea enrutado al equipo correcto. Dónde obtener Capturado del registro de auditoría del ticket cada vez que el campo 'group_id' se establece o cambia. La primera instancia de este cambio después de la creación es la asignación inicial. Capturar Identificado por un evento de 'Cambio' para el campo 'group_id' en el registro de auditoría del ticket. Tipo de evento explicit

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Acceder a Zendesk Explore: Inicie sesión en su instancia de Zendesk Support con una cuenta de usuario que tenga permisos para crear y gestionar informes en Zendesk Explore.
Crear un Nuevo Informe: Navegue al módulo de Explore. Haga clic en el icono de 'Informes' en la barra de navegación izquierda, luego haga clic en el botón 'Nuevo informe'.
Seleccionar el Conjunto de Datos: En la ventana 'Elegir un conjunto de datos', seleccione el conjunto de datos de Soporte: Actualizaciones de tickets [predeterminado]. Este conjunto de datos contiene el rastro de auditoría de cada cambio de ticket, lo cual es esencial para crear un registro de eventos.
Añadir Atributos Iniciales (Columnas): En el creador de informes, vaya a la sección 'Filas'. Haga clic en 'Añadir' y seleccione los siguientes atributos. Estos formarán las columnas de su registro de eventos: ID de Ticket, Actualización - Marca de tiempo, Estado del ticket, Nombre del asignado, Grupo del ticket, Prioridad del ticket, Canal del ticket, Cambios - Nombre del campo, Cambios - Valor anterior, Cambios - Nuevo valor, Comentario público.
Crear Atributos Calculados: Este es el paso más crítico. Vaya al menú de 'Cálculos' (el icono del matraz) y seleccione 'Atributo calculado estándar'. Cree los tres atributos definidos en la sección 'Consulta' a continuación: ActivityName, SourceSystem y LastDataUpdate. Deberá copiar las fórmulas proporcionadas exactamente.
Refinar Columnas del Informe: Añada sus atributos calculados recién creados (ActivityName, SourceSystem, LastDataUpdate) a la sección 'Filas'. Ahora puede eliminar los campos brutos utilizados para crear ActivityName (Cambios - Nombre del campo, Cambios - Valor anterior, Cambios - Nuevo valor, Comentario público) para limpiar la vista.
Añadir Filtros al Informe: Vaya a la sección 'Filtros' y haga clic en 'Añadir'. Añada un filtro para Actualización - Fecha y seleccione un rango de fechas apropiado (ej., los últimos 3 meses). Añada otro filtro en su atributo calculado ActivityName y excluya los valores nulos para eliminar cualquier actualización de ticket que no corresponda a una actividad deseada.
Ejecutar y Revisar el Informe: Zendesk Explore actualizará automáticamente el informe a medida que añada atributos y filtros. Revise la tabla de datos para asegurarse de que las filas y columnas aparecen como se espera. El informe debe mostrar una fila por evento.
Exportar los Datos a CSV: Una vez finalizado el informe, haga clic en el botón 'Exportar' en la esquina superior derecha y seleccione 'CSV'. Zendesk generará y descargará el archivo CSV.
Preparar para Subida: Abra el archivo CSV exportado. Renombre los encabezados de las columnas para que coincidan con los nombres de atributo requeridos para su herramienta de minería de procesos (ej., renombre 'Ticket ID' a TicketId, 'Update - Timestamp' a EventTimestamp). Asegúrese de que el formato de fecha para las marcas de tiempo sea compatible con ISO 8601. El archivo ya está listo para ser subido.

Configuración

Conjunto de Datos de Zendesk: El informe debe construirse sobre el conjunto de datos de Soporte: Actualizaciones de tickets [predeterminado]. Este es el único conjunto de datos estándar que proporciona el rastro de auditoría detallado necesario para reconstruir el proceso evento por evento.
Filtro de Rango de Fechas: Es crucial aplicar un filtro de fecha para limitar el volumen de datos. Utilice el atributo Actualización - Fecha como su filtro principal. Un rango de 3 a 6 meses de datos se recomienda típicamente para un análisis inicial.
Filtro de Actividad: Después de crear el atributo calculado ActivityName, debe filtrar el informe para excluir filas donde este valor sea nulo. Esto elimina cambios de tickets irrelevantes (ej., actualizaciones del sistema, cambios de etiquetas) de su registro de eventos.
Atributos Calculados: La lógica de esta extracción se basa en gran medida en un atributo calculado estándar para traducir los cambios de campo de tickets brutos a nombres de actividad legibles por humanos. La precisión en la fórmula es clave.
Requisitos Previos: El usuario que ejecuta el informe necesita al menos un rol de 'Visualizador' en Zendesk Explore. Para crear y guardar el informe, se requieren permisos de 'Editor' o 'Administrador'.

a Consulta de ejemplo config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Pasos

Requisitos Previos: Asegúrese de tener Python 3.6+ instalado en su sistema junto con las librerías requests y pandas. Puede instalarlas usando pip: pip install requests pandas.
Generar Token de API de Zendesk: Inicie sesión en su instancia de Zendesk Support como administrador. Navegue a Centro de Administración > Aplicaciones e integraciones > APIs > APIs de Zendesk. Bajo la sección "Tokens de API", añada un nuevo token de API activo y guarde de forma segura la cadena de token generada.
Configurar el Script de Python: Cree un nuevo archivo Python (ej., extract_zendesk_logs.py) y copie el script proporcionado en él. Actualice las variables de marcador de posición en la parte superior del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y ZENDESK_API_TOKEN con sus credenciales específicas. Establezca el START_TIMESTAMP para definir el inicio de su período de extracción de datos deseado (una marca de tiempo de época Unix).
Entender los Puntos de Acceso de la API: El script utiliza principalmente dos puntos de acceso de la API de Zendesk. El punto de acceso incremental/tickets/cursor.json se utiliza para extraer eficientemente todos los tickets actualizados desde el START_TIMESTAMP. Para cada ticket, el script luego llama al punto de acceso tickets/{ticket_id}/audits.json para obtener un historial detallado de cada cambio y evento.
Ejecutar el Script: Ejecute el script desde su terminal usando el comando: python extract_zendesk_logs.py. El script comenzará a obtener datos de la API de Zendesk.
Monitorear el Progreso del Script: El script imprimirá el número de tickets procesados en la consola, permitiéndole monitorear su progreso. Dependiendo del rango de fechas y el volumen de tickets, esto puede tomar una cantidad significativa de tiempo.
Recuperación de Datos y Paginación: El script maneja automáticamente la paginación de la API. Comienza con la URL de exportación inicial de tickets y sigue la after_url proporcionada en cada respuesta de la API hasta que se hayan recuperado todos los tickets del período.
Transformación de Eventos: Para cada ticket, el script itera a través de su historial de auditoría. Analiza cada evento de auditoría, mapeando los tipos de eventos internos de Zendesk (como Create, Change, Comment) a las actividades comerciales requeridas (como Incidente Creado, Estado Cambiado a Abierto, Respuesta Pública Enviada).
Manejo de Datos de SLA: El script incluye una función dedicada, get_sla_breach_events, para obtener métricas de SLA para cada ticket resuelto. Esto es necesario porque las violaciones de SLA no son eventos estándar en el registro de auditoría. Esta función realiza una llamada adicional a la API para obtener detalles de la aplicación de la política de SLA.
Generar el Registro de Eventos: Una vez que todos los tickets son procesados, el script compila los eventos extraídos en un DataFrame de pandas y guarda el registro de eventos final como un archivo CSV llamado zendesk_incident_event_log.csv en el mismo directorio donde se ejecutó el script.
Preparar para Subida: Revise el archivo CSV generado para verificar su exactitud. Este archivo ya está en el formato requerido para ser subido directamente a ProcessMind para su análisis.

Configuración

Credenciales de la API de Zendesk: Debe proporcionar su subdominio de Zendesk, la dirección de correo electrónico asociada a una cuenta de administrador o agente, y un token de API válido. Almacene estas credenciales de forma segura y no las codifique directamente en scripts con control de versiones para uso en producción.
Marca de Tiempo de Inicio (START_TIMESTAMP): Este valor entero determina el punto de partida para la extracción de datos. Debe ser una marca de tiempo de época Unix. Un punto de partida recomendado es de 3 a 6 meses en el pasado para recopilar una cantidad significativa de datos sin sobrecargar el sistema. Puede utilizar un convertidor en línea para obtener la marca de tiempo correcta para una fecha específica.
Límite de Tasa de la API: El script realiza numerosas llamadas a la API. Zendesk impone límites de tasa, que varían según el plan. Si bien el script es funcional para volúmenes de datos moderados, para instancias muy grandes, es posible que deba agregar llamadas time.sleep() dentro de los bucles para evitar exceder el límite de tasa y recibir un error 429.
Librerías de Python Requeridas: El script depende de la librería requests para realizar llamadas a la API y de la librería pandas para la manipulación de datos y la exportación a CSV. Asegúrese de que estas estén instaladas en su entorno Python.
Permisos de Usuario: La cuenta de usuario asociada con el token de API debe tener permisos suficientes para leer los datos de tickets, incluidas las auditorías y las métricas de tickets.

a Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
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", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Pasos

Requisitos Previos: Asegúrese de tener Python 3.6+ instalado en su sistema junto con las librerías requests y pandas. Puede instalarlas usando pip: pip install requests pandas.
Generar Token de API de Zendesk: Inicie sesión en su instancia de Zendesk Support como administrador. Navegue a Centro de Administración > Aplicaciones e integraciones > APIs > APIs de Zendesk. Bajo la sección "Tokens de API", añada un nuevo token de API activo y guarde de forma segura la cadena de token generada.
Configurar el Script de Python: Cree un nuevo archivo Python (ej., extract_zendesk_logs.py) y copie el script proporcionado en él. Actualice las variables de marcador de posición en la parte superior del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL y ZENDESK_API_TOKEN con sus credenciales específicas. Establezca el START_TIMESTAMP para definir el inicio de su período de extracción de datos deseado (una marca de tiempo de época Unix).
Entender los Puntos de Acceso de la API: El script utiliza principalmente dos puntos de acceso de la API de Zendesk. El punto de acceso incremental/tickets/cursor.json se utiliza para extraer eficientemente todos los tickets actualizados desde el START_TIMESTAMP. Para cada ticket, el script luego llama al punto de acceso tickets/{ticket_id}/audits.json para obtener un historial detallado de cada cambio y evento.
Ejecutar el Script: Ejecute el script desde su terminal usando el comando: python extract_zendesk_logs.py. El script comenzará a obtener datos de la API de Zendesk.
Monitorear el Progreso del Script: El script imprimirá el número de tickets procesados en la consola, permitiéndole monitorear su progreso. Dependiendo del rango de fechas y el volumen de tickets, esto puede tomar una cantidad significativa de tiempo.
Recuperación de Datos y Paginación: El script maneja automáticamente la paginación de la API. Comienza con la URL de exportación inicial de tickets y sigue la after_url proporcionada en cada respuesta de la API hasta que se hayan recuperado todos los tickets del período.
Transformación de Eventos: Para cada ticket, el script itera a través de su historial de auditoría. Analiza cada evento de auditoría, mapeando los tipos de eventos internos de Zendesk (como Create, Change, Comment) a las actividades comerciales requeridas (como Incidente Creado, Estado Cambiado a Abierto, Respuesta Pública Enviada).
Manejo de Datos de SLA: El script incluye una función dedicada, get_sla_breach_events, para obtener métricas de SLA para cada ticket resuelto. Esto es necesario porque las violaciones de SLA no son eventos estándar en el registro de auditoría. Esta función realiza una llamada adicional a la API para obtener detalles de la aplicación de la política de SLA.
Generar el Registro de Eventos: Una vez que todos los tickets son procesados, el script compila los eventos extraídos en un DataFrame de pandas y guarda el registro de eventos final como un archivo CSV llamado zendesk_incident_event_log.csv en el mismo directorio donde se ejecutó el script.
Preparar para Subida: Revise el archivo CSV generado para verificar su exactitud. Este archivo ya está en el formato requerido para ser subido directamente a ProcessMind para su análisis.

Configuración

Credenciales de la API de Zendesk: Debe proporcionar su subdominio de Zendesk, la dirección de correo electrónico asociada a una cuenta de administrador o agente, y un token de API válido. Almacene estas credenciales de forma segura y no las codifique directamente en scripts con control de versiones para uso en producción.
Marca de Tiempo de Inicio (START_TIMESTAMP): Este valor entero determina el punto de partida para la extracción de datos. Debe ser una marca de tiempo de época Unix. Un punto de partida recomendado es de 3 a 6 meses en el pasado para recopilar una cantidad significativa de datos sin sobrecargar el sistema. Puede utilizar un convertidor en línea para obtener la marca de tiempo correcta para una fecha específica.
Límite de Tasa de la API: El script realiza numerosas llamadas a la API. Zendesk impone límites de tasa, que varían según el plan. Si bien el script es funcional para volúmenes de datos moderados, para instancias muy grandes, es posible que deba agregar llamadas time.sleep() dentro de los bucles para evitar exceder el límite de tasa y recibir un error 429.
Librerías de Python Requeridas: El script depende de la librería requests para realizar llamadas a la API y de la librería pandas para la manipulación de datos y la exportación a CSV. Asegúrese de que estas estén instaladas en su entorno Python.
Permisos de Usuario: La cuenta de usuario asociada con el token de API debe tener permisos suficientes para leer los datos de tickets, incluidas las auditorías y las métricas de tickets.

a Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
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", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Pasos

Acceder a Zendesk Explore: Inicie sesión en su instancia de Zendesk Support con una cuenta de usuario que tenga permisos para crear y gestionar informes en Zendesk Explore.
Crear un Nuevo Informe: Navegue al módulo de Explore. Haga clic en el icono de 'Informes' en la barra de navegación izquierda, luego haga clic en el botón 'Nuevo informe'.
Seleccionar el Conjunto de Datos: En la ventana 'Elegir un conjunto de datos', seleccione el conjunto de datos de Soporte: Actualizaciones de tickets [predeterminado]. Este conjunto de datos contiene el rastro de auditoría de cada cambio de ticket, lo cual es esencial para crear un registro de eventos.
Añadir Atributos Iniciales (Columnas): En el creador de informes, vaya a la sección 'Filas'. Haga clic en 'Añadir' y seleccione los siguientes atributos. Estos formarán las columnas de su registro de eventos: ID de Ticket, Actualización - Marca de tiempo, Estado del ticket, Nombre del asignado, Grupo del ticket, Prioridad del ticket, Canal del ticket, Cambios - Nombre del campo, Cambios - Valor anterior, Cambios - Nuevo valor, Comentario público.
Crear Atributos Calculados: Este es el paso más crítico. Vaya al menú de 'Cálculos' (el icono del matraz) y seleccione 'Atributo calculado estándar'. Cree los tres atributos definidos en la sección 'Consulta' a continuación: ActivityName, SourceSystem y LastDataUpdate. Deberá copiar las fórmulas proporcionadas exactamente.
Refinar Columnas del Informe: Añada sus atributos calculados recién creados (ActivityName, SourceSystem, LastDataUpdate) a la sección 'Filas'. Ahora puede eliminar los campos brutos utilizados para crear ActivityName (Cambios - Nombre del campo, Cambios - Valor anterior, Cambios - Nuevo valor, Comentario público) para limpiar la vista.
Añadir Filtros al Informe: Vaya a la sección 'Filtros' y haga clic en 'Añadir'. Añada un filtro para Actualización - Fecha y seleccione un rango de fechas apropiado (ej., los últimos 3 meses). Añada otro filtro en su atributo calculado ActivityName y excluya los valores nulos para eliminar cualquier actualización de ticket que no corresponda a una actividad deseada.
Ejecutar y Revisar el Informe: Zendesk Explore actualizará automáticamente el informe a medida que añada atributos y filtros. Revise la tabla de datos para asegurarse de que las filas y columnas aparecen como se espera. El informe debe mostrar una fila por evento.
Exportar los Datos a CSV: Una vez finalizado el informe, haga clic en el botón 'Exportar' en la esquina superior derecha y seleccione 'CSV'. Zendesk generará y descargará el archivo CSV.
Preparar para Subida: Abra el archivo CSV exportado. Renombre los encabezados de las columnas para que coincidan con los nombres de atributo requeridos para su herramienta de minería de procesos (ej., renombre 'Ticket ID' a TicketId, 'Update - Timestamp' a EventTimestamp). Asegúrese de que el formato de fecha para las marcas de tiempo sea compatible con ISO 8601. El archivo ya está listo para ser subido.

Configuración

Conjunto de Datos de Zendesk: El informe debe construirse sobre el conjunto de datos de Soporte: Actualizaciones de tickets [predeterminado]. Este es el único conjunto de datos estándar que proporciona el rastro de auditoría detallado necesario para reconstruir el proceso evento por evento.
Filtro de Rango de Fechas: Es crucial aplicar un filtro de fecha para limitar el volumen de datos. Utilice el atributo Actualización - Fecha como su filtro principal. Un rango de 3 a 6 meses de datos se recomienda típicamente para un análisis inicial.
Filtro de Actividad: Después de crear el atributo calculado ActivityName, debe filtrar el informe para excluir filas donde este valor sea nulo. Esto elimina cambios de tickets irrelevantes (ej., actualizaciones del sistema, cambios de etiquetas) de su registro de eventos.
Atributos Calculados: La lógica de esta extracción se basa en gran medida en un atributo calculado estándar para traducir los cambios de campo de tickets brutos a nombres de actividad legibles por humanos. La precisión en la fórmula es clave.
Requisitos Previos: El usuario que ejecuta el informe necesita al menos un rol de 'Visualizador' en Zendesk Explore. Para crear y guardar el informe, se requieren permisos de 'Editor' o 'Administrador'.

a Consulta de ejemplo config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Su `Plantilla` de `Datos` para la Gestión de Incidentes

Su `Plantilla` de `Datos` para la Gestión de Incidentes

Atributos de Gestión de Incidentes

Actividades de Gestión de Incidentes

Guías de Extracción

Exportación de Informe de Interfaz de Usuario de Zendesk Explore a Archivo CSV

Pasos

Configuración

a Consulta de ejemplo config

Script de Python utilizando la API REST de Zendesk Support

Pasos

Configuración

a Consulta de ejemplo python

API de Exportación Incremental de Zendesk para Sincronización Masiva de Datos

Pasos

Configuración

a Consulta de ejemplo python

Herramienta ETL de Terceros con Conector de API de Zendesk

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Optimice la Gestión de Incidentes, Resuelva más Rápido Hoy

Su Plantilla de Datos para la Gestión de Incidentes

Su Plantilla de Datos para la Gestión de Incidentes

Atributos de Gestión de Incidentes

Actividades de Gestión de Incidentes

Guías de Extracción

Exportación de Informe de Interfaz de Usuario de Zendesk Explore a Archivo CSV

Pasos

Configuración

a Consulta de ejemplo config

Script de Python utilizando la API REST de Zendesk Support

Pasos

Configuración

a Consulta de ejemplo python

API de Exportación Incremental de Zendesk para Sincronización Masiva de Datos

Pasos

Configuración

a Consulta de ejemplo python

Herramienta ETL de Terceros con Conector de API de Zendesk

Pasos

Configuración

a Consulta de ejemplo config

Valoramos su privacidad

¿Listo para comenzar?

Optimice la Gestión de Incidentes, Resuelva más Rápido Hoy

Su `Plantilla` de `Datos` para la Gestión de Incidentes

Su `Plantilla` de `Datos` para la Gestión de Incidentes