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

Su Template de datos para la gestión de problemas

Zendesk Support

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

Su Template de datos para la gestión de problemas

Este Template ofrece un marco completo para representar 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 causas raíz. Con esta estructura, puede crear un Registro de eventos de alta calidad y obtener información más detallada sobre el proceso.

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

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

Descargar Template

Atributos de gestión de problemas

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

5 Obligatorio 8 Recomendado 6 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento o la acción realizada en el registro del problema.
Descripción Este atributo registra el paso o la acción específica que se realiza durante el ciclo de vida del registro del 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 del proceso. Su secuencia permite 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 Se obtiene de las auditorías de tickets o las métricas de tickets de Zendesk Ejemplos Registro del problema creadoInvestigación iniciadaSolución provisional publicada
	Hora de inicio EventTimestamp	Fecha y hora exactas en que ocurrió una actividad.
Descripción Este atributo registra el momento exacto en que se realizó una actividad en Zendesk. Aporta la dimensión temporal necesaria para ordenar correctamente los eventos y calcular la duración entre pasos. En el análisis, es fundamental para calcular los tiempos de ciclo, identificar demoras, comprobar el cumplimiento de los SLA y visualizar el proceso a lo largo del tiempo. Sin marcas de tiempo precisas, es imposible conocer 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 tickets de Zendesk, campo 'created_at' Ejemplos 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Registro del problema ProblemRecordId	Identificador numérico único asignado al ticket del problema en Zendesk.
Descripción Este atributo representa la clave única del registro del problema en Zendesk Support. Es el ID del caso central para Process Mining y permite agrupar todos los eventos, las actualizaciones y las interacciones posteriores en una sola instancia del proceso. En el análisis, este ID permite distinguir cada investigación del problema, desde su creación hasta su cierre. También permite relacionar los incidentes asociados y seguir el ciclo de vida del problema a través de los distintos niveles de soporte. Por qué es importante Es la clave obligatoria fundamental para agrupar eventos en casos en cualquier análisis de Process Mining. Dónde obtenerlo Objeto Ticket de Zendesk, 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 caso, siempre tendrá el valor 'Zendesk Support'. En el análisis, especialmente al combinar datos de varios sistemas (por ejemplo, Zendesk y Jira), este campo permite filtrar o agrupar los datos según su origen. Garantiza la trazabilidad de los datos en las vistas de procesos que abarcan varios sistemas. Por qué es importante Garantiza la trazabilidad de los datos y permite configurar Process Mining para varios sistemas. Dónde obtenerlo Se establece durante la extracción Ejemplos Zendesk Support
	Última actualización de los datos LastDataUpdate	Marca de tiempo que indica cuándo se modificó por última vez el registro del problema.
Descripción Este atributo refleja la última vez que se actualizaron los datos del registro del problema en el sistema de origen. Se diferencia de la marca de tiempo del evento porque corresponde al registro, no a la actividad. En el análisis, permite determinar si los datos están actualizados. Se utiliza para comprobar si el conjunto de datos está al día o si hay retrasos de sincronización entre el sistema de origen y el entorno de Process Mining. Por qué es importante Permite hacer un seguimiento de la actualización de los datos y facilita las estrategias de carga incremental. Dónde obtenerlo Objeto Ticket de Zendesk, campo 'updated_at' Ejemplos 2023-11-01T14:20:00Z
	Cantidad de incidentes relacionados RelatedIncidentCount	Cantidad de tickets de incidentes vinculados a este registro del problema.
Descripción Este atributo cuenta los tickets de incidentes asociados a este registro del problema. En Zendesk, se gestionan 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 a más usuarios y orienta las decisiones estratégicas sobre qué correcciones reducirán más el volumen de tickets y ofrecerán el mayor retorno de la inversión. Por qué es importante Indica la magnitud del problema y su impacto en los usuarios. Dónde obtenerlo API de tickets de Zendesk, cantidad de tickets donde type='incident' y problem_id=ThisID Ejemplos 015342
	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. Por lo general, se completa durante la actividad «Causa raíz identificada». 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 las iniciativas de mejora a largo plazo. Dónde obtenerlo Campos personalizados de tickets de Zendesk Ejemplos Error de softwareError de configuraciónError del usuario
	Categoría del problema ProblemCategory	Clasificación del problema (por ejemplo, software, hardware o red).
