> Mejora continua de procesos > Gestión de problemas > Zendesk Support > Template de datos

Su Template de datos de gestión de problemas

Zendesk Support

Atributos de la gestión de problemas (19) Actividades de la gestión de problemas (12) Guías de extracción (3)

Su Template de datos de gestión de problemas

Este Template proporciona un marco completo para mapear el ciclo de vida de la gestión de problemas en Zendesk Support. Describe los atributos esenciales, los hitos del proceso y la lógica de extracción necesarios para identificar cuellos de botella en el análisis de la causa raíz. Al seguir esta estructura, puede crear un registro de eventos de alta calidad para obtener una visión más profunda del proceso.

Atributos recomendados para un análisis detallado
Actividades clave del proceso y transiciones de estado
Guía de extracción de datos de Zendesk Support

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

Descargar Template

Atributos de la gestión de problemas

Estos campos de datos recomendados proporcionan el contexto necesario para analizar las categorías de tickets, los niveles de prioridad y la asignación de responsables durante todo el ciclo de vida de la resolución de problemas.

5 Obligatorio 8 Recomendado 6 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento o acción realizada en el registro de problema.
Descripción Este atributo registra el paso o la acción específica realizada durante el ciclo de vida del registro de problema. Algunos ejemplos son los cambios de estado, como de «Open» a «Pending», los cambios de asignación o pasos específicos del flujo de trabajo, como «Workaround Published». En el análisis, estas actividades forman los nodos del mapa de procesos. Su secuencia permite a los analistas visualizar el flujo de trabajo, identificar cuellos de botella y medir el tiempo transcurrido entre pasos específicos del proceso. Por qué es importante Define el «qué» del proceso y permite visualizar el flujo del proceso y analizar sus variantes. Dónde obtenerlo Obtenido de las auditorías de Zendesk Ticket o de las métricas de Ticket Ejemplos Registro de problema creadoInvestigación iniciadaSolución alternativa publicada
	Hora de inicio EventTimestamp	Fecha y hora específicas en las que ocurrió una actividad.
Descripción Este atributo registra el momento exacto en que tuvo lugar una actividad dentro del sistema Zendesk. Proporciona la dimensión temporal necesaria para ordenar correctamente los eventos y calcular las duraciones entre pasos. En el análisis, es fundamental para calcular los tiempos de ciclo, identificar retrasos, comprobar el cumplimiento de los SLA y visualizar el proceso a lo largo del tiempo. Sin marcas de tiempo precisas, es imposible comprender la velocidad del proceso de resolución de problemas. Por qué es importante Permite ordenar las actividades y calcular todos los KPI basados en el tiempo. Dónde obtenerlo Auditorías de Zendesk Ticket, campo «created_at» Ejemplos 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Registro de problema ProblemRecordId	Identificador numérico único asignado al ticket de problema en Zendesk.
Descripción Este atributo representa la clave única del registro de problema dentro del sistema Zendesk Support. Actúa como el ID central del caso para el Process Mining y permite agrupar todos los eventos, actualizaciones e interacciones posteriores en una sola instancia del proceso. En el análisis, este ID se utiliza para identificar de forma inequívoca cada recorrido de investigación del problema, desde su creación hasta el cierre. Permite relacionar los incidentes asociados y realizar un seguimiento del ciclo de vida del problema a través de los distintos niveles de soporte. Por qué es importante Es la clave obligatoria fundamental necesaria para agrupar eventos en casos en cualquier análisis de Process Mining. Dónde obtenerlo Objeto Zendesk Ticket, campo «id» cuando el tipo es «problem» Ejemplos 1045293849921
	Sistema de origen SourceSystem	Nombre del sistema del que proceden los datos.
Descripción Este atributo identifica la plataforma de software de la que se extrajeron los datos del proceso. En este contexto, se completará siempre con «Zendesk Support». En el análisis, especialmente al combinar datos de varios sistemas, como Zendesk y Jira, este campo permite a los analistas filtrar o agrupar los datos según su origen. Garantiza la trazabilidad y el linaje de los datos en las vistas de procesos que abarcan varios sistemas. Por qué es importante Garantiza el linaje de los datos y permite configuraciones de Process Mining en varios sistemas. Dónde obtenerlo Codificado durante la extracción Ejemplos Zendesk Support
	Última actualización de datos LastDataUpdate	Marca de tiempo que indica cuándo se modificó por última vez el registro de problema.
