Su Template de datos para la gestión de solicitudes de servicio
Su Template de datos para la gestión de solicitudes de servicio
Este es nuestro Template genérico de datos de Process Mining para Gestión de solicitudes de servicio. Utilice nuestros Templates específicos para cada sistema para obtener orientación más detallada.
Seleccione un sistema específico- Campos de datos estandarizados para realizar análisis coherentes en distintos sistemas.
- Actividades clave del proceso asignadas para lograr un descubrimiento completo del proceso.
- Una base versátil para optimizar cualquier Workflow de solicitudes de servicio.
Atributos de la gestión de solicitudes de servicio
| Nombre | Descripción | ||
|---|---|---|---|
| Actividad Activity | Nombre de una tarea, evento o cambio de estado específico que se produjo durante el ciclo de vida de la solicitud de servicio. | ||
| Descripción El atributo Actividad describe un paso o una acción específica realizada sobre una solicitud de servicio. Estas actividades forman los bloques secuenciales del proceso, como «Solicitud creada», «Solicitud asignada», «Trabajo en curso» y «Solicitud cerrada». Cada actividad representa un momento concreto del recorrido de una solicitud de servicio. Analizar las actividades es el núcleo del Process Mining. Permite descubrir y visualizar el flujo real del proceso. Al examinar la secuencia y la frecuencia de las actividades, los analistas pueden identificar rutas habituales, desviaciones del proceso estándar, cuellos de botella en los que las solicitudes quedan atascadas y ciclos de retrabajo en los que se repiten pasos innecesariamente. Por qué es importante Define los pasos del proceso y permite descubrir el flujo real, los cuellos de botella y las desviaciones. Dónde obtenerlo A menudo se obtiene de registros de cambios de estado, tablas de eventos o pistas de auditoría asociadas al objeto de solicitud de servicio. Ejemplos Solicitud de servicio creadaSolicitud asignadaSolicitud resueltaSolicitud de servicio cerrada | |||
| Hora de inicio StartTime | Marca de tiempo que indica cuándo comenzó una actividad o un evento. | ||
| Descripción La Hora de inicio registra la fecha y hora exactas en que comenzó una actividad específica. Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos y calcular la duración de las actividades y del ciclo de vida completo del caso. Cada actividad del proceso debería tener una Hora de inicio correspondiente para crear 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 cada actividad. Permite crear una visión temporal del proceso, destacar retrasos e 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 fundamental para ordenar correctamente los eventos y calcular todas las métricas relacionadas con el tiempo, como los tiempos de ciclo y los cuellos de botella. Dónde obtenerlo Se encuentra en las tablas del Registro de eventos o de la pista de auditoría, y suele registrarse 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 la solicitud de servicio CaseId | Identificador único de cada caso de solicitud de servicio. Se utiliza para seguir una solicitud individual desde su creación hasta su cierre. | ||
| Descripción El ID de la solicitud de servicio es la clave principal que identifica de forma única cada solicitud durante todo su ciclo de vida. Actúa como identificador del caso y vincula todas las actividades, los cambios de estado y los atributos relacionados en una instancia de proceso coherente. En el análisis de Process Mining, este ID es fundamental para reconstruir el recorrido completo de cada solicitud. Al agrupar todos los eventos bajo un CaseId común, los analistas pueden visualizar los flujos del proceso, calcular la duración de los casos e identificar variaciones en la forma de gestionar las distintas solicitudes. Es la base de cualquier análisis del 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 y obtener una visión completa del proceso de principio a fin. Dónde obtenerlo Normalmente se encuentra en la cabecera o en la tabla principal de transacciones de las solicitudes de servicio. Ejemplos SR-2023-00123REQ0045891TICKET-98765 | |||
| Sistema de origen SourceSystem | Identifica el sistema o la aplicación de donde proceden los datos de la solicitud de servicio. | ||
| Descripción El atributo Sistema de origen especifica el nombre de la plataforma de gestión de servicios de TI (ITSM) u otra aplicación de la que se extrajeron los datos. En entornos con varios sistemas, este campo ayuda a diferenciar las fuentes de datos y garantiza la claridad del linaje de los datos. Aunque no se utiliza directamente en la mayoría de los análisis de flujos de procesos, es fundamental para la gobernanza de datos, la validación y la resolución de problemas. Al combinar datos de varias 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 en la calidad de los datos entre distintas plataformas. Por qué es importante Es fundamental para la gobernanza de datos y la resolución de problemas, ya que aclara el origen de los datos, especialmente en entornos con varios sistemas integrados. Dónde obtenerlo Este valor suele añadirse durante el proceso de extracción de datos (ETL) y no es un campo propio del sistema de origen. Ejemplos ServiceNowJira Service ManagementZendesk | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica la última vez que se actualizaron los datos desde el sistema de origen. | ||
| Descripción Última actualización de datos proporciona la marca de tiempo de la extracción o actualización más reciente. Informa a los usuarios sobre la actualidad de los datos que analizan y les permite saber si el análisis refleja el estado actual o una instantánea anterior. Este atributo es esencial para la supervisión operativa y los informes, ya que aporta contexto sobre la actualidad de los insights generados. Ayuda a los usuarios a confiar en los datos y a tomar decisiones informadas basadas en su recencia. Por ejemplo, un panel que muestra datos actualizados hace una semana se interpretaría de forma distinta que uno actualizado hace una hora. Por qué es importante Indica la actualidad de los datos, algo esencial para garantizar que los análisis sean relevantes y se basen en información actualizada. Dónde obtenerlo Es un campo de metadatos que normalmente se genera y almacena durante el proceso de extracción de datos (ETL). Ejemplos 2023-10-27T08:00:00Z2023-10-26T23:59:59Z | |||
| Agente asignado AssignedAgent | Usuario o agente responsable en ese momento de trabajar en la solicitud de servicio. | ||
| Descripción El Agente asignado es la persona concreta responsable de gestionar la solicitud de servicio en un momento determinado. Una solicitud puede asignarse a distintos agentes durante su ciclo de vida. Este atributo es clave para analizar el rendimiento y la carga de trabajo. Permite a las organizaciones medir y comparar el rendimiento de cada agente, incluidos sus tiempos medios de resolución y el volumen de solicitudes que gestiona. También se utiliza para analizar las reasignaciones entre agentes, que pueden indicar problemas en la clasificación inicial, la especialización de los agentes o el equilibrio de la carga de trabajo. Por qué es importante Permite analizar el rendimiento individual de los agentes, la distribución de la carga de trabajo y la frecuencia de las reasignaciones entre agentes. Dónde obtenerlo Está disponible en el registro de la solicitud de servicio. Los cambios en este campo suelen registrarse en un registro de auditoría o una tabla de historial. Ejemplos John SmithJane Doeagent_user_123 | |||
| Equipo asignado AssignedTeam | Grupo o equipo de soporte responsable en ese momento de la solicitud de servicio. | ||
| Descripción El Equipo asignado hace referencia al grupo de soporte específico responsable de la solicitud de servicio. Las solicitudes suelen enrutarse entre distintos equipos, como una mesa de ayuda de nivel 1, un equipo de redes o un equipo de desarrollo de software, según los conocimientos necesarios. Analizar las transferencias entre equipos es una parte fundamental del Process Mining de la gestión de servicios. Este atributo permite visualizar las transferencias entre equipos y ayuda a identificar brechas de comunicación o retrasos. También permite comparar el rendimiento de los equipos, incluidos su eficiencia, volumen de solicitudes y capacidad para resolverlas sin más escalaciones. Por qué es importante Es fundamental para analizar las transferencias entre equipos, identificar retrasos en los traspasos y comparar el rendimiento de los equipos. Dónde obtenerlo Es un campo estándar del registro de la solicitud de servicio. Los cambios en este campo se registran en una pista de auditoría. Ejemplos Mesa de ayuda de nivel 1Operaciones de redSoporte de sistemas de RR. HH. | |||
| Estado de la solicitud RequestStatus | Estado actual o histórico de la solicitud de servicio en el momento de un evento, como «En curso» o «Cerrada». | ||
| Descripción El Estado de la solicitud indica la situación de la solicitud de servicio en un momento determinado de su ciclo de vida. Entre los estados habituales se encuentran Nueva, En curso, Pendiente, Resuelta y Cerrada. Este atributo ofrece una instantánea de la posición de la solicitud dentro del proceso general. Analizar el Estado de la solicitud es clave para comprender el flujo del proceso y las transiciones entre estados. Puede utilizarse para filtrar casos, identificar solicitudes atascadas en un estado concreto y medir el tiempo que pasan en cada estado. Por ejemplo, analizar cuánto tiempo permanecen las solicitudes en 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 y pone de relieve los cuellos de botella o retrasos del proceso. Dónde obtenerlo Está disponible en la tabla principal de solicitudes de servicio o en los registros del historial de estados. Ejemplos En cursoPendiente del clienteResueltoCerrado | |||
| Fecha límite del SLA SlaDueDate | Fecha y hora antes de las cuales se espera resolver la solicitud según su acuerdo de nivel de servicio (SLA). | ||
| Descripción La Fecha límite del SLA es una marca de tiempo objetivo calculada según el acuerdo de nivel de servicio asociado a la solicitud. Se determina a partir de factores como la prioridad, el tipo y la hora de creación de la solicitud, y define el plazo de resolución esperado. Este atributo es la base de todo análisis de cumplimiento de SLA. Al comparar el tiempo real de resolución con la Fecha límite del SLA, las organizaciones pueden determinar si una solicitud se resolvió a tiempo o si se incumplió el SLA. Es un KPI fundamental para medir la calidad del servicio y se utiliza para identificar problemas sistémicos que causan retrasos e incumplimientos. Por qué es importante Es el punto de referencia para medir el rendimiento. Se utiliza para calcular las tasas de cumplimiento de SLA e identificar las solicitudes que incumplen el objetivo. Dónde obtenerlo A menudo es un campo calculado del 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 | Nivel de prioridad asignado a la solicitud, que indica su impacto empresarial y urgencia. | ||
| Descripción La Prioridad de la solicitud es una clasificación que ayuda a los equipos de soporte a determinar el orden en que deben atender las solicitudes. Normalmente se basa en una combinación del impacto de la solicitud en el negocio y su urgencia. Los niveles habituales son Baja, Media, Alta y Crítica. Este atributo es fundamental para analizar el rendimiento y asignar recursos. Los analistas pueden comparar los tiempos de ciclo y el cumplimiento de los SLA entre distintos niveles de prioridad para comprobar que las solicitudes de alta prioridad se atienden correctamente. También ayuda a identificar si se están descuidando las solicitudes de baja prioridad o si los equipos de soporte siguen adecuadamente el sistema de priorización. Por qué es importante Es esencial para analizar si las solicitudes se atienden según su importancia empresarial y comprender cómo influye la prioridad en el tiempo de resolución. Dónde obtenerlo Normalmente es un campo estándar del registro principal de la solicitud de servicio. Ejemplos BajaMediaAltaCrítica | |||
| Tipo de servicio ServiceType | Categoría o tipo de servicio solicitado por el usuario. | ||
| Descripción Tipo de servicio clasifica la naturaleza de la solicitud de servicio. Puede incluir desde solicitudes de hardware nuevo o acceso a software hasta consultas generales o soporte técnico. Esta categorización ayuda a dirigir la solicitud al equipo adecuado y a comprender la demanda de los distintos servicios. En el análisis de procesos, Tipo de servicio es una dimensión eficaz para segmentar los datos. Al filtrar el mapa de procesos por distintos 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 orientar las iniciativas de mejora a categorías de servicio específicas. Por qué es importante Permite filtrar y comparar los procesos de distintas categorías de solicitudes, y revela cuellos de botella o ineficiencias específicos de cada tipo. Dónde obtenerlo Es un campo estándar del registro de la solicitud de servicio, normalmente vinculado a un catálogo de servicios. Ejemplos Solicitud de hardwareAcceso al softwareRestablecimiento de contraseñaConsulta general | |||
| ¿Se incumplió el SLA? IsSlaBreached | Indicador que señala si la solicitud de servicio se resolvió después de la fecha límite del SLA. | ||
| Descripción Este atributo booleano indica si la solicitud de servicio no cumplió el acuerdo de nivel de servicio definido. Su valor es true si la solicitud se resolvió después de «SlaDueDate» y false en caso contrario. Este atributo simplifica los informes y el análisis del cumplimiento del SLA. En lugar de realizar comparaciones de fechas en cada consulta, este indicador permite filtrar y agregar datos fácilmente. Es una métrica principal para los Dashboards centrados 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 analizar el rendimiento de los SLA, lo que facilita filtrar e informar sobre las solicitudes incumplidas. Dónde obtenerlo Es un atributo derivado que se calcula comparando la marca de tiempo de la resolución final con el campo «SlaDueDate» durante la transformación de datos. Ejemplos truefalse | |||
| Canal de envío SubmissionChannel | 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, mediante un portal de autoservicio, correo electrónico, llamada telefónica o API. Cada canal puede tener procesos asociados y expectativas de los usuarios diferentes. Analizar el proceso por canal de envío puede revelar insights importantes. Por ejemplo, las solicitudes enviadas mediante un portal de autoservicio pueden estar más estructuradas y resolverse más rápido que las enviadas por correo electrónico, que pueden requerir la introducción manual de datos. Este análisis puede ayudar a las organizaciones a promover los canales más eficientes o mejorar los procesos de los menos eficientes. Por qué es importante Ayuda a determinar si el método de envío influye en la eficiencia del proceso, el tiempo de resolución o la tasa de resolución en el primer contacto. Dónde obtenerlo Normalmente se encuentra como campo estándar del registro de la solicitud de servicio. Ejemplos PortalCorreo electrónicoTeléfonoChat | |||
| Código de resolución ResolutionCode | 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 ofrece una forma estructurada de clasificar el resultado de una solicitud de servicio. Algunos ejemplos son «Resuelta por el usuario», «Hardware reemplazado», «Software implementado» o «Solicitud duplicada». Normalmente, el agente introduce esta información al cerrar la solicitud. Estos códigos son valiosos para el análisis de causas raíz. Al analizar la frecuencia de los distintos códigos de resolución, las organizaciones pueden identificar problemas recurrentes, soluciones habituales y oportunidades para crear artículos de la base de conocimientos o resoluciones automatizadas. Por ejemplo, un número elevado de resoluciones de «Restablecimiento de contraseña» podría justificar la inversión en una herramienta de autoservicio para restablecer contraseñas. Por qué es importante Permite analizar las causas raíz al categorizar cómo se resuelven las solicitudes, lo que ayuda a identificar tendencias y áreas para una gestión proactiva de problemas. Dónde obtenerlo Es un campo que normalmente el agente completa manualmente al resolver o cerrar la solicitud de servicio. Ejemplos AtendidoError del usuarioCancelado por el usuarioYa no es necesario | |||
| Departamento de la persona solicitante RequestorDepartment | Departamento o unidad de negocio de la persona que envió la solicitud. | ||
| Descripción Este atributo identifica el departamento o la unidad de negocio de la persona que inició la solicitud de servicio. Aporta contexto organizativo a la solicitud. Analizar las solicitudes por departamento puede ayudar a identificar necesidades, tendencias o problemas específicos de cada departamento. Por ejemplo, un volumen elevado de un tipo concreto de solicitud en el departamento de Finanzas podría indicar la necesidad de formación específica o de una mejora del sistema. También permite elaborar informes de imputación de costes y comprender la demanda de servicios de TI en toda la organización. Por qué es importante Aporta contexto organizativo y permite analizar los patrones de solicitudes y la demanda de servicios por unidad de negocio. Dónde obtenerlo Normalmente, esta información se obtiene del perfil de usuario de la persona solicitante en el directorio de empleados o en el sistema ITSM. Ejemplos FinanzasRecursos humanosMarketingOperaciones de TI | |||
| Hora de finalización EndTime | Marca de tiempo que indica cuándo se completó una actividad o un evento. | ||
| Descripción La Hora de finalización registra la fecha y hora exactas en que terminó una actividad específica. Mientras que la Hora de inicio marca el comienzo, la Hora de finalización marca la conclusión y define la duración de un paso individual del proceso. No todos los eventos tienen una Hora de finalización diferenciada, ya que algunos pueden ser instantáneos. Este atributo es esencial para calcular el tiempo de procesamiento de cada actividad. 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 localizar las actividades que consumen más tiempo y que son candidatas principales a la optimización o automatización. Por qué es importante Permite calcular los tiempos de procesamiento de las actividades y ayuda a identificar qué pasos concretos del proceso consumen más tiempo. Dónde obtenerlo Se encuentra en las tablas del Registro de eventos o de la pista de auditoría. Si no está disponible explícitamente, puede ser necesario derivarlo utilizando la Hora de inicio de la actividad siguiente. Ejemplos 2023-10-26T10:05:12Z2023-10-26T15:00:45Z2023-10-28T09:20:00Z | |||
| Recuento de reasignaciones ReassignmentCount | Número total de veces que la solicitud se reasignó entre distintos agentes o equipos. | ||
| Descripción Recuento de reasignaciones es una métrica que suma el número de veces que una solicitud de servicio se transfirió de un agente o equipo a otro. Un recuento elevado puede indicar problemas como un enrutamiento inicial incorrecto, falta de conocimientos del agente o una asignación poco clara de la responsabilidad del proceso. Es un indicador clave de la ineficiencia del proceso. En Process Mining, esta métrica ayuda a cuantificar el «ping-pong» que experimenta una solicitud. Analizar los casos con un recuento elevado de reasignaciones puede revelar oportunidades para mejorar el proceso de triaje, reforzar la formación de los agentes o definir mejor las responsabilidades de los equipos, de modo que las solicitudes se enruten correctamente desde el primer momento. Por qué es importante Métrica clave para identificar la ineficiencia del proceso. Un número elevado de reasignaciones suele correlacionarse con tiempos de resolución más largos y una menor satisfacción de los usuarios. Dónde obtenerlo Esta es una métrica calculada que se obtiene contando el número de veces que cambia el campo «AssignedAgent» o «AssignedTeam» para un «CaseId» determinado. Ejemplos 0135 | |||
Actividades de la gestión de solicitudes de servicio
| Actividad | Descripción | ||
|---|---|---|---|
| Información solicitada | El agente encargado de atender la solicitud necesita información adicional de la persona solicitante para continuar. Normalmente, la solicitud pasa a un estado pendiente o en espera, lo que detiene el reloj de atención. | ||
| Por qué es importante Esta actividad pone de manifiesto las dependencias con la persona solicitante y es una de las principales causas de los tiempos de ciclo prolongados. Hacer un seguimiento de su frecuencia y duración revela brechas de comunicación. Dónde obtenerlo Se infiere a partir de un cambio de estado a uno como «Pendiente del cliente», «Esperando información del usuario» o «En espera». Recopilar Utilice la marca de tiempo del momento en que el estado de la solicitud cambia a uno que indica que está esperando al usuario. Tipo de evento inferred | |||
| Solicitud asignada | La solicitud de servicio se ha asignado a un agente o equipo de cumplimiento específico responsable de completar el trabajo. Esto marca la transición de la clasificación inicial a la cola de cumplimiento. | ||
| Por qué es importante Este es un hito fundamental para medir los KPI del tiempo hasta la asignación y comprender la distribución de la carga de trabajo entre equipos y personas. Dónde obtenerlo Este evento se captura mediante el seguimiento de los cambios en los campos «Responsable» o «Grupo asignado» del registro de auditoría o del historial de la solicitud. Recopilar Identifique la primera marca de tiempo en la que el campo del responsable o del grupo de asignación aparece cumplimentado. Tipo de evento explicit | |||
| Solicitud de servicio cerrada | La solicitud de servicio se cierra formalmente y pasa a un estado archivado en el que ya no pueden realizarse más acciones. Esta es la actividad final del 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 revelar retrasos en la confirmación de las soluciones. Dónde obtenerlo Normalmente corresponde a un cambio de estado final a «Cerrada», que suele producirse automáticamente después de un periodo determinado en el estado «Resuelta». Recopilar Utilice la marca de tiempo del Registro de eventos correspondiente al cambio de estado a «Cerrada». Tipo de evento explicit | |||
| Solicitud de servicio creada | Esta es la primera actividad del proceso y marca el envío 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, lo que genera un identificador de caso único. | ||
| Por qué es importante Esta actividad establece el inicio del ciclo de vida del proceso, algo fundamental para calcular el tiempo de ciclo general y analizar el volumen de solicitudes. Dónde obtenerlo Normalmente, se trata de un evento de creación explícito que aparece en la tabla principal de transacciones o tickets, con una marca de tiempo correspondiente al momento de creación del registro. Recopilar 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 que ya se había resuelto ha vuelto a un estado activo. Esto suele ocurrir cuando la persona solicitante indica que la solución no fue eficaz o que el problema ha reaparecido. | ||
| Por qué es importante Las solicitudes reabiertas son un indicador directo del retrabajo y de una baja tasa de resolución en el primer contacto. Analizar estos eventos es fundamental para mejorar la calidad del servicio. Dónde obtenerlo Se infiere a partir de un cambio de estado de «Resuelta» o «Cerrada» a un estado abierto o en curso. Recopilar Registre la marca de tiempo del momento en que el estado cambia de resuelto a activo. Tipo de evento inferred | |||
| Solicitud resuelta | El agente ha completado el trabajo de atención y considera que la solicitud de servicio ha sido satisfecha. La solicitud pasa al estado «Resuelta», lo que a menudo detiene el reloj del SLA. | ||
| Por qué es importante Este es el hito más importante del proceso de atención. El tiempo transcurrido desde la creación hasta la resolución es un KPI principal para medir el rendimiento. Dónde obtenerlo Casi siempre corresponde a un cambio de estado específico a «Resuelta» o «Atendida», registrado en el historial de la solicitud. Recopilar Utilice la marca de tiempo del Registro de eventos correspondiente al primer cambio de estado a «Resuelta» o su equivalente. Tipo de evento explicit | |||
| Trabajo en curso | El agente o equipo asignado ha comenzado a trabajar activamente para atender 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 atención activa. Analizar la duración de esta fase es clave para identificar ineficiencias del proceso. Dónde obtenerlo Normalmente se infiere a partir del primer cambio de estado a «En curso» o «Activo» después de la asignación. Recopilar Registre la marca de tiempo del primer cambio de estado a un estado activo, como «En curso», después de asignar la solicitud. Tipo de evento inferred | |||
| Aprobación solicitada | La solicitud de servicio se ha enviado a una persona aprobadora o a un grupo de aprobación designado y está pendiente de una decisión. Este paso es habitual en solicitudes con implicaciones económicas, de seguridad o de recursos. | ||
| Por qué es importante El seguimiento de esta actividad ayuda a identificar retrasos en la fase de aprobación, que a menudo constituye un cuello de botella importante antes de que pueda comenzar el trabajo de cumplimiento. Dónde obtenerlo A menudo, este evento se deduce de un cambio de estado a «Pendiente de aprobación» o «A la espera de aprobación» en el registro histórico de la solicitud. Recopilar Capture la marca de tiempo del momento en que el estado de la solicitud cambia a un estado pendiente de aprobación. Tipo de evento inferred | |||
| Dependencia externa activada | La solicitud de servicio se ha transferido a un proveedor externo o a otro departamento interno para que actúe. La solicitud pasa así a un estado de espera, pendiente de la respuesta de un tercero. | ||
| Por qué es importante Esto ayuda a aislar y medir los retrasos causados por terceros, algo fundamental para analizar el rendimiento con precisión y gestionar los SLA. Dónde obtenerlo Normalmente se infiere a partir de un cambio de estado a «Pendiente del proveedor» o «Esperando a un tercero», o de la asignación a un grupo específico del proveedor. Recopilar Identifique la marca de tiempo del momento en que el estado cambia a uno que indica una dependencia de terceros. Tipo de evento inferred | |||
| Información proporcionada | La persona solicitante ha respondido con la información necesaria, lo que permite al agente reanudar el trabajo. Normalmente, este evento saca la solicitud del estado pendiente. | ||
| Por qué es importante Esto marca el final de un periodo de espera provocado por el usuario. El tiempo entre «Información solicitada» y esta actividad es una métrica clave para analizar las dependencias. Dónde obtenerlo A menudo se infiere cuando el estado de una solicitud cambia de pendiente a activo, normalmente a raíz de un comentario o una actualización del usuario. Recopilar Registre la marca de tiempo del momento en que el estado vuelve a ser activo desde un estado pendiente del usuario. Tipo de evento inferred | |||
| Resolución confirmada | La persona solicitante ha confirmado activamente que el servicio se prestó de forma satisfactoria y que la solicitud está resuelta. Esto confirma positivamente que la resolución tuvo éxito. | ||
| 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 definitivo. Dónde obtenerlo Puede tratarse de un cambio de estado explícito o inferirse a partir de una respuesta positiva a una encuesta o de un comentario específico añadido por el usuario después de la resolución. Recopilar Identifique las marcas de tiempo de los eventos de confirmación del usuario, como un cambio de estado activado por este o una respuesta de encuesta vinculada. Tipo de evento inferred | |||
| SLA incumplido | Se ha incumplido un acuerdo de nivel de servicio basado en el tiempo, como el tiempo de respuesta o de resolución. Se trata de un evento calculado, no de una acción manual del usuario. | ||
| Por qué es importante Hacer un seguimiento de los incumplimientos de SLA es esencial para los informes de cumplimiento y para identificar las solicitudes que no se atienden a tiempo. Dónde obtenerlo 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. Recopilar Compare la marca de tiempo de resolución o respuesta con la fecha límite definida por el SLA. Si la fecha de resolución es posterior, genere este evento. Tipo de evento calculated | |||
| Solicitud aprobada | La solicitud de servicio ha sido aprobada formalmente por la parte requerida. Esta decisión permite que el proceso de cumplimiento avance a la siguiente etapa. | ||
| Por qué es importante Este evento marca un hito importante y concluye el subproceso de aprobación. El tiempo transcurrido entre «Aprobación solicitada» y «Solicitud aprobada» es un KPI crítico. Dónde obtenerlo Normalmente, este evento aparece en un registro de aprobaciones o se deduce de un cambio de estado de «Pendiente de aprobación» a un estado activo. Recopilar 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 se ha retirado antes de completar la atención. La cancelación puede iniciarla la persona solicitante o la mesa de servicio. | ||
| Por qué es importante Esto representa un final alternativo y no satisfactorio del proceso. Analizar las cancelaciones ayuda a entender por qué las solicitudes dejan de ser relevantes o se crean por error. Dónde obtenerlo Normalmente corresponde a un cambio de estado explícito a «Cancelada» o «Retirada» en el historial de estados de la solicitud. Recopilar Registre la marca de tiempo del momento en que el estado se actualiza a «Cancelada». Tipo de evento explicit | |||
| Solicitud reasignada | La responsabilidad de la solicitud de servicio se ha transferido de un agente o equipo a otro después de la asignación inicial. Esto suele indicar que la solicitud se dirigió al destino equivocado o que se produjo una escalación. | ||
| Por qué es importante Las reasignaciones frecuentes pueden indicar problemas en la clasificación inicial, las competencias de los agentes o la complejidad del proceso, y suelen prolongar los tiempos de resolución. Dónde obtenerlo Se registra haciendo un seguimiento de cualquier cambio en los campos «Responsable» o «Grupo asignado» después de la asignación inicial. Recopilar Registre cada marca de tiempo en la que se actualice el campo del responsable o del grupo asignado, excepto la asignación inicial. Tipo de evento explicit | |||
| Solicitud rechazada | La solicitud de servicio se ha denegado formalmente durante una fase de aprobación. Se trata de un estado terminal que detiene el proceso antes de que comience cualquier trabajo de cumplimiento. | ||
| Por qué es importante Analizar las solicitudes rechazadas ayuda a comprender los motivos de la denegación y puede revelar problemas relacionados con la definición de las solicitudes, las políticas o las expectativas de los usuarios. Dónde obtenerlo Normalmente, este evento se registra mediante un estado específico, como «Rechazada» o «Denegada», en el historial de estados de la solicitud. Recopilar Capture la marca de tiempo del momento en que el estado de la solicitud se actualiza a «Rechazada» o a 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 obtener instrucciones detalladas,
¿Listo para comenzar?
Empiece a optimizar su proceso de solicitudes de servicio. Elija una guía de extracción específica para su sistema y adapte su enfoque, o utilice esta plantilla genérica como punto de partida flexible para cualquier fuente de datos.
Empiece hoy a optimizar su gestión de solicitudes de servicio
Descubra las ineficiencias y acelere las resoluciones con información práctica y potente.
No se requiere tarjeta de crédito