Descripción Este atributo clasifica el problema según el servicio afectado o la pila tecnológica. Suele ser un campo desplegable personalizado en los formularios de Zendesk. En el análisis, se utiliza para el Dashboard «Precisión de la categorización de problemas». Comparar esta categoría inicial con la causa raíz final permite determinar si la clasificación inicial dirige los problemas a los equipos adecuados. Por qué es importante Permite segmentar los datos por tecnología o servicio empresarial. Dónde obtenerlo Campos personalizados de tickets de Zendesk Ejemplos Base de datosInterfaz de usuario y experiencia de usuarioInfraestructura de red
	Estado del problema ProblemStatus	Estado actual del registro del problema en su ciclo de vida.
Descripción Este atributo muestra el estado actual del problema, como Nuevo, Abierto, Pendiente, Resuelto o Cerrado. Refleja el progreso de la investigación. En el análisis, se utiliza para filtrar los casos abiertos y cerrados. Es esencial para el Dashboard de supervisión de registros de problemas estancados, que permite identificar los casos activos que no avanzan por los estados previstos del ciclo de vida. Por qué es importante Permite filtrar los casos según su estado de finalización. Dónde obtenerlo Objeto Ticket de Zendesk, campo 'status' Ejemplos nuevoabiertopendienteresueltocerrado
	Fecha límite del SLA SlaDueDate	Fecha y hora límite para resolver el problema.
Descripción Este atributo representa la fecha límite de resolución según la configuración del acuerdo de nivel de servicio. Suele calcularse a partir de la prioridad y 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 del SLA, que destaca 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 Endpoint de métricas de tickets o políticas de SLA de Zendesk Ejemplos 2023-12-01T17:00:00Z
	Grupo de soporte SupportGroup	Equipo o departamento asignado actualmente al registro del 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 traspasos entre grupos de soporte. Permite medir el rendimiento de cada equipo, identificar cuellos de botella en los traspasos y analizar la distribución de la carga de trabajo. Por qué es importante Permite analizar la organización e identificar cuellos de botella entre departamentos. Dónde obtenerlo Objeto Ticket de Zendesk, 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 responsable actualmente del registro del problema. Permite saber con precisión quién realizó cada acción. En el análisis, ayuda a comprender la carga de trabajo y el rendimiento individuales. Aunque es habitual analizar los datos por grupo, los datos de cada persona asignada pueden revelar necesidades de formación o identificar a quienes resuelven con especial eficacia las causas raíz complejas. Por qué es importante Permite analizar los recursos a nivel individual. Dónde obtenerlo Objeto Ticket de Zendesk, campo 'assignee_id' (resuelto al nombre) Ejemplos Juan PérezAna GarcíaSistema
	Prioridad Priority	Nivel de urgencia asignado al registro del problema.
Descripción Este atributo indica la importancia relativa del problema, que suele clasificarse como baja, normal, alta o urgente. Determina los acuerdos de nivel de servicio (SLA) esperados y la asignación de recursos. En el análisis, se utiliza para segmentar el proceso y comparar el rendimiento según el nivel de urgencia. Por ejemplo, permite comprobar si los problemas urgentes se resuelven realmente más rápido que los de prioridad baja, como requiere el Dashboard de velocidad de investigación de causas raíz. Por qué es importante Es esencial para segmentar los casos, analizar el cumplimiento de los SLA y priorizar los recursos. Dónde obtenerlo Objeto Ticket de Zendesk, campo 'priority' Ejemplos UrgenteAltaNormalBaja
	Asunto del problema ProblemSubject	Resumen breve o título del registro del problema.
Descripción Este atributo contiene el resumen escrito cuando se creó el problema. Normalmente describe el síntoma o el asunto que se está investigando. En el análisis, ofrece contexto al analizar casos específicos. También se pueden aplicar 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 Aporta contexto legible para cada caso. Dónde obtenerlo Objeto Ticket de Zendesk, campo 'subject' Ejemplos No se pueden procesar pagos en la región de la UEPicos de latencia en el servidor de inicio de sesiónError al exportar datos para usuarios administradores
	ID de la solicitud de cambio ChangeRequestId	Identificador de la solicitud de cambio vinculada para implementar la solución.