Descripción Este atributo refleja el momento más reciente en que se actualizaron los datos del registro de problema en el sistema de origen. Se diferencia de la marca de tiempo del evento porque se refiere al nivel del registro y no al nivel de la actividad. En el análisis, ayuda a determinar la actualidad de los datos. Se utiliza para identificar si el conjunto de datos está actualizado o si existen retrasos de sincronización entre el sistema de origen y el entorno de Process Mining. Por qué es importante Realiza un seguimiento de la actualidad de los datos y ayuda en las estrategias de carga incremental de datos. Dónde obtenerlo Objeto Zendesk Ticket, campo «updated_at» Ejemplos 2023-11-01T14:20:00Z
	Categoría de la causa raíz RootCauseCategory	Causa subyacente identificada del problema, por ejemplo, defecto de código o error de configuración.
Descripción Este atributo registra el diagnóstico final de la causa del problema. Normalmente se completa durante la actividad «Root Cause Identified». En el análisis, se utiliza para generar el informe «Precisión de la categorización de problemas» y analizar las tendencias de fallos del sistema. Ayuda a la dirección a determinar si debe centrarse en la calidad del código, la estabilidad de la infraestructura o la gestión de proveedores. Por qué es importante Permite analizar los patrones de fallos y orientar los esfuerzos de mejora a largo plazo. Dónde obtenerlo Campos personalizados de Zendesk Ticket Ejemplos Error de softwareError de configuraciónError del usuario
	Categoría del problema ProblemCategory	Clasificación del problema, por ejemplo, Software, Hardware o Network.
Descripción Este atributo categoriza el problema según el servicio o la pila tecnológica afectados. Normalmente es un campo desplegable personalizado de los formularios de Zendesk. En el análisis, se utiliza para el Dashboard de precisión de la categorización de problemas. Comparar esta categoría inicial con la causa raíz final ayuda a determinar si la clasificación inicial dirige correctamente los problemas a los equipos adecuados. Por qué es importante Permite segmentar por tecnología o servicio empresarial. Dónde obtenerlo Campos personalizados de Zendesk Ticket Ejemplos Base de datosUI/UXInfraestructura de red
	Estado del problema ProblemStatus	Estado actual del registro de problema dentro de su ciclo de vida.
Descripción Este atributo muestra el estado actual del problema, como New, Open, Pending, Solved o Closed. Refleja el avance de la investigación. En el análisis, se utiliza para filtrar los casos abiertos y cerrados. Es fundamental para el Dashboard de supervisión de registros de problemas obsoletos, ya que permite identificar qué casos activos no avanzan según el ciclo de vida de estados esperado. Por qué es importante Permite filtrar los casos según su estado de finalización. Dónde obtenerlo Objeto Zendesk Ticket, campo «status» Ejemplos NuevoAbiertoPendienteResueltoCerrado
	Fecha límite del SLA SlaDueDate	Fecha y hora objetivo para resolver el problema.
Descripción Este atributo representa el plazo de resolución según la configuración del acuerdo de nivel de servicio. Normalmente se calcula a partir de la prioridad y de la hora de creación del ticket. En el análisis, se compara con el tiempo real de resolución para calcular la «Tasa de cumplimiento del SLA de problemas». Alimenta el Dashboard de rendimiento y riesgo de los SLA al destacar los casos que se acercan al límite de tiempo asignado o que ya lo han superado. Por qué es importante Es fundamental para medir el cumplimiento y el rendimiento contractual. Dónde obtenerlo Métricas de Zendesk Ticket o endpoint de políticas de SLA Ejemplos 2023-12-01T17:00:00Z
	Grupo de soporte SupportGroup	Equipo o departamento asignado actualmente al registro de problema.
Descripción Este atributo identifica el grupo específico de agentes responsable del problema en un momento determinado. Cambia cuando el ticket pasa de un equipo a otro. En el análisis, es fundamental para el Dashboard de análisis de transferencias entre grupos de soporte. Permite medir el rendimiento por equipo, identificar cuellos de botella durante las transferencias y analizar la distribución de la carga de trabajo entre los recursos. Por qué es importante Permite analizar la organización e identificar cuellos de botella entre departamentos. Dónde obtenerlo Objeto Zendesk Ticket, campo «group_id» (resuelto al nombre) Ejemplos Soporte de nivel 2Equipo de bases de datosOperaciones de red
	Nombre de la persona asignada AssigneeName	Agente específico asignado para trabajar en el problema.
