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

Su `Template de Datos de Gestión de Problemas`

Zendesk Support

Atributos de Gestión de Problemas (20) Actividades de Gestión de Problemas (12) Guías de Extracción (3)

Su `Template de Datos de Gestión de Problemas`

Esta `template` proporciona un marco integral para mapear el ciclo de vida de su gestión de problemas dentro de Zendesk Support. Delinea los `atributos` esenciales, los hitos del proceso y la lógica de extracción necesaria para identificar `cuellos de botella` en el análisis de causa raíz. Siguiendo esta estructura, puede construir un `registro de eventos` de alta calidad para `insights` más profundos del proceso.

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

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

Descargar Plantilla

Atributos de 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 propiedad a lo largo de todo el ciclo de vida de resolución de problemas.

5 Requerido 8 Recomendado 7 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre del `event` o acción realizada sobre el registro del problema.
Descripción Este `atributo` captura el paso o acción específica realizada durante el ciclo de vida del registro del problema. Los ejemplos incluyen `cambios de estado` como 'Abierto' a 'Pendiente', `cambios de asignación` o pasos específicos del `workflow` como 'Solución Temporal Publicada'. En el análisis, esto forma los nodos del mapa de procesos. La secuencia de estas `actividades` 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, permitiendo la visualización del flujo del proceso y el análisis de variantes. Dónde obtener Derivado de las Auditorías de Tickets de Zendesk o de las Métricas de Tickets Ejemplos Registro de Problema AnotadoInvestigación IniciadaSolución Temporal Publicada
	Hora de Inicio EventTimestamp	La fecha y hora específicas en que ocurrió una actividad.
Descripción Este `atributo` registra el momento exacto en que una `actividad` tuvo lugar dentro del sistema Zendesk. Proporciona la dimensión temporal necesaria para secuenciar `events` correctamente y calcular duraciones entre pasos. En el análisis, esto es crítico para calcular tiempos de ciclo, identificar retrasos, verificar el `Cumplimiento` de `SLA` y visualizar el proceso a lo largo del tiempo. Sin `timestamps` precisos, es imposible comprender la velocidad del proceso de resolución de problemas. Por qué es importante Permite la clasificación de actividades y el cálculo de todos los KPI basados en tiempo. Dónde obtener Auditorías de Tickets de Zendesk, campo 'created_at' Ejemplos 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Registro de Problema ProblemRecordId	El identificador numérico único asignado al ticket de problema en Zendesk.
Descripción Este `atributo` representa la clave única para el registro de problemas dentro del sistema Zendesk Support. Sirve como el ID de Caso central para el `Process Mining`, permitiendo que todos los `events`, actualizaciones e interacciones posteriores se agrupen en una única instancia de proceso. En el análisis, este ID se utiliza para identificar de manera distintiva cada recorrido de investigación de problemas desde la creación hasta el cierre. Permite la correlación de `incidents` relacionados y el seguimiento del ciclo de vida del problema a través de varios niveles de soporte. Por qué es importante Es la clave fundamental obligatoria requerida para agrupar eventos en casos para cualquier análisis de 'process mining'. Dónde obtener Objeto de Ticket de Zendesk, campo 'id' donde el tipo es 'problema' Ejemplos 1045293849921
	Source System SourceSystem	El nombre del sistema donde se originaron los datos.
Descripción Este `atributo` identifica la plataforma de `software` de la cual se extrajeron los `data` del proceso. En este contexto, se rellenará consistentemente con 'Zendesk Support'. En el análisis, particularmente cuando se combinan `data` de múltiples sistemas (por ejemplo, Zendesk y Jira), este campo permite a los analistas filtrar o agrupar los `data` por su origen. Asegura la trazabilidad y el linaje de los `data` en vistas de proceso multisistema. Por qué es importante Asegura la trazabilidad de los datos y soporta configuraciones de 'process mining' multisistema. Dónde obtener Codificado rígidamente durante la extracción Ejemplos Zendesk Support
	Última actualización de datos LastDataUpdate	El `timestamp` que indica cuándo se modificó por última vez el registro de problema.