Descripción Este atributo vincula el registro del problema con un registro de gestión de cambios, que puede estar en otro sistema o corresponder a otro tipo de ticket. Indica que se ha iniciado un proceso formal de cambio. En el análisis, permite consultar el Dashboard «Tasa de inicio de solicitudes de cambio». Ayuda a seguir el paso del diagnóstico a la implementación y a comprobar que las causas raíz identificadas den lugar a acciones formales de cambio. Por qué es importante Vincula el proceso de gestión 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 se ha documentado el conocimiento obtenido al resolver el problema. En el análisis, la presencia de este campo se utiliza para calcular la «Tasa de integración de la base de conocimientos». Permite comprobar si la organización cierra el ciclo de aprendizaje al documentar soluciones para consultarlas en el futuro. Por qué es importante Mide la eficacia de los procesos de gestión del conocimiento. Dónde obtenerlo Campos personalizados de tickets de Zendesk o contenido vinculado Ejemplos 360045889KB-2991
	Sin actividad reciente IsStale	Indica si el problema lleva más de 14 días sin actividad.
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 «Seguimiento de registros de problemas sin actividad reciente». Ayuda a los responsables a localizar rápidamente los casos desatendidos que saturan el trabajo pendiente y que quizá deban cerrarse administrativamente o reasignarse. Por qué es importante Ayuda a identificar el desperdicio en los procesos y el trabajo desatendido. Dónde obtenerlo Se calcula en la herramienta de Process Mining: (Now - LastDataUpdate) > 14 days Ejemplos truefalse
	Solución temporal activa WorkaroundActive	Indicador de si se ha proporcionado o publicado una solución temporal.
Descripción Este atributo booleano indica si se documentó una solución temporal para el problema. A menudo, se obtiene de la presencia de la actividad «Solución temporal publicada» o de una casilla específica del formulario. En el análisis, se utiliza para el Dashboard «Cumplimiento de publicación de soluciones temporales». 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 temporal publicada» o de un campo personalizado Ejemplos truefalse
	Tiene revisión posterior a la implementación 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» aparece en el historial del caso. En el análisis, permite consultar el Dashboard «Cobertura de revisiones posteriores a la implementación». Es una métrica de cumplimiento que permite comprobar si la organización aprende de sus problemas más importantes. Por qué es importante Permite verificar 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 gestión de problemas

Registre estos pasos esenciales del proceso y los 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	Asignación del registro del 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 el Dashboard de análisis de traspasos entre grupos de soporte, que mide los tiempos de espera entre departamentos. Dónde obtenerlo Supervise los cambios en el campo 'group_id' del registro de auditoría del ticket. Capturar Se registra cuando se ejecuta la transacción Group Assignment Change Tipo de evento explicit
	Causa raíz identificada	Momento en que se determina la causa subyacente del problema. Normalmente se registra cuando el agente completa un campo de texto personalizado o una lista desplegable de categorías llamado 'Root Cause'.
Por qué es importante Es un hito fundamental para el Dashboard de velocidad de investigación de causas raíz y para medir la eficiencia del diagnóstico. Dónde obtenerlo Supervise los cambios en los campos personalizados llamados 'Root Cause', 'RCA' o 'Problem Source' para detectar valores no nulos. Capturar Compare los valores de los campos personalizados para comprobar si se han completado Tipo de evento inferred
	Corrección permanente aplicada	Indica que la solución técnica se ha implementado en el entorno. Suele registrarse mediante un cambio de estado personalizado o una etiqueta específica antes de que el ticket se marque como resuelto.
Por qué es importante Es esencial para el Dashboard de eficiencia de implementación de correcciones, que mide 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. Capturar Supervise las etiquetas o las listas desplegables de estado personalizadas Tipo de evento inferred
	Investigación iniciada	Marca el paso de un estado pasivo de «Nuevo» a un estado de trabajo activo. 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 estancados y es el punto de partida del KPI de duración media del análisis de causas raíz. Dónde obtenerlo Se infiere cuando el estado del ticket cambia de «Nuevo» a «Abierto» o «Pendiente». Capturar Compare el campo de estado antes y después Tipo de evento inferred
	Registro del problema cerrado	Evento final del ciclo de vida: el ticket queda bloqueado y ya no se puede modificar. En Zendesk, suele ocurrir automáticamente 4 días después de que el estado pasa a Solved.