Descripción Este atributo contiene el nombre de la persona usuaria responsable actualmente del registro de problema. Proporciona visibilidad detallada sobre quién realizó acciones específicas. En el análisis, ayuda a comprender la carga de trabajo y el rendimiento individuales. Aunque el análisis a nivel de grupo es habitual, los datos a nivel de persona asignada pueden revelar necesidades de formación o identificar a quienes son especialmente eficaces al resolver causas raíz complejas. Por qué es importante Permite analizar los recursos a nivel individual. Dónde obtenerlo Objeto Zendesk Ticket, campo «assignee_id» (resuelto al nombre) Ejemplos John DoeJane SmithSistema
	Número de incidentes relacionados RelatedIncidentCount	Número de tickets de incidentes vinculados a este registro de problema.
Descripción Este atributo cuenta cuántos tickets de incidentes individuales están asociados a este registro de problema. En Zendesk, se gestiona mediante el campo «problem_id» de los tickets de incidentes, que los vincula con este registro. En el análisis, es la métrica principal de «Correlación e impacto de incidentes». Ayuda a priorizar los problemas que afectan al mayor número de usuarios y orienta las decisiones estratégicas sobre qué correcciones generarán el mayor ROI en términos de reducción del volumen de tickets. Por qué es importante Indica la magnitud del problema y su impacto en los usuarios. Dónde obtenerlo API de Zendesk Tickets, número de tickets donde type='incident' y problem_id=ThisID Ejemplos 015342
	Prioridad Priority	Nivel de urgencia asignado al registro de problema.
Descripción Este atributo indica la importancia relativa del problema, normalmente clasificada como Low, Normal, High o Urgent. Determina los acuerdos de nivel de servicio (SLA) previstos y la asignación de recursos. En el análisis, se utiliza para segmentar el proceso y comparar el rendimiento según los distintos niveles de urgencia. Por ejemplo, ayuda a comprobar si los problemas «Urgent» se resuelven realmente más rápido que los de prioridad «Low», como exige el Dashboard de velocidad de la investigación de la causa raíz. Por qué es importante Es esencial para segmentar los casos y analizar el cumplimiento de los SLA y la priorización de recursos. Dónde obtenerlo Objeto Zendesk Ticket, campo «priority» Ejemplos UrgenteAltaNormalBaja
	Asunto del problema ProblemSubject	Resumen breve o título del registro de problema.
Descripción Este atributo contiene el resumen textual introducido cuando se creó el problema. Normalmente describe el síntoma o el problema que se está investigando. En el análisis, proporciona contexto al analista al profundizar en casos específicos. También pueden aplicarse técnicas de minería de texto para agrupar problemas similares o identificar temas recurrentes que no se registran en los campos de categoría estructurados. Por qué es importante Proporciona un contexto comprensible para cada caso. Dónde obtenerlo Objeto Zendesk Ticket, campo «subject» Ejemplos No se pueden procesar los pagos en la región de la UEPicos de latencia en el servidor de inicio de sesiónError al exportar datos para usuarios administradores
	Está obsoleto IsStale	Indica si el problema no ha tenido actividad durante más de 14 días.
Descripción Este atributo calculado identifica los registros que no se han actualizado recientemente. Compara la fecha actual, o la fecha del análisis, con la marca de tiempo de la última actividad. En el análisis, alimenta el Dashboard «Supervisión de registros de problemas obsoletos». Ayuda a los responsables a identificar rápidamente los casos desatendidos que saturan la cartera de trabajo y pueden requerir un cierre administrativo o una reasignación. Por qué es importante Ayuda a identificar desperdicios del proceso y elementos de trabajo desatendidos. Dónde obtenerlo Calculado en la herramienta de Process Mining: (Now - LastDataUpdate) > 14 days Ejemplos truefalse
	ID de la solicitud de cambio ChangeRequestId	Identificador de la solicitud de cambio vinculada para implementar la corrección.
Descripción Este atributo vincula el registro de problema con un registro de Gestión de Cambios, posiblemente en otro sistema o en un tipo de ticket diferente. Indica que se ha iniciado un proceso formal de cambio. En el análisis, contribuye al Dashboard de tasa de inicio de solicitudes de cambio. Ayuda a realizar un seguimiento de la transición del diagnóstico a la implementación y garantiza que las causas raíz identificadas den lugar a acciones formales de cambio. Por qué es importante Vincula el proceso de problemas con el proceso de gestión de cambios. Dónde obtenerlo Campos personalizados de tickets de Zendesk o tickets vinculados Ejemplos CR-1002CHG00394
	ID del artículo de conocimiento KnowledgeArticleId	ID del artículo de la base de conocimientos creado o vinculado al problema.
