Su Plantilla de Datos de Gestión de Solicitudes de Servicio
Su Plantilla de Datos de Gestión de Solicitudes de Servicio
Esta es nuestra plantilla genérica de datos de Process Mining para Gestión de Solicitudes de Servicio. Use nuestras plantillas específicas de sistema para una guía más detallada.
Seleccione un sistema específico- Campos de datos estandarizados para un análisis consistente entre sistemas.
- Actividades clave del proceso mapeadas para un descubrimiento integral del proceso.
- Una base versátil para optimizar cualquier flujo de trabajo de solicitudes de servicio.
Atributos de Gestión de Solicitudes de Servicio
| Nombre | Descripción | ||
|---|---|---|---|
| Actividad Activity | El nombre de una tarea específica, evento o cambio de estado que ocurrió dentro del ciclo de vida de la solicitud de servicio. | ||
| Descripción El atributo Actividad describe un paso o acción específica realizada en una solicitud de servicio. Estas actividades forman los bloques de construcción secuenciales del proceso, como 'Solicitud Creada', 'Solicitud Asignada', 'Trabajo en Curso' y 'Solicitud Cerrada'. Cada actividad representa un punto distinto en el tiempo en el recorrido de una solicitud de servicio. Analizar actividades es el núcleo del Process Mining. Permite el descubrimiento y la visualización del flujo de proceso real. Al examinar la secuencia y la frecuencia de las actividades, los analistas pueden identificar rutas comunes, desviaciones del proceso estándar, cuellos de botella donde las solicitudes se atascan y bucles de retrabajo donde los pasos se repiten innecesariamente. Por qué es importante Define los pasos del proceso, permitiendo el descubrimiento del flujo de proceso real, los cuellos de botella y las desviaciones. Dónde obtener A menudo se deriva de logs de cambio de estado, tablas de eventos o rastreos de auditoría asociados con el objeto de solicitud de servicio. Ejemplos Solicitud de Servicio CreadaSolicitud AsignadaSolicitud ResueltaSolicitud de Servicio Cerrada | |||
| Hora de Inicio StartTime | El timestamp que indica cuándo comenzó una *actividad* o un *evento*. | ||
| Descripción La Hora de Inicio registra la fecha y hora precisas en que comenzó una actividad específica. Esta marca de tiempo es crucial para ordenar los eventos cronológicamente y para calcular la duración de las actividades y el ciclo de vida general del caso. Cada actividad en el proceso debe tener una Hora de Inicio correspondiente para construir un registro de eventos preciso. En el análisis de procesos, la Hora de Inicio se utiliza para calcular indicadores clave de rendimiento como el tiempo de ciclo, el tiempo de espera entre actividades y el tiempo de procesamiento de la actividad. Permite la creación de una vista del proceso basada en el tiempo, resaltando los retrasos y ayudando a identificar qué pasos consumen más tiempo. Las marcas de tiempo precisas son fundamentales para cualquier análisis relacionado con el rendimiento. Por qué es importante Esta marca de tiempo es crítica para ordenar los eventos correctamente y calcular todas las métricas relacionadas con el tiempo, como los tiempos de ciclo y los cuellos de botella. Dónde obtener Se encuentra en el registro de eventos o en las tablas de seguimiento de auditoría, a menudo registrado como 'fecha de creación' o 'marca de tiempo del evento' para cada registro de actividad. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z | |||
| ID de Solicitud de Servicio CaseId | El identificador único para cada caso de solicitud de servicio. Se utiliza para rastrear una única solicitud desde su creación hasta su cierre. | ||
| Descripción El ID de Solicitud de Servicio es la clave principal que identifica de forma única cada solicitud de servicio a lo largo de su ciclo de vida. Actúa como el identificador de caso, vinculando todas las actividades relacionadas, cambios de estado y atributos en una instancia de proceso coherente. En el análisis de Process Mining, este ID es fundamental para reconstruir el recorrido de principio a fin de cada solicitud. Al agrupar todos los eventos bajo un CaseId común, los analistas pueden visualizar los flujos de proceso, calcular las duraciones de los casos e identificar variaciones en cómo se manejan las diferentes solicitudes. Es la piedra angular de cualquier análisis realizado sobre el proceso de gestión de solicitudes de servicio. Por qué es importante Este ID es esencial para unir todos los eventos de una solicitud de servicio, permitiendo una vista completa del proceso de principio a fin. Dónde obtener Típicamente se encuentra en el encabezado o en la tabla principal de transacciones para solicitudes de servicio. Ejemplos SR-2023-00123REQ0045891TICKET-98765 | |||
| Source System SourceSystem | Identifica el sistema o aplicación donde se originaron los datos de la solicitud de servicio. | ||
| Descripción El atributo de Sistema de Origen especifica el nombre de la plataforma de Gestión de Servicios de TI (ITSM) u otra aplicación de la cual se extrajeron los datos. En entornos con múltiples sistemas, este campo ayuda a diferenciar las fuentes de datos y asegura una clara trazabilidad de los datos. Si bien no se utiliza directamente en la mayoría de los análisis de flujo de procesos, es fundamental para la gobernanza de datos, la validación y la resolución de problemas. Al combinar datos de múltiples fuentes, este atributo permite a los analistas segmentar la vista del proceso por sistema, lo que puede revelar diferencias en la ejecución del proceso o la calidad de los datos entre diferentes plataformas. Por qué es importante Crucial para la gobernanza de datos y la resolución de problemas, aclara el origen de los datos, especialmente en entornos con múltiples sistemas integrados. Dónde obtener Este valor se añade típicamente durante el proceso de extracción de datos (ETL) y no es un campo inherente en el propio sistema de origen. Ejemplos ServiceNowJira Service ManagementZendesk | |||
| Última actualización de datos LastDataUpdate | La `timestamp` que indica la última vez que los `datos` se actualizaron desde el sistema de origen. | ||
| Descripción Última Actualización de Datos proporciona una marca de tiempo de la extracción o actualización de datos más reciente. Informa a los usuarios sobre la frescura de los datos que están analizando, asegurando que comprendan si el análisis refleja el estado actual o una instantánea pasada. Este atributo es esencial para el monitoreo operativo y la elaboración de informes, ya que proporciona contexto para la puntualidad de los insights generados. Ayuda a los usuarios a confiar en los datos y a tomar decisiones informadas basándose en su actualidad. Por ejemplo, un dashboard que muestra datos actualizados hace una semana se interpretaría de manera diferente a uno actualizado hace una hora. Por qué es importante Indica la frescura de los datos, lo cual es vital para asegurar que los análisis sean relevantes y se basen en información actualizada. Dónde obtener Este es un campo de metadatos típicamente generado y almacenado durante el proceso de extracción de datos (ETL). Ejemplos 2023-10-27T08:00:00Z2023-10-26T23:59:59Z | |||
| Agente Asignado AssignedAgent | El usuario individual o agente actualmente asignado para trabajar en la solicitud de servicio. | ||
| Descripción El Agente Asignado es la persona específica responsable de gestionar la solicitud de servicio en un momento dado. Una solicitud puede ser asignada a diferentes agentes a lo largo de su ciclo de vida. Este atributo es clave para el análisis de rendimiento y carga de trabajo. Permite a las organizaciones medir y comparar el rendimiento de los agentes individuales, incluyendo sus tiempos promedio de resolución y el volumen de solicitudes que manejan. También se utiliza para analizar las reasignaciones entre agentes, lo que puede indicar problemas con el triaje inicial, la especialización del agente o el equilibrio de la carga de trabajo. Por qué es importante Permite el análisis del rendimiento individual del agente, la distribución de la carga de trabajo y la frecuencia de reasignaciones entre agentes. Dónde obtener Disponible en el registro de la solicitud de servicio. Los cambios en este campo a menudo se rastrean en un log de auditoría o tabla de historial. Ejemplos John SmithJane Doeagent_user_123 | |||
| Equipo asignado AssignedTeam | El grupo o equipo de soporte actualmente asignado a la solicitud de servicio. | ||
| Descripción El Equipo Asignado se refiere al grupo de soporte específico responsable de la solicitud de servicio. Las solicitudes a menudo se enrutan entre diferentes equipos, como una mesa de ayuda de Nivel 1, un equipo de red o un equipo de desarrollo de software, dependiendo de la experiencia requerida. Analizar las transferencias entre equipos es una parte fundamental del Process Mining para la gestión de servicios. Este atributo permite la visualización de las transferencias de equipo a equipo, ayudando a identificar lagunas de comunicación o retrasos. También permite la evaluación comparativa del rendimiento entre equipos, comparando su eficiencia, volumen de solicitudes y capacidad para resolver solicitudes sin mayor escalada. Por qué es importante Crucial para analizar las transferencias de procesos entre equipos, identificar retrasos en las derivaciones y comparar el rendimiento del equipo. Dónde obtener Un campo estándar en el registro de solicitud de servicio. Los cambios en este campo se registran en un log de auditoría. Ejemplos Mesa de Servicio Nivel 1Operaciones de redSoporte de Sistemas de RR. HH. | |||
| Estado de Solicitud RequestStatus | El estado actual o histórico de la solicitud de servicio en el momento de un evento, como 'En Curso' o 'Cerrado'. | ||
| Descripción El Estado de la Solicitud indica el estado de la solicitud de servicio en un momento dado de su ciclo de vida. Los estados comunes incluyen Nuevo, En Curso, Pendiente, Resuelto y Cerrado. Este atributo proporciona una instantánea de dónde se encuentra la solicitud en el proceso general. Analizar el Estado de la Solicitud es clave para comprender el flujo del proceso y las transiciones de estado. Se puede utilizar para filtrar casos, identificar solicitudes estancadas en un estado particular y medir el tiempo transcurrido en cada estado. Por ejemplo, analizar cuánto tiempo permanecen las solicitudes en un estado 'Pendiente' puede revelar retrasos causados por la espera de información de usuarios o equipos externos. Por qué es importante Permite analizar cuánto tiempo pasan las solicitudes en cada estado, destacando cuellos de botella o retrasos en el proceso. Dónde obtener Disponible en la tabla principal de solicitudes de servicio o en los logs de historial de estado. Ejemplos En ProgresoPendiente de ClienteResueltoCerrado | |||
| Fecha de Vencimiento de SLA SlaDueDate | La fecha y hora en que se espera que la solicitud se resuelva según su Acuerdo de Nivel de Servicio (SLA). | ||
| Descripción La Fecha Límite de SLA es una marca de tiempo objetivo calculada en función del acuerdo de nivel de servicio asociado con la solicitud. Se determina por factores como la prioridad, el tipo y el tiempo de creación de la solicitud, definiendo el plazo de resolución esperado. Este atributo es la base para todo análisis de cumplimiento de SLA. Al comparar el tiempo de resolución real con la Fecha Límite de SLA, las organizaciones pueden determinar si una solicitud se resolvió a tiempo o si se incumplió el SLA. Este es un KPI crítico para medir la calidad del servicio y se utiliza para identificar problemas sistémicos que causan retrasos y conducen a incumplimientos. Por qué es importante Esta es la referencia para medir el rendimiento. Se utiliza para calcular las tasas de cumplimiento de SLA e identificar qué solicitudes se incumplen. Dónde obtener A menudo, un campo calculado en el registro de la solicitud de servicio, determinado por la política de SLA aplicada. Ejemplos 2023-10-28T17:00:00Z2023-11-01T09:00:00Z | |||
| Prioridad de la Solicitud RequestPriority | El nivel de prioridad asignado a la solicitud, indicando su impacto comercial y urgencia. | ||
| Descripción Prioridad de la Solicitud es una clasificación que ayuda a los equipos de soporte a determinar el orden en que deben manejar las solicitudes. Generalmente se basa en una combinación del impacto de la solicitud en el negocio y su urgencia. Los niveles de prioridad comunes incluyen Baja, Media, Alta y Crítica. Este atributo es vital para el análisis de rendimiento y la asignación de recursos. Los analistas pueden comparar los tiempos de ciclo y el cumplimiento del SLA entre diferentes niveles de prioridad para asegurar que las solicitudes de alta prioridad se estén manejando adecuadamente. También ayuda a identificar si las solicitudes de baja prioridad están siendo desatendidas o si el sistema de priorización está siendo seguido correctamente por los equipos de soporte. Por qué es importante Esencial para analizar si las solicitudes se manejan según la importancia del negocio y para comprender cómo la prioridad impacta el tiempo de resolución. Dónde obtener Típicamente un campo estándar en el registro principal de la solicitud de servicio. Ejemplos BajoMedioAltoCrítico | |||
| Tipo de Servicio ServiceType | La categoría o tipo de servicio solicitado por el usuario. | ||
| Descripción Tipo de Servicio clasifica la naturaleza de la solicitud de servicio. Esto puede ir desde solicitudes de nuevo hardware o acceso a software hasta consultas generales o soporte técnico. Esta categorización ayuda a enrutar la solicitud al equipo correcto y a comprender la demanda de diferentes servicios. En el análisis de procesos, el Tipo de Servicio es una dimensión potente para segmentar los datos. Al filtrar el mapa de procesos por diferentes tipos de servicio, las organizaciones pueden descubrir que ciertos tipos de solicitudes siguen procesos muy diferentes, tienen tiempos de ciclo más largos o experimentan más retrabajo. Este insight permite esfuerzos de mejora de procesos dirigidos para categorías de servicio específicas. Por qué es importante Permite filtrar y comparar procesos para diferentes categorías de solicitudes, revelando cuellos de botella o ineficiencias únicos para cada tipo. Dónde obtener Un campo estándar en el registro de solicitud de servicio, a menudo vinculado a un catálogo de servicios. Ejemplos Solicitud de HardwareAcceso a SoftwareRestablecimiento de ContraseñaConsulta General | |||
| ¿Se incumplió el SLA? IsSlaBreached | Un indicador que señala si la solicitud de servicio se resolvió después de su fecha límite de SLA. | ||
| Descripción Este atributo booleano indica si la solicitud de servicio no cumplió con su acuerdo de nivel de servicio definido. Es verdadero si la solicitud se resolvió después de la 'SlaDueDate', y falso en caso contrario. Este atributo simplifica los informes y análisis de cumplimiento de SLA. En lugar de realizar comparaciones de fechas en cada consulta, esta simple bandera permite un fácil filtrado y agregación. Es una métrica principal para dashboards que se centran en el rendimiento del SLA y ayuda a identificar rápidamente el volumen y el porcentaje de solicitudes que no cumplen los objetivos de servicio. Por qué es importante Proporciona un indicador claro y sencillo para el análisis del rendimiento del SLA, facilitando el filtrado y la generación de informes sobre las solicitudes incumplidas. Dónde obtener Este es un atributo derivado, calculado al comparar la marca de tiempo de resolución final con el campo 'SlaDueDate' durante la transformación de datos. Ejemplos truefalse | |||
| Canal de Presentación SubmissionChannel | El método o canal a través del cual se envió la solicitud de servicio. | ||
| Descripción El Canal de Envío indica cómo se creó la solicitud de servicio, por ejemplo, a través de un portal de autoservicio, correo electrónico, llamada telefónica o API. Diferentes canales pueden tener diferentes procesos asociados o expectativas de usuario. Analizar el proceso por canal de envío puede revelar información importante. Por ejemplo, las solicitudes enviadas a través de un portal de autoservicio podrían estar más estructuradas y resolverse más rápido que las enviadas por correo electrónico, que pueden requerir la entrada manual de datos. Este análisis puede ayudar a las organizaciones a promover canales más eficientes o a mejorar los procesos para aquellos menos eficientes. Por qué es importante Ayuda a determinar si el método de envío impacta la eficiencia del proceso, el tiempo de resolución o la tasa de resolución en el primer contacto. Dónde obtener Típicamente se encuentra como un campo estándar en el registro de la solicitud de servicio. Ejemplos PortalEmailTeléfonoChat | |||
| Código de Resolución ResolutionCode | Un código o categoría que indica el resultado final o el motivo del cierre de la solicitud. | ||
| Descripción El Código de Resolución proporciona una forma estructurada de clasificar el resultado de una solicitud de servicio. Ejemplos incluyen 'Resuelto por el Usuario', 'Hardware Reemplazado', 'Software Desplegado' o 'Solicitud Duplicada'. Esta información es típicamente ingresada por el agente al cerrar la solicitud. Estos códigos son valiosos para el análisis de causas raíz. Al analizar la frecuencia de diferentes códigos de resolución, las organizaciones pueden identificar problemas recurrentes, soluciones comunes y oportunidades para crear artículos de la base de conocimientos o resoluciones automatizadas. Por ejemplo, un alto número de resoluciones de 'Restablecimiento de Contraseña' podría justificar la inversión en una herramienta de autoservicio de restablecimiento de contraseña. Por qué es importante Permite el análisis de causas raíz al categorizar cómo se resuelven las solicitudes, ayudando a identificar tendencias y áreas para la gestión proactiva de problemas. Dónde obtener Un campo que suele ser rellenado manualmente por el agente al resolver o cerrar la solicitud de servicio. Ejemplos CumplidoError del UsuarioCancelado por el UsuarioYa No Requerido | |||
| Departamento del Solicitante RequestorDepartment | El departamento o unidad de negocio del usuario que envió la solicitud. | ||
| Descripción Este atributo identifica el departamento o unidad de negocio de la persona que inició la solicitud de servicio. Proporciona contexto organizacional a la solicitud. Analizar las solicitudes por departamento puede ayudar a identificar necesidades, tendencias o problemas específicos del departamento. Por ejemplo, un alto volumen de un cierto tipo de solicitud del departamento de Finanzas podría indicar la necesidad de capacitación dirigida o una mejora del sistema. También permite la elaboración de informes de contracargo y la comprensión de la demanda de servicios de TI en toda la organización. Por qué es importante Proporciona contexto organizacional, permitiendo el análisis de patrones de solicitud y demanda de servicio por unidad de negocio. Dónde obtener Esta información se extrae típicamente del perfil de usuario del solicitante en el directorio de empleados o sistema ITSM. Ejemplos FinanzasRecursos HumanosMarketingOperaciones de TI | |||
| Hora de Finalización EndTime | La marca de tiempo que indica cuándo se completó una actividad o evento. | ||
| Descripción La Hora de Finalización registra la fecha y hora precisas en que una actividad específica fue terminada. Mientras que la Hora de Inicio marca el comienzo, la Hora de Finalización marca la conclusión, definiendo la duración de un solo paso del proceso. No todos los eventos tienen una Hora de Finalización distinta, ya que algunos pueden ser instantáneos. Este atributo es esencial para calcular el tiempo de procesamiento de las actividades individuales. Al restar la Hora de Inicio de la Hora de Finalización, los analistas pueden medir cuánto tiempo dedican los agentes o sistemas a trabajar activamente en una tarea. Esto ayuda a identificar qué actividades específicas consumen mucho tiempo y son candidatos principales para la optimización o automatización. Por qué es importante Permite el cálculo de los tiempos de procesamiento de actividades, ayudando a identificar qué pasos específicos del proceso consumen más tiempo. Dónde obtener Se encuentra en el registro de eventos o en las tablas de seguimiento de auditoría. Puede que sea necesario derivarlo utilizando la hora de inicio de la siguiente actividad si no está explícitamente disponible. Ejemplos 2023-10-26T10:05:12Z2023-10-26T15:00:45Z2023-10-28T09:20:00Z | |||
| Recuento de Reasignaciones ReassignmentCount | El número total de veces que la solicitud fue reasignada entre diferentes agentes o equipos. | ||
| Descripción El recuento de reasignaciones es una métrica que suma el número de veces que una solicitud de servicio fue transferida de un agente o equipo a otro. Un recuento alto puede indicar problemas como un enrutamiento inicial incorrecto, falta de conocimiento del agente o una propiedad del proceso poco clara. Este es un indicador clave de ineficiencia del proceso. En Process Mining, esta métrica ayuda a cuantificar la cantidad de 'ping-pong' que experimenta una solicitud. Analizar casos con altos recuentos de reasignación puede revelar oportunidades para mejorar el proceso de triaje, mejorar la capacitación del agente o refinar las responsabilidades del equipo para asegurar que las solicitudes se enruten correctamente la primera vez. Por qué es importante Una métrica clave para identificar ineficiencias en el proceso. Un alto número de reasignaciones suele correlacionarse con tiempos de resolución más largos y la insatisfacción del usuario. Dónde obtener Esta es una métrica calculada, derivada al contar el número de veces que el campo 'Agente Asignado' o 'Equipo Asignado' cambia para un 'CaseId' dado. Ejemplos 0135 | |||
Actividades de Gestión de Solicitudes de Servicio
| Actividad | Descripción | ||
|---|---|---|---|
| En Curso | El agente o equipo asignado ha comenzado a trabajar activamente en el cumplimiento de la solicitud de servicio. Esto indica que la solicitud ha pasado de una cola a un estado de trabajo activo. | ||
| Por qué es importante Esta actividad marca el inicio del tiempo de cumplimiento activo. Analizar la duración de esta fase es clave para identificar ineficiencias en el proceso. Dónde obtener Esto se infiere comúnmente del primer cambio de estado a 'En Progreso' o 'Activo' después de la asignación. Capturar Capture la marca de tiempo del primer cambio de estado a un estado activo como 'En Curso' después de que se haya asignado la solicitud. Tipo de evento inferred | |||
| Información Solicitada | El agente de cumplimiento requiere información adicional del solicitante para continuar. La solicitud se coloca típicamente en un estado pendiente o en espera, pausando el reloj de cumplimiento. | ||
| Por qué es importante Esta actividad resalta las dependencias del solicitante y es una causa principal de los tiempos de ciclo prolongados. El seguimiento de su frecuencia y duración revela brechas de comunicación. Dónde obtener Esto se infiere de un cambio de estado a un estado como 'Pendiente de Cliente', 'Esperando Información del Usuario' o 'En Espera'. Capturar Utilice la marca de tiempo cuando el estado de la solicitud cambie a un estado que indique que está esperando al usuario. Tipo de evento inferred | |||
| Solicitud Asignada | La solicitud de servicio ha sido asignada a un agente o equipo de cumplimiento específico responsable de completar el trabajo. Esto marca la transición desde el triaje inicial a la cola de cumplimiento. | ||
| Por qué es importante Este es un hito crucial para medir los KPIs de tiempo de asignación y comprender la distribución de la carga de trabajo entre equipos e individuos. Dónde obtener Esto se captura rastreando los cambios en los campos 'Asignado a' o 'Grupo Asignado' en la pista de auditoría o registro de historial de la solicitud. Capturar Identifique la primera marca de tiempo donde se completa el campo de asignado o grupo de asignación. Tipo de evento explicit | |||
| Solicitud de Servicio Cerrada | La solicitud de servicio se cierra formalmente y se traslada a un estado archivado donde no se pueden realizar más acciones. Esta es la actividad final en el ciclo de vida. | ||
| Por qué es importante Esta actividad marca el final definitivo del proceso. El tiempo entre la resolución y el cierre puede resaltar los retrasos del proceso al confirmar soluciones. Dónde obtener Este suele ser un cambio de estado final a 'Cerrado', a menudo ocurriendo automáticamente después de un período de tiempo establecido en el estado 'Resuelto'. Capturar Utilice la marca de tiempo del registro de eventos cuando el estado cambia a 'Cerrado'. Tipo de evento explicit | |||
| Solicitud de Servicio Creada | Esta es la primera actividad en el proceso, que marca la presentación formal y el registro de una nueva solicitud de servicio. Se captura cuando un usuario envía una solicitud a través de un portal, correo electrónico u otro canal, generando un identificador de caso único. | ||
| Por qué es importante Esta actividad establece el inicio del ciclo de vida del proceso, lo cual es fundamental para calcular el tiempo de ciclo general y analizar los volúmenes de solicitudes. Dónde obtener Este es típicamente un evento de creación explícito que se encuentra en la tabla principal de transacciones o tickets, con marca de tiempo en el momento de la creación del registro. Capturar Utilice la marca de tiempo de creación del registro principal de la solicitud de servicio. Tipo de evento explicit | |||
| Solicitud Reabierta | Una solicitud de servicio previamente resuelta ha vuelto a un estado activo. Esto suele ocurrir cuando el solicitante indica que la solución no fue efectiva o que el problema ha reaparecido. | ||
| Por qué es importante Las solicitudes reabiertas son un indicador directo de retrabajo y de una baja tasa de resolución en el primer contacto. Analizar estos eventos es crucial para mejorar la calidad del servicio. Dónde obtener Esto se infiere de un cambio de estado de 'Resuelto' o 'Cerrado' de nuevo a un estado abierto o en progreso. Capturar Capture la marca de tiempo cuando el estado cambia de un estado resuelto a uno activo. Tipo de evento inferred | |||
| Solicitud Resuelta | El agente ha completado el trabajo de cumplimiento y considera que la solicitud de servicio ha sido satisfecha. La solicitud se coloca en un estado 'Resuelto', deteniendo a menudo el reloj del SLA. | ||
| Por qué es importante Este es el hito más crítico en el proceso de cumplimiento. El tiempo desde la creación hasta la resolución es un KPI principal para medir el rendimiento. Dónde obtener Este es casi siempre un cambio de estado distinto a 'Resuelto' o 'Completado' registrado en el registro de historial de la solicitud. Capturar Utilice la marca de tiempo del registro de eventos cuando el estado cambia por primera vez a 'Resuelto' o su equivalente. Tipo de evento explicit | |||
| Aprobación Solicitada | La solicitud de servicio ha sido enviada a un aprobador o grupo de aprobación designado y está a la espera de una decisión. Este paso es común para solicitudes que tienen implicaciones de costo, seguridad o recursos. | ||
| Por qué es importante El seguimiento de esta actividad ayuda a identificar retrasos en la fase de aprobación, lo cual es a menudo un cuello de botella significativo antes de que pueda comenzar el trabajo de cumplimiento. Dónde obtener Esto a menudo se infiere de un cambio de estado a 'Pendiente de Aprobación' o 'Esperando Aprobación' en el registro de historial de la solicitud. Capturar Capture la marca de tiempo cuando el estado de la solicitud cambia a un estado pendiente de aprobación. Tipo de evento inferred | |||
| Dependencia Externa Activada | La solicitud de servicio ha sido transferida a un proveedor externo o a un departamento interno diferente para su acción. Esto coloca la solicitud en un estado de espera pendiente de la respuesta del tercero. | ||
| Por qué es importante Esto ayuda a aislar y medir los retrasos causados por terceros, lo cual es fundamental para un análisis de rendimiento preciso y la gestión de SLA. Dónde obtener Esto se infiere típicamente de un cambio de estado a 'Pendiente de Proveedor' o 'Esperando a Terceros', o de una asignación a un grupo específico de proveedores. Capturar Identifique la marca de tiempo cuando el estado cambia a un estado que indica una dependencia de terceros. Tipo de evento inferred | |||
| Información Proporcionada | El solicitante ha respondido con la información necesaria, permitiendo al agente de cumplimiento reanudar el trabajo. Este evento típicamente saca la solicitud de un estado pendiente. | ||
| Por qué es importante Esto marca el final de un período de espera inducido por el usuario. El tiempo entre 'Información Solicitada' y esta actividad es una métrica clave para el análisis de dependencias. Dónde obtener Esto a menudo se infiere cuando el estado de una solicitud cambia de un estado pendiente de nuevo a uno activo, frecuentemente provocado por un comentario o actualización del usuario. Capturar Capture la marca de tiempo cuando el estado vuelve a un estado activo desde un estado pendiente del usuario. Tipo de evento inferred | |||
| Resolución Confirmada | El solicitante ha confirmado activamente que el servicio se ha entregado satisfactoriamente y la solicitud está resuelta. Esto proporciona una confirmación positiva de una resolución exitosa. | ||
| Por qué es importante Esta actividad proporciona datos valiosos para medir la satisfacción del cliente y valida la eficacia de la resolución antes del cierre final. Dónde obtener Esto puede ser un cambio de estado explícito o inferirse de una respuesta positiva a una encuesta o de un comentario específico añadido por el usuario después de la resolución. Capturar Identifique las marcas de tiempo de los eventos de confirmación del usuario, como un cambio de estado activado por el usuario o una respuesta de encuesta vinculada. Tipo de evento inferred | |||
| SLA Incumplido | Se ha violado un acuerdo de nivel de servicio (SLA) basado en el tiempo, como el tiempo de respuesta o el tiempo de resolución. Este es un evento calculado, no una acción manual del usuario. | ||
| Por qué es importante El seguimiento de los incumplimientos de SLA es esencial para la elaboración de informes de cumplimiento e identificar solicitudes que no se manejan de manera oportuna. Dónde obtener Algunos sistemas registran esto como un evento explícito. De lo contrario, debe calcularse comparando las marcas de tiempo de resolución con las marcas de tiempo objetivo del SLA. Capturar Compare la marca de tiempo de resolución o respuesta con la fecha límite de SLA definida. Si la fecha de resolución es posterior, genere este evento. Tipo de evento calculated | |||
| Solicitud Aprobada | La solicitud de servicio ha sido formalmente aprobada por la parte requerida. Esta decisión permite que el proceso de cumplimiento avance a la siguiente etapa. | ||
| Por qué es importante Esto marca un hito clave, que concluye el subproceso de aprobación. El tiempo entre 'Aprobación Solicitada' y 'Solicitud Aprobada' es un KPI crítico. Dónde obtener Este evento se encuentra generalmente en un registro de aprobación o se infiere de un cambio de estado de 'Pendiente de Aprobación' a un estado activo. Capturar Utilice la marca de tiempo del registro de aprobación o del evento de cambio de estado en el registro de auditoría de la solicitud. Tipo de evento explicit | |||
| Solicitud de Servicio Cancelada | La solicitud de servicio ha sido retirada antes de que se completara el cumplimiento. Esto puede ser iniciado por el solicitante o por la mesa de servicio. | ||
| Por qué es importante Esto representa un final alternativo y no exitoso del proceso. Analizar las cancelaciones ayuda a comprender por qué las solicitudes se vuelven irrelevantes o se crearon por error. Dónde obtener Este es típicamente un cambio de estado explícito a 'Cancelado' o 'Retirado' en el historial de estado de la solicitud. Capturar Capture la marca de tiempo cuando el estado se actualiza a un estado 'Cancelado'. Tipo de evento explicit | |||
| Solicitud Reasignada | La propiedad de la solicitud de servicio ha sido transferida de un agente o equipo a otro después de la asignación inicial. Esto a menudo indica una solicitud mal enrutada o una escalada. | ||
| Por qué es importante Las reasignaciones frecuentes pueden indicar problemas con el triaje inicial, las habilidades de los agentes o la complejidad del proceso, lo que a menudo lleva a tiempos de resolución más largos. Dónde obtener Esto se captura rastreando cualquier cambio en los campos 'Asignado a' o 'Grupo Asignado' después de que se haya producido la primera asignación. Capturar Capture cada marca de tiempo donde se actualiza el campo de asignado o grupo de asignación, excluyendo la asignación inicial. Tipo de evento explicit | |||
| Solicitud Rechazada | La solicitud de servicio fue formalmente denegada durante una fase de aprobación. Este es un estado terminal que detiene el proceso antes de que comience cualquier trabajo de cumplimiento. | ||
| Por qué es importante El análisis de solicitudes rechazadas ayuda a comprender las razones de la denegación y puede revelar problemas con las definiciones de las solicitudes, las políticas o las expectativas del usuario. Dónde obtener Esto se registra típicamente como un estado específico como 'Rechazado' o 'Denegado' en el historial de estado de la solicitud. Capturar Capture la marca de tiempo cuando el estado de la solicitud se actualiza a 'Rechazado' o un estado terminal similar. Tipo de evento explicit | |||
Guías de Extracción
Los métodos de extracción varían según el sistema. Para instrucciones detalladas,