Por qué es importante Marca el final definitivo del ciclo de vida del registro y se utiliza para la conservación de datos y la elaboración de informes históricos. Dónde obtenerlo Se obtiene del cambio de estado del ticket a 'Closed'. Capturar Se registra cuando el estado cambia a Closed Tipo de evento explicit
	Registro del problema creado	Creación inicial del ticket del problema en Zendesk Support. Este evento registra la fecha y hora en que el problema se anotó por primera vez en el sistema y suele iniciar 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 del 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. Capturar Se registra cuando se ejecuta 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 se ha verificado la corrección y que el caso está completo.
Por qué es importante Es el punto final principal para calcular el rendimiento y el riesgo del SLA, así como la tasa de cumplimiento del SLA de problemas. Dónde obtenerlo Se obtiene del cambio de estado del ticket a 'Solved'. Capturar Se registra cuando el estado cambia a Solved Tipo de evento explicit
	Solución provisional publicada	Acción de documentar y compartir una solución temporal al problema. En Zendesk, suele registrarse mediante una etiqueta específica o un campo de casilla personalizado que indica que hay una solución provisional disponible.
Por qué es importante Es compatible con el Dashboard de cumplimiento de publicación de soluciones provisionales, que permite ofrecer un alivio temporal a los usuarios durante investigaciones prolongadas. Dónde obtenerlo Supervise la incorporación de la etiqueta 'workaround_published' o los cambios en un campo booleano personalizado llamado 'Workaround'. Capturar Compare los valores del campo personalizado o de la etiqueta Tipo de evento inferred
	Borrador de la solución propuesta	Creación de un artículo de la base de conocimientos a partir de la investigación del problema. Se infiere por el uso de la aplicación Zendesk Knowledge Capture o por la vinculación de un artículo nuevo.
Por qué es importante Es compatible con el KPI de tasa de integración de la base de conocimientos y fomenta el aprendizaje organizacional. Dónde obtenerlo Supervise los eventos relacionados con la integración 'Knowledge Capture' o etiquetas como 'kcs_draft'. Capturar Infiera el evento 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 previamente como resuelto vuelve a un estado abierto o activo. Esto indica que la corrección ha fallado o que la resolución se ha rechazado.
Por qué es importante Es compatible con el 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 cambia de 'Solved' a 'Open', 'New' o 'Pending'. Capturar 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 necesario para el KPI de frecuencia de revisiones posteriores a la implementación y permite garantizar 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'. Capturar Supervise el campo personalizado para comprobar si se ha completado Tipo de evento inferred
	Solicitud de cambio iniciada	Indica que se ha iniciado un proceso formal de gestión de cambios para resolver el problema. Suele inferirse cuando se completa un campo personalizado 'Change Request ID' o se vincula un ticket de tipo 'Change'.
Por qué es importante Permite hacer un seguimiento de la tasa de inicio de solicitudes de cambio y vincula 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 vínculo de tipo 'problem_change'. Capturar Supervise el campo personalizado para detectar la entrada 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 Reports en las versiones más recientes) y seleccione New query.
Cuando se le solicite elegir un conjunto de datos, seleccione Support, luego Updates History y, por último, Support: Updates History [default]. Este conjunto contiene los registros de eventos necesarios para Process Mining, no solo datos del estado actual.
En el panel Metrics, añada Count (Tickets) o Count (Updates) para confirmar que se están obteniendo 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 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 atributo calculado estándar. 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 que aparece en la sección Query más abajo.
Añada el nuevo atributo Activity Mapper al panel Rows. Filtre este atributo para excluir los valores NULL y eliminar el ruido irrelevante del sistema.
Añada más atributos al panel Rows para aportar contexto: Ticket > Priority, Ticket > Group, Ticket > Status y los campos personalizados que necesite para analizar las causas raíz o las categorías (por ejemplo, Ticket > Ticket tags o campos personalizados específicos).
En el panel Filters, defina el intervalo de tiempo con Time - Timestamp > Update - Date para cubrir el período que desea analizar (por ejemplo, Last 6 Months).
Haga clic en el icono Visualization type y seleccione Table. Si está disponible la opción, compruebe que la tabla no esté pivotada y tenga un formato plano; de lo contrario, asegúrese de que todos los atributos estén en la sección Rows.
Exporte el resultado haciendo clic en Export > CSV. Compruebe que esté marcada la casilla Keep attribute formatting para conservar los formatos de fecha y hora que necesita ProcessMind.