Descripción Este atributo almacena la referencia a un artículo de Zendesk Guide o a un recurso de conocimiento externo. Indica que el conocimiento obtenido del problema se ha documentado. En el análisis, la presencia de este campo se utiliza para calcular la «Tasa de integración de la base de conocimientos». Verifica que la organización cierre el ciclo de aprendizaje al documentar las soluciones para futuras consultas. Por qué es importante Mide la eficacia de los procesos de gestión del conocimiento. Dónde obtenerlo Campos personalizados de Zendesk Ticket o contenido vinculado Ejemplos 360045889KB-2991
	Solución alternativa activa WorkaroundActive	Indicador que señala si se ha proporcionado o publicado una solución alternativa.
Descripción Este atributo booleano indica si se documentó una solución temporal para el problema. A menudo se obtiene a partir de la presencia de la actividad «Solución alternativa publicada» o de una casilla de verificación específica del formulario. En el análisis, se utiliza para el Dashboard «Cumplimiento de la publicación de soluciones alternativas». Mide con qué frecuencia el equipo de soporte ofrece un alivio inmediato a los usuarios mientras continúa la investigación a largo plazo. Por qué es importante Es fundamental para medir la mitigación del impacto en los usuarios durante las investigaciones. Dónde obtenerlo Se obtiene de la presencia de la actividad «Solución alternativa publicada» o de un campo personalizado Ejemplos truefalse
	Tiene PIR HasPostImplementationReview	Indica si se realizó una revisión posterior a la implementación.
Descripción Este atributo indica si el proceso de resolución del problema incluyó una fase de revisión. Se obtiene comprobando si la actividad «Revisión posterior a la implementación realizada» existe en el historial del caso. En el análisis, respalda el Dashboard «Cobertura de las revisiones posteriores a la implementación». Es una métrica de Cumplimiento que garantiza que la organización aprenda de sus problemas más importantes. Por qué es importante Valida el Cumplimiento de los procesos de mejora continua. Dónde obtenerlo Se obtiene de la presencia de la actividad «Revisión posterior a la implementación realizada» Ejemplos truefalse

Obligatorio Recomendado Opcional

Actividades de la gestión de problemas

Capture estos pasos esenciales del proceso y cambios de estado para visualizar el flujo completo, desde la identificación inicial del problema hasta la implementación de una solución permanente.

8 Recomendado 4 Opcional

	Actividad	Descripción
	Asignado a un grupo de soporte	Enrutamiento del registro de problema a un equipo técnico o departamento específico. Se registra cuando se actualiza el campo Group ID del ticket.
Por qué es importante Es fundamental para que el Dashboard de análisis de transferencias entre grupos de soporte mida los tiempos de espera entre departamentos. Dónde obtenerlo Supervise los cambios del campo «group_id» en el registro de auditoría del ticket. Recopilar Registrado cuando se ejecutó la transacción Group Assignment Change Tipo de evento explicit
	Causa raíz identificada	Momento en el que se determina la causa subyacente del problema. Normalmente se registra cuando el agente completa un campo de texto personalizado «Root Cause» o una categoría desplegable.
Por qué es importante Hito fundamental para el Dashboard de velocidad de la investigación de la causa raíz y para medir la eficiencia del diagnóstico. Dónde obtenerlo Supervise los cambios en los campos personalizados «Root Cause», «RCA» o «Problem Source» cuando pasen a tener valores no nulos. Recopilar Compare los valores de los campos personalizados para comprobar si están cumplimentados Tipo de evento inferred
	Corrección permanente aplicada	Indica que la solución técnica se ha implementado en el entorno. Normalmente se registra mediante una transición de estado personalizada o una etiqueta específica antes de que el ticket se resuelva por completo.
Por qué es importante Es esencial para que el Dashboard de eficiencia de implementación de correcciones mida el tiempo transcurrido entre el diagnóstico y la implementación. Dónde obtenerlo Se infiere a partir de una etiqueta específica, por ejemplo «fix_deployed», o de un campo de estado personalizado, si existe. Recopilar Supervise las etiquetas o los campos desplegables de estado personalizados Tipo de evento inferred
	Investigación iniciada	Marca la transición de un estado pasivo «New» a un estado activo de trabajo. Indica que un agente ha reconocido el problema y ha comenzado el diagnóstico.
