Il template dei dati per l’inserimento dei clienti KYC
Il template dei dati per l’inserimento dei clienti KYC
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati
Attributi dell’inserimento dei clienti KYC
| Nome | Descrizione | ||
|---|---|---|---|
| Nome dell’attività ActivityName | Il nome dello specifico evento aziendale o dell’attività che si è verificata in un determinato momento del processo di onboarding. | ||
| Descrizione Il nome dell’attività descrive un singolo passaggio o traguardo del percorso di onboarding del cliente, ad esempio 'Verifica iniziale eseguita' o 'Richiesta approvata'. La sequenza delle attività costituisce la base della mappa del processo. L’analisi di questo attributo consente di visualizzare il flusso del processo, individuare i percorsi più comuni e quelli alternativi e misurare la frequenza di ogni passaggio. È fondamentale per capire quali azioni vengono svolte e in quale ordine. Perché è importante Questo attributo definisce i passaggi del processo e consente di creare una mappa del processo e di analizzare il flusso e le varianti. Dove reperirli Queste informazioni si trovano in genere nelle tabelle del flusso di lavoro o del registro di controllo di Fenergo, associate alle transizioni di stato dei casi o al completamento delle attività. Esempi Dati e documenti richiestiRevisione di conformità avviataDomanda approvata | |||
| Ora di inizio EventStartTime | La data e l’ora che indicano l’inizio ufficiale di un’attività o di un evento. | ||
| Descrizione Questo attributo registra la data e l’ora esatte di inizio di una specifica attività. Fornisce l’ordine cronologico necessario per ricostruire il flusso del processo ed è essenziale per tutte le analisi basate sul tempo. Nel Process Mining, l’ora di inizio serve a calcolare la durata delle attività, i tempi di attesa tra un’attività e l’altra e il tempo di ciclo complessivo del caso. Costituisce la struttura temporale dell’Event Log ed è fondamentale per analizzare le prestazioni e i colli di bottiglia. Perché è importante Questa data e ora sono fondamentali per ordinare cronologicamente gli eventi e calcolare tutte le metriche temporali, come i tempi di ciclo e le durate. Dove reperirli Si trova nelle tabelle del registro di controllo, dell’Event Log o della cronologia del flusso di lavoro di Fenergo, spesso con etichette come 'Timestamp', 'StartDate' o 'CreationDate'. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Richiesta del cliente CustomerApplication | Identificativo univoco del percorso di onboarding di un singolo cliente, utilizzato come identificativo principale del caso. | ||
| Descrizione La richiesta del cliente è l’identificativo centrale che raggruppa tutte le attività e gli eventi relativi al processo di onboarding KYC di un singolo cliente. Consente di seguire la richiesta dall’invio iniziale alla risoluzione finale, sia che venga approvata, respinta o chiusa. Nel Process Mining, questo attributo è fondamentale per ricostruire il percorso completo di ogni richiesta. Consente di analizzare i flussi di processo, i tempi di ciclo, le varianti e i colli di bottiglia per singola richiesta, offrendo una visione chiara della gestione dei singoli casi. Perché è importante È l’ID del caso essenziale che collega tutti gli eventi correlati e permette di analizzare il processo di onboarding del cliente dall’inizio alla fine. Dove reperirli In genere corrisponde alla chiave primaria dell’entità di gestione dei casi o di gestione del ciclo di vita del cliente in Fenergo. Esempi APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Sistema di origine SourceSystem | Il sistema di riferimento da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo identifica il sistema di origine dei dati degli eventi. Per questo processo il sistema sarà sempre Fenergo, ma nei dati provenienti da più fonti consente di distinguere i diversi sistemi. In fase di analisi, serve soprattutto a filtrare i dati per sistema o a verificarne la provenienza. Aiuta a mantenere chiarezza negli ambienti in cui si combinano dati provenienti da più sistemi per ottenere una visione complessiva del processo. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la governance e la convalida dei dati e per assicurarsi che l’analisi si basi sulla fonte corretta. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione dei dati per indicare l’origine dei record. Esempi FenergoFenergo CLM | |||
| Ultimo aggiornamento dei dati LastDataUpdate | La data e l’ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati relativi a questo processo. | ||
| Descrizione Questo attributo registra la data e l’ora dell’aggiornamento più recente dei dati. Fornisce un’indicazione della loro attualità ed è importante per valutare quanto siano aggiornate le informazioni analizzate. Nelle Dashboard e nei report, questa informazione indica agli utenti quanto sono recenti i dati. Aiuta a capire se l’analisi riflette le operazioni in tempo reale o una situazione storica. Perché è importante Fornisce un contesto essenziale sull’attualità dei dati, aiutando gli utenti a capire quanto sia aggiornata l’analisi del processo. Dove reperirli Questo valore viene generato e registrato nel set di dati durante il processo di estrazione e caricamento dei dati (ETL). Esempi 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Data obiettivo SLA SlaTargetDate | La data entro cui si prevede di completare il caso di onboarding del cliente. | ||
| Descrizione La data obiettivo SLA rappresenta la scadenza concordata per completare l’intero processo di onboarding relativo a una richiesta del cliente. È un riferimento fondamentale per misurare le prestazioni effettive. Questo attributo è essenziale per la Dashboard 'Monitoraggio della conformità agli SLA' e per calcolare il KPI 'Tasso di rispetto degli SLA'. Consente di gestire in modo proattivo i casi a rischio di superamento dello SLA e aiuta a stabilire le priorità di lavoro. Perché è importante Definisce la data obiettivo di completamento, fondamentale per monitorare il rispetto degli SLA e dare priorità ai casi in ritardo. Dove reperirli Questa data viene spesso calcolata in base alla data di invio della richiesta e alle regole aziendali configurate nel modulo di gestione degli SLA di Fenergo. Esempi 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Dipartimento dell’utente UserDepartment | Il dipartimento o l’unità aziendale a cui appartiene l’utente che ha avviato l’attività. | ||
| Descrizione Questo attributo fornisce il contesto organizzativo dell’utente che ha svolto un’attività, ad esempio 'Conformità', 'Operazioni di onboarding' o 'Vendite'. Spesso deriva dalle informazioni del profilo utente. Questa dimensione è fondamentale per analizzare i passaggi di consegne tra dipartimenti e individuare i colli di bottiglia tra funzioni diverse. Supporta direttamente la Dashboard 'Distribuzione delle attività del personale', consentendo di aggregare il lavoro per team o dipartimento. Perché è importante Consente di analizzare le prestazioni del processo per dipartimento, mettendo in evidenza i passaggi di consegne tra dipartimenti, i ritardi e la distribuzione del carico di lavoro. Dove reperirli Potrebbe essere necessario recuperare queste informazioni da una tabella separata con i dati anagrafici degli utenti o del personale, utilizzando l’ID 'InitiatingUser'. Fenergo potrebbe anche memorizzarle nel profilo dell’utente. Esempi ComplianceOnboarding dei clientiControllo qualità | |||
| Ora di fine EventEndTime | La data e l’ora che indicano il completamento di un’attività o di un evento. | ||
| Descrizione Questo attributo registra la data e l’ora esatte in cui termina una specifica attività. Insieme all’ora di inizio, ne definisce la durata effettiva. Nel Process Mining, l’ora di fine viene utilizzata insieme all’ora di inizio per calcolare il tempo di elaborazione di ogni attività. È essenziale per individuare i passaggi che richiedono più tempo e analizzare l’efficienza nell’impiego delle risorse. Perché è importante Consente di calcolare i tempi di elaborazione delle attività, un dato fondamentale per individuare le attività di lunga durata e i colli di bottiglia che incidono sulle prestazioni. Dove reperirli Si trova nelle tabelle del registro di controllo o della cronologia del flusso di lavoro di Fenergo, spesso con etichette come 'EndDate' o 'CompletionDate', oppure si ricava dall’ora di inizio dell’evento successivo. Esempi 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Punteggio di rischio RiskScore | Un punteggio numerico che rappresenta il livello di rischio calcolato per il cliente. | ||
| Descrizione Il punteggio di rischio è una misura quantitativa del rischio potenziale associato a un cliente, calcolata sulla base di diversi fattori, come la giurisdizione, il settore e i risultati delle verifiche. In genere, il motore di regole di Fenergo calcola questo punteggio. Questo attributo consente di mettere in relazione i livelli di rischio con l’andamento del processo. Ad esempio, l’analisi può rivelare se i clienti ad alto rischio hanno tempi di ciclo più lunghi o richiedono più interventi manuali. Queste informazioni sono utili per la Dashboard 'Analisi approfondita della revisione del rischio e della conformità'. Perché è importante Quantifica il rischio associato al cliente e consente di analizzare l’impatto dei livelli di rischio sulla durata del processo, sulle rilavorazioni e sugli esiti. Dove reperirli È uno dei principali risultati del modulo di valutazione del rischio del cliente di Fenergo. Viene memorizzato nell’entità del caso o del cliente. Esempi 154585 | |||
| Stato della richiesta ApplicationStatus | L’esito attuale o finale della richiesta del cliente. | ||
| Descrizione Questo attributo indica l’esito della richiesta al termine del processo o il suo stato attuale, se è ancora in corso. Tra i valori più comuni figurano 'Approvato', 'Respinto' e 'In corso'. È una dimensione fondamentale per l’analisi degli esiti. Consente di filtrare e confrontare i flussi di processo in base al risultato finale, un’operazione essenziale per la Dashboard 'Rilavorazioni e rifiuti delle richieste' e per calcolare KPI come il tasso di rifiuto delle richieste. Perché è importante Definisce l’esito di un caso e consente di confrontare i percorsi delle richieste approvate con quelli delle richieste respinte, oltre a comprendere i tassi di successo. Dove reperirli In genere corrisponde allo stato finale registrato sull’entità del caso nel sistema di gestione dei casi di Fenergo. Esempi ApprovatoRespintoIn attesa della funzione conformitàChiuso | |||
| Utente che ha avviato l’attività InitiatingUser | L’ID utente o il nome della persona che ha eseguito l’attività. | ||
| Descrizione Questo attributo identifica il dipendente o l’utente di sistema che ha eseguito una determinata attività o un evento. Può essere un ID utente univoco, un nome o un ruolo. L’analisi per utente aiuta a comprendere la distribuzione del carico di lavoro e le prestazioni individuali, oltre a individuare eventuali esigenze di formazione. È essenziale per la Dashboard 'Distribuzione delle attività del personale' e per approfondire le attività svolte da singole persone o team. Perché è importante Registra quale utente ha eseguito un’azione e consente di analizzare la distribuzione del carico di lavoro, le prestazioni dei team e l’allocazione delle risorse. Dove reperirli Queste informazioni sono in genere registrate nei registri di controllo o nelle tabelle della cronologia delle attività di Fenergo, insieme ai dettagli dell’evento, spesso con etichette come 'UserID', 'UserName' o 'ModifiedBy'. Esempi j.doea.smithSYSTEM | |||
| Canale della richiesta ApplicationChannel | Il canale attraverso cui è stata inviata la richiesta del cliente. | ||
| Descrizione Questo attributo identifica la fonte di invio della richiesta, ad esempio un portale online, una filiale o un gestore delle relazioni. La fonte può influire sulla qualità dei dati e sui requisiti di elaborazione. Questa dimensione viene utilizzata nella Dashboard 'Efficienza per origine e tipo di richiesta' per confrontare le prestazioni dei diversi canali. Aiuta le aziende a capire quali canali sono più efficienti e quali potrebbero richiedere una revisione del processo. Perché è importante Identifica la fonte delle richieste e consente di analizzare l’efficienza, i costi e l’esperienza del cliente per ciascun canale. Dove reperirli Queste informazioni potrebbero essere raccolte in un modulo iniziale di inserimento dati in Fenergo o trasmesse da un sistema a monte. Esempi Portale onlineFilialeGestore delle relazioniApp mobile | |||
| Conforme allo SLA IsSlaCompliant | Un indicatore booleano che specifica se il caso è stato completato entro la data obiettivo dello SLA. | ||
| Descrizione Questo attributo è un indicatore binario delle prestazioni SLA per un caso completato. Assume il valore 'true' se la data e l’ora dell’attività finale di chiusura sono uguali o precedenti alla 'SlaTargetDate'; in caso contrario assume il valore 'false'. Questo campo calcolato semplifica il monitoraggio e la rendicontazione degli SLA. Consente di aggregare facilmente i dati per calcolare il KPI complessivo 'Tasso di rispetto degli SLA' e di filtrare i casi per analizzare le caratteristiche dei processi conformi e non conformi. Perché è importante Misura direttamente le prestazioni SLA, semplificando il calcolo del KPI relativo al tasso di rispetto degli SLA e il filtraggio dei casi non conformi. Dove reperirli Si ricava confrontando la data e l’ora dell’attività finale del caso, ad esempio 'Richiesta approvata' o 'Richiesta respinta', con la 'SlaTargetDate'. Esempi truefalse | |||
| È automatizzata IsAutomated | Un indicatore booleano che specifica se l’attività è stata eseguita dal sistema anziché da un utente. | ||
| Descrizione Questo attributo distingue le attività eseguite automaticamente dal sistema, come la verifica iniziale e i controlli di sistema, da quelle svolte manualmente da un utente. Spesso si determina verificando se l’utente che ha eseguito l’attività è un account di sistema o di servizio. L’analisi di questo indicatore è fondamentale per comprendere il livello di automazione del processo. Aiuta a quantificare l’impatto dell’automazione su efficienza, costi e velocità e a individuare ulteriori opportunità di automazione. Perché è importante Distingue le attività svolte da persone da quelle eseguite dal sistema, un aspetto essenziale per analizzare l’automazione e comprendere i costi delle risorse. Dove reperirli In genere si ricava dal campo 'InitiatingUser'. Per impostare questo indicatore su true si utilizza un elenco di ID utente di sistema noti. Esempi truefalse | |||
| È una rilavorazione IsRework | Un indicatore booleano che specifica se un’attività fa parte di un ciclo di rilavorazione. | ||
| Descrizione Questo attributo identifica le attività che rappresentano un passo indietro nel processo, ad esempio il ritorno alla 'Revisione dei documenti' dopo l’avvio della 'Revisione di conformità' o qualsiasi occorrenza di 'Ulteriori informazioni richieste'. Individuare le rilavorazioni è fondamentale per comprendere le inefficienze e gli ostacoli del processo. Questo indicatore consente di calcolare direttamente il KPI 'Tasso di cicli di rilavorazione' e aiuta a visualizzare e quantificare l’impatto dei passaggi ripetitivi e improduttivi sul flusso del processo. Perché è importante Mette in evidenza i cicli di rilavorazione inefficienti, aiutando a quantificare gli sprechi e a individuare le aree da migliorare per aumentare il tasso di completamento corretto al primo tentativo. Dove reperirli Questo indicatore si ricava applicando tecniche di Process Mining che analizzano la sequenza delle attività. Ad esempio, se per lo stesso caso l''Attività A' è seguita dall''Attività B' e poi ricompare l''Attività A', la seconda occorrenza dell''Attività A' è una rilavorazione. Esempi truefalse | |||
| ID cliente CustomerId | Un identificativo univoco del cliente o della persona giuridica per cui è in corso l’onboarding. | ||
| Descrizione L’ID cliente è il riferimento univoco dell’entità del cliente nel sistema dei dati anagrafici. Mentre il numero della richiesta identifica il caso nel processo, l’ID cliente collega l’attività di onboarding a uno specifico cliente. Questo attributo consente di analizzare la cronologia dell’onboarding di un singolo cliente, ad esempio per verificare se ha seguito più processi di onboarding nel tempo. Permette inoltre di unire i dati di processo ad altri dati relativi al cliente, per ottenere una visione aziendale più completa. Perché è importante Collega il processo di onboarding a un’entità cliente univoca e consente analisi incentrate sul cliente e l’arricchimento dei dati. Dove reperirli Questo ID è memorizzato nel record del cliente o della persona giuridica in Fenergo ed è associato al caso di onboarding. Esempi CUST-98765CUST-98766CUST-98767 | |||
| Motivo del rifiuto RejectionReason | Un codice o una descrizione che spiega perché una richiesta è stata respinta. | ||
| Descrizione Quando lo stato finale di una richiesta è 'Respinto', questo attributo ne specifica il motivo. Alcuni esempi sono 'Controllo dei precedenti non superato', 'Documentazione incompleta' o 'Profilo di rischio elevato'. È un attributo essenziale per individuare le cause profonde delle richieste non andate a buon fine. Supporta direttamente la Dashboard 'Rilavorazioni e rifiuti delle richieste', classificando i casi di insuccesso e aiutando l’azienda a individuare i problemi ricorrenti e ad adottare misure correttive per aumentare il tasso di superamento al primo tentativo. Perché è importante Fornisce informazioni essenziali sui motivi per cui le richieste non vanno a buon fine e consente di individuarne le cause profonde per ridurre i rifiuti. Dove reperirli In genere si trova in un campo relativo al codice del motivo o alle note associato allo stato finale di rifiuto nel flusso di lavoro dei casi di Fenergo. Esempi Corrispondenza con elenchi di sanzioniDocumenti non validiViolazione delle politicheRichiesta ritirata dal cliente | |||
| Numero di richieste di informazioni aggiuntive AdditionalInfoRequestCount | Il numero totale di volte in cui sono state richieste informazioni aggiuntive per una richiesta. | ||
| Descrizione Questa metrica conta le occorrenze dell’attività 'Informazioni aggiuntive richieste' per ogni caso. Un valore elevato indica un maggior numero di scambi di comunicazioni, che può rallentare il processo e peggiorare l’esperienza del cliente. Questo attributo supporta direttamente il KPI 'Casi con richieste di informazioni aggiuntive'. Serve a individuare le richieste per cui le informazioni sono state richieste troppe volte, un possibile segnale di problemi nella raccolta iniziale dei dati o di requisiti complessi. L’analisi aiuta a rendere più efficiente la raccolta delle informazioni. Perché è importante Quantifica gli ostacoli per il cliente e i ritardi di processo causati da informazioni iniziali incomplete, aiutando a migliorare la fase di raccolta dei dati. Dove reperirli È una metrica calcolata contando il numero di eventi 'Informazioni aggiuntive richieste' per ogni ID 'CustomerApplication'. Esempi 013 | |||
| Paese Country | Il paese di residenza o la giurisdizione associata alla richiesta del cliente. | ||
| Descrizione Questo attributo specifica il paese associato al cliente, che spesso determina le norme applicabili e i fattori di rischio pertinenti al processo di onboarding. L’analisi del processo per paese consente di confrontare tempi di ciclo, livelli di rischio e complessità del processo tra diverse giurisdizioni. Aiuta a capire in che modo le differenze regionali incidono sulle prestazioni operative e a garantire la conformità alle normative locali. Perché è importante Consente di segmentare il processo per area geografica, un aspetto fondamentale per analizzare l’impatto normativo e le prestazioni regionali. Dove reperirli Queste informazioni fanno parte dei dati anagrafici principali del cliente, raccolti durante la richiesta e memorizzati nell’entità del soggetto in Fenergo. Esempi USAGBRSGPDEU | |||
| Responsabile del caso CaseOwner | L’utente o il team principalmente responsabile della gestione della richiesta durante il suo intero ciclo di vita. | ||
| Descrizione Il responsabile del caso è la persona o il gruppo a cui è affidata la responsabilità principale di un caso di onboarding. In genere, è responsabile del completamento puntuale e corretto del caso. Questo attributo aiuta ad analizzare il carico di lavoro e le prestazioni a livello di responsabile dei casi. Può servire a verificare se alcuni responsabili hanno tempi di ciclo più lunghi o tassi di rifiuto più elevati, aspetti che potrebbero indicare esigenze di formazione o squilibri nell’allocazione delle risorse. Perché è importante Identifica la persona o il team responsabile di un caso e consente di analizzare le prestazioni dei responsabili dei casi. Dove reperirli Di solito è un campo specifico dell’entità principale del caso in Fenergo, che indica a chi è stato assegnato il caso. Esempi s.jonesonboarding_team_am.chen | |||
| Tipo di cliente CustomerType | La categoria del cliente per cui è in corso l’onboarding, ad esempio persona fisica, società o trust. | ||
| Descrizione Questo attributo suddivide i clienti in categorie in base alla struttura giuridica o al rapporto con l’istituto finanziario. I diversi tipi di cliente seguono spesso percorsi di onboarding distinti, con livelli di complessità e requisiti di adeguata verifica differenti. L’analisi del processo per tipo di cliente aiuta a individuare le differenze di prestazioni tra i segmenti. È essenziale per la Dashboard 'Efficienza per origine e tipo di richiesta', che consente di confrontare i tempi di ciclo e i tassi di approvazione e di definire miglioramenti mirati del processo. Perché è importante Consente di confrontare le prestazioni del processo tra diversi segmenti di clientela, che spesso presentano livelli di complessità e SLA differenti. Dove reperirli Queste informazioni sono in genere memorizzate nell’entità del cliente o del soggetto in Fenergo e collegate al caso della richiesta. Esempi Persona fisicaSocietàTrustSocietà di persone | |||
Attività di inserimento dei clienti KYC
| Attività | Descrizione | ||
|---|---|---|---|
| Caso chiuso | Questa è l’attività finale, che indica la chiusura amministrativa del caso di onboarding in Fenergo, senza ulteriori azioni previste. Si applica sia alle richieste approvate sia a quelle respinte e si deduce dallo stato finale 'Chiuso'. | ||
| Perché è importante Questa attività segna la conclusione definitiva dell’intero processo. Consente di calcolare correttamente il tempo di ciclo per tutti i casi, indipendentemente dall’esito, e conferma che il processo è terminato. Dove reperirli Si deduce dal registro di controllo dei casi di Fenergo, individuando la data e l’ora in cui lo stato del caso viene impostato su 'Chiuso', 'Completato' o un altro stato terminale. Acquisizione Individuare la data e l’ora della modifica finale dello stato a 'Chiuso' o 'Completato'. Tipo di evento inferred | |||
| Caso creato | Questa attività segna l’avvio del processo di inserimento KYC, quando in Fenergo viene creata formalmente una nuova domanda di un cliente. In genere è registrata come evento esplicito, con una data e un’ora specifiche corrispondenti al primo salvataggio del record del caso. | ||
| Perché è importante In quanto evento di inizio, questa attività è essenziale per calcolare il tempo di ciclo complessivo dell’inserimento e analizzare il volume di casi gestiti. Fornisce la base di riferimento per tutte le misurazioni successive del processo e per il monitoraggio degli SLA. Dove reperirli In genere, si utilizza la data e l’ora di creazione dell’entità principale del caso in Fenergo, spesso reperibile nelle tabelle relative ai casi o ai flussi di lavoro di inserimento dei clienti. Acquisizione Utilizzi la data e l’ora di creazione del record del caso di inserimento. Tipo di evento explicit | |||
| Domanda approvata | Questa attività rappresenta la decisione finale di approvare la domanda di inserimento del cliente. Si deduce dal passaggio del caso a uno stato finale come 'Approvato' o 'Inserimento approvato'. | ||
| Perché è importante Questa fase fondamentale indica un esito positivo prima delle operazioni finali di attivazione del conto. È essenziale per calcolare i tassi di approvazione e analizzare le caratteristiche dei clienti inseriti con successo. Dove reperirli Si deduce dalla cronologia del caso o dal registro di audit, individuando la data e l’ora del passaggio finale allo stato 'Approvato' o a un altro stato conclusivo positivo. Acquisizione Individui la data e l’ora del passaggio finale allo stato 'Approvato'. Tipo di evento inferred | |||
| Domanda rifiutata | Questa attività è un evento conclusivo che rappresenta la decisione finale di rifiutare la domanda del cliente. Si deduce dal passaggio del caso a uno stato finale come 'Rifiutato' o 'Respinto'. | ||
| Perché è importante In quanto fase conclusiva del processo, questa attività è essenziale per calcolare il 'Tasso di rifiuto delle domande' e analizzare le cause degli esiti negativi. Aiuta a individuare i motivi più frequenti di rifiuto e a migliorare la qualità delle domande. Dove reperirli Si deduce dal registro di audit del caso, rilevando la data e l’ora del passaggio finale allo stato 'Rifiutato'. Il motivo del rifiuto è spesso registrato in un campo correlato. Acquisizione Individui la data e l’ora del passaggio finale allo stato 'Rifiutato'. Tipo di evento inferred | |||
| Revisione dei documenti completata | Indica il completamento della verifica, manuale o automatizzata, dell’autenticità e della correttezza di tutti i documenti inviati dal cliente. In genere si deduce dal completamento di un’attività del flusso di lavoro o da una modifica dello stato in Fenergo. | ||
| Perché è importante È una fase cruciale in cui si verificano spesso ritardi. Analizzarne la durata e gli esiti aiuta a individuare i colli di bottiglia nell’elaborazione dei documenti e a monitorare KPI come il 'Tasso di superamento al primo tentativo'. Dove reperirli Si deduce dalla data e ora di completamento dell’attività 'Verifica dei documenti' nel flusso di lavoro del caso o dall’aggiornamento dello stato a 'Documenti approvati' nella cronologia del caso. Acquisizione Utilizzi la data e l’ora di completamento dell’attività di revisione dei documenti o di una modifica di stato correlata. Tipo di evento inferred | |||
| Revisione di conformità avviata | Questa attività segna l’inizio della revisione da parte del reparto conformità, una fase cruciale e spesso lunga. Si deduce dall’assegnazione del caso alla coda di lavoro del reparto o dal passaggio allo stato 'In attesa di revisione di conformità'. | ||
| Perché è importante Questa attività è il punto di partenza per misurare il KPI 'Tempo medio di revisione di conformità'. Aiuta a capire quanto a lungo i casi restano in attesa prima che il team addetto alla conformità inizi a lavorarci. Dove reperirli Si deduce dal registro di audit del caso in Fenergo, rilevando la data e l’ora del passaggio allo stato 'In revisione di conformità' o dell’assegnazione del caso a un responsabile o a un team addetto alla conformità. Acquisizione Individui la data e l’ora del passaggio allo stato 'In revisione di conformità' o dell’evento di assegnazione. Tipo di evento inferred | |||
| Revisione di conformità completata | Segna l’approvazione formale del reparto conformità e indica che tutti i requisiti normativi sono stati rispettati. Si deduce dal completamento di un’attività o dal passaggio allo stato 'Conformità approvata'. | ||
| Perché è importante Il completamento di questa attività, una fase fondamentale, è determinante per il tempo di ciclo complessivo. Segna la fine del periodo da misurare per il 'Tempo medio di revisione di conformità' e consente di individuare i colli di bottiglia nella funzione di conformità. Dove reperirli Si deduce dalla data e ora di completamento dell’attività 'Revisione di conformità' nel flusso di lavoro di Fenergo o dall’evento di aggiornamento dello stato nella cronologia del caso. Acquisizione Utilizzi la data e l’ora di completamento dell’attività di revisione di conformità o dell’aggiornamento dello stato. Tipo di evento inferred | |||
| Valutazione del rischio completata | Indica il completamento della classificazione interna del rischio, durante la quale al cliente viene assegnato un livello di rischio sulla base di diversi fattori. Si deduce da una modifica dello stato o dalla compilazione di un campo relativo al livello di rischio. | ||
| Perché è importante È una fase decisionale importante, che spesso determina il percorso successivo del flusso di lavoro. Analizzarne la durata aiuta a snellire una fase cruciale per la conformità e a garantire coerenza nella valutazione del rischio. Dove reperirli Si deduce dalla cronologia del caso, individuando il passaggio a uno stato come 'Rischio valutato' o la compilazione del campo finale 'Livello di rischio del cliente'. Acquisizione Utilizzi la data e l’ora in cui viene definito il livello di rischio o impostato uno stato correlato. Tipo di evento inferred | |||
| Conto attivato | Indica che il conto del cliente è stato creato e attivato correttamente nel sistema bancario centrale o nel sistema a valle pertinente dopo l’approvazione. L’informazione può essere dedotta da un aggiornamento dello stato finale in Fenergo successivo all’approvazione. | ||
| Perché è importante Questa attività conferma il passaggio completato dal processo di onboarding allo stato di cliente attivo. Misurare il tempo che intercorre tra l’approvazione e l’attivazione può far emergere ritardi nella configurazione operativa. Dove reperirli L’informazione può essere dedotta da uno stato del caso come 'Conto attivo' o 'Onboarding completato'. Può anche corrispondere a un evento esplicito registrato da un’integrazione con un sistema a valle. Acquisizione Cerchi una modifica dello stato successiva all’approvazione o un evento nel registro di esito positivo dell’integrazione. Tipo di evento inferred | |||
| Controlli dei precedenti avviati | Questa attività segna il momento in cui vengono avviati i controlli esterni sui precedenti, antiriciclaggio (AML) o sul credito. Spesso è registrata come evento esplicito quando viene chiamato un servizio di terze parti tramite un’integrazione. | ||
| Perché è importante Monitorare l’avvio e il completamento di questi controlli è essenziale per comprendere i ritardi dovuti a dipendenze esterne. Aiuta a distinguere il tempo di elaborazione interno dai tempi di attesa esterni. Dove reperirli In genere, si ricava dai registri di sistema che riportano le chiamate API ai fornitori esterni di servizi di verifica o dalla creazione di un’attività specifica 'Controllo dei precedenti' nel caso Fenergo. Acquisizione Cerchi nei registri le integrazioni con servizi esterni o la creazione di un’attività 'Verifica'. Tipo di evento explicit | |||
| Dati e documenti richiesti | Questo evento indica che il sistema o un addetto all’inserimento ha richiesto formalmente al cliente le informazioni e i documenti necessari. Spesso viene registrato come evento esplicito quando viene inviata una comunicazione basata su un template standard. | ||
| Perché è importante Questa attività segna l’inizio di una fase che dipende dal cliente. Misurare il tempo che intercorre da questo momento alla ricezione dei documenti è fondamentale per analizzare il percorso del cliente e individuare ritardi nelle comunicazioni. Dove reperirli Si ricava dall’Event Log delle comunicazioni con i clienti o dal registro di completamento dell’attività 'Richiesta documenti'. Può anche essere dedotto dal passaggio allo stato 'In attesa di informazioni dal cliente'. Acquisizione Cerchi un evento registrato relativo a una comunicazione con il cliente o al completamento di un’attività. Tipo di evento explicit | |||
| Documenti ricevuti | Questa attività indica che il cliente ha caricato o inviato i documenti richiesti, ora disponibili in Fenergo per la revisione. In genere si deduce dal passaggio del caso allo stato 'Documenti ricevuti' o 'In attesa di revisione'. | ||
| Perché è importante Segna la fine dell’attesa del cliente e l’inizio del ciclo di revisione interno. È fondamentale per misurare i tempi di risposta dei clienti e i tempi di attesa nelle code di elaborazione interne. Dove reperirli Si deduce dalla traccia di audit del caso, che registra la data e l’ora del passaggio allo stato 'Documenti ricevuti' o a uno stato equivalente. Può anche essere collegato agli eventi di caricamento dei documenti. Acquisizione Individui la data e l’ora del passaggio allo stato 'Documenti ricevuti' o 'Pronto per la revisione'. Tipo di evento inferred | |||
| Informazioni aggiuntive richieste | Indica un ciclo di rilavorazione in cui il team addetto all’inserimento deve ricontattare il cliente per chiedere chiarimenti o documenti mancanti. È un evento esplicito, in genere registrato quando viene inviata una comunicazione al cliente. | ||
| Perché è importante Questa attività è un indicatore importante di inefficienza del processo e di una cattiva esperienza per il cliente. Monitorarne la frequenza aiuta a individuare le cause profonde delle rilavorazioni e a misurare il KPI 'Tasso di cicli di rilavorazione'. Dove reperirli Si ricava dall’Event Log delle comunicazioni con i clienti o dal passaggio allo stato 'In attesa di informazioni aggiuntive'. Il primo metodo consente di rilevare con maggiore precisione il momento esatto della richiesta. Acquisizione Cerchi gli eventi di comunicazione registrati o il passaggio allo stato 'In attesa di risposta del cliente'. Tipo di evento explicit | |||
| Verifica iniziale eseguita | Indica il completamento dei controlli preliminari, automatici o manuali, come la convalida di base dei dati o la verifica rispetto agli elenchi delle sanzioni. Spesso si deduce da una modifica dello stato del caso nel flusso di lavoro di Fenergo, ad esempio dal passaggio da 'Nuovo' a 'Verifica completata'. | ||
| Perché è importante Monitorare questa fase iniziale aiuta a individuare problemi di qualità dei dati e colli di bottiglia nella fase di prequalificazione. Consente di distinguere la fase iniziale automatizzata dalle successive verifiche manuali, più approfondite. Dove reperirli Si deduce dalla cronologia del caso o dal registro di audit, individuando la data e l’ora in cui lo stato passa a una condizione che indica il completamento della verifica, come 'Verifica superata' o 'In attesa di documenti'. Acquisizione Individui nella cronologia del caso il passaggio allo stato 'Verifica completata' o a uno stato equivalente. Tipo di evento inferred | |||
Guide all’estrazione
Passaggi
- Acceda al modulo di reportistica: acceda all’applicazione Fenergo con un account utente che disponga delle autorizzazioni necessarie per il modulo di reportistica e analisi. Apra il modulo, che si trova in genere nel menu principale dell’applicazione.
- Crei un nuovo report: avvii la creazione di un nuovo report personalizzato. Scelga un nome e una descrizione che ne identifichino chiaramente lo scopo, ad esempio «Event log dell’inserimento KYC per il Process Mining».
- Definisca l’origine principale dei dati: selezioni l’oggetto dati o la vista principale che registra il ciclo di vita dei casi. Spesso si tratta di una vista preconfigurata, come
[CaseWorkflowHistory]o[LifecycleEventsView]. L’oggetto deve contenere gli identificativi dei casi, i nomi degli eventi o gli stati e i relativi timestamp. - Configuri le colonne del report (attributi): utilizzi l’interfaccia di creazione dei report per aggiungere le colonne. Mappi i campi di origine del modello dati Fenergo agli attributi richiesti per l’event log. Ad esempio, associ
CaseIDaCustomerApplication,EventTimestampaEventStartTimeedEventPerformeraInitiatingUser. - Definisca la logica delle attività: è il passaggio più importante. Il report deve generare una riga distinta per ciascuna delle 14 attività richieste. A tal fine, crei blocchi logici o insiemi di dati filtrati per ogni attività e li combini con UNION o una funzione equivalente nel generatore di report.
- Definisca la logica di «Caso creato»: crei il primo blocco. Filtri l’origine dei dati per individuare l’evento iniziale di creazione del caso. Spesso si basa sul timestamp più remoto associato al caso o su un tipo di evento denominato «Caso creato». Mappi
CreationDateaEventStartTime. - Definisca la logica delle attività basate sullo stato: per le attività dedotte dalle modifiche di stato, ad esempio «Documenti ricevuti» e «Domanda approvata», crei blocchi separati. Filtri l’origine dei dati in base al valore specifico del campo
Statoe utilizziStatusChangeDatecomeEventStartTime. - Definisca la logica delle attività basate sulle attività del flusso di lavoro: per le attività associate ai task del flusso di lavoro, ad esempio «Controllo di conformità completato», crei blocchi che filtrano in base a
TaskNameeTaskCompletionDate. Utilizzi la data di completamento comeEventStartTime. - Imposti i filtri globali del report: applichi filtri a livello di report per circoscrivere i dati. Imposti un intervallo di date specifico per
EventStartTime, così da evitare esportazioni eccessivamente ampie. Per l’analisi iniziale si consiglia un periodo da 3 a 6 mesi. Filtri in base al tipo di caso specifico, ad esempio «Inserimento dei clienti KYC». - Esegua il report e ne visualizzi l’anteprima: esegua il report nell’interfaccia di Fenergo. Controlli le prime 100-200 righe per verificare che la struttura dei dati sia corretta, che tutte le colonne siano compilate come previsto e che siano presenti attività diverse.
- Esporti i dati: esporti i risultati completi del report in un file CSV o Excel. Questo è il file grezzo dell’event log.
- Prepari i dati finali: apra il file CSV esportato. Se il report non ha potuto generare direttamente le colonne
SourceSystemeLastDataUpdate, le aggiunga manualmente. Imposti «Fenergo» come valore diSourceSystemper tutte le righe e inserisca il timestamp dell’esportazione inLastDataUpdate.
Configurazione
- Prerequisiti: l’utente deve poter accedere al modulo di reportistica e analisi di Fenergo e disporre delle autorizzazioni per creare ed eseguire report personalizzati.
- Origini principali dei dati: il report dovrebbe basarsi principalmente sugli oggetti Fenergo relativi alla gestione dei casi e alla cronologia del flusso di lavoro. Tra le origini più comuni figurano
[CaseDetails],[CaseStatusHistory]e[WorkflowTaskHistory]. I nomi esatti possono variare in base alla configurazione di Fenergo. - Intervallo di date: è fondamentale impostare un filtro sull’intervallo di date del timestamp dell’evento per gestire le prestazioni. Inizi con un periodo recente da 3 a 6 mesi. Per l’analisi storica, esegua il report in più blocchi, ad esempio per trimestre o per anno.
- Filtri principali: filtri sempre in base al processo o al tipo di caso specifico, ad esempio «Inserimento dei clienti KYC», per escludere i dati non pertinenti. In base agli obiettivi dell’analisi, potrebbe essere necessario filtrare anche per tipo di persona giuridica o giurisdizione.
- Definizione delle attività: ogni attività deve essere definita applicando criteri di filtro specifici a campi come
Stato,TaskNameo un campo dedicatoEventType. Questi campi sono essenziali per isolare ogni singolo evento del processo. - Considerazioni sulle prestazioni: i report che combinano molte origini dati o coprono intervalli di date ampi possono essere lenti. Se possibile, pianifichi l’esecuzione del report nelle ore di minore attività. Eviti di includere nell’esportazione colonne non necessarie, poiché aumentano i tempi di elaborazione.
a Query di esempio sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' È pronto a iniziare?
Utilizzando questo template dei dati, potrà individuare le inefficienze e semplificare il processo di inserimento dei clienti KYC in Fenergo. Inizi oggi a ottimizzare le attività e a migliorare la soddisfazione dei clienti.
Semplifichi l’inserimento dei clienti KYC e ottenga approvazioni più rapide
Si unisca alle aziende che hanno ridotto i tempi di inserimento a sole 24 ore.
Non è richiesta la carta di credito. Può iniziare in pochi minuti.