Templat data proses orientasi pelanggan KYC Anda
Templat data proses orientasi pelanggan KYC Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data
Atribut proses orientasi pelanggan KYC
| Nama | Deskripsi | ||
|---|---|---|---|
| Nama Aktivitas ActivityName | Nama peristiwa bisnis atau tugas tertentu yang terjadi pada suatu waktu dalam proses onboarding. | ||
| Deskripsi Nama Aktivitas menjelaskan satu langkah atau pencapaian dalam proses onboarding pelanggan, seperti 'Penyaringan Awal Dilakukan' atau 'Pengajuan Disetujui'. Urutan aktivitas ini menjadi dasar peta proses. Dengan menganalisis atribut ini, Anda dapat melihat alur proses, menemukan jalur yang umum maupun alternatif, serta mengukur frekuensi setiap langkah. Atribut ini penting untuk memahami tindakan apa yang dilakukan dan dalam urutan seperti apa. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam proses, sehingga Anda dapat membuat peta proses dan menganalisis alur serta variasinya. Sumber data Informasi ini biasanya terdapat di tabel workflow atau log audit Fenergo, terkait dengan perubahan status kasus atau penyelesaian tugas. Contoh Data dan dokumen dimintaPeninjauan kepatuhan dimulaiPengajuan disetujui | |||
| Pengajuan Pelanggan CustomerApplication | Pengenal unik untuk satu proses onboarding pelanggan, yang berfungsi sebagai ID kasus utama. | ||
| Deskripsi Pengajuan Pelanggan adalah pengenal utama yang mengelompokkan semua aktivitas dan peristiwa terkait dalam proses onboarding KYC seorang pelanggan. Pengenal ini memungkinkan pelacakan pengajuan dari awal, sejak dikirim, hingga keputusan akhir, baik disetujui, ditolak, maupun ditutup. Dalam process mining, atribut ini menjadi dasar untuk merekonstruksi seluruh perjalanan setiap pengajuan. Atribut ini memungkinkan analisis alur proses, waktu siklus, variasi, dan hambatan untuk setiap pengajuan, sehingga Anda dapat melihat dengan jelas bagaimana tiap kasus ditangani. Mengapa ini penting Ini adalah ID Kasus utama yang menghubungkan semua peristiwa terkait, sehingga proses onboarding pelanggan dapat dianalisis dari awal hingga akhir. Sumber data Biasanya ini adalah kunci utama dalam entitas manajemen kasus inti atau manajemen siklus hidup klien di Fenergo. Contoh APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Waktu Mulai EventStartTime | Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa resmi dimulai. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu tepat saat suatu aktivitas dimulai. Informasi ini memberikan urutan kronologis yang diperlukan untuk merekonstruksi alur proses dan menjadi dasar semua analisis berbasis waktu. Dalam process mining, waktu mulai digunakan untuk menghitung durasi aktivitas, waktu tunggu di antara aktivitas, dan waktu siklus keseluruhan kasus. Informasi ini menjadi dasar kronologis log peristiwa dan penting untuk analisis kinerja serta hambatan. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis dan menghitung semua metrik berbasis waktu, seperti waktu siklus dan durasi. Sumber data Tersimpan di tabel jejak audit, log peristiwa, atau riwayat workflow Fenergo, biasanya dengan label 'Timestamp', 'StartDate', atau 'CreationDate'. Contoh 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Pembaruan Data Terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk proses ini terakhir kali diperbarui atau diekstrak. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu pembaruan data terbaru. Informasi ini menunjukkan seberapa baru data yang dianalisis dan membantu Anda memahami ketepatan waktu insight yang dihasilkan. Di dasbor dan laporan, informasi ini memberi tahu pengguna seberapa mutakhir data yang digunakan. Dengan begitu, pengguna dapat mengetahui apakah analisis mencerminkan operasional saat ini atau hanya kondisi pada periode sebelumnya. Mengapa ini penting Memberi konteks penting tentang kebaruan data, sehingga pengguna tahu seberapa mutakhir analisis proses. Sumber data Nilai ini dibuat dan dicatat dalam kumpulan data selama proses ekstraksi dan pemuatan data (ETL). Contoh 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Sistem Sumber SourceSystem | Sistem pencatatan asal tempat data diekstrak. | ||
| Deskripsi Atribut ini menunjukkan sistem asal data peristiwa. Untuk proses ini, sistemnya selalu Fenergo. Namun, dalam kumpulan data gabungan, atribut ini membantu membedakan sumber data. Atribut ini terutama digunakan untuk memfilter data dari sistem tertentu atau memverifikasi asal data. Dengan begitu, sumber data tetap jelas saat data dari beberapa sistem digabungkan untuk memberikan gambaran proses secara menyeluruh. Mengapa ini penting Menunjukkan asal data, yang penting untuk tata kelola dan validasi data serta memastikan analisis menggunakan sumber yang tepat. Sumber data Biasanya berupa nilai tetap yang ditambahkan saat ekstraksi data untuk menandai asal catatan. Contoh FenergoFenergo CLM | |||
| Departemen Pengguna UserDepartment | Departemen atau unit bisnis tempat pengguna yang memulai aktivitas bekerja. | ||
| Deskripsi Atribut ini memberikan konteks organisasi bagi pengguna yang melakukan aktivitas, misalnya 'Kepatuhan', 'Operasional Onboarding', atau 'Penjualan'. Informasi ini sering diambil dari profil pengguna. Dimensi ini penting untuk menganalisis serah terima proses antar departemen dan menemukan hambatan lintas fungsi. Atribut ini juga mendukung dasbor 'Distribusi Aktivitas Staf' dengan mengelompokkan pekerjaan berdasarkan tim atau departemen. Mengapa ini penting Memungkinkan analisis kinerja proses berdasarkan departemen, termasuk serah terima antar departemen, keterlambatan, dan pembagian beban kerja. Sumber data Informasi ini mungkin perlu digabungkan dari tabel data induk pengguna atau SDM terpisah menggunakan ID 'InitiatingUser'. Fenergo juga mungkin menyimpan informasi ini di profil pengguna. Contoh ComplianceOrientasi klienJaminan Kualitas | |||
| Pengguna yang Memulai InitiatingUser | ID pengguna atau nama orang yang melakukan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan karyawan atau pengguna sistem yang bertanggung jawab menjalankan tugas atau peristiwa tertentu. Nilainya dapat berupa ID pengguna unik, nama, atau peran. Analisis berdasarkan pengguna membantu Anda memahami pembagian beban kerja dan kinerja individu, serta menemukan kebutuhan pelatihan. Atribut ini penting untuk dasbor 'Distribusi Aktivitas Staf' dan untuk menelusuri aktivitas yang dilakukan individu atau tim tertentu. Mengapa ini penting Mencatat pengguna yang melakukan tindakan, sehingga beban kerja, kinerja tim, dan alokasi sumber daya dapat dianalisis. Sumber data Informasi ini biasanya tersimpan bersama detail peristiwa di log audit atau tabel riwayat tugas Fenergo, dengan label seperti 'UserID', 'UserName', atau 'ModifiedBy'. Contoh j.doea.smithSYSTEM | |||
| Skor Risiko RiskScore | Skor numerik yang menunjukkan tingkat risiko pelanggan berdasarkan hasil perhitungan. | ||
| Deskripsi Skor Risiko mengukur potensi risiko yang terkait dengan pelanggan berdasarkan berbagai faktor, seperti yurisdiksi, industri, dan hasil penyaringan. Skor ini biasanya dihitung oleh mesin aturan Fenergo. Atribut ini memungkinkan Anda melihat hubungan antara tingkat risiko dan perilaku proses. Misalnya, analisis dapat menunjukkan apakah pelanggan berisiko tinggi mengalami waktu siklus lebih lama atau memerlukan lebih banyak penanganan manual. Informasi ini berguna untuk dasbor 'Analisis Mendalam Peninjauan Risiko dan Kepatuhan'. Mengapa ini penting Mengukur risiko pelanggan, sehingga dampak tingkat risiko terhadap durasi proses, pengerjaan ulang, dan hasil dapat dianalisis. Sumber data Ini adalah keluaran utama modul Penilaian Risiko Klien Fenergo. Nilainya disimpan pada entitas kasus atau klien. Contoh 154585 | |||
| Status Pengajuan ApplicationStatus | Hasil akhir atau status terkini pengajuan pelanggan. | ||
| Deskripsi Atribut ini menunjukkan hasil pengajuan di akhir proses atau statusnya saat ini jika proses masih berjalan. Nilai yang umum antara lain 'Disetujui', 'Ditolak', atau 'Sedang Berjalan'. Dimensi ini penting untuk menganalisis hasil. Anda dapat memfilter dan membandingkan alur proses berdasarkan hasil akhirnya. Informasi ini diperlukan untuk dasbor 'Pengerjaan Ulang dan Penolakan Pengajuan' serta untuk menghitung KPI seperti Tingkat Penolakan Pengajuan. Mengapa ini penting Menentukan hasil suatu kasus, sehingga Anda dapat membandingkan jalur pengajuan yang disetujui dan ditolak serta memahami tingkat keberhasilannya. Sumber data Biasanya berupa status akhir yang tercatat pada entitas kasus di sistem manajemen kasus Fenergo. Contoh DisetujuiDitolakMenunggu Bagian KepatuhanDitutup | |||
| Tanggal Target SLA SlaTargetDate | Tanggal batas yang ditetapkan untuk menyelesaikan kasus onboarding pelanggan. | ||
| Deskripsi Tanggal Target SLA adalah tenggat yang disepakati untuk menyelesaikan seluruh proses onboarding pengajuan pelanggan. Tanggal ini menjadi tolok ukur penting untuk mengukur kinerja aktual. Atribut ini penting untuk dasbor 'Pemantauan Kepatuhan SLA' dan penghitungan KPI 'Tingkat Kepatuhan SLA'. Atribut ini membantu Anda menangani lebih awal kasus yang berisiko melampaui SLA dan menentukan prioritas pekerjaan. Mengapa ini penting Menentukan tanggal target penyelesaian, yang penting untuk memantau kepatuhan SLA dan memprioritaskan kasus yang terlambat. Sumber data Tanggal ini sering dihitung berdasarkan tanggal pengajuan dikirim dan aturan bisnis yang dikonfigurasi dalam modul manajemen SLA Fenergo. Contoh 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Waktu Selesai EventEndTime | Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa selesai. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu tepat saat suatu aktivitas selesai. Jika dipasangkan dengan waktu mulai, atribut ini menunjukkan durasi aktif suatu tugas. Dalam process mining, waktu selesai digunakan bersama waktu mulai untuk menghitung waktu pengerjaan setiap aktivitas. Informasi ini penting untuk menemukan langkah yang paling banyak menyita waktu dan menganalisis efisiensi sumber daya. Mengapa ini penting Memungkinkan penghitungan waktu pengerjaan aktivitas, yang menjadi dasar untuk menemukan tugas berdurasi panjang dan hambatan kinerja. Sumber data Tersimpan di tabel jejak audit atau riwayat workflow Fenergo, biasanya dengan label 'EndDate', 'CompletionDate', atau disimpulkan dari waktu mulai peristiwa berikutnya. Contoh 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Alasan Penolakan RejectionReason | Kode atau keterangan yang menjelaskan alasan pengajuan ditolak. | ||
| Deskripsi Jika status akhir pengajuan adalah 'Ditolak', atribut ini menunjukkan alasan spesifiknya. Contohnya, 'Gagal dalam Pemeriksaan Latar Belakang', 'Dokumen Tidak Lengkap', atau 'Profil Risiko Tinggi'. Atribut ini penting untuk mencari akar penyebab pengajuan yang gagal. Atribut ini mendukung dasbor 'Pengerjaan Ulang dan Penolakan Pengajuan' dengan mengelompokkan penyebab kegagalan. Dengan begitu, bisnis dapat menemukan masalah yang sering terjadi dan melakukan perbaikan untuk meningkatkan tingkat kelulusan pada pengajuan pertama. Mengapa ini penting Memberi gambaran penting tentang alasan pengajuan gagal, sehingga akar masalah dapat ditemukan dan tingkat penolakan dikurangi. Sumber data Biasanya terdapat di kolom kode alasan atau catatan yang terkait dengan status penolakan akhir dalam workflow kasus Fenergo. Contoh Kecocokan dengan Daftar SanksiDokumen Tidak ValidPelanggaran KebijakanPelanggan Membatalkan | |||
| Dilakukan Otomatis IsAutomated | Penanda boolean yang menunjukkan apakah aktivitas dilakukan oleh sistem, bukan oleh pengguna manusia. | ||
| Deskripsi Atribut ini membedakan tugas yang dijalankan otomatis oleh sistem, seperti penyaringan awal dan pemeriksaan sistem, dari tugas yang dilakukan secara manual oleh pengguna. Biasanya, hal ini ditentukan dengan memeriksa apakah pengguna yang menjalankan tugas merupakan akun sistem atau layanan. Analisis penanda ini penting untuk memahami tingkat otomatisasi proses. Informasi ini membantu mengukur dampak otomatisasi terhadap efisiensi, biaya, dan kecepatan, serta menemukan peluang untuk menambah otomatisasi. Mengapa ini penting Membedakan aktivitas manusia dan sistem, yang penting untuk menganalisis otomatisasi dan memahami biaya sumber daya. Sumber data Biasanya ditentukan dari kolom 'InitiatingUser'. Daftar ID pengguna sistem yang diketahui digunakan untuk menetapkan penanda ini ke true. Contoh truefalse | |||
| ID Pelanggan CustomerId | Pengenal unik untuk pelanggan atau badan hukum yang menjalani onboarding. | ||
| Deskripsi ID Pelanggan adalah referensi unik untuk entitas klien dalam sistem data induk. Nomor pengajuan berfungsi sebagai ID kasus dalam proses, sedangkan ID Pelanggan menghubungkan aktivitas onboarding dengan klien tertentu. Atribut ini memungkinkan analisis riwayat onboarding seorang pelanggan, misalnya jika pelanggan tersebut telah menjalani beberapa proses onboarding dari waktu ke waktu. Atribut ini juga memungkinkan data proses digabungkan dengan data lain terkait pelanggan untuk memberikan gambaran bisnis yang lebih menyeluruh. Mengapa ini penting Menghubungkan proses onboarding dengan entitas pelanggan yang unik, sehingga analisis dapat berfokus pada pelanggan dan data dapat diperkaya. Sumber data ID ini disimpan pada catatan klien atau badan hukum di Fenergo dan dikaitkan dengan kasus onboarding. Contoh CUST-98765CUST-98766CUST-98767 | |||
| Jenis Pelanggan CustomerType | Klasifikasi pelanggan yang menjalani onboarding, seperti perorangan, perusahaan, atau perwalian. | ||
| Deskripsi Atribut ini mengelompokkan pelanggan berdasarkan struktur hukum atau hubungan mereka dengan lembaga keuangan. Setiap jenis pelanggan biasanya mengikuti jalur onboarding yang berbeda, dengan tingkat kerumitan dan persyaratan uji tuntas yang beragam. Analisis proses berdasarkan Jenis Pelanggan membantu menemukan perbedaan kinerja antarsegmen. Atribut ini penting untuk dasbor 'Efisiensi Sumber dan Jenis Pengajuan' guna membandingkan waktu siklus dan tingkat persetujuan, lalu menentukan perbaikan proses yang sesuai. Mengapa ini penting Memungkinkan perbandingan kinerja proses antarsegmen pelanggan yang memiliki tingkat kerumitan dan SLA berbeda. Sumber data Informasi ini biasanya tersimpan pada entitas pelanggan atau klien di Fenergo dan ditautkan ke kasus pengajuan. Contoh PeroranganPerusahaanPerwalianKemitraan | |||
| Jumlah Permintaan Info Tambahan AdditionalInfoRequestCount | Jumlah total permintaan informasi tambahan untuk suatu pengajuan. | ||
| Deskripsi Metrik ini menghitung berapa kali aktivitas 'Informasi Tambahan Diminta' terjadi pada setiap kasus. Jumlah yang lebih tinggi menunjukkan lebih banyak komunikasi bolak-balik, yang dapat memperlambat proses dan menurunkan kualitas pengalaman pelanggan. Atribut ini mendukung KPI 'Kasus dengan Permintaan Info Tambahan'. Atribut ini digunakan untuk menemukan pengajuan dengan permintaan berlebihan, yang mungkin menunjukkan masalah dalam pengumpulan data awal atau persyaratan kasus yang rumit. Analisis ini membantu menyederhanakan pengumpulan informasi. Mengapa ini penting Mengukur hambatan bagi pelanggan dan keterlambatan proses akibat informasi awal yang tidak lengkap, sehingga tahap pengumpulan data dapat diperbaiki. Sumber data Ini adalah metrik hasil perhitungan yang diperoleh dengan menghitung jumlah peristiwa 'Informasi Tambahan Diminta' untuk setiap ID 'CustomerApplication'. Contoh 013 | |||
| Kanal Pengajuan ApplicationChannel | Kanal yang digunakan untuk mengirim pengajuan pelanggan. | ||
| Deskripsi Atribut ini menunjukkan sumber pengajuan, misalnya portal online, kantor cabang, atau manajer hubungan. Sumber pengajuan dapat memengaruhi kualitas data dan persyaratan pemrosesan. Dimensi ini digunakan dalam dasbor 'Efisiensi Sumber dan Jenis Pengajuan' untuk membandingkan kinerja berbagai kanal. Informasi ini membantu bisnis mengetahui kanal mana yang paling efisien dan kanal mana yang perlu diperbaiki prosesnya. Mengapa ini penting Menunjukkan sumber pengajuan, sehingga efisiensi kanal, biaya, dan pengalaman pelanggan dapat dianalisis. Sumber data Informasi ini mungkin dicatat dalam formulir entri data awal di Fenergo atau diteruskan dari sistem hulu. Contoh Portal OnlineKantor CabangManajer HubunganAplikasi Seluler | |||
| Mematuhi SLA IsSlaCompliant | Penanda boolean yang menunjukkan apakah kasus selesai sebelum atau pada tanggal target SLA. | ||
| Deskripsi Atribut ini menunjukkan kinerja SLA secara biner untuk kasus yang telah selesai. Nilainya ditetapkan ke 'true' jika stempel waktu aktivitas penutupan terakhir sama dengan atau lebih awal dari 'SlaTargetDate', dan ke 'false' jika tidak. Kolom hasil perhitungan ini menyederhanakan pemantauan dan pelaporan SLA. Anda dapat mengelompokkan nilainya untuk menghitung KPI 'Tingkat Kepatuhan SLA' secara keseluruhan, atau memfilternya untuk menganalisis karakteristik proses pada kasus yang patuh dan tidak patuh. Mengapa ini penting Mengukur kinerja SLA secara langsung, sehingga KPI Tingkat Kepatuhan SLA mudah dihitung dan kasus yang tidak patuh dapat difilter. Sumber data Nilai ini diperoleh dengan membandingkan stempel waktu aktivitas terakhir kasus, seperti 'Pengajuan Disetujui' atau 'Pengajuan Ditolak', dengan 'SlaTargetDate'. Contoh truefalse | |||
| Negara Country | Negara domisili atau yurisdiksi pengajuan pelanggan. | ||
| Deskripsi Atribut ini menunjukkan negara yang terkait dengan pelanggan. Negara tersebut sering menentukan aturan regulasi dan faktor risiko yang berlaku dalam proses onboarding. Analisis proses berdasarkan negara memungkinkan perbandingan waktu siklus, tingkat risiko, dan kerumitan proses antar yurisdiksi. Analisis ini membantu Anda memahami dampak perbedaan wilayah terhadap kinerja operasional dan memastikan kepatuhan terhadap peraturan setempat. Mengapa ini penting Memungkinkan proses dikelompokkan berdasarkan wilayah geografis, yang penting untuk menganalisis dampak regulasi dan kinerja regional. Sumber data Informasi ini merupakan bagian dari data inti pelanggan yang dikumpulkan selama proses pengajuan dan disimpan pada entitas klien di Fenergo. Contoh USAGBRSGPDEU | |||
| Pemilik Kasus CaseOwner | Pengguna atau tim utama yang bertanggung jawab mengelola pengajuan selama siklus hidupnya. | ||
| Deskripsi Pemilik Kasus adalah individu atau kelompok yang diberi tanggung jawab utama atas suatu kasus onboarding. Biasanya, orang ini bertanggung jawab memastikan kasus selesai tepat waktu dan berhasil. Atribut ini membantu menganalisis beban kerja dan kinerja pengelola kasus. Anda dapat melihat apakah pemilik kasus tertentu memiliki waktu siklus lebih lama atau tingkat penolakan lebih tinggi. Hal ini dapat menunjukkan kebutuhan pelatihan atau ketimpangan sumber daya. Mengapa ini penting Menunjukkan orang atau tim yang bertanggung jawab atas suatu kasus, sehingga kinerja pengelola kasus dapat dianalisis. Sumber data Biasanya berupa kolom khusus pada entitas kasus utama di Fenergo yang menunjukkan penanggung jawab kasus. Contoh s.jonesonboarding_team_am.chen | |||
| Termasuk Pengerjaan Ulang IsRework | Penanda boolean yang menunjukkan apakah suatu aktivitas merupakan bagian dari siklus pengerjaan ulang. | ||
| Deskripsi Atribut ini menandai aktivitas yang menunjukkan proses mundur satu langkah, misalnya kembali ke 'Peninjauan Dokumen' setelah 'Peninjauan Kepatuhan' dimulai, atau setiap kemunculan 'Informasi Tambahan Diminta'. Menemukan pengerjaan ulang penting untuk memahami inefisiensi dan hambatan dalam proses. Penanda ini memungkinkan penghitungan langsung KPI 'Tingkat Siklus Pengerjaan Ulang' serta membantu memvisualisasikan dan mengukur dampak langkah berulang yang tidak perlu dalam alur proses. Mengapa ini penting Menunjukkan siklus pengerjaan ulang yang tidak efisien, sehingga pemborosan dapat diukur dan area perbaikan untuk meningkatkan tingkat keberhasilan pada percobaan pertama dapat ditemukan. Sumber data Penanda ini diperoleh dengan teknik process mining yang menganalisis urutan aktivitas. Misalnya, jika 'Aktivitas A' diikuti 'Aktivitas B', lalu 'Aktivitas A' muncul lagi untuk kasus yang sama, kemunculan kedua 'Aktivitas A' dianggap sebagai pengerjaan ulang. Contoh truefalse | |||
Aktivitas proses orientasi pelanggan KYC
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Kasus dibuat | Aktivitas ini menandai dimulainya proses KYC onboarding, saat pengajuan pelanggan baru resmi dibuat di Fenergo. Biasanya, sistem mencatat peristiwa ini secara eksplisit dengan stempel waktu saat data kasus pertama kali disimpan. | ||
| Mengapa ini penting Sebagai peristiwa awal, aktivitas ini penting untuk menghitung waktu siklus onboarding secara keseluruhan dan menganalisis jumlah kasus yang diproses. Aktivitas ini menjadi acuan untuk semua pengukuran proses dan pemantauan SLA berikutnya. Sumber data Biasanya, aktivitas ini diambil dari stempel waktu pembuatan entitas kasus utama di Fenergo, yang sering ditemukan dalam tabel terkait kasus atau alur kerja Client Onboarding. Pengumpulan data Gunakan stempel waktu pembuatan catatan kasus onboarding. Jenis peristiwa explicit | |||
| Kasus Ditutup | Ini adalah aktivitas terakhir yang menandakan kasus onboarding telah ditutup secara administratif di Fenergo dan tidak memerlukan tindakan lanjutan. Ini berlaku untuk pengajuan yang disetujui maupun ditolak, dan dapat disimpulkan dari status akhir 'Closed'. | ||
| Mengapa ini penting Aktivitas ini menjadi titik akhir yang pasti untuk seluruh proses. Aktivitas ini memastikan perhitungan waktu siklus yang akurat untuk semua kasus, apa pun hasilnya, serta mengonfirmasi bahwa proses telah selesai. Sumber data Disimpulkan dari log audit kasus Fenergo dengan mencari stempel waktu saat status kasus diubah menjadi 'Closed', 'Completed', atau status akhir lainnya. Pengumpulan data Cari stempel waktu perubahan status terakhir menjadi 'Closed' atau 'Completed'. Jenis peristiwa inferred | |||
| Pengajuan disetujui | Aktivitas ini menandai keputusan akhir untuk menyetujui pengajuan onboarding pelanggan. Aktivitas ini disimpulkan saat status kasus berubah menjadi status akhir 'Approved' atau 'Onboarding Approved'. | ||
| Mengapa ini penting Pencapaian penting ini menandakan hasil yang berhasil sebelum tahap akhir aktivasi akun. Aktivitas ini diperlukan untuk menghitung tingkat persetujuan dan menganalisis karakteristik pelanggan yang berhasil menjalani onboarding. Sumber data Disimpulkan dari riwayat kasus atau log audit dengan mencari stempel waktu perubahan status akhir menjadi 'Approved' atau status positif akhir yang serupa. Pengumpulan data Cari stempel waktu perubahan status akhir menjadi 'Approved'. Jenis peristiwa inferred | |||
| Pengajuan ditolak | Aktivitas ini merupakan peristiwa akhir yang menandai keputusan final untuk menolak pengajuan pelanggan. Aktivitas ini disimpulkan saat status kasus berubah menjadi status akhir 'Rejected' atau 'Declined'. | ||
| Mengapa ini penting Sebagai titik akhir penting dalam proses, aktivitas ini diperlukan untuk menghitung 'Application Rejection Rate' dan menganalisis penyebab kegagalan. Aktivitas ini membantu menemukan penyebab umum penolakan dan meningkatkan kualitas pengajuan. Sumber data Disimpulkan dari log audit kasus dengan mencatat stempel waktu saat status akhir berubah menjadi 'Rejected'. Alasan penolakan biasanya disimpan di kolom terkait. Pengumpulan data Cari stempel waktu perubahan status akhir menjadi 'Rejected'. Jenis peristiwa inferred | |||
| Penilaian risiko selesai | Menandai selesainya proses klasifikasi risiko internal, saat pelanggan diberi peringkat risiko berdasarkan berbagai faktor. Aktivitas ini disimpulkan dari perubahan status atau pengisian kolom peringkat risiko. | ||
| Mengapa ini penting Ini adalah pencapaian penting dalam pengambilan keputusan yang sering menentukan jalur alur kerja berikutnya. Menganalisis durasinya membantu menyederhanakan tahap kepatuhan yang penting dan memastikan penilaian risiko dilakukan secara konsisten. Sumber data Disimpulkan dari log riwayat kasus dengan mencari waktu saat status kasus berubah menjadi 'Risk Assessed' atau saat kolom akhir 'Customer Risk Rating' diisi. Pengumpulan data Gunakan stempel waktu saat peringkat risiko ditetapkan atau status terkait diperbarui. Jenis peristiwa inferred | |||
| Peninjauan dokumen selesai | Menandai selesainya proses manual atau otomatis untuk memverifikasi keaslian dan kebenaran semua dokumen yang dikirimkan pelanggan. Peristiwa ini biasanya disimpulkan dari penyelesaian tugas alur kerja atau perubahan status di Fenergo. | ||
| Mengapa ini penting Ini adalah pencapaian penting yang sering menjadi sumber keterlambatan. Menganalisis durasi dan hasil aktivitas ini membantu menemukan hambatan dalam pemrosesan dokumen dan mendukung KPI seperti 'First-Time Pass Rate'. Sumber data Disimpulkan dari stempel waktu penyelesaian tugas 'Document Verification' dalam alur kerja kasus atau pembaruan status menjadi 'Documents Approved' di log riwayat kasus. Pengumpulan data Gunakan stempel waktu penyelesaian tugas peninjauan dokumen atau perubahan status terkait. Jenis peristiwa inferred | |||
| Peninjauan kepatuhan dimulai | Aktivitas ini menandai dimulainya peninjauan oleh departemen kepatuhan, tahap penting yang sering memakan waktu. Aktivitas ini disimpulkan saat kasus dimasukkan ke antrean kerja kepatuhan atau statusnya berubah menjadi 'Pending Compliance Review'. | ||
| Mengapa ini penting Aktivitas ini menjadi titik awal untuk mengukur KPI 'Average Compliance Review Time'. Aktivitas ini membantu mengetahui berapa lama kasus menunggu sebelum mulai ditangani oleh tim kepatuhan. Sumber data Disimpulkan dari log audit kasus Fenergo dengan mencatat stempel waktu perubahan status menjadi 'In Compliance Review' atau saat kasus ditugaskan kepada petugas atau tim kepatuhan. Pengumpulan data Cari stempel waktu perubahan status menjadi 'Under Compliance Review' atau peristiwa penugasan. Jenis peristiwa inferred | |||
| Peninjauan kepatuhan selesai | Menandai persetujuan resmi dari departemen kepatuhan, yang menunjukkan bahwa semua ketentuan peraturan telah dipenuhi. Aktivitas ini disimpulkan dari penyelesaian tugas atau perubahan status menjadi 'Compliance Approved'. | ||
| Mengapa ini penting Sebagai pencapaian penting, penyelesaian aktivitas ini berpengaruh besar pada waktu siklus keseluruhan. Aktivitas ini menjadi titik akhir pengukuran 'Average Compliance Review Time' dan membantu menemukan hambatan dalam fungsi kepatuhan. Sumber data Disimpulkan dari stempel waktu penyelesaian tugas 'Compliance Review' dalam alur kerja Fenergo atau peristiwa pembaruan status di riwayat kasus. Pengumpulan data Gunakan stempel waktu penyelesaian tugas peninjauan kepatuhan atau pembaruan status. Jenis peristiwa inferred | |||
| Akun diaktifkan | Menunjukkan bahwa akun pelanggan berhasil dibuat dan diaktifkan di sistem perbankan inti atau sistem hilir terkait setelah mendapat persetujuan. Hal ini dapat disimpulkan dari pembaruan status akhir di Fenergo setelah persetujuan. | ||
| Mengapa ini penting Aktivitas ini mengonfirmasi bahwa proses onboarding berhasil beralih ke status pelanggan aktif. Mengukur waktu dari persetujuan hingga aktivasi dapat mengungkap keterlambatan dalam penyiapan operasional. Sumber data Hal ini dapat disimpulkan dari status kasus seperti 'Account Active' atau 'Onboarding Complete'. Bisa juga berupa peristiwa eksplisit yang dicatat oleh integrasi dengan sistem hilir. Pengumpulan data Cari perubahan status setelah persetujuan atau catatan peristiwa keberhasilan integrasi. Jenis peristiwa inferred | |||
| Data dan dokumen diminta | Peristiwa ini menandakan bahwa sistem atau petugas onboarding secara resmi meminta informasi dan dokumen yang diperlukan dari pelanggan. Biasanya, peristiwa ini tercatat secara eksplisit saat templat komunikasi standar dikirim. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya tahap yang bergantung pada pelanggan. Mengukur waktu dari tahap ini hingga dokumen diterima penting untuk menganalisis perjalanan pelanggan dan menemukan keterlambatan komunikasi. Sumber data Diambil dari log peristiwa komunikasi dengan pelanggan atau log penyelesaian tugas 'Request Documents'. Peristiwa ini juga dapat disimpulkan dari perubahan status menjadi 'Awaiting Customer Information'. Pengumpulan data Cari peristiwa komunikasi dengan pelanggan atau penyelesaian tugas yang tercatat. Jenis peristiwa explicit | |||
| Dokumen diterima | Aktivitas ini menandakan bahwa pelanggan telah mengunggah atau mengirimkan dokumen yang diperlukan dan dokumen tersebut kini tersedia di Fenergo untuk ditinjau. Biasanya, aktivitas ini disimpulkan saat status kasus berubah menjadi 'Documents Received' atau 'Pending Review'. | ||
| Mengapa ini penting Aktivitas ini menandai berakhirnya waktu tunggu pelanggan dan dimulainya siklus peninjauan internal. Aktivitas ini penting untuk mengukur waktu respons pelanggan dan waktu antrean pemrosesan internal. Sumber data Disimpulkan dari jejak audit kasus yang mencatat stempel waktu perubahan status menjadi 'Documents Received' atau status serupa. Aktivitas ini juga dapat dikaitkan dengan peristiwa pengunggahan dokumen. Pengumpulan data Cari stempel waktu perubahan status menjadi 'Documents Received' atau 'Ready for Review'. Jenis peristiwa inferred | |||
| Informasi tambahan diminta | Aktivitas ini menandai pengerjaan ulang, saat tim onboarding perlu kembali menghubungi pelanggan untuk meminta klarifikasi atau dokumen yang belum disertakan. Peristiwa ini biasanya tercatat secara eksplisit saat komunikasi dikirim kepada pelanggan. | ||
| Mengapa ini penting Aktivitas ini merupakan indikator utama inefisiensi proses dan pengalaman pelanggan yang buruk. Melacak frekuensinya membantu menemukan penyebab pengerjaan ulang dan mendukung KPI 'Rework Loop Rate'. Sumber data Diambil dari log peristiwa komunikasi dengan pelanggan atau perubahan status menjadi 'Awaiting Additional Information'. Log komunikasi lebih akurat untuk mengetahui waktu permintaan yang sebenarnya. Pengumpulan data Cari peristiwa komunikasi yang tercatat atau perubahan status menjadi 'Pending Customer Response'. Jenis peristiwa explicit | |||
| Pemeriksaan awal dilakukan | Menandai selesainya pemeriksaan awal otomatis atau manual, seperti validasi data dasar atau pemeriksaan daftar sanksi. Peristiwa ini sering disimpulkan dari perubahan status dalam alur kerja kasus Fenergo, misalnya dari 'New' menjadi 'Screening Complete'. | ||
| Mengapa ini penting Melacak pencapaian awal ini membantu menemukan masalah kualitas data dan hambatan pada tahap pra-kualifikasi. Aktivitas ini memisahkan tahap awal otomatis dari proses peninjauan manual yang lebih mendalam. Sumber data Disimpulkan dari riwayat kasus atau log audit dengan mencari stempel waktu saat status kasus berubah menjadi status yang menandakan pemeriksaan selesai, seperti 'Screening Passed' atau 'Awaiting Documents'. Pengumpulan data Cari perubahan status menjadi 'Screening Complete' atau status serupa dalam riwayat kasus. Jenis peristiwa inferred | |||
| Pemeriksaan latar belakang dimulai | Aktivitas ini menandai dimulainya pemeriksaan latar belakang, AML, atau kredit oleh pihak eksternal. Biasanya, peristiwa ini tercatat secara eksplisit saat integrasi dengan layanan pihak ketiga dipanggil. | ||
| Mengapa ini penting Melacak dimulainya dan selesainya pemeriksaan ini penting untuk memahami keterlambatan akibat ketergantungan pada pihak eksternal. Hal ini membantu memisahkan waktu proses internal dari waktu tunggu eksternal. Sumber data Biasanya, aktivitas ini diambil dari log sistem yang mencatat panggilan API ke penyedia pemeriksaan eksternal atau dari pembuatan tugas 'Background Check' tertentu dalam kasus Fenergo. Pengumpulan data Cari log integrasi layanan eksternal atau pembuatan tugas 'Screening'. Jenis peristiwa explicit | |||
Panduan ekstraksi
Langkah
- Buka modul pelaporan: Masuk ke aplikasi Fenergo menggunakan akun pengguna yang memiliki izin memadai untuk modul pelaporan dan analitik. Buka modul tersebut, biasanya melalui menu utama aplikasi.
- Buat laporan baru: Mulai membuat laporan khusus. Pilih nama dan deskripsi yang menjelaskan tujuannya, misalnya, 'Log peristiwa orientasi KYC untuk process mining'.
- Tentukan sumber data utama: Pilih objek atau tampilan data inti yang mencatat siklus hidup kasus. Biasanya, sumbernya berupa tampilan yang telah dikonfigurasi, seperti
[CaseWorkflowHistory]atau[LifecycleEventsView]. Objek ini harus memuat ID kasus, nama atau status peristiwa, serta stempel waktu. - Atur kolom laporan (atribut): Tambahkan kolom melalui antarmuka pembuat laporan. Petakan kolom sumber dari model data Fenergo ke atribut log peristiwa yang diperlukan. Contohnya, petakan
CaseIDFenergo keCustomerApplication,EventTimestampkeEventStartTime, danEventPerformerkeInitiatingUser. - Susun logika aktivitas: Ini langkah terpenting. Atur laporan agar menghasilkan satu baris terpisah untuk setiap dari 14 aktivitas yang diperlukan. Caranya, buat blok logika atau kumpulan data yang difilter untuk setiap aktivitas, lalu gabungkan dengan UNION atau fungsi sejenis di pembuat laporan.
- Tentukan logika 'Kasus Dibuat': Buat blok pertama. Filter sumber data untuk menemukan peristiwa pembuatan kasus awal. Biasanya, peristiwa ini ditentukan dari stempel waktu paling awal pada kasus atau jenis peristiwa bernama 'Kasus Dibuat'. Petakan
CreationDatekeEventStartTime. - Tentukan logika aktivitas berdasarkan status: Untuk aktivitas yang disimpulkan dari perubahan status, seperti 'Dokumen Diterima' atau 'Pengajuan Disetujui', buat blok terpisah. Filter sumber data berdasarkan nilai kolom
Statustertentu dan gunakanStatusChangeDatesebagaiEventStartTime. - Tentukan logika aktivitas berdasarkan tugas: Untuk aktivitas yang terkait dengan tugas workflow, seperti 'Tinjauan Kepatuhan Selesai', buat blok yang memfilter
TaskNamedanTaskCompletionDate. Gunakan tanggal penyelesaian sebagaiEventStartTime. - Atur filter laporan global: Terapkan filter pada tingkat laporan untuk membatasi data. Tentukan
Date RangeuntukEventStartTimeagar hasil ekspor tidak terlalu besar. Untuk analisis awal, disarankan menggunakan periode 3 hingga 6 bulan. Filter juga berdasarkan jenis kasus tertentu, seperti 'Orientasi Pelanggan KYC'. - Jalankan dan pratinjau laporan: Jalankan laporan di antarmuka Fenergo. Periksa 100-200 baris pertama untuk memastikan struktur data sudah benar, semua kolom terisi sesuai harapan, dan berbagai aktivitas tercantum.
- Ekspor data: Ekspor seluruh hasil laporan ke file CSV atau Excel. File ini berisi log peristiwa mentah.
- Siapkan data akhir: Buka file CSV yang diekspor. Jika kolom
SourceSystemdanLastDataUpdatetidak dapat dibuat langsung melalui laporan, tambahkan secara manual. IsiSourceSystemdengan 'Fenergo' untuk semua baris dan isiLastDataUpdatedengan waktu ekspor.
Konfigurasi
- Prasyarat: Pengguna perlu memiliki akses ke modul pelaporan dan analitik Fenergo serta izin untuk membuat dan menjalankan laporan khusus.
- Sumber data utama: Laporan sebaiknya terutama menggunakan objek riwayat kasus dan workflow Fenergo. Sumber yang umum mencakup
[CaseDetails],[CaseStatusHistory], dan[WorkflowTaskHistory]. Nama persisnya dapat berbeda, tergantung konfigurasi Fenergo Anda. - Rentang tanggal: Tetapkan filter rentang tanggal pada stempel waktu peristiwa untuk menjaga kinerja sistem. Mulailah dengan periode terbaru selama 3 hingga 6 bulan. Untuk analisis historis, jalankan laporan secara bertahap, misalnya per kuartal atau per tahun.
- Filter utama: Selalu filter berdasarkan proses atau jenis kasus tertentu, seperti 'Orientasi Pelanggan KYC', agar data yang tidak relevan tidak ikut terambil. Bergantung pada tujuan analisis, Anda mungkin juga perlu memfilter berdasarkan jenis badan hukum atau yurisdiksi.
- Definisi aktivitas: Tentukan setiap aktivitas menggunakan kriteria filter khusus pada kolom seperti
Status,TaskName, atau kolomEventTypekhusus. Kolom-kolom ini penting untuk memisahkan setiap peristiwa unik dalam proses. - Pertimbangan kinerja: Laporan yang menggabungkan banyak sumber data atau memindai rentang tanggal yang panjang dapat berjalan lambat. Jika memungkinkan, jadwalkan laporan di luar jam sibuk. Jangan sertakan kolom yang tidak diperlukan dalam ekspor karena akan menambah waktu pemrosesan.
Contoh kueri 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]' Siap memulai?
Dengan menggunakan templat data ini, Anda dapat mulai menemukan inefisiensi dan menyederhanakan proses orientasi pelanggan KYC di Fenergo. Mulailah mengoptimalkan operasional dan meningkatkan kepuasan pelanggan hari ini.
Sederhanakan proses orientasi pelanggan KYC dan percepat persetujuan
Bergabunglah dengan bisnis yang memangkas waktu orientasi menjadi hanya 24 jam.
Tidak perlu kartu kredit. Anda bisa mulai dalam hitungan menit.