Por qué es importante Se utiliza para calcular las métricas de registros de problemas obsoletos y es el punto de partida del KPI de duración media del análisis de la causa raíz. Dónde obtenerlo Se infiere cuando el estado del ticket cambia de «New» a «Open» o «Pending». Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Registro de problema cerrado	Evento final del ciclo de vida en el que el ticket se bloquea y no se pueden realizar más cambios. En Zendesk, normalmente ocurre de forma automática 4 días después del estado «Solved».
Por qué es importante Marca el final absoluto de la vida del registro y se utiliza para la conservación de datos y los informes históricos. Dónde obtenerlo Se obtiene cuando el estado del ticket cambia a «Closed». Recopilar Registrado cuando el estado cambia a Closed Tipo de evento explicit
	Registro de problema creado	Creación inicial del ticket de problema en Zendesk Support. Este evento registra la marca de tiempo en la que el problema se registró por primera vez en el sistema y normalmente activa la instancia del proceso.
Por qué es importante Establece la hora de inicio del ciclo de resolución de principio a fin y sirve como referencia para todas las métricas posteriores de tiempo de entrega. Dónde obtenerlo Se obtiene de la marca de tiempo «created_at» del objeto del ticket o de la primera entrada del registro de auditoría del ticket. Recopilar Registrado cuando se ejecutó la transacción Ticket Created Tipo de evento explicit
	Resolución verificada	Marcado formal del problema como resuelto. En Zendesk, ocurre cuando el estado estándar del sistema se establece en «Solved», lo que indica que la corrección se ha verificado y el caso está completo.
Por qué es importante Es el punto final principal para los cálculos de rendimiento y riesgo de los SLA y de la tasa de cumplimiento del SLA de problemas. Dónde obtenerlo Se obtiene cuando el estado del ticket cambia a «Solved». Recopilar Registrado cuando el estado cambia a Solved Tipo de evento explicit
	Solución alternativa publicada	Acción de documentar y compartir una corrección temporal para el problema. En Zendesk, suele registrarse mediante una etiqueta específica o un campo de casilla personalizado que indica que hay una solución alternativa disponible.
Por qué es importante Contribuye al Dashboard de cumplimiento de publicación de soluciones alternativas y garantiza que los usuarios reciban un alivio temporal durante las investigaciones prolongadas. Dónde obtenerlo Supervise la adición de la etiqueta «workaround_published» o el cambio de un campo booleano personalizado denominado «Workaround». Recopilar Compare los valores del campo personalizado o de la etiqueta Tipo de evento inferred
	Borrador de solución propuesto	Creación de un artículo de la base de conocimientos basado en la investigación del problema. Se infiere a partir del uso de la aplicación Zendesk Knowledge Capture o de la vinculación de un artículo nuevo.
Por qué es importante Contribuye al KPI de tasa de integración de la base de conocimientos y garantiza el aprendizaje organizativo. Dónde obtenerlo Supervise los eventos relacionados con la integración «Knowledge Capture» o las etiquetas como «kcs_draft». Recopilar Obtenga el dato a partir de etiquetas específicas del sistema o de eventos de vinculación Tipo de evento inferred
	Investigación del problema reabierta	Ocurre cuando un registro de problema marcado anteriormente como «Solved» vuelve a un estado «Open» o activo. Esto indica que la corrección ha fallado o que la resolución ha sido rechazada.
Por qué es importante Contribuye al KPI de tasa de reapertura de problemas y ayuda a identificar problemas de calidad en el proceso de resolución. Dónde obtenerlo Se infiere cuando el estado pasa de «Solved» a «Open», «New» o «Pending». Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Revisión posterior a la implementación realizada	Confirmación de que se ha completado una revisión retrospectiva después de aplicar la corrección. Normalmente, el coordinador del proceso actualiza una casilla o un campo de fecha.
Por qué es importante Es necesaria para el KPI de frecuencia de revisiones posteriores a la implementación y garantiza el cumplimiento de los estándares de calidad. Dónde obtenerlo Supervise las actualizaciones de la casilla personalizada «PIR Completed» o del campo de fecha «PIR Date». Recopilar Supervise el campo personalizado para comprobar que se ha completado Tipo de evento inferred
	Solicitud de cambio iniciada	Indica que se ha activado un proceso formal de gestión de cambios para corregir el problema. A menudo se infiere cuando se completa un campo personalizado «Change Request ID» o se vincula un ticket de tipo «Change».
Por qué es importante Realiza un seguimiento de la tasa de inicio de solicitudes de cambio y conecta la Gestión de Problemas con los flujos de trabajo de Gestión de Cambios. Dónde obtenerlo Supervise las actualizaciones de un campo personalizado como «change_reference» o la creación de un tipo de vínculo «problem_change». Recopilar Supervise el campo personalizado para detectar la introducción de un ID externo Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Zendesk Support

Pasos