Configuración

Conjunto de datos: Support: Updates History (Importante: no utilice el conjunto de datos estándar Tickets, ya que solo muestra el estado actual).
Filtro de tiempo: Update - Date (Recomendación: últimos 90 a 180 días, según el volumen).
Tipo de ticket: Filtre exclusivamente por Problem para no mezclar incidencias y solicitudes de servicio.
Límite de filas: Las exportaciones de Zendesk Explore suelen estar limitadas a 50.000 filas. Si su conjunto de datos supera ese 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 de Zendesk, ya que no son campos estándar del sistema.
Permisos del sistema: Se requiere una licencia Explore Viewer o Explore Professional.

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

Confirmar los requisitos previos: Compruebe 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 suele estar alojada en Snowflake o Amazon Redshift.
Conectarse a la base de datos: Utilice el cliente SQL que prefiera (como DBeaver, DataGrip o la interfaz web nativa de Snowflake/Redshift) para conectarse al almacén de datos de Zendesk con las credenciales proporcionadas.
Identificar los campos personalizados: Antes de ejecutar la consulta, identifique los ID únicos de los campos personalizados que utiliza su proceso de gestión de problemas. En Zendesk, vaya a Admin Center > 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. Deberá sustituir con ellos los marcadores de posición de la consulta.
Revisar la consulta SQL: La consulta proporcionada utiliza una expresión de tabla común (CTE) llamada ProblemTickets para seleccionar y filtrar primero todos los registros de problemas. Esto mejora el rendimiento y la legibilidad. A continuación, la consulta principal utiliza UNION ALL para combinar los resultados de 12 instrucciones SELECT, una por cada actividad requerida.
Personalizar 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, defina 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 (por ejemplo, [Your 'Root Cause Category' field_id], [Your 'Change Request ID' field_id]) por los ID reales que identificó en el paso 3.
Ejecutar la consulta: Ejecute el script SQL modificado en la base de datos. El tiempo de ejecución dependerá del intervalo de fechas y del volumen de datos de los tickets.
Revisar la lógica de 'Proposed Solution Drafted': La consulta supone que la redacción de una solución queda registrada al completar un campo personalizado llamado [Your 'KB Article ID' field_id]. Si su proceso es distinto, por ejemplo, si utiliza una etiqueta o un comentario específico, deberá ajustar esta parte de la consulta.
Validar los datos: Cuando termine la consulta, revise brevemente los resultados. Compruebe que haya una cantidad razonable de filas, que estén presentes todas las columnas y que no haya valores NULL inesperados en columnas esenciales como ProblemRecordId y EventTimestamp.
Exportar el registro de eventos: Exporte todo el conjunto de resultados desde su cliente SQL a un archivo CSV. Compruebe que el archivo utilice la codificación UTF-8 y que los encabezados de columna coincidan con los nombres de atributos que requiere su herramienta de Process Mining.
Preparar la carga: Antes de cargar el archivo, compruebe que el CSV no tenga problemas de formato. Asegúrese de que los valores de fecha y hora de la columna EventTimestamp tengan un formato uniforme, 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 por tipo de ticket: La consulta está configurada para analizar únicamente los tickets cuyo type sea 'problem'. Esto es esencial para separar el proceso de gestión de problemas de las incidencias y otros tipos de tickets.
Filtro por intervalo de fechas: Se recomienda encarecidamente filtrar los datos por un período específico para controlar el rendimiento. La CTE inicial de la consulta incluye el marcador de posición created_at >= '[YYYY-MM-DD]'. Para un primer análisis, suele utilizarse un período 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 instancia de 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 esas actividades.
Latencia de los datos: Los datos de la base replicada no se actualizan en tiempo real. Por lo general, transcurren algunas horas entre un evento en Zendesk y su aparición en el almacén de datos. Téngalo en cuenta al analizar actividades recientes.

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: Compruebe que tenga 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 la terminal o el símbolo del sistema.
Generar un token de 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. Cópielo de inmediato y guárdelo en un lugar seguro, ya que no volverá a mostrarse.
Configurar el script de Python: Cree un archivo Python nuevo (por ejemplo, extract_zendesk_problems.py) y copie en él el script completo de la sección Query. Actualice las variables de marcador de posición al inicio del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN y START_TIME. Para la primera ejecución, asigne a START_TIME la marca de tiempo Unix de la fecha de inicio deseada para la extracción.
Asignar los ID de los campos personalizados: Identifique los ID numéricos de los campos personalizados que utiliza su proceso de gestión de problemas. 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 ID.
Ejecutar el script: Ejecútelo desde la terminal con el comando python extract_zendesk_problems.py. El script comenzará a obtener datos de la API Incremental Export de Zendesk.
Supervisar la ejecución: El script mostrará el progreso, incluido el número de tickets procesados y la marca de tiempo actual de los datos que está obteniendo. Gestionará automáticamente los límites de solicitudes de la API y hará pausas cuando sea necesario.
Obtener y transformar los datos: Primero, el script obtiene todos los tickets de problemas creados o actualizados desde START_TIME. Después, recupera el historial completo de auditoría de cada ticket, que contiene todos los cambios anteriores.
Generar el 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.
Gestionar las cargas incrementales: Después de la carga inicial completa, actualice la variable START_TIME en las ejecuciones posteriores con el valor end_time que se mostró al final de la última ejecución correcta. Así obtendrá solo los datos nuevos y actualizados, sin duplicados.
Revisar el resultado: Al finalizar, el script generará el archivo zendesk_problem_event_log.csv en el mismo directorio. Este CSV contiene el registro de eventos estructurado y listo para el análisis.
Preparar la carga: Abra el archivo CSV en una hoja de cálculo y compruebe su contenido. Antes de cargarlo en ProcessMind, asegúrese de que estén presentes y correctamente completadas todas las columnas requeridas (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate).

