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 para Process Mining de Gestión de reclamaciones. Para obtener indicaciones más específicas, use nuestros Templates para cada sistema.
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.
- Estructura flexible, aplicable a cualquier sistema de gestión de reclamaciones.
Atributos de la gestión de reclamaciones
| Nombre | Descripción | ||
|---|---|---|---|
| Hora de inicio StartTime | 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 cuándo comenzó una actividad. Es un dato fundamental de cada evento del registro del proceso, ya que aporta 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, de espera y de procesamiento. Analizar las marcas de tiempo ayuda a detectar demoras 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 Suele registrarse en los registros de eventos, las pistas de auditoría o los 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 | Identificador único de una reclamación de seguro, que sirve como identificador principal del caso para Process Mining. | ||
| Descripción El ID de la reclamación es una clave única que se asigna a cada reclamación de seguro cuando se registra. Es el hilo conductor que vincula todas las actividades, los eventos y los datos relacionados durante todo el ciclo de vida de la reclamación, desde su 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 caso. Al agrupar todos los eventos que comparten el mismo ID, el software puede visualizar el flujo del proceso, identificar variaciones y calcular métricas por caso. Así, cada acción, desde la asignación del perito hasta la emisión del pago, queda asociada correctamente a la reclamación correspondiente, lo que permite analizar el proceso de forma coherente y precisa. Por qué es importante Este identificador esencial del caso vincula todos los eventos relacionados y permite seguir el recorrido completo de cada reclamación. Dónde obtenerlo Suele encontrarse en el encabezado o en el registro principal del expediente de la reclamación o de la transacción en el sistema de gestión de reclamaciones. Ejemplos CL-2023-001234A789-C54329876543210 | |||
| Nombre de la actividad ActivityName | Nombre de la actividad empresarial o del evento que tuvo lugar en un momento determinado para una reclamación. | ||
| Descripción El nombre de la actividad describe un paso, una tarea o un evento específico del ciclo de 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 concreto del proceso que se registra en el registro de eventos. En el análisis de Process Mining, las actividades son los componentes básicos del mapa del proceso. Analizar su secuencia, frecuencia y duración permite conocer el flujo real del proceso, las rutas habituales, los cuellos de botella y las desviaciones del procedimiento estándar. Usar nombres de actividad claros y coherentes es fundamental para crear un modelo de proceso comprensible y útil para la acción. Por qué es importante Las actividades son la base del mapa del proceso: definen los pasos y las tareas cuya secuencia y duración se analizan para comprender el rendimiento del proceso. Dónde obtenerlo Suele encontrarse en los registros de eventos, las pistas de auditoría o los registros de transacciones del sistema de gestión de reclamaciones. Ejemplos Reclamación registradaPérdida evaluadaPago emitidoReclamación denegada | |||
| Sistema de origen SourceSystem | Sistema de registro del que se extrajeron los datos de los eventos. | ||
| 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 los clientes (CRM). Conocer el sistema de origen resulta útil para validar los datos y analizar la fragmentación del proceso. Permite 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 sistemas. Este análisis puede señalar 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 validarlos 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 reclamacionesPortal de CRMSistema de gestión documental | |||
| Última actualización de los datos LastDataUpdate | Marca de tiempo de la actualización o extracción más reciente de datos del sistema de origen. | ||
| Descripción Última actualización de los datos indica cuándo se actualizaron por última vez los datos del registro de eventos desde los sistemas de origen. Esta marca de tiempo permite conocer la actualidad de los datos analizados y ayuda a que las partes interesadas sepan si están al día. En cualquier análisis de procesos, conocer la actualidad de los datos es fundamental para tomar decisiones informadas. Este atributo permite saber si se está viendo un proceso casi en tiempo real o una instantánea histórica. Es especialmente importante para los Dashboards de seguimiento continuo y para garantizar que las conclusiones se basen en información pertinente y actualizada. Por qué es importante Aporta un contexto esencial sobre la actualidad de los datos y ayuda a garantizar que el análisis y las decisiones se basen en información actualizada. Dónde obtenerlo Suelen ser metadatos generados durante el proceso de extracción, transformación y carga de datos (ETL). Ejemplos 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Departamento Department | Unidad de negocio, equipo o departamento responsable de gestionar la actividad o la reclamación en un momento determinado. | ||
| Descripción El atributo Departamento especifica el grupo de la organización responsable de una reclamación en una etapa concreta de su ciclo de vida. Algunos ejemplos son «Primera notificación del siniestro», «Unidad de investigaciones» o «Departamento de pagos». Esta información es fundamental para comprender los traspasos y la colaboración entre distintas áreas de la organización. Analizar el proceso por departamento puede revelar demoras cuando una reclamación pasa de un equipo a otro. También ayuda a identificar cuellos de botella entre departamentos y es esencial para evaluar la carga de trabajo y el rendimiento de cada equipo, así como para respaldar KPI como el equilibrio de la carga de trabajo de los peritos y los Dashboards de 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 permite evaluar el rendimiento de la organización. Dónde obtenerlo Suele almacenarse en el registro de la reclamación y a menudo está asociado al usuario asignado o a la etapa actual del proceso. Ejemplos Equipo de recepciónUnidad de investigaciones especialesEvaluación de responsabilidadFinanzas y pagos | |||
| Fecha objetivo de resolución ResolutionTargetDate | Fecha límite prevista para resolver la reclamación, según los acuerdos de nivel de servicio (SLA) o la normativa. | ||
| Descripción La fecha objetivo de resolución, o fecha límite, es la fecha establecida para completar el proceso de reclamación. A menudo viene determinada por requisitos normativos o acuerdos de nivel de servicio (SLA) internos destinados a garantizar una atención oportuna al cliente. Este atributo es fundamental para el cumplimiento y el seguimiento del rendimiento. Al comparar la fecha real de cierre de la reclamación con la fecha objetivo, las organizaciones pueden medir el índice de cumplimiento de los SLA. Process Mining puede señalar los pasos o las variantes del proceso con mayor probabilidad de incumplir los SLA. Esto permite gestionar los plazos de forma proactiva y priorizar las mejoras que más contribuyen a resolver las reclamaciones a tiempo, además de respaldar directamente el Dashboard «Cumplimiento de SLA y plazos». Por qué es importante Permite medir el cumplimiento de los SLA o de los plazos normativos, un indicador fundamental de la eficacia del proceso. Dónde obtenerlo Suele calcularse según reglas de negocio cuando se crea una reclamación y almacenarse en el registro principal. Ejemplos 2023-04-142023-06-192023-08-30 | |||
| Gravedad de la reclamación ClaimSeverity | Clasificación de la complejidad estimada o del posible impacto financiero de la reclamación, por ejemplo, bajo, medio o alto. | ||
| Descripción La gravedad de la reclamación permite evaluar su complejidad, urgencia o posible coste financiero. Esta clasificación ayuda a priorizar las reclamaciones y asignarlas a peritos con el nivel de experiencia adecuado. La gravedad puede determinarse según factores como el importe estimado de la pérdida, la naturaleza del incidente o la existencia de un litigio. Analizar el proceso según la gravedad de la reclamación es fundamental para comprobar si los procedimientos de gestión se adaptan adecuadamente. Por ejemplo, cabe esperar que las reclamaciones graves tengan tiempos de ciclo más largos, pero también que sigan una ruta de investigación más rigurosa. Este atributo ayuda a verificar que las reclamaciones complejas reciban la atención necesaria y que las sencillas se procesen con rapidez, optimizando la asignación de recursos y la satisfacción del cliente. Por qué es importante Ayuda a distinguir las reclamaciones sencillas de las complejas y permite analizar si la ejecución del proceso se adapta adecuadamente a la complejidad de cada caso. Dónde obtenerlo Suele determinarse mediante reglas de negocio durante la recepción de la reclamación y almacenarse como campo en el registro principal. Ejemplos BajaMediaAltaCatastrófica | |||
| Hora de fin EndTime | Marca de tiempo que indica cuándo finalizó una actividad o un evento específico. | ||
| Descripción La hora de fin es una marca precisa de fecha y hora que indica cuándo concluyó una actividad. Si se dispone también de la hora de inicio, permite medir con exactitud cuánto tardó en completarse. Este atributo es muy valioso para analizar el rendimiento en detalle. La diferencia entre la hora de inicio y la hora de fin 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 determinar qué actividades consumen más recursos y dónde conviene centrar los esfuerzos para agilizar las operaciones. Es fundamental para crear Dashboards sobre cuellos de botella del proceso y 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 Suele encontrarse en los registros de eventos o las pistas de auditoría, junto a la hora de inicio. Puede ser necesario calcularla si solo se registran los eventos de cambio. Ejemplos 2023-03-15T11:30:00Z2023-05-20T15:05:45Z2023-07-01T11:29:15Z | |||
| Importe de liquidación SettlementAmount | Importe final pagado al reclamante o a un tercero para resolver la reclamación. | ||
| Descripción El importe de liquidación representa el valor monetario total pagado para resolver una reclamación. Es una métrica clave del resultado que refleja el impacto financiero del caso. Suele determinarse después de evaluar la pérdida y tomar una decisión. En Process Mining, este atributo es esencial para analizar los costes. Permite calcular KPI como el coste medio por reclamación e investigar cómo afectan las variaciones del proceso a los resultados financieros. Por ejemplo, el análisis podría mostrar que las reclamaciones con ciclos de retrabajo o tiempos de ciclo más largos tienden a generar importes de liquidación más elevados. Así se establece una relación directa entre la eficiencia del proceso y el rendimiento financiero, que sirve de base para el Dashboard «Análisis de costes de reclamaciones». Por qué es importante Esta métrica clave del resultado vincula directamente el comportamiento del proceso con el impacto financiero y permite analizar la relación entre costes y beneficios de las mejoras. Dónde obtenerlo Se encuentra en los registros financieros o de pagos asociados a la reclamación y se completa al cerrar el caso o efectuar el pago. Ejemplos 1500.0025000.50125.750.00 | |||
| Perito asignado AssignedAdjuster | Nombre o ID del usuario, por ejemplo, un perito de seguros, responsable de gestionar la reclamación o la actividad. | ||
| Descripción El perito asignado identifica al empleado o usuario que realizó una actividad específica o que es responsable de la reclamación en un momento determinado. Este atributo vincula los pasos del proceso con las personas que los ejecutan. Analizar los datos por perito es fundamental para gestionar la carga de trabajo, evaluar el rendimiento e identificar necesidades de formación. Permite a los gerentes comparar el rendimiento de los miembros del equipo, distribuir el trabajo de forma equitativa e identificar a quienes destacan o necesitan apoyo adicional. Esta perspectiva sobre los recursos es clave para los Dashboards de rendimiento y equilibrio de la carga de trabajo del equipo. 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 los registros de transacciones, las pistas de auditoría o los campos de asignación de usuarios del sistema de gestión de reclamaciones. Ejemplos John SmithUSER789Emily Jonesequipo_peritos_a | |||
| Tipo de reclamación ClaimType | Categoría de la reclamación de seguro, que permite segmentar y comparar el rendimiento del proceso en distintos tipos de reclamaciones. | ||
| Descripción El tipo de reclamación es una clasificación basada en la línea de negocio o la naturaleza de la pérdida, como «Automóvil», «Propiedad», «Responsabilidad civil» 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 conclusiones útiles. Permite comparar los tiempos de ciclo, los costes y la conformidad del proceso entre distintas categorías. El análisis puede revelar, por ejemplo, que un proceso eficiente para las reclamaciones de automóviles no lo es para las de propiedad, lo que ayuda a orientar las mejoras. Este atributo es esencial para el Dashboard «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 detectar problemas específicos de cada categoría. Dónde obtenerlo Campo estándar del registro principal de la reclamación, que suele completarse cuando se crea el caso. Ejemplos AutomóvilPropiedadIndemnización laboralResponsabilidad civil general | |||
| Canal de presentación SubmissionChannel | Método o canal por el que se presentó inicialmente la reclamación. | ||
| Descripción El canal de presentación identifica cómo se notificó por primera vez la reclamación a la empresa. Entre los canales habituales se encuentran un portal de clientes en línea, una aplicación móvil, un agente, un corredor de seguros o el correo postal. Analizar el proceso por canal de presentación puede revelar diferencias importantes en la calidad de los datos, la eficiencia y la experiencia del cliente. Por ejemplo, las reclamaciones presentadas a través de un portal digital pueden tener menos errores de introducción de datos y tiempos de procesamiento inicial más cortos que las enviadas por correo postal. Estas conclusiones pueden 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 influye el canal de recepción en la eficiencia del proceso, la calidad de los datos y el tiempo de ciclo general. Dónde obtenerlo Suele registrarse durante el proceso de primera notificación del siniestro (FNOL) y almacenarse en el registro principal de la reclamación. Ejemplos Portal webAgenteTeléfonoCorreo postal | |||
| Estado de la reclamación ClaimStatus | Estado general de la reclamación en un momento determinado, por ejemplo, abierta, pendiente o cerrada. | ||
| Descripción El estado de la reclamación indica en qué etapa de su ciclo de vida se encontraba cuando se produjo un evento. Ofrece una visión general de la situación del caso en el proceso, 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 aporta un contexto valioso. Puede utilizarse para validar el flujo del proceso, por ejemplo, para comprobar si la actividad «Pago emitido» cambia correctamente el estado a «Cerrado», y para analizar cuánto tiempo permanecen las reclamaciones en determinados estados. Esto ayuda a comprender cuánto tiempo quedan pendientes los casos y puede revelar demoras o ineficiencias sistémicas. Por qué es importante Aporta contexto sobre el estado de una reclamación en cualquier momento, ayuda a analizar el tiempo que pasa en cada etapa y permite validar el flujo del proceso. Dónde obtenerlo Campo principal del registro de la reclamación, que se actualiza a medida que el caso avanza en su ciclo de vida. Ejemplos AbiertaPendiente: a la espera de información del clienteCerrada: pagadaCerrada: denegada | |||
| Fecha del siniestro LossDate | Fecha en que ocurrió el incidente o siniestro que dio lugar a la reclamación del seguro. | ||
| Descripción La fecha del siniestro indica cuándo ocurrió realmente el hecho, como un accidente de automóvil o daños a una propiedad, que dio lugar a la reclamación. No es la fecha en que se notificó o registró la reclamación 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 notificación». Analizar este intervalo ayuda a comprender el comportamiento de los clientes y a detectar posibles riesgos de fraude, por ejemplo, demoras inusualmente largas en la notificación. También permite reconstruir mejor todo el recorrido de la reclamación, desde el incidente hasta su resolución, y ofrece una perspectiva más amplia que la del tiempo de procesamiento interno. Por qué es importante Indica la fecha en que ocurrió el incidente y permite analizar los retrasos en la notificación y el recorrido completo desde el siniestro hasta el cierre. Dónde obtenerlo La persona reclamante la proporciona al presentar el «aviso inicial del siniestro» y se almacena en el registro principal de la reclamación. Ejemplos 2023-03-102023-05-182023-06-25 | |||
| Importe reclamado ClaimedAmount | Importe total que la persona asegurada solicita inicialmente al presentar la reclamación. | ||
| Descripción El importe reclamado es la estimación inicial del siniestro o la cantidad que solicita la persona reclamante al comienzo del proceso. Este valor puede cambiar durante la investigación y la evaluación. Este atributo resulta útil para varios tipos de análisis. Puede servir para asignar un nivel inicial de gravedad a la reclamación y hacer un seguimiento de la diferencia entre el importe reclamado inicialmente y el importe final de la indemnización. Analizar esa diferencia permite evaluar la precisión de las estimaciones iniciales y la eficacia de las medidas de control de costes en el proceso de reclamaciones. También es un dato clave para las previsiones financieras y el cálculo de reservas. Por qué es importante Representa el alcance financiero inicial de la reclamación. Es útil para evaluar su gravedad y analizar la diferencia con el importe final de la indemnización. Dónde obtenerlo Se registra al presentar la reclamación y se almacena en la sección financiera del registro. Ejemplos 2000.0035000.00500.00 | |||
| Motivo del rechazo DenialReason | Motivo específico por el que se deniega o rechaza una reclamación. | ||
| Descripción El motivo del rechazo es un código o una descripción que explica por qué no se pagó una reclamación. Puede deberse a problemas de cobertura de la póliza, a una actividad fraudulenta o a la falta de documentación obligatoria. Analizar los motivos de rechazo es fundamental para detectar oportunidades de mejora en los procesos internos y en la comunicación con los clientes. Por ejemplo, si se rechazan muchas reclamaciones por falta de información, quizá sea necesario mejorar el proceso de recepción. Analizar las causas raíz de los rechazos puede ayudar a redactar pólizas más claras, informar mejor a los clientes y reducir el trabajo administrativo dedicado a reclamaciones que acabarán rechazándose. Por qué es importante Permite entender por qué no se pagan las reclamaciones y analizar las causas raíz para mejorar la comunicación con los clientes y los procesos iniciales. Dónde obtenerlo La persona encargada de evaluar la reclamación lo selecciona de una lista predefinida o lo introduce como texto cuando se registra la actividad «Reclamación rechazada». Ejemplos Sin cobertura en la pólizaSospecha de fraudeDocumentación incompletaReclamación duplicada | |||
| Número de póliza PolicyNumber | Identificador único de la póliza de seguro con la que se presentó la reclamación. | ||
| Descripción El número de póliza es la referencia única del contrato de seguro que cubre el siniestro declarado. Vincula la reclamación con un cliente concreto, 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 un dato contextual fundamental. Permite agrupar los datos de las reclamaciones por póliza o cliente, lo que puede revelar patrones, como las reclamaciones frecuentes de una misma persona asegurada. También permite enriquecer los datos de las reclamaciones con información de la póliza, como el tipo de póliza y el importe de la cobertura, para realizar análisis y segmentaciones más avanzados. Por qué es importante Vincula la reclamación con el contrato de seguro correspondiente y permite enriquecer los datos con información de la póliza para realizar un análisis más profundo y contextualizado. Dónde obtenerlo Dato fundamental que se recoge al recibir 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 reclamaciones
| Actividad | Descripción | ||
|---|---|---|---|
| Decisión sobre la reclamación | Un hito decisivo en el que la aseguradora toma una decisión formal, basada en la investigación, para aprobar, aprobar parcialmente o denegar la reclamació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 el curso posterior de la reclamación, ya sea el pago o la denegación. Es esencial para analizar los tiempos y los resultados de las decisiones. Dónde obtenerlo Casi siempre se registra como un cambio de estado explícito en el sistema, por ejemplo, a «Aprobado», «Denegado» o «Liquidado». Capturar Busque la primera actualización de estado a una situación de decisión definitiva, como «Aprobado» o «Denegado». 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 se envía el pago al reclamante o al proveedor. | ||
| Por qué es importante Este es un evento financiero crítico y suele marcar el final de la ruta ideal del proceso. Es fundamental para medir el tiempo hasta el pago desde la aprobación de la reclamación. Dónde obtenerlo Se registra como una transacción explícita o una actualización del estado final del pago, a menudo activada por una integración con un sistema financiero. Capturar 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 fija una reserva. Representa la estimación formal del coste potencial 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 permite obtener información sobre la precisión de la valoración y la eficiencia del proceso. Dónde obtenerlo Este evento se registra cuando se introducen por primera vez los importes de las reservas o cuando se ajustan posteriormente en los registros financieros de la reclamación. Capturar Registre la marca de tiempo de la primera transacción en el registro de reservas financieras de la reclamación. Tipo de evento explicit | |||
| Reclamación cerrada | Esta es la última actividad administrativa: marca el cierre del expediente de la reclamación después de emitir el pago o denegar la reclamación. En esta etapa, todas las actividades han finalizado. | ||
| Por qué es importante Este es el evento final principal del proceso. Es esencial para calcular el tiempo de ciclo total de principio a fin de todas las reclamaciones. Dónde obtenerlo Se registra mediante la actualización final del estado a «Cerrado» o «Finalizado» en el sistema, una vez completado el resto del procesamiento. Capturar Identifique la marca de tiempo en que el campo de estado principal de la reclamación se actualiza a su valor final «Cerrado». Tipo de evento inferred | |||
| Reclamación denegada | Esta actividad representa el resultado final de una reclamación cuyo pago no se aprueba. Se produce tras una decisión de denegación e implica cerrar el registro de la reclamación con el 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 los índices 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 «Denegado» o «Rechazado». Capturar Busque una actualización final del estado a «Denegado», «Rechazado» o una situación final similar, que puede producirse después de la decisión inicial. Tipo de evento inferred | |||
| Reclamación registrada | Esta actividad marca la creación formal de un registro de reclamación en el sistema de procesamiento, después del primer aviso de siniestro (FNOL). En este momento se asigna oficialmente un Claim ID único y se abre el caso para su tramitación. | ||
| Por qué es importante Este es el principal evento de inicio del proceso de gestión de reclamaciones. Es fundamental para medir el tiempo de ciclo total desde el registro oficial hasta el cierre. Dónde obtenerlo Este evento suele registrarse mediante la marca de tiempo de creación del registro principal de la reclamación o del objeto del caso en el sistema de origen. Capturar Identifique el evento de creación o la primera actualización de estado en el historial de la reclamación. Tipo de evento explicit | |||
| Revisión inicial completada | Indica que la persona asignada ha completado la primera revisión exhaustiva de la reclamación. En esta etapa, evalúa la validez y los detalles del caso, y determina las siguientes acciones necesarias. | ||
| Por qué es importante Este hito permite medir el tiempo de clasificación y evaluación inicial. Las demoras en esta etapa pueden afectar significativamente al tiempo de ciclo total de la reclamación. Dónde obtenerlo A menudo se deduce de un cambio de estado en el sistema, por ejemplo, de «Nuevo» o «Asignado» a «En revisión» o «Investigación». Capturar Busque un cambio de estado que indique el fin de la evaluación inicial y el inicio de la tramitación activa. Tipo de evento inferred | |||
| Importe de liquidación calculado | Tras una decisión de aprobación, esta actividad representa el cálculo del importe final de la liquidación o del pago. El cálculo se basa en los límites de la póliza, los deducibles y las pérdidas evaluadas. | ||
| Por qué es importante El tiempo que lleva 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 Es probable que se registre cuando se introduce y confirma el importe final del pago o de la liquidación en el módulo financiero del sistema. Capturar 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 | |||
| Información adicional recibida | Indica que se han recibido los documentos o la información solicitados y que puede reanudarse la tramitación de la reclamación. Esta actividad pone fin al estado de espera iniciado con la solicitud. | ||
| Por qué es importante Este evento cierra el ciclo de solicitud de información. El tiempo transcurrido entre la solicitud y la recepción es un indicador clave de las dependencias externas y los cuellos de botella. Dónde obtenerlo Suele deducirse cuando el estado de la reclamación cambia de «Información pendiente» a un estado activo, como «En revisión». Capturar Detecte el cambio de estado de «Pendiente» a un estado activo de tramitación. Tipo de evento inferred | |||
| Información adicional solicitada | Esta actividad se produce cuando la persona encargada de la reclamación determina que necesita más información de quien la presenta o de un tercero para continuar. A menudo, esto inicia un estado de espera en el proceso. | ||
| Por qué es importante Esta actividad marca el inicio de un ciclo habitual de repetición de trabajo o espera. Analizar su frecuencia y duración ayuda a detectar problemas en la recopilación inicial de datos y la comunicación. Dónde obtenerlo Suele registrarse mediante un cambio de estado específico, como «Información pendiente», o mediante el registro de un evento de comunicación saliente. Capturar Identifique los cambios de estado a «Información pendiente» o la creación de una tarea o comunicación relacionada con una solicitud de información. Tipo de evento inferred | |||
| Investigación completada | Indica que han concluido todas las actividades de investigación y que se han recopilado y documentado todos los datos necesarios. Este paso es un requisito previo para tomar una decisión final sobre la reclamación. | ||
| Por qué es importante Este hito marca el final de la fase de recopilación de pruebas. El tiempo transcurrido hasta este punto es clave para comprender la eficiencia de la investigación. Dónde obtenerlo Suele inferirse cuando el estado de la reclamación cambia de «En investigación» a un estado de decisión, como «Pendiente de decisión» o «Lista para evaluación». Capturar Identifique el cambio de estado que indica el final de la investigación y que la reclamación está lista para una decisión definitiva. Tipo de evento inferred | |||
| Investigación iniciada | Esta actividad marca el inicio de la fase formal de investigación exhaustiva de la reclamación. 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 permite aislar y medir la duración de esta fase, que suele ser compleja y llevar mucho tiempo. Dónde obtenerlo A menudo se deduce de un cambio de estado de la reclamación a «En investigación» o a un estado similar, o de la creación de la primera tarea relacionada con la investigación. Capturar Busque un cambio de estado a «En investigación» o la creación de la primera tarea formal de investigación. Tipo de evento inferred | |||
| Pago autorizado | Representa la aprobación formal del pago del importe de liquidación calculado. A menudo es un paso independiente que requiere la intervención de un gerente u otra autoridad 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 revelar 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 en el sistema, como «Aprobado para el pago». Capturar Registre la marca de tiempo del evento de aprobación del pago o del cambio de estado a «Aprobado para el pago». Tipo de evento explicit | |||
| Persona responsable de la reclamación asignada | Esta actividad registra la asignación de la reclamación a una persona o equipo específico encargado de tramitarla. Establece quién se responsabiliza de gestionar el caso durante todo su ciclo de vida. | ||
| Por qué es importante El seguimiento de las asignaciones es fundamental para analizar la distribución de la carga de trabajo y el rendimiento del equipo, así como para identificar demoras en los traspasos de reclamaciones. Dónde obtenerlo Esta información suele registrarse en un historial de asignaciones o mediante el seguimiento de los cambios en el campo «responsable» o «asignado» del registro de la reclamación. Capturar Registre las actualizaciones de los campos de asignación de usuarios o grupos asociados al caso de la reclamación. Tipo de evento explicit | |||
| Reclamación reabierta | Se produce cuando una reclamación previamente cerrada o denegada se reactiva para revisarla o procesarla de nuevo. Suele deberse a una apelación, a nueva información o a la detección de un error. | ||
| Por qué es importante Las reclamaciones reabiertas implican un retrabajo considerable. Registrar 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 cuando el estado cambia de «Cerrado» o «Denegado» a un estado activo, como «En revisión». Capturar Detecte un cambio de estado desde una situación final, por ejemplo, «Cerrado», a una situación activa que no sea 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,
consulte nuestra guía de ETL o seleccione un proceso y un sistema específicos.
¿Todo listo para comenzar?
Empiece a mejorar la gestión de reclamaciones con una guía de extracción específica para su sistema o utilice este Template genérico para preparar su Registro de eventos.
Tome el control: optimice los procesos y mejore el rendimiento desde hoy
Detecte ineficiencias, impulse la innovación y alcance sus objetivos más rápido.
No se requiere tarjeta de crédito. Comience a optimizar hoy.