Inicie sesión en su instancia de Zendesk y acceda a la interfaz de informes de Explore desde el menú de productos.
Haga clic en la carpeta Queries, o en Reports en las versiones más recientes, y seleccione New query.
Cuando se le solicite seleccionar un conjunto de datos, elija Support, después Updates History y, por último, Support: Updates History [default]. Este conjunto contiene los registros de eventos necesarios para Process Mining, no solo los datos del estado actual.
En el panel Metrics, añada Count (Tickets) o Count (Updates) para asegurarse de que se extraigan datos.
En el panel Filters, añada un filtro para Ticket > Ticket type y seleccione Problem para limitar el conjunto de datos al proceso de gestión de problemas.
En el panel Rows, añada los siguientes atributos en este orden específico para definir la estructura del registro de eventos: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name y Changes > Changes - Field name.
Para crear la columna Activity Name, debe crear un Standard Calculated Attribute. Haga clic en el icono Calculation de la barra lateral derecha, seleccione Standard calculated attribute, asígnele el nombre Activity Mapper y pegue el código proporcionado en la sección Query que aparece a continuación.
Añada este nuevo atributo Activity Mapper al panel Rows. Filtre este atributo para excluir los valores NULL y eliminar el ruido irrelevante del sistema.
Añada atributos adicionales al panel Rows para aportar contexto: Ticket > Priority, Ticket > Group, Ticket > Status y cualquier campo personalizado necesario para analizar la causa raíz o las categorías, como Ticket > Ticket tags o campos personalizados específicos.
Establezca el intervalo de tiempo en el panel Filters mediante Time - Timestamp > Update - Date para cubrir el periodo de análisis que desee, por ejemplo, Last 6 Months.
Haga clic en el icono Visualization type y seleccione Table. Asegúrese de que la tabla no esté pivotada o sea plana, si esa opción está disponible, o simplemente compruebe que todos los atributos se encuentren en la sección Rows.
Exporte el resultado haciendo clic en Export > CSV. Compruebe que la casilla Keep attribute formatting esté marcada para conservar los formatos de marca de tiempo en ProcessMind.

Configuración

Conjunto de datos: Support: Updates History (crítico: no utilice el conjunto de datos estándar Tickets, ya que solo muestra el estado actual).
Filtro de tiempo: Update - Date (recomendado: últimos 90 a 180 días, según el volumen).
Tipo de ticket: Filtre estrictamente por Problem para evitar mezclar Incidents y Service Requests.
Límite de filas: Las exportaciones de Zendesk Explore suelen estar limitadas a 50.000 filas. Si su conjunto de datos supera este límite, utilice el filtro Update - Date para exportar fragmentos mensuales más pequeños y combinarlos externamente.
Campos personalizados: Identifique los ID de campo específicos de Root Cause, Change Request y Workaround en su instancia concreta de Zendesk, ya que no son campos estándar del sistema.
Permisos del sistema: Se necesita una licencia Explore Viewer o Explore Professional.

a Consulta de ejemplo config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Pasos

Confirmación de requisitos previos: Asegúrese de que su organización tenga habilitado el complemento Zendesk Data Sharing. Confirme que dispone de credenciales de acceso de solo lectura a la base de datos replicada de Zendesk, que normalmente se aloja en Snowflake o Amazon Redshift.
Conexión con la base de datos: Utilice su cliente SQL preferido, como DBeaver, DataGrip o la interfaz web nativa de Snowflake o Redshift, para conectarse al almacén de datos de Zendesk con las credenciales proporcionadas.
Identificación de campos personalizados: Antes de ejecutar la consulta, debe identificar los ID únicos de los campos personalizados utilizados en su proceso de gestión de problemas. En Zendesk, acceda a Admin Center y vaya a Objects and rules > Tickets > Fields. Localice los campos «Root Cause», «Change Request ID», «Workaround Published», «Permanent Fix Applied» y «Post-Implementation Review» para obtener sus ID específicos. Estos ID se utilizarán para sustituir los marcadores de posición de la consulta.
Revisión de la consulta SQL: La consulta proporcionada utiliza una Common Table Expression (CTE) denominada ProblemTickets para seleccionar y filtrar primero todos los registros de problemas. Esto mejora el rendimiento y la legibilidad. A continuación, la parte principal de la consulta utiliza UNION ALL para combinar los resultados de 12 instrucciones SELECT independientes, una por cada actividad necesaria.
Personalización de la consulta: Abra un editor de consultas nuevo y pegue el script SQL completo. Modifique los marcadores de posición del script:
- En la CTE ProblemTickets, establezca el intervalo de fechas deseado sustituyendo '[YYYY-MM-DD]'.
- Para cada actividad que dependa de un campo personalizado, sustituya los ID de marcador de posición, como [Your 'Root Cause Category' field_id] y [Your 'Change Request ID' field_id], por los ID reales identificados en el paso 3.
Ejecución de la consulta: Ejecute el script SQL modificado en la base de datos. El tiempo de ejecución variará según el intervalo de fechas y el volumen de datos de los tickets.
Investigación de la lógica de «Proposed Solution Drafted»: La consulta presupone que la redacción de una solución se registra al completar un campo personalizado denominado [Your 'KB Article ID' field_id]. Si su proceso es diferente, por ejemplo, si utiliza una etiqueta o un comentario específico, deberá ajustar esta parte de la consulta.
Validación de los datos: Cuando finalice la consulta, revise brevemente los resultados. Compruebe que haya un número razonable de filas, que estén presentes todas las columnas y que no haya valores NULL inesperados en columnas críticas como ProblemRecordId y EventTimestamp.
Exportación del registro de eventos: Exporte todo el conjunto de resultados desde su cliente SQL a un archivo CSV. Asegúrese de que el archivo utilice la codificación UTF-8 y que los encabezados de columna coincidan con los nombres de atributos requeridos por su herramienta de Process Mining.
Preparación para la carga: Antes de cargar el archivo, compruebe que no haya problemas de formato en el CSV. Asegúrese de que los valores de fecha y hora de la columna EventTimestamp utilicen un formato coherente, como YYYY-MM-DD HH24:MI:SS.