Descripción Este `atributo` refleja la hora más reciente en que se actualizaron los `data` del registro del problema en el sistema de origen. Es distinto del `timestamp` del `event`, ya que se refiere al nivel del registro en lugar del nivel de la `actividad`. En el análisis, esto ayuda a determinar la frescura de los `data`. Se utiliza para identificar si el `dataset` es actual o si existen desfases de sincronización entre el sistema de origen y el entorno de `Process Mining`. Por qué es importante Rastrea la frescura de los datos y ayuda en las estrategias de carga de datos incremental. Dónde obtener Objeto de Ticket de Zendesk, campo 'updated_at' Ejemplos 2023-11-01T14:20:00Z
	Categoría de Causa Raíz RootCauseCategory	La causa subyacente identificada del problema (por ejemplo, Defecto de Código, Error de Configuración).
Descripción Este `atributo` captura el diagnóstico final de lo que causó el problema. Generalmente se rellena durante la `actividad` 'Causa Raíz Identificada'. En el análisis, esto se utiliza para generar el informe de 'Precisión de Categorización de Problemas' y para analizar tendencias en fallos del sistema. Ayuda a la gerencia a comprender si deben centrarse en la calidad del código, la estabilidad de la infraestructura o la gestión de proveedores. Por qué es importante Permite el análisis de patrones de falla y dirige los esfuerzos de mejora a largo plazo. Dónde obtener Campos Personalizados de Tickets de Zendesk Ejemplos Error de Software`Error de Configuración`Error del Usuario
	Categoría del Problema ProblemCategory	La clasificación del problema (por ejemplo, Software, Hardware, Red).
Descripción Este `atributo` categoriza el problema basándose en el servicio o pila tecnológica afectada. Típicamente es un campo desplegable personalizado en los formularios de Zendesk. En el análisis, esto se utiliza para el `dashboard` de 'Precisión de Categorización de Problemas'. Comparar esta categoría inicial con la causa raíz final ayuda a identificar si el triaje inicial está dirigiendo los problemas correctamente a los equipos adecuados. Por qué es importante Permite la segmentación por tecnología o servicio de negocio. Dónde obtener Campos Personalizados de Tickets de Zendesk Ejemplos Base de `datos`UI/UXInfraestructura de Red
	Conteo de `Incidents` Relacionados RelatedIncidentCount	El número de tickets de incidente vinculados a este registro de problema.