Configuración

Credenciales de la API de Zendesk: El script requiere el subdominio de Zendesk, la dirección de correo electrónico del usuario asociado al token de API y el propio token para autenticarse.
Hora de inicio: La variable START_TIME es una marca de tiempo Unix que define el inicio de la extracción de datos. Para la primera ejecución, asígnele una fecha pasada (por ejemplo, de hace 6 meses) para obtener datos históricos. En las ejecuciones posteriores, utilice la hora de finalización de la ejecución anterior para obtener datos incrementales.
Asignación de campos personalizados: El diccionario CUSTOM_FIELD_MAPPING es esencial. Debe sustituir los ID de marcador de posición por los ID reales de los campos personalizados de su instancia de Zendesk para registrar 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 del registro de eventos de gestión de problemas las incidencias, las tareas y las preguntas.
Límites de solicitudes 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 la pausa según su plan de Zendesk y el volumen de datos que extraiga.
Requisitos previos: Para ejecutar el script, necesita un entorno Python 3 con las bibliotecas requests y pandas. El token de API debe estar asociado a una cuenta con permiso para leer los datos de los tickets.

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()

¿Todo listo para comenzar?

Mejore la estabilidad de TI aplicando hoy esta plantilla a su entorno de Zendesk. Nuestro equipo puede ayudarle a perfeccionar la extracción de datos y dar los primeros pasos con Process Mining.

Volver a la guía de mejora

Descargar Template

Optimice la gestión de problemas para resolver incidencias de TI más rápido

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

Iniciar la prueba gratuita

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

Su Template de datos para la gestión de problemas

Su Template de datos para la gestión de problemas

Atributos de gestión de problemas

Actividades de gestión de problemas

Guías de extracción

Exportar el historial de actualizaciones de Zendesk Explore

Pasos

Configuración

Consulta de ejemplo config

Consulta SQL mediante Zendesk Data Sharing

Pasos

Configuración

Consulta de ejemplo sql

Extracción con Python mediante la API Incremental Export

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

Optimice la gestión de problemas para resolver incidencias de TI más rápido