Configuración

Requisitos previos: Esta extracción requiere el complemento Zendesk Data Sharing y acceso SQL directo a los datos replicados en una instancia de Snowflake o Amazon Redshift.
Filtro de tipo de ticket: La consulta está preconfigurada para analizar únicamente los tickets cuyo type sea 'problem'. Esto es fundamental para aislar el proceso de gestión de problemas de los incidentes y otros tipos de tickets.
Filtrado por intervalo de fechas: Se recomienda encarecidamente filtrar los datos por un periodo específico para controlar el rendimiento. La consulta incluye el marcador de posición created_at >= '[YYYY-MM-DD]' en la CTE inicial. Para un primer análisis, suele utilizarse un intervalo de 3 a 6 meses.
Configuración de campos personalizados: Esta extracción depende en gran medida de la configuración específica de su Zendesk. Debe identificar e introducir el field_id correcto de los campos personalizados que registran actividades como «Root Cause Identified», «Change Request Initiated» y «Workaround Published». Si no sustituye los ID de marcador de posición, la consulta fallará o no devolverá datos para estas actividades.
Latencia de los datos: Los datos de la base de datos replicada no se actualizan en tiempo real. Normalmente transcurren varias horas entre el momento en que ocurre un evento en Zendesk y su aparición en el almacén de datos. Téngalo en cuenta al analizar actividades muy recientes.

a Consulta de ejemplo sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Pasos

Requisitos previos: Asegúrese de tener Python 3.6 o una versión posterior instalada en su sistema. Instale las bibliotecas necesarias, requests y pandas, ejecutando pip install requests pandas en su terminal o símbolo del sistema.
Genere un token de la API de Zendesk: Inicie sesión en Zendesk Support como administrador. Vaya a Admin Center > Apps and integrations > APIs > Zendesk API. En la sección Token Access, haga clic en «Add API token» para crear un token nuevo. Cópielo inmediatamente y guárdelo de forma segura, ya que no volverá a mostrarse.
Configure el script de Python: Cree un archivo nuevo de Python, por ejemplo, extract_zendesk_problems.py, y copie en él el script completo proporcionado en la sección Query. Actualice las variables de marcador de posición situadas al principio del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN y START_TIME. En la ejecución inicial, establezca START_TIME en la marca de tiempo Unix de la fecha de inicio deseada para la extracción.
Asigne los identificadores de los campos personalizados: Identifique los identificadores numéricos de los campos personalizados utilizados en su proceso de Problem Management. Puede encontrarlos en Admin Center > Objects and rules > Tickets > Fields, consultando la URL o las propiedades del campo. Actualice el diccionario CUSTOM_FIELD_MAPPING del script con sus identificadores específicos.
Ejecute el script: Ejecute el script desde su terminal con el comando python extract_zendesk_problems.py. El script comenzará a recuperar datos de la API de exportación incremental de Zendesk.
Supervise la ejecución: El script mostrará su progreso, incluido el número de tickets procesados y la marca de tiempo que está consultando. Gestionará automáticamente los límites de frecuencia de la API mediante pausas cuando sea necesario.
Recuperación y transformación de datos: Primero, el script recupera todos los tickets de problema creados o actualizados desde START_TIME. Después, obtiene el historial de auditoría completo de cada ticket, que contiene todos los cambios históricos.
Generación del Registro de eventos: El script procesa cada evento de auditoría y asigna los cambios de campos, como el estado, el grupo o los campos personalizados, a las actividades empresariales definidas. También obtiene y almacena en caché los nombres de usuarios y grupos para enriquecer los datos.
Gestión de cargas incrementales: Después de la carga inicial, actualice la variable START_TIME en las ejecuciones posteriores con el valor de end_time mostrado al final de la ejecución correcta anterior. Así solo recuperará datos nuevos y actualizados, sin duplicados.
Revise el resultado: Cuando finalice el script, generará un archivo llamado zendesk_problem_event_log.csv en el mismo directorio. Este archivo CSV contiene el Registro de eventos estructurado, listo para el análisis.
Prepárese para la carga: Abra el archivo CSV en una herramienta de hojas de cálculo para verificar su contenido. Antes de cargarlo en ProcessMind, asegúrese de que todas las columnas necesarias (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) estén presentes y correctamente cumplimentadas.