Descripción Este `atributo` cuenta cuántos tickets de incidente individuales están asociados con este registro de problema. En Zendesk, esto se gestiona a través del campo 'problem_id' en los tickets de incidente que se vinculan a este registro. En el análisis, esta es la `métrica` principal para 'Correlación e Impacto de Incidentes'. Ayuda a priorizar problemas que están afectando al mayor número de usuarios, guiando las decisiones estratégicas sobre qué soluciones producirán el mayor `ROI` en términos de reducción del volumen de tickets. Por qué es importante Indica la magnitud y el impacto del problema en el usuario. Dónde obtener `API` de Tickets de Zendesk, recuento de tickets donde type='incident' y problem_id=ThisID Ejemplos 015342
	Estado del Problema ProblemStatus	El `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, esto se utiliza para filtrar entre `cases` abiertos y cerrados. Es vital para el `dashboard` de 'Monitoreo de Registros de Problemas Estancados' para identificar qué `cases` activos no están progresando a través del ciclo de vida de `estado` esperado. Por qué es importante Permite filtrar casos por su estado de finalización. Dónde obtener Objeto de Ticket de Zendesk, campo 'status' Ejemplos newabiertopendienteresueltocerrado
	Fecha de Vencimiento de SLA SlaDueDate	La `fecha` y hora objetivo para la resolución del problema.
Descripción Este `atributo` representa la fecha límite para la resolución basada en la configuración del Acuerdo de Nivel de Servicio. Generalmente se calcula en función de la `prioridad` y la hora en que se creó el ticket. En el análisis, esto se compara con el tiempo de resolución real para calcular la 'Tasa de Adherencia a `SLA` de Problemas'. Impulsa el `dashboard` de 'Rendimiento y Riesgo de `SLA`' al destacar los `cases` que se acercan o han excedido su tiempo asignado. Por qué es importante Es crítico para medir el cumplimiento y el rendimiento contractual. Dónde obtener Métricas de Tickets de Zendesk o `endpoint` de Políticas `SLA` Ejemplos 2023-12-01T17:00:00Z
	Grupo de Soporte SupportGroup	El equipo o departamento actualmente asignado al registro de problema.
Descripción Este `atributo` identifica el grupo específico de agentes responsables del problema en un momento dado. Cambia a medida que el ticket se transfiere de un equipo a otro. En el análisis, esto es crucial para el `dashboard` de 'Análisis de Transferencia de Grupo de Soporte'. Permite la medición del rendimiento por equipo, la identificación de `cuellos de botella` durante las transferencias y el análisis de la distribución de la `carga de trabajo` de recursos. Por qué es importante Permite el análisis organizacional y la identificación de cuellos de botella (bottlenecks) entre departamentos. Dónde obtener Objeto de Ticket de Zendesk, campo 'group_id' (resuelto a nombre) Ejemplos Soporte L2Equipo de Base de DatosOperaciones de red
	Nombre del Asignado AssigneeName	El agente específico asignado para trabajar en el problema.
Descripción Este `atributo` contiene el nombre del usuario individual que es actualmente responsable del registro de problema. Proporciona visibilidad granular sobre quién realizó acciones específicas. En el análisis, esto ayuda a comprender la `carga de trabajo` y el rendimiento individual. Si bien el análisis a nivel de grupo es común, los `data` a nivel de asignado pueden resaltar necesidades de capacitación o individuos que son particularmente efectivos en la resolución de `causas raíz` complejas. Por qué es importante Permite el análisis de recursos a nivel individual. Dónde obtener Objeto de Ticket de Zendesk, campo 'assignee_id' (resuelto a nombre) Ejemplos John DoeJane SmithSistema
	Prioridad Priority	El nivel de urgencia asignado al registro de problema.
Descripción Este `atributo` indica la importancia relativa del problema, típicamente categorizado como Bajo, Normal, Alto o Urgente. Impulsa los acuerdos de nivel de servicio (`SLAs`) esperados y la asignación de recursos. En el análisis, esto se utiliza para segmentar el proceso y comparar el rendimiento a través de diferentes niveles de urgencia. Por ejemplo, ayuda a verificar si los problemas 'Urgentes' se están resolviendo más rápido que los de prioridad 'Baja', según lo requiere el `dashboard` de 'Velocidad de Investigación de Causa Raíz'. Por qué es importante Es esencial para segmentar casos y analizar el cumplimiento del SLA y la priorización de recursos. Dónde obtener Objeto de Ticket de Zendesk, campo 'priority' Ejemplos UrgenteAltoNormalBajo
	Asunto del Problema ProblemSubject	El resumen corto o título del registro del problema.
Descripción Este `atributo` contiene el resumen de texto introducido cuando se creó el problema. Usualmente describe el síntoma o el problema que se está investigando. En el análisis, esto proporciona contexto al analista al profundizar en `cases` específicos. Las técnicas de minería de texto también pueden aplicarse aquí para agrupar problemas similares o identificar temas recurrentes que no están capturados por campos de categoría estructurados. Por qué es importante Proporciona contexto legible para casos individuales. Dónde obtener Objeto de 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ónLa exportación de datos falla para usuarios administradores
	Duración de la Investigación InvestigationDuration	El tiempo transcurrido desde el inicio de la investigación hasta la identificación de la causa raíz.
Descripción Este `atributo` calculado mide la duración de la fase central de diagnóstico. Calcula la diferencia de tiempo entre la `actividad` 'Investigación Iniciada' y la `actividad` 'Causa Raíz Identificada'. En el análisis, esta es la `métrica` principal para la 'Duración Promedio del Análisis de Causa Raíz'. Permite el `benchmarking` de la velocidad de diagnóstico entre diferentes grupos de soporte y categorías de problemas. Por qué es importante Mide la eficiencia del proceso de diagnóstico. Dónde obtener Calculado en la herramienta de Process Mining: Timestamp(Causa Raíz) - Timestamp(Inicio de Investigación) Ejemplos 48 horas5 días
	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 `fecha` de análisis) con el `timestamp` de la última `actividad`. En el análisis, esto impulsa el `dashboard` de 'Monitoreo de Registros de Problemas Estancados'. Ayuda a los gerentes a aislar rápidamente los `cases` desatendidos que saturan la cartera de problemas y pueden requerir un cierre administrativo o una reasignación. Por qué es importante Ayuda a identificar el desperdicio de procesos y los elementos de trabajo descuidados. Dónde obtener Calculado en la herramienta de Process Mining: (Actual - ÚltimaActualizaciónDeDatos) > 14 días Ejemplos truefalse
	ID de Solicitud de Cambio ChangeRequestId	El identificador de la solicitud de cambio vinculada para implementar la solución.
Descripción Este `atributo` vincula el registro del problema a un registro de Gestión de Cambios (potencialmente en otro sistema o un tipo de ticket diferente). Significa que se ha iniciado un proceso de cambio formal. En el análisis, esto apoya el `dashboard` de 'Tasa de Inicio de Solicitud de Cambio'. Ayuda a rastrear la transición del diagnóstico a la implementación, asegurando que las `causas raíz` identificadas resulten en acciones de cambio formales. Por qué es importante Vincula el proceso de problemas al proceso de gestión de cambios. Dónde obtener Campos Personalizados de Tickets de Zendesk o Tickets Vinculados Ejemplos CR-1002CHG00394
	ID del Artículo de Conocimiento KnowledgeArticleId	El ID del artículo de la base de conocimiento creado o vinculado al problema.
Descripción Este `atributo` almacena la referencia a un artículo de Zendesk Guide o a un elemento de conocimiento externo. Indica que el conocimiento obtenido del problema ha sido capturado. En el análisis, la presencia de este campo se utiliza para calcular la 'Tasa de Integración de Base de Conocimiento'. Verifica que la organización está cerrando el "bucle de aprendizaje" al documentar soluciones para futuras referencias. Por qué es importante Mide la efectividad de los procesos de gestión del conocimiento. Dónde obtener Campos Personalizados de Tickets de Zendesk o Contenido Vinculado Ejemplos 360045889KB-2991
	Solución Temporal Activa WorkaroundActive	Un indicador que señala si se ha proporcionado/publicado una solución temporal (workaround).
Descripción Este `atributo` booleano indica si se documentó una solución temporal para el problema. A menudo se deriva de la presencia de una `actividad` 'Solución Temporal Publicada' o una casilla de verificación específica en el formulario. En el análisis, esto se utiliza para el `dashboard` de '`Cumplimiento` de Publicación de Soluciones Temporales'. Mide con qué frecuencia el equipo de soporte proporciona alivio inmediato a los usuarios mientras continúa la investigación a largo plazo. Por qué es importante Es clave para medir la mitigación del impacto en el usuario durante las investigaciones. Dónde obtener Derivado de la presencia de la actividad 'Solución Temporal Publicada' o un Campo Personalizado Ejemplos truefalse
	Tiene PIR HasPostImplementationReview	Indica si se realizó una Revisión Post-Implementación.
Descripción Este `atributo` indica si el proceso de resolución de problemas incluyó una fase de revisión. Se deriva al verificar si la `actividad` 'Revisión Post-Implementación Realizada' existe en el historial del `case`. En el análisis, esto apoya el `dashboard` de 'Cobertura de Revisión Post-Implementación'. Es una `métrica` de `Cumplimiento` que asegura que la organización está aprendiendo de sus problemas mayores. Por qué es importante Valida el cumplimiento de los procesos de mejora continua. Dónde obtener Derivado de la presencia de la actividad 'Revisión Post-Implementación Realizada' Ejemplos truefalse

Requerido Recomendado Opcional

Actividades de Gestión de Problemas

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

8 Recomendado 4 Opcional

	Actividad	Descripción
	Asignado a Grupo de Soporte	El enrutamiento del registro de problema a un equipo técnico o departamento específico. Esto se rastrea cuando se actualiza el campo ID de Grupo en el ticket.
Por qué es importante Crítico para el 'dashboard' de Análisis de Transferencias (Handovers) del Grupo de Soporte para medir los tiempos de espera entre departamentos. Dónde obtener Supervise el campo 'group_id' en el `event log` de auditoría del ticket para detectar cambios. Capturar Registrado cuando se ejecuta la transacción 'Cambio de Asignación de Grupo' Tipo de evento explicit
	Causa Raíz Identificada	El punto donde se determina la causa subyacente del problema. Esto generalmente se captura cuando un campo de texto personalizado 'Causa Raíz' o una categoría desplegable es rellenado por el agente.
Por qué es importante Un hito crucial para el 'dashboard' de Velocidad de Investigación de Causa Raíz y para medir la eficiencia del diagnóstico. Dónde obtener Supervise los cambios en los campos personalizados etiquetados como 'Causa Raíz', 'RCA' o 'Origen del Problema' para valores no nulos. Capturar Comparar valores de campos personalizados para su población Tipo de evento inferred
	Investigación Iniciada	Marca la transición de un estado pasivo 'Nuevo' a un estado de trabajo activo. Esto indica que un agente ha reconocido el problema y ha iniciado el diagnóstico.
Por qué es importante Utilizado para calcular `métricas` de Registros de Problemas Obsoletos y es el punto de partida para el `KPI` de Duración Promedio del Análisis de Causa Raíz. Dónde obtener Inferido cuando el estado del ticket cambia de 'Nuevo' a 'Abierto' o 'Pendiente'. Capturar Compare el campo de estado antes/después Tipo de evento inferred
	Registro de Problema Anotado	La creación inicial del ticket de problema dentro de Zendesk Support. Este `event` captura el `timestamp` cuando el problema se registró por primera vez en el sistema, generalmente activando la instancia del proceso.
Por qué es importante Establece la hora de inicio para el Ciclo de Resolución de Principio a Fin y sirve como línea de base para todas las métricas de tiempo de entrega posteriores. Dónde obtener Derivado de la marca de tiempo 'created_at' en el objeto del ticket o de la primera entrada en el registro de auditoría del ticket. Capturar Registrado cuando se ejecuta la transacción 'Ticket Creado' Tipo de evento explicit
	Registro de Problema Cerrado	El `event` final del ciclo de vida donde el ticket se bloquea y no se pueden realizar más cambios. En Zendesk, esto suele ocurrir automáticamente 4 días después del estado Resuelto.
Por qué es importante Marca el fin absoluto de la vida del registro y se utiliza para la retención de datos e informes históricos. Dónde obtener Derivado del cambio de estado del ticket a 'Cerrado'. Capturar Registrado cuando el estado cambia a Cerrado Tipo de evento explicit
	Resolución Verificada	La marcación formal del problema como Resuelto. En Zendesk, esto ocurre cuando el `estado` estándar del sistema se establece en 'Resuelto', indicando que la solución está verificada y el `case` está completo.
Por qué es importante El `endpoint` principal para los cálculos de Rendimiento y Riesgo de `SLA` y la Tasa de Adherencia a `SLA` de Problemas. Dónde obtener Derivado del cambio de estado del ticket a 'Resuelto'. Capturar Registrado cuando el estado cambia a Resuelto Tipo de evento explicit
	Solución Permanente Aplicada	Significa que la solución técnica ha sido desplegada al entorno. Esto generalmente se rastrea a través de una transición de `estado` personalizada o una etiqueta específica antes de que el ticket esté completamente resuelto.
Por qué es importante Esencial para el 'dashboard' de Eficiencia en la Implementación de Soluciones para medir el tiempo desde el diagnóstico hasta el despliegue. Dónde obtener Inferido de una etiqueta específica (por ejemplo, 'fix_deployed') o de un campo de estado personalizado si existe. Capturar Supervise las etiquetas o los menús desplegables de `estado` personalizados Tipo de evento inferred
	Solución Temporal Publicada	La acción de documentar y compartir una solución temporal para el problema. En Zendesk, esto a menudo se captura a través de una etiqueta específica o un campo de casilla de verificación personalizado que indica que una solución temporal está disponible.
Por qué es importante Soporta el `dashboard` de `Cumplimiento` de Publicación de Soluciones Temporales, asegurando que se proporcione un alivio temporal a los usuarios durante investigaciones prolongadas. Dónde obtener Supervise la adición de una etiqueta 'workaround_published' o un cambio en un campo booleano personalizado llamado 'Solución Temporal'. Capturar Comparar valores de campos personalizados o etiquetas Tipo de evento inferred
	Investigación de Problema Reabierta	Ocurre cuando un registro de problema previamente marcado como "Resuelto" vuelve a un estado "Abierto" o activo. Esto indica una solución fallida o una resolución rechazada.
Por qué es importante Soporta el `KPI` de Tasa de Reapertura de Problemas y ayuda a identificar problemas de calidad en el proceso de resolución. Dónde obtener Inferido cuando el estado transiciona de 'Resuelto' de nuevo a 'Abierto', 'Nuevo' o 'Pendiente'. Capturar Compare el campo de estado antes/después Tipo de evento inferred
	Revisión Post-Implementación Realizada	Confirmando que se ha completado una revisión retrospectiva después de la corrección. Esto suele ser una casilla de verificación o un campo de fecha actualizado por el coordinador del proceso.
Por qué es importante Requerido para el `KPI` de Frecuencia de Revisión Post-Implementación para asegurar el `Cumplimiento` con los estándares de calidad. Dónde obtener Supervise las actualizaciones de una casilla de verificación personalizada 'PIR Completado' o un campo de `fecha` 'Fecha PIR'. Capturar Supervise el campo personalizado para su finalización Tipo de evento inferred
	Solicitud de Cambio Iniciada	Indica que se ha activado un proceso formal de gestión de cambios para solucionar el problema. Esto se infiere a menudo cuando se rellena un campo personalizado 'Change Request ID' o se vincula un ticket de tipo 'Change'.
Por qué es importante Rastrea la Tasa de Inicio de Solicitudes de Cambio y vincula la `Gestión de Problemas` con los `workflows` de `Gestión de Cambios`. Dónde obtener Supervise las actualizaciones de un campo personalizado como 'change_reference' o la creación de un tipo de enlace 'problem_change'. Capturar Supervise el campo personalizado para la entrada de ID externo Tipo de evento inferred
	Solución Propuesta Redactada	La creación de un artículo de base de conocimiento basado en la investigación del problema. Esto se infiere del uso de la aplicación Zendesk Knowledge Capture o de la vinculación de un nuevo artículo.
Por qué es importante Soporta el `KPI` de Tasa de Integración de Base de Conocimiento, asegurando el aprendizaje organizacional. Dónde obtener Supervise los `events` relacionados con la integración de 'Knowledge Capture' o etiquetas como 'kcs_draft'. Capturar Derivar de etiquetas de sistema específicas o eventos de enlace 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 navegue a la interfaz de informes de Explore a través de la bandeja de productos.
Haga clic en la carpeta 'Queries' (o 'Reports' en versiones más recientes) y seleccione 'New query'.
Cuando se le pida seleccionar un conjunto de datos, elija 'Support' seguido de 'Updates History' y luego 'Support: Updates History [default]'. Este conjunto de datos contiene los registros de eventos ('event logs') requeridos para el 'process mining' en lugar de solo datos de estado actual.
En el panel 'Metrics', añada 'Count (Tickets)' o 'Count (Updates)' para asegurar que se están extrayendo datos.
En el panel 'Filters', añada un filtro para 'Ticket > Ticket type' y seleccione 'Problem' para restringir 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 de 'Calculation' en la barra lateral derecha, seleccione 'Standard calculated attribute', nómbrelo 'Activity Mapper', y pegue el código proporcionado en la sección 'Query' a continuación.
Añada este nuevo atributo 'Activity Mapper' al panel 'Rows'. Filtre este atributo para excluir valores NULL y eliminar ruido irrelevante del sistema.
Añada atributos adicionales al panel 'Rows' para contexto: 'Ticket > Priority', 'Ticket > Group', 'Ticket > Status', y cualquier campo personalizado ('custom fields') requerido para el análisis de causa raíz o categoría (por ejemplo, 'Ticket > Ticket tags' o 'Custom Fields' específicos).
Establezca el rango de tiempo en el panel 'Filters' utilizando 'Time - Timestamp > Update - Date' para cubrir su ventana de análisis deseada (por ejemplo, 'Últimos 6 Meses').
Haga clic en el icono de 'Visualization type' y seleccione 'Table'. Asegúrese de que la tabla esté 'unpivoted' o plana si esa opción está disponible, o simplemente asegúrese de que todos los atributos estén en la sección 'Rows'.
Exporte el resultado haciendo clic en 'Export > CSV'. Asegúrese de que la casilla 'Keep attribute formatting' esté marcada para preservar los formatos de marca de tiempo para ProcessMind.

Configuración

Conjunto de datos: Support: Updates History (Crítico: No utilice el conjunto de datos estándar de '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 'Problema' para evitar mezclar 'Incidentes' 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 este límite, utilice el filtro 'Update - Date' para exportar en bloques mensuales más pequeños y fusionarlos externamente.
Campos Personalizados: Identifique los 'Field IDs' específicos para 'Causa Raíz', 'Solicitud de Cambio' y 'Solución Temporal' en su instancia particular de Zendesk, ya que estos no son campos de sistema estándar.
Permisos del Sistema: Requiere una licencia de '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 tiene habilitado el complemento 'Zendesk Data Sharing'. Confirme que tiene credenciales de acceso de solo lectura para la base de datos replicada de Zendesk, que típicamente se aloja en una instancia de Snowflake o Amazon Redshift.
Conexión a la Base de Datos: Utilice su cliente SQL preferido (como DBeaver, DataGrip o la interfaz web nativa de Snowflake/Redshift) para establecer una conexión con su 'data warehouse' de Zendesk utilizando las credenciales proporcionadas.
Identificación de Campos Personalizados: Antes de ejecutar la consulta, debe identificar los IDs únicos de los campos personalizados utilizados en su proceso de Gestión de Problemas. Navegue al 'Admin Center' en Zendesk, vaya a 'Objects and rules > Tickets > Fields'. Busque los campos para 'Causa Raíz', 'ID de Solicitud de Cambio', 'Solución Temporal Publicada', 'Corrección Permanente Aplicada' y 'Revisión Post-Implementación' para obtener sus IDs de campo específicos. Estos se usarán para reemplazar los marcadores de posición en la consulta.
Revisión de la Consulta SQL: La consulta proporcionada utiliza una 'Common Table Expression' (CTE) llamada ProblemTickets para seleccionar y filtrar primero todos los registros de problemas. Esto mejora el rendimiento y la legibilidad. La parte principal de la consulta luego utiliza UNION ALL para combinar los resultados de 12 declaraciones SELECT separadas, una para cada actividad requerida.
Personalización de la Consulta: Abra un nuevo editor de consultas y pegue el script SQL completo. Modifique los marcadores de posición dentro del script:
- En la CTE ProblemTickets, establezca el rango de fechas deseado reemplazando '[YYYY-MM-DD]'.
- Para cada actividad que depende de un campo personalizado, reemplace los IDs de marcador de posición (por ejemplo, [Su 'ID de campo de Categoría de Causa Raíz'], [Su 'ID de campo de Solicitud de Cambio']) con los IDs reales que identificó en el paso 3.
Ejecución de la Consulta: Ejecute el script SQL modificado contra la base de datos. El tiempo de ejecución variará dependiendo del rango de fechas y del volumen de datos de los tickets.
Investigar la Lógica de 'Solución Propuesta Redactada': La consulta asume que la redacción de una solución se captura al rellenar un campo personalizado llamado [Su 'ID de campo de Artículo de KB']. Si su proceso difiere, por ejemplo, utilizando una etiqueta o un comentario específico, deberá ajustar esta parte de la consulta en consecuencia.
Validación de Datos: Una vez que la consulta se complete, realice una breve revisión de los resultados. Verifique un número razonable de filas, asegúrese de que todas las columnas estén presentes y busque cualquier valor NULL inesperado en columnas críticas como ProblemRecordId y EventTimestamp.
Exportación del Registro de Eventos: Exporte todo el conjunto de resultados de su cliente SQL a un archivo CSV. Asegúrese de que el archivo utilice codificación UTF-8 y de 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, verifique el archivo CSV en busca de problemas de formato. Asegúrese de que los valores de fecha y hora en la columna EventTimestamp estén en un formato consistente, 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 donde el type es 'problema'. Esto es crítico para aislar el proceso de Gestión de Problemas de los incidentes y otros tipos de tickets.
Filtrado por Rango de Fechas: Es altamente recomendable filtrar los datos por un período específico para gestionar el rendimiento. La consulta incluye un marcador de posición created_at >= '[YYYY-MM-DD]' en la CTE inicial. Para un primer análisis, un rango de 3 a 6 meses es lo habitual.
Configuración de Campos Personalizados: Esta extracción depende en gran medida de su configuración específica de Zendesk. Debe identificar e insertar el field_id correcto para los campos personalizados que rastrean actividades como 'Causa Raíz Identificada', 'Solicitud de Cambio Iniciada' y 'Solución Temporal Publicada'. La consulta fallará o no devolverá datos para estas actividades si los IDs de los marcadores de posición no se reemplazan.
Latencia de Datos: Los datos en la base de datos replicada no son en tiempo real. Típicamente, hay un retraso de unas pocas horas entre la ocurrencia de un evento en Zendesk y su aparición en el 'data warehouse'. Tenga esto en cuenta al analizar actividad muy reciente.

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 instalado Python 3.6 o superior en su sistema. Instale las librerías requests y pandas necesarias ejecutando pip install requests pandas en su terminal o símbolo del sistema.
Generar el token de la API de Zendesk: Inicie sesión en Zendesk Support como administrador. Diríjase al Centro de administración > Aplicaciones e integraciones > API > API de Zendesk. En la sección Acceso por token, haga clic en "Agregar token de API" para crear uno nuevo. Copie este token de inmediato y guárdelo de forma segura, ya que no se volverá a mostrar.
Configurar el script de Python: Cree un nuevo archivo Python (por ejemplo, extract_zendesk_problems.py) y copie el script completo incluido en la sección de consulta. Actualice las variables de marcador de posición al inicio del script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN y START_TIME. Para la ejecución inicial, asigne a START_TIME el timestamp Unix de la fecha de inicio que desee para la extracción.
Mapear los ID de campos personalizados: Identifique los ID numéricos de los campos personalizados utilizados en su proceso de Gestión de problemas. Puede localizarlos en el Centro de administración > Objetos y reglas > Tickets > Campos, revisando la URL o las propiedades del campo. Actualice el diccionario CUSTOM_FIELD_MAPPING en el script con sus ID específicos.
Ejecutar el script: Ejecute el script desde su terminal con el comando python extract_zendesk_problems.py. El script comenzará a obtener datos de la API de exportación incremental de Zendesk.
Monitorear la ejecución: El script mostrará su progreso, incluyendo el número de tickets procesados y el timestamp actual que está consultando. Gestionará automáticamente los límites de frecuencia de la API pausando la ejecución cuando sea necesario.
Recuperación y transformación de datos: El script primero recupera todos los tickets de problemas creados o actualizados desde el START_TIME. Para cada ticket, obtiene el historial de auditoría completo con todos los cambios históricos.
Generación del registro de eventos: El script procesa cada evento de auditoría, mapeando los cambios de campo (como estado, grupo o actualizaciones de campos personalizados) con las actividades de negocio definidas. También recupera y almacena en caché los nombres de usuarios y grupos para enriquecer los datos.
Gestión de cargas incrementales: Tras la carga inicial completa, para las siguientes ejecuciones, actualice la variable START_TIME con el valor end_time impreso al final de la ejecución anterior exitosa. Así se asegurará de extraer solo datos nuevos o actualizados sin duplicados.
Revisar el resultado: Una vez que el script finalice, generará un archivo llamado zendesk_problem_event_log.csv en el mismo directorio. Este CSV contiene el registro de eventos estructurado y listo para el análisis.
Preparar para la carga: Abra el archivo CSV en una herramienta de hojas de cálculo para verificar su contenido. Asegúrese de que todas las columnas obligatorias (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) estén presentes y correctamente cumplimentadas antes de subirlas a ProcessMind.

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 con el token de API, y el propio token de API para la autenticación.
Hora de Inicio: La variable START_TIME es una marca de tiempo Unix epoch que define el punto de partida para la extracción de datos. Para la primera ejecución, configúrelo a una fecha en el pasado (por ejemplo, hace 6 meses) para obtener datos históricos. Para ejecuciones posteriores, utilice la hora final de la ejecución anterior para obtener datos de forma incremental.
Mapeo de Campos Personalizados: El diccionario CUSTOM_FIELD_MAPPING es crítico. Debe actualizar los IDs de los marcadores de posición con los IDs reales de los campos personalizados de su instancia de Zendesk para capturar correctamente actividades como 'Solución Temporal Publicada' y 'Causa Raíz Identificada'.
Filtro de Tipo de Ticket: El script está codificado para procesar solo tickets donde el type es 'problema'. Esto asegura que los incidentes, tareas y preguntas se excluyan del registro de eventos de gestión de problemas.
Límite de Tasa de API: El script incluye una función básica time.sleep(60) para manejar errores 429 de 'Too Many Requests'. La duración de esta pausa podría necesitar ajustarse según su plan de Zendesk y el volumen de datos que se extraen.
Requisitos previos: Un entorno Python 3 con las librerías requests y pandas es necesario para ejecutar el script. El token de API debe estar asociado con una cuenta que tenga permiso para leer los datos de los 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()

Su `Template de Datos de Gestión de Problemas`

Su `Template de Datos de Gestión de Problemas`

Atributos de Gestión de Problemas

Actividades de 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` vía Compartición de `Data` de Zendesk

Pasos

Configuración

a Consulta de ejemplo sql

Extracción de Python utilizando la `API` de Exportación Incremental

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice Su Gestión de Problemas para Soluciones de TI Más Rápidas

Su Template de Datos de Gestión de Problemas

Su Template de Datos de Gestión de Problemas

Atributos de Gestión de Problemas

Actividades de 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` vía Compartición de `Data` de Zendesk

Pasos

Configuración

a Consulta de ejemplo sql

Extracción de Python utilizando la `API` de Exportación Incremental

Pasos

Configuración

a Consulta de ejemplo python

Valoramos su privacidad

¿Listo para comenzar?

Optimice Su Gestión de Problemas para Soluciones de TI Más Rápidas

Su `Template de Datos de Gestión de Problemas`

Su `Template de Datos de Gestión de Problemas`