Su Template de datos para la gestión de reclamaciones
Su Template de datos para la gestión de reclamaciones
Este es nuestro Template genérico de datos de Process Mining para Gestión de siniestros. Utilice nuestros Templates específicos para cada sistema para obtener orientación más detallada.
Seleccione un sistema específico- Orientación estructurada sobre los atributos de datos esenciales.
- Actividades clave del proceso para obtener una visión completa del recorrido.
- Un marco flexible, aplicable a cualquier sistema de reclamaciones.
Atributos de la gestión de siniestros
| Nombre | Descripción | ||
|---|---|---|---|
| Hora de inicio StartTime | La marca de tiempo que indica cuándo comenzó una actividad o un evento específico. | ||
| Descripción La hora de inicio es una marca precisa de fecha y hora que indica el momento en que comenzó una actividad. Es un dato fundamental de cada evento del registro de procesos, ya que proporciona el contexto temporal necesario para analizar el rendimiento. En Process Mining, la hora de inicio es esencial para ordenar cronológicamente los eventos y reconstruir con precisión el recorrido del caso. Sirve de base para calcular indicadores clave de rendimiento, como los tiempos de ciclo, los tiempos de espera y los tiempos de procesamiento. Analizar las marcas de tiempo ayuda a identificar retrasos entre pasos, medir el cumplimiento de los acuerdos de nivel de servicio (SLA) y comprender la dinámica temporal del proceso de reclamaciones. Por qué es importante Esta marca de tiempo es esencial 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 Normalmente se registra en registros de eventos, pistas de auditoría o datos de transacciones, a menudo con etiquetas como «hora del evento» o «fecha de creación». Ejemplos 2023-03-15T09:00:00Z2023-05-20T14:35:10Z2023-07-01T11:21:05Z | |||
| ID de la reclamación ClaimId | El identificador único de una reclamación de seguro individual, que sirve como identificador principal del caso para Process Mining. | ||
| Descripción El ID de la reclamación es una clave única asignada a cada reclamación de seguro cuando se registra. Actúa como el hilo central que conecta todas las actividades, eventos y datos relacionados durante el ciclo de vida de la reclamación, desde la presentación inicial hasta el cierre definitivo. En Process Mining, el ID de la reclamación es fundamental para reconstruir el recorrido completo de cada reclamación. Al agrupar todos los eventos con el mismo ID de la reclamación, el software puede visualizar el flujo del proceso, identificar variaciones y calcular métricas a nivel de caso. Garantiza que cada acción, desde la asignación de la persona ajustadora hasta la emisión del pago, se atribuya correctamente a la reclamación correspondiente, lo que permite realizar un análisis del proceso coherente y preciso. Por qué es importante Este es el identificador esencial del caso que vincula todos los eventos relacionados y permite rastrear el recorrido completo de cada reclamación. Dónde obtenerlo Normalmente se encuentra en el encabezado o en el registro principal de un expediente de reclamación o de una transacción del sistema de gestión de reclamaciones. Ejemplos CL-2023-001234A789-C54329876543210 | |||
| Nombre de la actividad ActivityName | El nombre de la actividad empresarial o del evento que tuvo lugar en un momento concreto para una reclamación. | ||
| Descripción El nombre de la actividad describe un paso, una tarea o un evento específico dentro del ciclo de vida de la gestión de reclamaciones. Estas actividades representan el trabajo realizado, como «Reclamación registrada», «Investigación iniciada» o «Pago emitido». Cada actividad es un punto diferenciado del proceso que se captura en el registro de eventos. En el análisis de Process Mining, las actividades son los elementos básicos del mapa de procesos. Analizar su secuencia, frecuencia y duración revela el flujo real del proceso, las rutas habituales, los cuellos de botella y las desviaciones respecto al procedimiento estándar. Utilizar nombres de actividad claros y coherentes es fundamental para crear un modelo de proceso comprensible y útil. Por qué es importante Las actividades constituyen el núcleo del mapa de procesos y definen los pasos y las tareas cuya secuencia y duración se analizan para comprender el rendimiento del proceso. Dónde obtenerlo Normalmente se encuentra en registros de eventos, pistas de auditoría o registros de transacciones del sistema de gestión de reclamaciones. Ejemplos Siniestro registradoPérdida evaluadaPago emitidoReclamación denegada | |||
| Sistema de origen SourceSystem | El sistema de registro del que se extrajeron los datos del evento. | ||
| Descripción El atributo Sistema de origen identifica la aplicación o plataforma de TI específica en la que se registró originalmente la actividad. En entornos complejos, los datos de gestión de reclamaciones pueden proceder de varios sistemas, como una plataforma central de reclamaciones, un sistema de gestión documental o una herramienta de gestión de relaciones con clientes (CRM). Comprender el sistema de origen es útil para validar los datos y analizar la fragmentación del proceso. Ayuda a rastrear los problemas de calidad de los datos hasta su origen y puede revelar ineficiencias causadas por transferencias manuales de datos o traspasos de trabajo entre distintos sistemas. Este análisis puede poner de manifiesto oportunidades para mejorar la integración y la automatización de los sistemas. Por qué es importante Identifica el origen de los datos de los eventos, algo fundamental para validar los datos y analizar la ejecución del proceso en varios sistemas de TI. Dónde obtenerlo Esta información puede formar parte de la lógica de extracción de datos o almacenarse como un campo en los registros de eventos de los sistemas integrados. Ejemplos Suite de gestión de siniestrosPortal de CRMSistema de gestión de documentos | |||
| Última actualización de datos LastDataUpdate | La marca de tiempo de la actualización o extracción más reciente de datos del sistema de origen. | ||
| Descripción La última actualización de datos indica cuándo se actualizó por última vez el registro de eventos desde los sistemas de origen. Esta marca de tiempo proporciona contexto sobre la actualidad de los datos analizados y garantiza que las partes interesadas conozcan su vigencia. En cualquier análisis de procesos, conocer la actualidad de los datos es fundamental para tomar decisiones informadas. Este atributo ayuda a comprender si se está visualizando un proceso casi en tiempo real o una instantánea histórica. Es especialmente importante para los Dashboards de supervisión continua y para garantizar que las conclusiones se basen en información pertinente y actualizada. Por qué es importante Proporciona un contexto esencial sobre la actualidad de los datos y garantiza que el análisis y las decisiones se basen en información actualizada. Dónde obtenerlo Normalmente son metadatos generados durante el proceso de extracción, transformación y carga (ETL) de datos. Ejemplos 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Departamento Department | La unidad de negocio, el equipo o el departamento responsable de gestionar la actividad o la reclamación en un momento determinado. | ||
| Descripción El atributo Departamento especifica el grupo organizativo responsable de un siniestro en una etapa concreta de su ciclo de vida. Algunos ejemplos son 'Primer aviso de siniestro', 'Unidad de investigación' o 'Departamento de pagos'. Esta información es fundamental para comprender las transferencias y la colaboración entre las distintas partes de la organización. Analizar el proceso desde la perspectiva departamental puede revelar retrasos que se producen cuando un siniestro pasa de un equipo a otro. Ayuda a identificar cuellos de botella entre departamentos y es esencial para evaluar las cargas de trabajo y el rendimiento específicos de cada equipo, además de respaldar KPI como Equilibrio de la carga de trabajo de las personas gestoras y Dashboards sobre el rendimiento del equipo. Por qué es importante Ayuda a analizar los traspasos del proceso entre equipos e identificar cuellos de botella entre departamentos, lo que respalda el análisis del rendimiento de la organización. Dónde obtenerlo Normalmente se almacena en el registro de la reclamación, a menudo asociado a la persona usuaria asignada o a la fase actual del proceso. Ejemplos Equipo de recepciónUnidad de investigaciones especialesEvaluación de responsabilidadFinanzas y pagos | |||
| Fecha objetivo de resolución ResolutionTargetDate | La fecha objetivo para resolver la reclamación, basada en acuerdos de nivel de servicio (SLA) o en la normativa. | ||
| Descripción La fecha objetivo de resolución, o fecha límite, es el plazo establecido para completar el proceso de reclamación. Esta fecha suele estar determinada por requisitos normativos o acuerdos internos de nivel de servicio (SLA) diseñados para garantizar una atención oportuna a la clientela. Este atributo es fundamental para el cumplimiento y la supervisión del rendimiento. Al comparar la fecha real de cierre de la reclamación con la fecha objetivo, las organizaciones pueden medir su tasa de cumplimiento de los SLA. Process Mining puede destacar qué pasos o variantes del proceso tienen más probabilidades de provocar incumplimientos de los SLA. Esto permite gestionar los plazos de forma proactiva y priorizar las mejoras que tengan mayor impacto en la resolución puntual, respaldando directamente el panel «Cumplimiento de SLA y plazos». Por qué es importante Permite medir el rendimiento puntual frente a los SLA o los plazos normativos, una medida crítica de la eficacia del proceso. Dónde obtenerlo Normalmente se calcula según reglas de negocio cuando se crea una reclamación y se almacena en el registro principal de la reclamación. Ejemplos 2023-04-142023-06-192023-08-30 | |||
| Gravedad de la reclamación ClaimSeverity | Una clasificación de la complejidad estimada o del posible impacto financiero de la reclamación, como Baja, Media o Alta. | ||
| Descripción Gravedad de la reclamación proporciona una evaluación de la complejidad, urgencia o posible coste financiero de la reclamación. Esta clasificación ayuda a priorizar las reclamaciones y asignarlas a personas ajustadoras con el nivel de experiencia adecuado. La gravedad puede determinarse mediante factores como el importe estimado de la pérdida, la naturaleza del incidente o la existencia de litigios. Analizar el proceso según la gravedad de la reclamación es fundamental para comprobar si los procedimientos de gestión están adaptados correctamente. Por ejemplo, se espera que las reclamaciones de gravedad alta tengan tiempos de ciclo más largos, pero deberían seguir una ruta de investigación más rigurosa. Este atributo ayuda a verificar que las reclamaciones complejas reciban la atención necesaria, mientras que las sencillas se procesen rápidamente, optimizando la asignación de recursos y la satisfacción de la clientela. Por qué es importante Ayuda a diferenciar entre reclamaciones sencillas y complejas y permite analizar si la ejecución del proceso está adaptada adecuadamente a la complejidad de la reclamación. Dónde obtenerlo A menudo se determina mediante reglas de negocio durante la recepción de la reclamación y se almacena como un campo del registro principal de la reclamación. Ejemplos BajoMedioAltoCatastrófico | |||
| Hora de finalización EndTime | La marca de tiempo que indica cuándo se completó una actividad o un evento específico. | ||
| Descripción La hora de finalización es una marca precisa de fecha y hora que indica el momento en que concluyó una actividad. Cuando está disponible junto con una hora de inicio, permite medir exactamente cuánto tardó en completarse una actividad. Este atributo es muy valioso para el análisis detallado del rendimiento. La diferencia entre la hora de inicio y la hora de finalización proporciona el 'tiempo de procesamiento' o la 'duración de la actividad', una métrica clave para identificar pasos ineficientes. Analizar los tiempos de procesamiento ayuda a localizar qué actividades consumen más recursos y dónde deben centrarse los esfuerzos de optimización. Es fundamental para crear Dashboards relacionados con los cuellos de botella del proceso y el rendimiento de los equipos. Por qué es importante Permite calcular con precisión los tiempos de procesamiento de las actividades, algo fundamental para identificar cuellos de botella y analizar la eficiencia de los recursos. Dónde obtenerlo Normalmente se encuentra en registros de eventos o pistas de auditoría junto con la hora de inicio. Puede ser necesario derivarla si solo se registran eventos de cambio. Ejemplos 2023-03-15T11:30:00Z2023-05-20T15:05:45Z2023-07-01T11:29:15Z | |||
| Importe de la liquidación SettlementAmount | El importe financiero final pagado a la persona reclamante o a un tercero para resolver la reclamación. | ||
| Descripción El importe de la liquidación representa el valor monetario total pagado para liquidar una reclamación. Es una métrica de resultado fundamental que refleja el impacto financiero de la reclamación. Normalmente se determina después de evaluar la pérdida y tomar una decisión. En Process Mining, este atributo es esencial para el análisis basado en costes. Permite calcular KPI como el «Coste medio por reclamación» e investigar cómo las variaciones del proceso afectan a los resultados financieros. Por ejemplo, el análisis puede mostrar que las reclamaciones con determinados ciclos de retrabajo o tiempos de ciclo más largos tienden a generar importes de liquidación más elevados. Esto establece un vínculo directo entre la eficiencia del proceso y el rendimiento financiero, y sustenta el panel «Análisis del coste de las reclamaciones». Por qué es importante Es una métrica de resultado clave que vincula directamente el comportamiento del proceso con el impacto financiero y permite realizar análisis de coste-beneficio de las mejoras del proceso. Dónde obtenerlo Se encuentra en los registros financieros o de pagos asociados a la reclamación y se finaliza cuando se cierra la reclamación o se efectúa el pago. Ejemplos 1500.0025000.50125.750.00 | |||
| Persona ajustadora asignada AssignedAdjuster | El nombre o ID de la persona usuaria, como una persona ajustadora de reclamaciones, responsable de gestionar la reclamación o la actividad. | ||
| Descripción La persona gestora asignada identifica a la empleada, el empleado o la persona usuaria que ejecutó una actividad concreta o es responsable del siniestro en un momento determinado. Este atributo vincula los pasos del proceso con los recursos humanos que los ejecutan. Analizar los datos por persona gestora es fundamental para gestionar la carga de trabajo, evaluar el rendimiento e identificar necesidades de formación. Permite comparar el rendimiento entre integrantes del equipo, garantizar una distribución equitativa del trabajo y detectar a quienes tienen un rendimiento destacado o necesitan apoyo adicional. Esta visión a nivel de recurso es clave para los Dashboards relacionados con el rendimiento del equipo y el equilibrio de la carga de trabajo. Por qué es importante Vincula las actividades del proceso con las personas que las realizan y permite analizar la carga de trabajo, el rendimiento del equipo y la asignación de recursos. Dónde obtenerlo Se encuentra en registros de transacciones, registros de auditoría o campos de asignación de personas usuarias del sistema de gestión de reclamaciones. Ejemplos John SmithUSER789Emily Jonesadjuster_team_a | |||
| Tipo de reclamación ClaimType | La categoría de la reclamación de seguro, que ayuda a segmentar y comparar el rendimiento del proceso para distintos tipos de reclamaciones. | ||
| Descripción Tipo de reclamación es una clasificación que categoriza las reclamaciones según la línea de negocio o la naturaleza de la pérdida, como «Automóvil», «Propiedad», «Responsabilidad» o «Incapacidad». Los distintos tipos de reclamación suelen seguir rutas de proceso diferentes y tener distintos niveles de complejidad y SLA. Segmentar el análisis del proceso por tipo de reclamación es una técnica fundamental para obtener información útil. Permite comparar los tiempos de ciclo, los costes y la conformidad del proceso entre distintas categorías. Este análisis puede revelar que un proceso eficiente para reclamaciones de automóvil resulta ineficiente para reclamaciones de propiedad, lo que orienta las iniciativas de mejora específicas. Este atributo es esencial para el panel «Rendimiento por categoría de reclamación». Por qué es importante Permite segmentar las reclamaciones para comparar los procesos y el rendimiento entre distintas líneas de negocio y revelar problemas específicos de cada categoría. Dónde obtenerlo Es un campo estándar del registro principal de la reclamación, que normalmente se establece cuando se crea la reclamación. Ejemplos AutomóvilPropiedadCompensación laboralResponsabilidad civil general | |||
| Canal de presentación SubmissionChannel | El método o canal mediante el que se presentó inicialmente la reclamación. | ||
| Descripción Canal de presentación identifica cómo se comunicó por primera vez una reclamación a la empresa. Entre los canales habituales se incluyen un portal de clientes en línea, una aplicación móvil, una persona agente, una correduría o el correo postal tradicional. Analizar el proceso por canal de presentación puede revelar diferencias importantes en la calidad de los datos, la eficiencia y la experiencia de la clientela. Por ejemplo, las reclamaciones presentadas a través de un portal digital pueden contener menos errores de introducción de datos y tener tiempos de procesamiento inicial más rápidos que las presentadas por correo postal. Esta información puede orientar las decisiones estratégicas sobre qué canales promover y dónde invertir en automatización y mejora de procesos. Por qué es importante Ayuda a analizar cómo el canal de recepción afecta a la eficiencia del proceso, la calidad de los datos y el tiempo total del ciclo. Dónde obtenerlo Normalmente se registra durante el proceso de «Primer aviso de siniestro» (FNOL) y se almacena en el registro principal de la reclamación. Ejemplos Portal webAgenteTeléfonoCorreo postal | |||
| Estado de la reclamación ClaimStatus | El estado general de la reclamación en un momento determinado, como Abierta, Pendiente o Cerrada. | ||
| Descripción Estado de la reclamación indica la situación de la reclamación dentro de su ciclo de vida en el momento de un evento. Este estado proporciona un resumen general de la fase en la que se encuentra la reclamación, por ejemplo, «En investigación», «A la espera de información» o «Liquidada». Aunque Process Mining reconstruye el flujo detallado a partir de las actividades, el atributo Estado de la reclamación ofrece una valiosa capa de contexto. Puede utilizarse para validar el flujo del proceso, por ejemplo, para comprobar si la actividad «Pago emitido» cambia correctamente el estado a «Cerrada», y para analizar cuánto tiempo permanecen las reclamaciones en determinados estados. Esto ayuda a comprender cuánto tiempo permanecen pendientes los casos y puede poner de manifiesto retrasos o ineficiencias sistémicas. Por qué es importante Proporciona contexto sobre el estado de una reclamación en cualquier momento, ayuda a analizar el tiempo empleado en las distintas fases y permite validar el flujo del proceso. Dónde obtenerlo Es un campo principal del registro de la reclamación, que se actualiza a medida que la reclamación avanza durante su ciclo de vida. Ejemplos AbiertoPendiente - A la espera de información del clienteCerrado - PagadoCerrado - Denegado | |||
| Fecha del siniestro LossDate | La fecha en la que se produjo el incidente o la pérdida que originó la reclamación de seguro. | ||
| Descripción La fecha del siniestro marca la fecha real del evento, por ejemplo, un accidente de automóvil o daños en una propiedad, que dio lugar a la reclamación. Se diferencia de la fecha en que la reclamación se comunicó o registró en el sistema. La diferencia entre la fecha del siniestro y la fecha de registro de la reclamación se conoce como «retraso en la comunicación». Analizar este retraso es importante para comprender el comportamiento de la clientela e identificar posibles riesgos de fraude, como demoras inusualmente largas en la comunicación. Proporciona una cronología más completa de toda la experiencia de la reclamación, desde el incidente hasta la resolución, y ofrece una visión más amplia que el simple tiempo de procesamiento interno. Por qué es importante Establece la fecha del incidente real y permite analizar los retrasos en la comunicación y la cronología completa desde el evento hasta el cierre. Dónde obtenerlo La persona reclamante la proporciona durante el «Primer aviso de siniestro» y se almacena en el registro principal de la reclamación. Ejemplos 2023-03-102023-05-182023-06-25 | |||
| Importe reclamado ClaimedAmount | El importe monetario total solicitado inicialmente por la persona titular de la póliza al presentar la reclamación. | ||
| Descripción El importe reclamado es la estimación inicial de la pérdida o el importe solicitado por la persona reclamante al comienzo del proceso. Este valor puede revisarse posteriormente durante la fase de investigación y evaluación. Este atributo resulta útil para varios tipos de análisis. Puede utilizarse para establecer un nivel de gravedad inicial de la reclamación y hacer un seguimiento de la variación entre la reclamación inicial y el importe final de la liquidación. Analizar esta variación puede proporcionar información sobre la precisión de las estimaciones iniciales y la eficacia de las medidas de control de costes del proceso de reclamaciones. Es un dato de entrada clave para las previsiones financieras y el cálculo de reservas. Por qué es importante Representa el alcance financiero inicial de la reclamación y resulta útil para evaluar su gravedad y analizar la variación respecto al importe final de la liquidación. Dónde obtenerlo Se captura durante el proceso inicial de presentación de la reclamación y se almacena en la sección financiera del registro de la reclamación. Ejemplos 2000.0035000.00500.00 | |||
| Motivo de denegación DenialReason | El motivo específico indicado cuando una reclamación se deniega o rechaza. | ||
| Descripción El motivo de denegación es un código o una descripción textual que explica por qué no se pagó una reclamación. Los motivos pueden abarcar problemas de cobertura de la póliza, actividad fraudulenta o la falta de documentación requerida. Analizar los motivos de denegación es fundamental para identificar oportunidades de mejora tanto en los procesos internos como en la comunicación con la clientela. Por ejemplo, si se deniega un gran número de reclamaciones por falta de información, puede ser necesario mejorar el proceso de recepción. El análisis de causa raíz de los motivos de denegación puede conducir a una redacción más clara de las pólizas, una mejor educación de la clientela y una reducción del esfuerzo administrativo dedicado a reclamaciones que finalmente serán denegadas. Por qué es importante Proporciona información sobre por qué no se pagan las reclamaciones, lo que permite analizar las causas raíz para mejorar la comunicación con los clientes y los procesos de atención inicial. Dónde obtenerlo El ajustador lo selecciona de una lista predefinida o lo introduce como texto cuando se produce la actividad «Claim Denied». Ejemplos No cubierto por la pólizaFraude sospechadoDocumentación incompletaReclamación duplicada | |||
| Número de póliza PolicyNumber | El identificador único de la póliza de seguro en virtud de la cual se presentó la reclamación. | ||
| Descripción El número de póliza es la referencia única del contrato de seguro que cubre la pérdida comunicada. Vincula la reclamación con una persona cliente concreta, las condiciones de la póliza, los límites de cobertura y otros detalles contractuales. Aunque no siempre se utiliza directamente en el análisis del flujo del proceso, el número de póliza es una información contextual fundamental. Permite agregar los datos de las reclamaciones a nivel de póliza o de cliente, lo que puede revelar patrones como reclamaciones frecuentes de una misma persona titular. También permite enriquecer los datos de las reclamaciones con detalles a nivel de póliza, como el tipo de póliza o el importe de cobertura, para realizar segmentaciones y análisis más avanzados. Por qué es importante Vincula la reclamación con el contrato de seguro específico y permite enriquecerla con datos de la póliza para realizar un análisis más profundo y contextualizado. Dónde obtenerlo Es un dato fundamental que se captura durante la recepción de la reclamación y se almacena en el encabezado del registro de la reclamación. Ejemplos POL-987654A-100-200-300555444333 | |||
Actividades de gestión de siniestros
| Actividad | Descripción | ||
|---|---|---|---|
| Decisión sobre la reclamación tomada | Un hito decisivo en el que la aseguradora toma una decisión formal para aprobar, aprobar parcialmente o denegar la reclamación basándose en la investigación. Representa el resultado oficial del proceso de resolución. | ||
| Por qué es importante Este es un punto de decisión crítico que determina la trayectoria posterior de la reclamación, ya sea el pago o la denegación. Es esencial para analizar el tiempo de toma de decisiones y los resultados. Dónde obtenerlo Casi siempre se registra como un cambio de estado explícito en el sistema a un estado como «Aprobada», «Denegada» o «Liquidada». Recopilar Busque la primera actualización de estado a un estado de decisión final, como «Aprobada» o «Denegada». Tipo de evento inferred | |||
| Pago emitido | Esta actividad marca la ejecución de la transacción financiera para pagar la reclamación. Representa el momento en que el pago se envía a la persona reclamante o al proveedor. | ||
| Por qué es importante Este es un evento financiero crítico y a menudo marca el final del proceso habitual. Es fundamental para medir el tiempo transcurrido hasta el pago desde la aprobación de la reclamación. Dónde obtenerlo Se registra como un registro de transacciones explícito o una actualización del estado final del pago, a menudo activada por una integración con un sistema financiero. Recopilar Identifique el evento en el que un registro de pago asociado a la reclamación se marca como «Pagado», «Emitido» o «Desembolsado». Tipo de evento explicit | |||
| Pérdida evaluada | Este hito marca el momento en que se estima el impacto financiero de la reclamación y se establece una reserva. Representa la estimación formal del posible coste de la reclamación. | ||
| Por qué es importante Este es un evento financiero clave del proceso. Analizar cuándo y con qué frecuencia se ajustan las reservas proporciona información sobre la precisión de la valoración y la eficiencia del proceso. Dónde obtenerlo Este evento se registra cuando los importes de las reservas se introducen por primera vez o se ajustan posteriormente en los registros financieros de la reclamación del sistema. Recopilar Capture la marca de tiempo de la primera transacción del registro de reservas financieras de la reclamación. Tipo de evento explicit | |||
| Reclamación cerrada | Esta es la actividad administrativa final, que marca el cierre del expediente de la reclamación después de emitir el pago o denegar la reclamación. En esta fase, todas las actividades han concluido. | ||
| Por qué es importante Este es el evento final principal del proceso. Es esencial para calcular el tiempo total del ciclo de extremo a extremo de todas las reclamaciones. Dónde obtenerlo Se registra mediante la actualización final del estado a «Cerrada» o «Finalizada» en el sistema, una vez completado el resto del procesamiento. Recopilar Identifique la marca de tiempo en la que el campo de estado principal de la reclamación se actualiza a su valor final «Cerrada». Tipo de evento inferred | |||
| Reclamación denegada | Esta actividad representa el resultado final de una reclamación que no se aprueba para el pago. Se produce después de una decisión de denegación e implica finalizar el registro de la reclamación con un estado denegado. | ||
| Por qué es importante Este es un evento final clave de una de las principales variantes del proceso. Analizar las reclamaciones denegadas es fundamental para comprender las tasas y los motivos de denegación. Dónde obtenerlo Este evento se registra cuando el estado final de la reclamación se establece definitivamente como «Denegada» o «Rechazada». Recopilar Busque una actualización final del estado a «Denegada», «Rechazada» o un estado final similar, que puede producirse después de la decisión inicial. Tipo de evento inferred | |||
| Revisión inicial completada | Representa la finalización de la primera revisión exhaustiva del siniestro por parte del gestor asignado. Durante este paso, el gestor evalúa la validez y los detalles del siniestro y determina las siguientes acciones necesarias. | ||
| Por qué es importante Este hito ayuda a medir el tiempo de clasificación y evaluación inicial. Los retrasos en esta etapa pueden afectar significativamente al tiempo total de ciclo del siniestro. Dónde obtenerlo A menudo se infiere a partir de un cambio de estado en el sistema, como pasar de «New» o «Assigned» a «Under Review» o «Investigation». Recopilar Busque un cambio de estado que indique el final de la fase de evaluación inicial y el comienzo de la gestión activa. Tipo de evento inferred | |||
| Siniestro registrado | Esta actividad marca la creación formal de un registro de siniestro en el sistema de gestión después del First Notice of Loss (FNOL). En este punto, se asigna oficialmente un Claim ID único y el caso se abre formalmente para su gestión. | ||
| Por qué es importante Este es el evento de inicio principal del proceso de gestión de siniestros. Es esencial para medir el tiempo total de ciclo desde el registro oficial hasta el cierre. Dónde obtenerlo Este evento suele capturarse a partir de la marca de tiempo de creación del registro principal del siniestro o del objeto del caso en el sistema de origen. Recopilar Identifique el evento de creación o la primera actualización de estado en el registro histórico del siniestro. Tipo de evento explicit | |||
| Gestor de siniestros asignado | Esta actividad registra la asignación del siniestro a un gestor, tramitador o equipo concreto. Establece la responsabilidad y la rendición de cuentas para gestionar el siniestro durante todo su ciclo de vida. | ||
| Por qué es importante Registrar las asignaciones es fundamental para analizar la distribución de la carga de trabajo, el rendimiento del equipo e identificar retrasos en los traspasos de siniestros. Dónde obtenerlo Esta información suele registrarse en un registro de asignaciones o mediante el seguimiento de los cambios en el campo «owner» o «assignee» del registro del siniestro. Recopilar Capture las actualizaciones de los campos de asignación de usuario o grupo asociados al caso del siniestro. Tipo de evento explicit | |||
| Información adicional recibida | Marca la recepción de los documentos o la información solicitados, lo que permite reanudar la gestión del siniestro. Esta actividad concluye el estado de «espera» iniciado por la solicitud. | ||
| Por qué es importante Este evento cierra el bucle de solicitud de información. El tiempo transcurrido entre la solicitud y la recepción de la información es un indicador clave de las dependencias externas y los cuellos de botella. Dónde obtenerlo Normalmente se infiere cuando el estado del siniestro cambia de «Pending Information» a un estado activo como «Under Review». Recopilar Detecte el cambio de estado desde un estado «pending» a un estado de gestión «active». Tipo de evento inferred | |||
| Información adicional solicitada | Esta actividad se produce cuando el gestor determina que necesita más información del reclamante o de un tercero para continuar. A menudo inicia un estado de «espera» en el proceso. | ||
| Por qué es importante Esta actividad marca el inicio de un bucle habitual de reproceso o espera. Analizar su frecuencia y duración ayuda a identificar problemas en la recopilación inicial de datos y la comunicación. Dónde obtenerlo Suele capturarse mediante un cambio de estado específico, por ejemplo, «Pending Information», o registrando un evento de comunicación saliente. Recopilar Identifique los cambios de estado a «pending information» o la creación de una tarea o comunicación relacionada con una solicitud de información. Tipo de evento inferred | |||
| Investigación completada | Representa la conclusión de todas las actividades de investigación, una vez recopilados y documentados todos los hechos necesarios. Este paso es un requisito previo para tomar una decisión final sobre el siniestro. | ||
| Por qué es importante Este hito marca el final de la fase de recopilación de pruebas. La duración hasta este punto es fundamental para comprender la eficiencia de la investigación. Dónde obtenerlo Normalmente se infiere cuando el estado de la reclamación cambia de «En investigación» a un estado relacionado con la toma de decisiones, como «Decisión pendiente» o «Lista para evaluación». Recopilar Identifique el cambio de estado que indica el final de la investigación y la preparación para tomar una decisión definitiva. Tipo de evento inferred | |||
| Investigación iniciada | Esta actividad indica el comienzo de la fase formal de investigación exhaustiva del siniestro. Puede incluir la asignación de especialistas, la programación de inspecciones u otras actividades de recopilación de pruebas. | ||
| Por qué es importante Registrar el inicio de la investigación ayuda a aislar y medir la duración de esta fase, que suele ser compleja y consumir mucho tiempo dentro del proceso de gestión de siniestros. Dónde obtenerlo A menudo se infiere a partir de un cambio en el estado del siniestro a «Under Investigation» o a un estado similar, o de la creación de la primera tarea relacionada con la investigación. Recopilar Busque un cambio de estado a «Under Investigation» o la creación de la primera tarea formal de investigación. Tipo de evento inferred | |||
| Liquidación calculada | Después de una decisión de aprobación, esta actividad representa el cálculo del importe final de la liquidación o del pago. Se basa en los límites de la póliza, las franquicias y las pérdidas evaluadas. | ||
| Por qué es importante El tiempo empleado en este paso puede revelar cuellos de botella entre la decisión sobre la reclamación y la autorización del pago. Es un paso clave del proceso de liquidación financiera. Dónde obtenerlo Probablemente se registra cuando el campo del importe final del pago o de la liquidación se introduce y confirma en el módulo financiero del sistema. Recopilar Identifique cuándo se completa el importe final de la liquidación o cuándo se crea un registro de pago con el estado «pendiente de aprobación». Tipo de evento explicit | |||
| Pago autorizado | Representa la aprobación formal del pago del importe de liquidación calculado. A menudo es un paso independiente en el que interviene una persona responsable o una autoridad distinta para prevenir el fraude y garantizar la precisión. | ||
| Por qué es importante Este es un punto de control crítico. Analizar el tiempo entre el cálculo y la autorización puede poner de manifiesto cuellos de botella en las aprobaciones o problemas de cumplimiento. Dónde obtenerlo Se registra mediante una transacción de aprobación específica o un cambio de estado como «Aprobado para pago» en el sistema. Recopilar Capture la marca de tiempo del evento de aprobación del pago o del cambio de estado a «Aprobado para pago». Tipo de evento explicit | |||
| Reclamación reabierta | Se produce cuando una reclamación previamente cerrada o denegada se reactiva para una revisión o un procesamiento adicionales. Normalmente se debe a una apelación, nueva información o la detección de un error. | ||
| Por qué es importante Las reclamaciones reabiertas representan un retrabajo significativo. Hacer un seguimiento de esta actividad es fundamental para identificar fallos del proceso, motivos de apelación y su impacto en los costes. Dónde obtenerlo Este evento se registra mediante un cambio de estado de «Cerrada» o «Denegada» a un estado activo como «En revisión». Recopilar Detecte un cambio de estado desde un estado final, por ejemplo «Cerrada», a un estado activo no final. Tipo de evento inferred | |||
Guías de extracción
Los métodos de extracción varían según el sistema. Para obtener instrucciones detalladas,
¿Listo para comenzar?
Comience a mejorar su gestión de reclamaciones eligiendo una guía de extracción específica para su sistema o aplicando este Template genérico para preparar su Registro de eventos.
Tome el control: optimice sus procesos y mejore el rendimiento ahora
Identifique las ineficiencias, impulse la innovación y alcance sus objetivos más rápido.
No necesita tarjeta de crédito. Comience a optimizar hoy.