Configuración

Credenciales de la API de Zendesk: El script requiere su subdominio de Zendesk, la dirección de correo electrónico del usuario asociado al token de la API y el propio token para autenticarse.
Hora de inicio: La variable START_TIME es una marca de tiempo de época Unix que define el punto inicial de la extracción de datos. En la primera ejecución, establézcala en una fecha pasada, por ejemplo, seis meses atrás, para obtener datos históricos. En las ejecuciones posteriores, utilice la hora de finalización de la ejecución anterior para recuperar datos de forma incremental.
Asignación de campos personalizados: El diccionario CUSTOM_FIELD_MAPPING es fundamental. Debe sustituir los identificadores de marcador de posición por los identificadores reales de los campos personalizados de su instancia de Zendesk para capturar correctamente actividades como «Workaround Published» y «Root Cause Identified».
Filtro por tipo de ticket: El script está configurado para procesar únicamente tickets cuyo type sea «problem». Así se excluyen los incidentes, las tareas y las preguntas del Registro de eventos de Problem Management.
Limitación de frecuencia de la API: El script incluye una función básica time.sleep(60) para gestionar los errores 429 «Too Many Requests». Es posible que deba ajustar la duración de esta pausa según su plan de Zendesk y el volumen de datos extraído.
Requisitos previos: Para ejecutar el script se necesita un entorno Python 3 con las bibliotecas requests y pandas. El token de la API debe estar asociado a una cuenta con permiso para leer datos de tickets.

a Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

class=class="hl-string">"hl-comment"># Caching for user and group lookups to reduce API calls
user_cache = {}
group_cache = {}

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

def get_user_name(user_id):
    if not user_id: return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def get_group_name(group_id):
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    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', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

¿Listo para comenzar?

Transforme la estabilidad de su entorno de TI aplicando hoy este Template a su entorno de Zendesk. Nuestro equipo está disponible para ayudarle a perfeccionar la extracción de sus datos y comenzar su recorrido de Process Mining.

Volver a la guía de mejora Descargar Template

Optimice su gestión de problemas para resolver antes las incidencias de TI

Reduzca los ciclos de resolución un 30 % y corrija los cuellos de botella de TI.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Configuración en minutos.

Su Template de datos de gestión de problemas

Su Template de datos de gestión de problemas

Atributos de la gestión de problemas

Actividades de la gestión de problemas

Guías de extracción

Exportación del historial de actualizaciones de Zendesk Explore

Pasos

Configuración

a Consulta de ejemplo config

Consulta SQL mediante Zendesk Data Sharing

Pasos

Configuración

a Consulta de ejemplo sql

Extracción con Python mediante la API de exportación incremental

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice su gestión de problemas para resolver antes las incidencias de TI

Su Template de datos de gestión de problemas

Su Template de datos de gestión de problemas

Atributos de la gestión de problemas

Actividades de la gestión de problemas

Guías de extracción

Exportación del historial de actualizaciones de Zendesk Explore

Pasos

Configuración

a Consulta de ejemplo config

Consulta SQL mediante Zendesk Data Sharing

Pasos

Configuración

a Consulta de ejemplo sql

Extracción con Python mediante la API de exportación incremental

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice su gestión de problemas para resolver antes las incidencias de TI

Valoramos su privacidad