Il template dei dati per la gestione dei sinistri
Il template dei dati per la gestione dei sinistri
- Attributi consigliati per un’analisi dettagliata
- Attività principali della gestione dei sinistri da monitorare
- Indicazioni pratiche per l’estrazione dei dati
Attributi della gestione dei sinistri
| Nome | Descrizione | ||
|---|---|---|---|
| ID del caso ClaimId | Identificativo univoco di un singolo sinistro, utilizzato come identificativo principale del caso nell’analisi del processo. | ||
| Descrizione L’ID del sinistro è la chiave fondamentale che collega tutte le attività, gli eventi e i dati relativi all’intero ciclo di gestione. Consente di ricostruire in modo coerente ogni interazione, dalla denuncia iniziale alla chiusura definitiva, come parte di un unico caso. Nel Process Mining, questo attributo è essenziale per ricostruire il percorso completo di ogni sinistro. Consente di analizzare i flussi di processo, calcolare i tempi complessivi di risoluzione e individuare le differenze nel modo in cui vengono gestiti i diversi sinistri. Perché è importante È l’identificativo principale che collega tutti gli eventi correlati in un’unica istanza di processo e rende possibile l’analisi dell’intero ciclo di gestione del sinistro. Dove reperirli È una chiave primaria nelle tabelle principali di gestione dei sinistri di FINEOS Claims. Esempi CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Nome dell’attività ActivityName | Nome dell’evento aziendale o dell’attività specifica che si è verificata in una fase del processo di gestione dei sinistri. | ||
| Descrizione Questo attributo descrive un singolo passaggio o una tappa del processo di gestione dei sinistri, ad esempio Claim Submitted, Initial Review Performed o Payment Issued. Ogni attività rappresenta un’azione distinta svolta nell’ambito del sinistro. Analizzare la sequenza e la frequenza di queste attività è alla base del Process Mining. L’analisi mostra il flusso effettivo del processo, aiuta a individuare i colli di bottiglia in cui si accumula il lavoro e mette in evidenza i percorsi più comuni o eccezionali seguiti dai sinistri. Perché è importante Definisce i passaggi del processo e consente di visualizzarne la mappa, analizzando i modelli dei flussi di lavoro e le relative deviazioni. Dove reperirli In genere si ricava dagli Event Log, dai cambi di stato delle attività o dalle tracce di audit di FINEOS Claims. Esempi Sinistro registratoDanno valutatoPagamento autorizzatoSinistro chiuso | |||
| Ora dell’evento EventTime | Data e ora che indicano quando si è verificata una specifica attività o un evento. | ||
| Descrizione L’ora dell’evento registra la data e l’ora esatte in cui si è svolta un’attività di gestione del sinistro. Questi dati cronologici sono fondamentali per ordinare correttamente gli eventi e ricostruire la sequenza temporale del caso. Nell’analisi, questa data e ora servono a calcolare durate, tempi di ciclo e tempi di attesa tra le diverse fasi. Sono indispensabili per individuare i ritardi, misurare le prestazioni rispetto agli SLA e comprendere l’andamento del processo nel tempo. Perché è importante Definisce l’ordine cronologico degli eventi, indispensabile per calcolare tutte le metriche temporali, come il tempo di ciclo, e individuare i colli di bottiglia. Dove reperirli In genere, queste informazioni sono disponibili come data e ora di creazione o aggiornamento associate a ciascun evento o registrazione di stato in FINEOS Claims. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
| Sistema di origine SourceSystem | Identifica il sistema informatico da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo indica l’origine dei dati di processo. In questa analisi il valore sarà sempre FINEOS Claims; in un ambiente con più sistemi, è invece fondamentale per ricostruire la provenienza dei dati e garantirne la qualità. Più in generale, aiuta a distinguere i processi che coinvolgono più sistemi e a interpretare correttamente i dati in base alla loro origine. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, necessarie per la governance e la convalida dei dati e per l’integrazione con altri sistemi. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione per indicare l’origine del set di dati. Esempi FINEOS ClaimsFINEOS Claims v11.2 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultimo aggiornamento dei dati dell’evento dal sistema di origine. | ||
| Descrizione Questo attributo indica la data e l’ora dell’estrazione o dell’aggiornamento più recente dei dati. È utile per valutarne l’attualità e capire quanto siano aggiornati i dati analizzati. Questa informazione è fondamentale per la governance dei dati e permette agli utenti di sapere se stanno consultando i dati di processo più recenti. Aiuta a gestire le aspettative sui ritardi di aggiornamento ed è essenziale per la reportistica sui processi quasi in tempo reale. Perché è importante Indica quanto sono aggiornati i dati e permette agli utenti di capire quale periodo copre l’analisi e quando è stato effettuato l’ultimo aggiornamento. Dove reperirli In genere, questa data e ora viene generata e registrata dallo strumento di estrazione dei dati o di ETL al termine del caricamento. Esempi 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Canale di invio SubmissionChannel | Metodo o canale utilizzato per inviare inizialmente il sinistro. | ||
| Descrizione Questo attributo registra la modalità di ricezione del sinistro, ad esempio tramite un portale online, e-mail, posta o un agente. Il canale di invio può incidere notevolmente sulla qualità dei dati e sui tempi iniziali di elaborazione. Analizzare il processo in base al canale di invio aiuta a capire se alcuni canali consentono un’elaborazione più rapida, comportano più rilavorazioni (ad esempio, per informazioni mancanti) o portano a esiti migliori. Queste informazioni possono orientare gli investimenti per ottimizzare i canali, ad esempio migliorando i moduli online per ridurre gli errori. Perché è importante Aiuta a capire se alcuni canali di ricezione consentono un’elaborazione più efficiente o comportano più rilavorazioni, fornendo indicazioni utili per definire la strategia e gli investimenti sui canali. Dove reperirli Consulti la documentazione di FINEOS Claims. Questo dato viene in genere acquisito durante la fase di ricezione del sinistro e memorizzato nella scheda principale. Esempi Portale onlinePostaIntermediarioTelefono | |||
| Data obiettivo di risoluzione ResolutionTargetDate | Data entro cui si prevede di risolvere il sinistro, in base agli SLA o ai requisiti normativi. | ||
| Descrizione Questo attributo indica la scadenza entro cui completare il processo di gestione del sinistro, definita dagli accordi sul livello di servizio (SLA) o dai requisiti normativi. Costituisce il valore di riferimento per misurare le prestazioni effettive. Questa data è essenziale per monitorare il rispetto degli SLA. Confrontando la data effettiva di chiusura del sinistro con la data obiettivo di risoluzione, è possibile calcolare il tasso di conformità agli SLA, individuare i sinistri a rischio di mancato rispetto delle scadenze e analizzare le cause profonde dei ritardi che determinano la non conformità. Perché è importante È il valore di riferimento per misurare la conformità agli SLA. Consente di individuare i sinistri in ritardo e analizzarne le cause. Dove reperirli Consulti la documentazione di FINEOS Claims. Spesso questa data viene calcolata applicando regole aziendali alla data e al tipo di invio del sinistro. Esempi 2023-11-15T23:59:59Z2024-01-30T23:59:59Z | |||
| Gravità del sinistro ClaimSeverity | Classificazione della complessità del sinistro o del suo potenziale impatto finanziario (ad esempio, basso, medio, alto). | ||
| Descrizione La gravità del sinistro indica il livello di complessità, urgenza o esposizione finanziaria. Rispetto ai sinistri di bassa gravità, quelli più gravi possono richiedere più passaggi, verifiche specialistiche o tempi di elaborazione più lunghi. L’analisi del processo in base alla gravità aiuta a capire se l’allocazione delle risorse e la progettazione del processo sono adeguate ai diversi livelli di complessità. Può rivelare se i sinistri più gravi subiscono ritardi sproporzionati o se quelli meno gravi sono sottoposti a verifiche eccessive, favorendo una segmentazione del processo e una gestione delle risorse più efficaci. Perché è importante La segmentazione per gravità consente di verificare se il processo assegna la giusta priorità ai sinistri con maggiore impatto e di individuare i livelli di complessità che causano colli di bottiglia. Dove reperirli Consulti la documentazione di FINEOS Claims. La gravità può essere indicata in un campo dedicato oppure ricavata da altri attributi, come l’importo stimato del danno. Esempi BassoMedioAltoComplesso | |||
| Liquidatore assegnato AssignedAdjuster | Nome o ID del liquidatore o dell’utente responsabile dell’attività. | ||
| Descrizione Questo attributo identifica la persona o il team che ha svolto una specifica attività nel processo di gestione dei sinistri. È il principale collegamento tra le attività di processo e le risorse umane. Analizzare i dati per liquidatore assegnato è fondamentale per comprendere la distribuzione del carico di lavoro, le prestazioni individuali e l’efficienza nell’impiego delle risorse. L’analisi può mettere in evidenza i liquidatori sovraccarichi, individuare esigenze formative confrontando i risultati e favorire una migliore assegnazione delle risorse per bilanciare i carichi di lavoro. Perché è importante Collega le fasi del processo alle persone che le svolgono e consente di analizzare il carico di lavoro, valutare l’efficienza nell’impiego delle risorse e confrontare le prestazioni. Dove reperirli Consultare la documentazione di FINEOS Claims. Queste informazioni sono in genere registrate nei campi relativi alla titolarità delle attività o all’assegnazione degli utenti associati agli eventi del sinistro. Esempi John SmithEmily JonesADJ-4561 | |||
| Ora di fine EndTime | Data e ora che indicano quando è stata completata una specifica attività o un evento. | ||
| Descrizione L’attributo Ora di fine registra il momento esatto in cui termina un’attività. Insieme all’ora di inizio (EventTime), consente di calcolare con precisione quanto tempo è servito per completare ogni passaggio, ovvero il relativo tempo di elaborazione. Nell’analisi, è fondamentale per distinguere il tempo di elaborazione effettivo dai tempi di attesa. Consente di creare analisi dettagliate dei colli di bottiglia, mostrando quali attività richiedono più tempo e in quali punti si formano le code. Perché è importante Consente di calcolare con precisione il tempo di elaborazione di ogni attività, un dato essenziale per individuare i passaggi inefficienti e valutare l’impiego delle risorse. Dove reperirli Consultare la documentazione di FINEOS Claims. Il dato potrebbe essere disponibile negli Event Log oppure ricavabile dall’ora di inizio dell’evento successivo. Esempi 2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T17:00:00Z | |||
| Reparto Department | Reparto o unità aziendale responsabile della gestione dell’attività o del sinistro. | ||
| Descrizione Questo attributo indica l’unità organizzativa, ad esempio «Ricezione iniziale», «Unità investigativa» o «Reparto pagamenti», responsabile di una determinata attività o titolare del sinistro in una specifica fase. Analizzare il processo per reparto è fondamentale per comprendere i passaggi di consegne tra funzioni, spesso all’origine dei ritardi. L’analisi aiuta a individuare i reparti che costituiscono colli di bottiglia, misurare l’efficienza di ciascuno e valutare come vengono distribuite le risorse nell’organizzazione. Perché è importante Consente di analizzare le prestazioni per unità organizzativa, mettendo in evidenza i ritardi nei passaggi tra reparti e i colli di bottiglia a livello di reparto. Dove reperirli Consulti la documentazione di FINEOS Claims. Il dato può essere associato al profilo utente del liquidatore assegnato o alla coda a cui è assegnata un’attività. Esempi Ricezione e registrazioneUnità investigativa specialeElaborazione dei pagamentiValutazione medica | |||
| Stato del sinistro ClaimStatus | Stato attuale o storico del sinistro al momento dell’evento. | ||
| Descrizione Lo stato del sinistro indica la fase del suo ciclo di vita, ad esempio «Aperto», «In attesa di informazioni», «Approvato», «Respinto» o «Chiuso». Questo attributo mostra a che punto si trova il sinistro in un determinato momento. Nell’analisi dei processi, le variazioni di stato corrispondono spesso direttamente alle attività svolte. Monitorare lo stato è fondamentale per comprendere gli esiti dei sinistri, individuare i colli di bottiglia in cui restano bloccati a lungo e analizzare le ragioni degli esiti finali, come «Respinto» o «Chiuso». Perché è importante Questo attributo è essenziale per comprendere gli esiti dei sinistri, filtrare i casi attivi e quelli chiusi e individuare le fasi in cui i sinistri restano bloccati. Dove reperirli Consulti la documentazione di FINEOS Claims. È un campo fondamentale della scheda principale del sinistro, aggiornato nel corso del suo ciclo di vita. Esempi RegistratoIn revisioneIn attesa di pagamentoChiuso - PagatoChiuso - Respinto | |||
| Tipo di sinistro ClaimType | Categoria del sinistro assicurativo, ad esempio invalidità, danni a beni o responsabilità civile. | ||
| Descrizione Il tipo di sinistro classifica i sinistri in base alla natura della polizza o dell’evento che ha causato il danno. I diversi tipi di sinistro seguono spesso varianti di processo specifiche, sono soggetti a requisiti normativi diversi e richiedono modalità di gestione dedicate. È una dimensione fondamentale per l’analisi comparativa. Filtrando o segmentando la vista del processo per tipo di sinistro, gli analisti possono individuare i colli di bottiglia specifici, confrontare le prestazioni tra le categorie e definire interventi di miglioramento mirati alle esigenze di ciascun tipo di sinistro. L’analisi aiuta a capire se alcuni tipi di sinistro sono intrinsecamente meno efficienti da gestire. Perché è importante Consente di segmentare il processo per confrontare le prestazioni e individuare le differenze tra le categorie di sinistri, così da definire interventi di miglioramento più mirati. Dove reperirli Consulti la documentazione di FINEOS Claims. È un attributo fondamentale del sinistro, in genere impostato al momento della registrazione e memorizzato nella tabella principale dei casi. Esempi Invalidità a breve termineInvalidità a lungo termineAssicurazione sulla vitaMorte accidentale | |||
| Area geografica del cliente CustomerRegion | Area geografica o stato di residenza del richiedente o del contraente. | ||
| Descrizione Questo attributo indica la posizione geografica associata al sinistro, determinata in base all’indirizzo del richiedente o al luogo in cui si è verificato il danno. L’analisi geografica può far emergere differenze regionali nei tipi e nella frequenza dei sinistri e nell’efficienza della loro gestione. Aiuta a capire se alcune sedi regionali ottengono risultati migliori di altre o se fattori locali, come le normative o gli eventi meteorologici, incidono sul processo. Queste informazioni consentono di orientare meglio la gestione e l’allocazione delle risorse. Perché è importante Consente di segmentare i dati per area geografica e individuare differenze regionali nelle prestazioni, nella conformità o nei colli di bottiglia legati a specifiche località. Dove reperirli Consulti la documentazione di FINEOS Claims. Queste informazioni si ricavano in genere dai dati dell’indirizzo del contraente o del richiedente memorizzati nel sistema. Esempi Nord-estCaliforniaMedio OvestFlorida | |||
| Data del sinistro LossDate | Data in cui si è verificato l’evento che ha dato origine alla richiesta di indennizzo. | ||
| Descrizione La data del sinistro indica quando si è verificato l’evento, ad esempio un incidente o un infortunio. È diversa dalla data di invio della richiesta e può essere un fattore importante per la convalida e la gestione del sinistro. Questo attributo fornisce un contesto utile. L’intervallo tra la data del sinistro e la data di invio della richiesta (ritardo nella denuncia) può essere un indicatore chiave delle prestazioni. Analizzarlo può far emergere problemi nel processo di denuncia e il loro impatto sul ciclo di vita complessivo del sinistro. Perché è importante Fornisce un contesto importante e consente di calcolare il ritardo nella denuncia, ossia il tempo trascorso tra il sinistro e l’invio della richiesta, che può influire sulla complessità e sull’esito del caso. Dove reperirli Consulti la documentazione di FINEOS Claims. Questa data è un campo standard, acquisito durante la fase di «Prima denuncia del sinistro» o di registrazione. Esempi 2023-10-152023-09-012024-02-20 | |||
| È una rilavorazione IsRework | Indicatore booleano che segnala se un’attività è una ripetizione o una rilavorazione. | ||
| Descrizione Questo attributo calcolato contrassegna le attività che rappresentano una rilavorazione, ad esempio una seconda occorrenza dell’evento «Richieste informazioni aggiuntive» per lo stesso sinistro. In genere viene individuata rilevando attività ripetute o passaggi a ritroso nel flusso del processo. Segnalare esplicitamente le rilavorazioni semplifica le analisi dell’inefficienza e consente di calcolarne facilmente il tasso, un indicatore chiave delle prestazioni. Le Dashboard possono usare questo indicatore per visualizzare la frequenza e l’impatto delle rilavorazioni e aiutare a individuare le cause profonde di questi cicli inefficienti. Perché è importante Segnala direttamente i cicli inefficienti del processo, semplificando il calcolo del tasso di rilavorazione e l’analisi dei fattori che portano a ripetere il lavoro. Dove reperirli Questo dato viene ricavato durante l’analisi di Process Mining, individuando le attività ripetute per lo stesso caso. Ad esempio, si può contrassegnare la seconda occorrenza di «Indagine avviata». Esempi truefalse | |||
| Importo del danno LossAmount | Importo finanziario stimato o accantonato in relazione al danno. | ||
| Descrizione L’importo del danno rappresenta la stima iniziale o la riserva finanziaria accantonata per un sinistro. Il valore può essere aggiornato durante le indagini e la valutazione del caso. Questi dati finanziari sono fondamentali per segmentare i sinistri e capire come l’impatto economico si correla alle modalità di svolgimento del processo. Ad esempio, aiutano a rispondere a domande come: i sinistri di importo più elevato richiedono più tempo per essere gestiti o comportano più rilavorazioni? Sono inoltre un elemento essenziale per le previsioni finanziarie e la gestione dei rischi. Perché è importante Fornisce un contesto finanziario per il processo e consente di analizzare come il valore del sinistro incida sui tempi di elaborazione, sulla complessità e sui percorsi seguiti. Dove reperirli Consulti la documentazione di FINEOS Claims. Queste informazioni si trovano in genere nelle tabelle finanziarie o relative alle riserve collegate al sinistro. Esempi 5000.00150000.00250.50 | |||
| Importo del pagamento PaymentAmount | Importo effettivamente pagato per il sinistro. | ||
| Descrizione L’importo del pagamento è la somma finale erogata dopo la liquidazione e l’approvazione del sinistro. Se sono stati effettuati più pagamenti, può riferirsi a una singola transazione. Questo attributo è essenziale per la riconciliazione finanziaria e per analizzare gli esiti economici del processo. Consente di confrontare la stima iniziale del danno con l’importo finale liquidato. Nell’analisi del processo, aiuta a comprendere l’impatto finanziario delle diverse varianti o decisioni. Perché è importante Registra l’esito finanziario del processo, un dato fondamentale per misurare le prestazioni finanziarie e analizzare il valore dei sinistri. Dove reperirli Consulti la documentazione di FINEOS Claims. Questi dati si trovano nelle tabelle delle transazioni di pagamento collegate al caso. Esempi 4850.00145000.000.00 | |||
| Motivo del rifiuto DenialReason | Codice o descrizione che spiega perché un sinistro è stato respinto. | ||
| Descrizione Quando l’esito di un sinistro è «Respinto», questo attributo indica il motivo specifico della decisione. Tra le possibili cause figurano «Escluso dalla polizza», «Sospetta frode» o «Informazioni incomplete». È un attributo fondamentale per analizzare le cause profonde dei rifiuti. Esaminando la frequenza dei diversi motivi, l’organizzazione può individuare problemi ricorrenti nella procedura di invio, dubbi dei clienti sulla copertura della polizza o possibili esigenze di formazione dei liquidatori. Queste informazioni possono portare a iniziative per ridurre i rifiuti e migliorare la soddisfazione dei clienti. Perché è importante È essenziale per analizzare le cause profonde degli esiti negativi del processo e individuare opportunità per ridurre i rifiuti dei sinistri e migliorare la qualità della fase di ricezione. Dove reperirli Consulti la documentazione di FINEOS Claims. In genere si tratta di un campo strutturato o di un codice selezionato quando viene eseguita l’attività «Sinistro respinto». Esempi Esclusione dalla polizzaInformazioni non forniteSinistro duplicatoSospetta frode | |||
| Motivo della riapertura ReopenReason | Codice o descrizione che spiega perché un sinistro chiuso è stato riaperto. | ||
| Descrizione Questo attributo registra il motivo per cui un sinistro è passato dallo stato «Chiuso» a uno stato attivo. Tra i motivi più comuni figurano la ricezione di nuove informazioni, un ricorso del richiedente o la correzione di un errore. Analizzare i motivi delle riaperture è un modo diretto per misurare la qualità e la definitività del processo. Un numero elevato di sinistri riaperti, soprattutto per motivi ricorrenti, indica che la chiusura iniziale non è stata corretta. Questi dati possono mettere in luce le debolezze nelle fasi di indagine o di decisione e indicare con chiarezza dove intervenire per migliorare il processo, così da chiudere correttamente i sinistri fin dal primo tentativo. Perché è importante Fornisce indicazioni dirette sui casi in cui un sinistro è stato chiuso troppo presto o in modo errato, evidenziando le opportunità per risolverlo correttamente al primo tentativo. Dove reperirli Consulti la documentazione di FINEOS Claims. In genere il motivo viene registrato quando un utente esegue l’azione «Riapri sinistro» nel sistema. Esempi Ricorso presentatoRicevute nuove prove medicheCorrezione di un errore amministrativoNecessaria una rettifica del pagamento | |||
| Numero di polizza PolicyNumber | Identificativo univoco della polizza assicurativa a cui fa riferimento il sinistro. | ||
| Descrizione Il numero di polizza identifica il contratto assicurativo a copertura del sinistro. Collega il sinistro a un cliente specifico, alle condizioni della polizza e ai dettagli della copertura. Pur non essendo direttamente un attributo del processo, fornisce un contesto aziendale essenziale. Consente di aggregare i dati dei sinistri per polizza o cliente, un’operazione utile per analizzare la frequenza dei sinistri e l’esperienza dei clienti, nonché per individuare le polizze che generano molti sinistri complessi. Perché è importante Fornisce un contesto aziendale essenziale: collega il sinistro a uno specifico contratto del cliente e consente di analizzare il processo dal punto di vista del cliente. Dove reperirli Consulti la documentazione di FINEOS Claims. È un dato fondamentale, acquisito al momento della registrazione del sinistro e memorizzato nella scheda principale. Esempi POL-987654321POL-123456789 | |||
| Stato SLA SLAState | Stato calcolato che indica se un sinistro completato ha rispettato la data obiettivo di risoluzione. | ||
| Descrizione Questo attributo fornisce uno stato chiaro e categoriale delle prestazioni SLA per ciascun sinistro. Si ricava confrontando la data di «Chiusura del sinistro» con la «Data obiettivo di risoluzione» e classificando l’esito come «Nei tempi» o «In ritardo». Semplifica la rendicontazione e l’analisi del rispetto degli SLA. Invece di lavorare con le date grezze, gli analisti possono usare questa semplice categoria per creare Dashboard che mostrano il tasso di conformità agli SLA, filtrare tutti i sinistri in ritardo e analizzarne le caratteristiche comuni, nonché monitorare l’andamento delle prestazioni SLA nel tempo. Supporta direttamente la Dashboard e l’indicatore chiave relativi al rispetto degli SLA. Perché è importante Fornisce un indicatore chiaro e semplice delle prestazioni SLA per ogni caso, facilitando la misurazione e l’analisi del tasso di conformità agli SLA. Dove reperirli È un campo calcolato confrontando la data e l’ora dell’ultima attività con la «ResolutionTargetDate» di ciascun caso. Esempi Nei tempiIn ritardo | |||
Attività di gestione dei sinistri
| Attività | Descrizione | ||
|---|---|---|---|
| Decisione sul sinistro presa | È una tappa decisiva in cui l’assicuratore approva, approva parzialmente o respinge formalmente il sinistro. In FINEOS viene quasi sempre registrata con un passaggio esplicito a uno stato come Approved, Denied o Settled. | ||
| Perché è importante È una tappa fondamentale, che determina il percorso successivo del processo, verso il pagamento o la chiusura. È essenziale per misurare il tempo necessario a prendere una decisione e analizzare gli esiti dei sinistri. Dove reperirli Si deduce dalla data e ora riportate nello storico degli stati del sinistro, in corrispondenza di uno stato decisionale finale, ad esempio Approved, Rejected o Denied. Acquisizione Data e ora del passaggio allo stato Approved o Denied. Tipo di evento inferred | |||
| Pagamento autorizzato | Indica l’approvazione formale del pagamento dell’importo calcolato. Spesso è una fase distinta dalla decisione sul sinistro e richiede l’autorizzazione di un responsabile o di un team specifico. Viene registrata con un cambio di stato, ad esempio Approved for Payment. | ||
| Perché è importante Questa attività è fondamentale per il KPI relativo al tempo di ciclo dell’autorizzazione del pagamento. I ritardi tra la decisione e l’autorizzazione possono costituire un collo di bottiglia nascosto e incidere sensibilmente sulla soddisfazione dei clienti. Dove reperirli Si deduce dalla data e ora del passaggio a Pending Payment, Ready for Payment o Payment Authorized nello storico degli stati del sinistro. Acquisizione Data e ora del passaggio allo stato Approved for Payment o a uno stato analogo. Tipo di evento inferred | |||
| Pagamento emesso | Indica il momento in cui il pagamento viene effettivamente elaborato e inviato al richiedente o al fornitore. In FINEOS, spesso l’operazione è avviata dall’integrazione con un sistema finanziario e registrata in un registro delle transazioni o con l’aggiornamento dello stato finale del pagamento. | ||
| Perché è importante È un momento decisivo per il cliente. Analizzare il tempo che intercorre tra l’autorizzazione e l’emissione del pagamento aiuta a semplificare il processo e a migliorare l’esperienza del cliente. Dove reperirli Può trattarsi di un evento esplicito registrato in una tabella delle transazioni di pagamento di FINEOS o in un sistema integrato di contabilità fornitori. Anche il passaggio allo stato Paid è una possibile fonte. Acquisizione Utilizzare la data della transazione nel registro dei pagamenti oppure la data e l’ora del passaggio allo stato Paid. Tipo di evento explicit | |||
| Sinistro chiuso | Indica lo stato finale del sinistro nel sistema, dopo il completamento di tutte le attività, compreso il pagamento o il respingimento. L’evento viene registrato quando lo stato del sinistro passa a Closed o Finalized in FINEOS. | ||
| Perché è importante Questa attività è il principale evento finale del processo. Il tempo che intercorre tra Claim Submitted e Claim Closed è un KPI fondamentale per misurare l’efficienza e le prestazioni complessive del processo. Dove reperirli Si deduce dalla data e ora dell’ultimo passaggio allo stato Closed nello storico degli stati del sinistro. È l’ultimo aggiornamento registrato per un sinistro completato correttamente. Acquisizione Data e ora del passaggio finale allo stato Closed o Finalized. Tipo di evento inferred | |||
| Sinistro denunciato | Indica la ricezione iniziale della denuncia di sinistro da parte dell’organizzazione, spesso tramite canali diversi, come portali web, e-mail o posta. È il punto di partenza del processo e viene in genere registrato quando la First Notice of Loss (FNOL) viene inserita in un’area di staging o direttamente in FINEOS. | ||
| Perché è importante Questa attività costituisce il principale evento di inizio del processo. Analizzare il tempo che intercorre tra la denuncia e la registrazione aiuta a individuare i ritardi nell’inserimento dei dati e nell’apertura iniziale del sinistro, che incidono sul tempo di ciclo complessivo. Dove reperirli È probabile che il dato venga ricavato dalla data di creazione della prima notifica di sinistro o della registrazione FNOL in FINEOS. Può provenire da un Event Log esplicito oppure essere dedotto dalla prima data e ora associate all’ID del sinistro. Acquisizione Utilizzare la data e l’ora di creazione della First Notice of Loss (FNOL) o della registrazione iniziale del sinistro. Tipo di evento inferred | |||
| Sinistro registrato | Indica la creazione formale della registrazione del sinistro nel sistema FINEOS. In questa fase viene assegnato ufficialmente un ID univoco e il caso viene aperto per la gestione. L’evento viene in genere rilevato dalla data e ora di creazione dell’oggetto principale del sinistro. | ||
| Perché è importante È una tappa fondamentale, che trasforma una semplice notifica in un caso attivo. Costituisce un punto di partenza affidabile per misurare il ciclo di gestione interno. Dove reperirli Si ricava dalla data e ora di creazione dell’entità principale del caso nel database FINEOS. Per finalità di audit, la maggior parte degli oggetti principali del sistema registra una data di creazione. Acquisizione Utilizzare la data e l’ora di creazione della registrazione principale del caso. Tipo di evento explicit | |||
| Danno valutato | Indica che l’impatto economico del sinistro è stato calcolato e registrato. La valutazione può includere danni, spese mediche o altre passività. Spesso l’evento viene rilevato quando in FINEOS vengono compilati e salvati specifici campi relativi alla valutazione economica. | ||
| Perché è importante È una tappa economica fondamentale. Il tempo necessario per valutare il danno dopo la conclusione dell’indagine può essere un indicatore delle prestazioni del team di valutazione. Dove reperirli È probabile che venga dedotto dalla data e ora in cui i campi relativi alle riserve economiche o alla stima del danno vengono compilati per la prima volta o finalizzati nel sistema. Potrebbe non corrispondere a uno stato distinto, ma a un evento di inserimento dei dati. Acquisizione Utilizzare la data e l’ora dell’ultimo aggiornamento dei campi relativi alla valutazione economica o alle riserve. Tipo di evento inferred | |||
| Importo della liquidazione calcolato | Dopo l’approvazione, viene calcolato l’importo esatto da pagare in base ai massimali di polizza, alle franchigie e ai danni valutati. È probabile che l’evento venga registrato quando l’importo finale del pagamento o della liquidazione viene inserito e confermato in FINEOS. | ||
| Perché è importante Questa attività distingue il calcolo dell’importo dalle fasi di approvazione e autorizzazione del pagamento. Aiuta ad analizzare l’efficienza del team finanziario nel definire l’importo finale. Dove reperirli Si deduce dalla data e ora in cui l’importo finale della liquidazione o del pagamento viene inserito o aggiornato nei dati finanziari del sinistro. Acquisizione Utilizzare la data e l’ora dell’ultimo aggiornamento del campo relativo all’importo finale della liquidazione. Tipo di evento inferred | |||
| Indagine avviata | Indica l’inizio della fase formale di indagine o valutazione del sinistro. In genere viene registrato quando il caso è assegnato a un investigatore o quando lo stato passa esplicitamente a Under Investigation in FINEOS. | ||
| Perché è importante Questa tappa segna l’inizio di una fase potenzialmente lunga e complessa. Registrarne l’ora di avvio è essenziale per misurare la durata e l’efficienza dell’indagine. Dove reperirli Si deduce dalla data e ora del passaggio allo stato Under Investigation o Adjudication in Progress. Può anche corrispondere alla data di assegnazione al sinistro di un ruolo di investigatore. Acquisizione Data e ora del passaggio del sinistro allo stato Under Investigation. Tipo di evento inferred | |||
| Indagine completata | Indica che tutte le attività necessarie per l’indagine sono terminate e che il sinistro è pronto per la decisione finale. Si deduce dal passaggio da Under Investigation a uno stato successivo, come Pending Decision o Ready for Assessment. | ||
| Perché è importante Questa attività segna la fine della raccolta delle prove. Analizzare il tempo che intercorre tra Investigation Started e questa fase aiuta a individuare i colli di bottiglia nel processo di valutazione. Dove reperirli Si deduce dalla data e ora in cui lo stato del sinistro passa da Under Investigation a uno stato che indica l’avvio della fase decisionale o di valutazione. Acquisizione Data e ora del passaggio del sinistro da Under Investigation a Ready for Decision. Tipo di evento inferred | |||
| Informazioni aggiuntive ricevute | Indica la ricezione dei documenti o delle informazioni richiesti, che consente di riprendere la gestione del sinistro. In genere si deduce dal passaggio dallo stato Pending Information a uno stato attivo, come Under Review o Ready for Assessment. | ||
| Perché è importante Misurare il tempo tra la richiesta e la ricezione delle informazioni permette di evidenziare i ritardi dovuti a fattori esterni. Segnala inoltre la ripresa della gestione interna ed è quindi utile per analizzare i tempi di attesa e i blocchi del processo. Dove reperirli Si deduce dalla data e ora in cui lo stato del sinistro passa da Pending ad Active o In Progress. Anche l’evento di caricamento di un documento associato può fornire una data e un’ora precise. Acquisizione Data e ora del passaggio da Pending Information a uno stato di gestione attiva. Tipo di evento inferred | |||
| Prima revisione completata | Indica che un liquidatore o un addetto ha completato la prima valutazione della validità del sinistro, dei relativi dettagli e della documentazione necessaria. Spesso si deduce da una modifica dello stato in FINEOS, ad esempio dal passaggio da New o Registered a Under Review o Assigned. | ||
| Perché è importante Registrare il completamento di questa fase aiuta a misurare il tempo necessario per la prima azione e a individuare gli arretrati nella fase iniziale di valutazione e assegnazione. Eventuali ritardi possono allungare sensibilmente l’intero ciclo di gestione del sinistro. Dove reperirli Si deduce dalla data e ora in cui lo stato del sinistro cambia indicando che la revisione è terminata, ad esempio Initial Review Complete, Pending Information o Under Investigation. Il dato si trova in genere in una tabella con lo storico degli stati del sinistro. Acquisizione Individuare la data e l’ora del passaggio dallo stato New o Open a uno stato successivo alla revisione. Tipo di evento inferred | |||
| Richiesta di informazioni aggiuntive | Questa attività si verifica quando l’addetto alla gestione del sinistro stabilisce che, per procedere, servono altre informazioni dal richiedente o da una terza parte. In FINEOS viene spesso registrata con il passaggio allo stato Pending Information oppure con la registrazione di un evento specifico di comunicazione in uscita. | ||
| Perché è importante Questa attività è fondamentale per analizzare le rilavorazioni e i cicli del processo. Se si verifica spesso, può indicare problemi nella raccolta iniziale dei dati ed essere una delle principali cause di ritardo. Dove reperirli Si deduce dal passaggio del sinistro allo stato Pending Information o a uno stato analogo. Può anche essere registrata come evento esplicito quando il sistema genera una comunicazione con la richiesta di informazioni. Acquisizione Data e ora del passaggio allo stato Pending Information oppure registrazione della richiesta di informazioni inviata per lettera o e-mail. Tipo di evento inferred | |||
| Sinistro respinto | Indica l’esito finale di un sinistro per il quale il pagamento non è stato approvato. L’evento viene registrato quando lo stato del sinistro è impostato definitivamente su Denied o Rejected. È un possibile punto di conclusione alternativo del processo. | ||
| Perché è importante Questa attività è un punto di conclusione fondamentale del processo. Analizzare i percorsi che portano al respingimento può fornire indicazioni sulla qualità dei dati raccolti, sull’interpretazione delle polizze o su possibili schemi di frode. Dove reperirli Si deduce dalla data e ora in cui lo stato finale del sinistro viene registrato come Denied o Rejected nella tabella dello storico degli stati. Acquisizione Data e ora del passaggio finale allo stato Denied o Rejected. Tipo di evento inferred | |||
| Sinistro riaperto | Si verifica quando un sinistro precedentemente chiuso viene riattivato per ulteriori verifiche o per proseguire la gestione, spesso in seguito a un ricorso o alla ricezione di nuove informazioni. L’evento viene registrato quando lo stato passa da Closed o Denied a uno stato attivo, come Under Review. | ||
| Perché è importante Monitorare i sinistri riaperti è fondamentale per comprendere le eccezioni e i problemi del processo. Permette di individuare i casi che non sono stati risolti correttamente al primo tentativo e che incidono sull’efficienza e sui costi operativi. Dove reperirli Si deduce dal passaggio da uno stato terminale, ad esempio Closed, a uno stato attivo non terminale, come Reopened o Under Review. Per rilevarlo è necessario analizzare la sequenza dei cambi di stato nel tempo. Acquisizione Individuare la data e l’ora del passaggio da uno stato chiuso a uno stato aperto. Tipo di evento inferred | |||
Guide all’estrazione
I metodi di estrazione per questo processo sono in fase di convalida. Torni a consultare questa pagina più avanti oppure ci contatti per ricevere assistenza.
È pronto a iniziare?
Questo template semplifica la preparazione dei dati, consentendoLe di passare rapidamente all’individuazione di informazioni utili e al miglioramento delle attività di gestione dei sinistri. Inizi a sfruttare i dati fin da oggi per aumentare l’efficienza e migliorare la soddisfazione degli assicurati.
Accelerare la gestione dei sinistri: inizi oggi
Si unisca ai leader che raggiungono il 70% di elaborazione automatica senza intervento in FINEOS.
Non è richiesta alcuna carta di credito; la configurazione richiede pochi minuti.