KYC müşteri işe alımı veri şablonunuz
KYC müşteri işe alımı veri şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
KYC müşteri işe alımı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Başlangıç zamanı EventStartTime | Bir etkinliğin veya olayın resmen ne zaman başladığını gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, belirli bir etkinliğin başladığı kesin tarih ve saati kaydeder. Süreç akışını yeniden oluşturmak için gereken kronolojik sırayı sağlar ve zamana dayalı tüm analizler için gereklidir. Process Mining çalışmalarında başlangıç zamanı, etkinliklerin süresini, aralarındaki bekleme süresini ve vakanın toplam çevrim süresini hesaplamak için kullanılır. Olay günlüğünün zamansal temelini oluşturur; performans ve darboğaz analizinde önemli rol oynar. Neden önemli? Bu zaman damgası, olayları kronolojik sıraya koymak ve çevrim süreleri ile süreler gibi zamana dayalı metrikleri hesaplamak için gereklidir. Nereden alınır? Fenergo’nun denetim izi, olay günlüğü veya iş akışı geçmişi tablolarında bulunur; genellikle 'Timestamp', 'StartDate' veya 'CreationDate' olarak adlandırılır. Örnekler 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Etkinlik adı ActivityName | Müşteri kabul sürecinde belirli bir anda gerçekleşen iş olayının veya görevin adı. | ||
| Açıklama Etkinlik adı, müşteri kabul yolculuğundaki 'İlk tarama yapıldı' veya 'Başvuru onaylandı' gibi tek bir adımı ya da kilometre taşını tanımlar. Bu etkinliklerin sıralaması süreç haritasının temelini oluşturur. Bu özniteliği analiz ederek süreç akışını görselleştirebilir, yaygın ve alternatif yolları belirleyebilir, her adımın ne sıklıkta gerçekleştiğini ölçebilirsiniz. Hangi işlemlerin hangi sırayla yapıldığını anlamak için önemlidir. Neden önemli? Bu öznitelik, süreç adımlarını tanımlar; böylece süreç haritası oluşturabilir, akışı ve farklılıkları analiz edebilirsiniz. Nereden alınır? Bu bilgi genellikle Fenergo’nun iş akışı veya denetim günlüğü tablolarında, vaka durumu geçişleri ya da görev tamamlamalarıyla ilişkili olarak bulunur. Örnekler Veri ve belgeler istendiUyumluluk incelemesi başlatıldıBaşvuru onaylandı | |||
| Müşteri başvurusu CustomerApplication | Tek bir müşterinin müşteri kabul sürecini tanımlayan benzersiz kimlik. Birincil vaka kimliği olarak kullanılır. | ||
| Açıklama Müşteri başvurusu, tek bir müşterinin KYC müşteri kabul sürecine ait tüm etkinlikleri ve olayları bir araya getiren temel tanımlayıcıdır. Başvurunun ilk gönderiminden nihai sonuca kadar izlenmesini sağlar; sonuç onay, ret veya kapatma olabilir. Process Mining çalışmalarında bu öznitelik, her başvurunun tüm yolculuğunu yeniden oluşturmak için temel oluşturur. Süreç akışlarını, çevrim sürelerini, farklılıkları ve darboğazları başvuru bazında incelemenizi sağlayarak vakaların nasıl ele alındığını açıkça gösterir. Neden önemli? Bu temel vaka kimliği, ilgili tüm olayları birbirine bağlayarak müşteri kabul sürecinin baştan sona analiz edilmesini sağlar. Nereden alınır? Bu genellikle Fenergo’nun temel vaka yönetimi veya müşteri yaşam döngüsü yönetimi varlığındaki birincil anahtardır. Örnekler APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Kaynak sistem SourceSystem | Verinin alındığı kayıt sistemi. | ||
| Açıklama Bu öznitelik, olay verisinin geldiği sistemi belirtir. Bu süreçte kaynak her zaman Fenergo’dur; ancak birden fazla kaynaktan veri içeren Veri Setlerinde kaynakları ayırt etmeye yardımcı olur. Analizde temel olarak belirli sistemlerden gelen verileri filtrelemek veya verinin kaynağını doğrulamak için kullanılır. Bütüncül bir süreç görünümü oluşturmak amacıyla birden fazla sistemden gelen verilerin birleştirildiği ortamlarda açıklık sağlar. Neden önemli? Verinin kaynağını belirtir. Veri yönetişimi ve doğrulama, ayrıca analizin doğru kaynağa dayanmasını sağlamak açısından önemlidir. Nereden alınır? Bu genellikle kayıtların kaynağını belirtmek için veri çıkarma sırasında eklenen sabit bir değerdir. Örnekler FenergoFenergo CLM | |||
| Son veri güncellemesi LastDataUpdate | Bu sürece ait verinin en son yenilendiği veya çıkarıldığı zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, verinin en son yenilendiği tarih ve saati kaydeder. Analiz edilen verinin güncelliğini anlamanıza yardımcı olur ve içgörülerin ne kadar güncel olduğunu gösterir. Dashboardlarda ve raporlarda bu bilgi, kullanıcılara verinin güncelliğini bildirir. Analizin gerçek zamanlı operasyonları mı yoksa geçmişteki bir anlık görüntüyü mü yansıttığı konusunda beklentileri yönetmeye yardımcı olur. Neden önemli? Verinin güncelliği hakkında önemli bağlam sağlar ve kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasına yardımcı olur. Nereden alınır? Bu değer, veri çıkarma ve yükleme (ETL) sırasında oluşturulur ve Veri Setine eklenir. Örnekler 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Başvuru durumu ApplicationStatus | Müşteri başvurusunun mevcut durumu veya nihai sonucu. | ||
| Açıklama Bu öznitelik, sürecin sonunda başvurunun sonucunu veya süreç devam ediyorsa mevcut durumunu belirtir. Yaygın değerler arasında 'Onaylandı', 'Reddedildi' ve 'Devam ediyor' bulunur. Sonuç analizinde önemli bir boyuttur. Süreç akışlarını nihai sonuca göre filtreleyip karşılaştırmanızı sağlar. Bu, 'Başvuruda yeniden çalışma ve ret' Dashboardu ve başvuru ret oranı gibi KPI’ların hesaplanması için gereklidir. Neden önemli? Vakanın sonucunu tanımlar; onaylanan ve reddedilen başvuruların izlerini karşılaştırarak başarı oranlarını anlamanızı sağlar. Nereden alınır? Bu, genellikle Fenergo’nun vaka yönetimi sistemindeki vaka kaydına yazılan son durumdur. Örnekler OnaylandıReddedildiUyumluluk incelemesi bekleniyorKapalı | |||
| Bitiş zamanı EventEndTime | Bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, belirli bir etkinliğin tamamlandığı kesin tarih ve saati kaydeder. Bir görevin etkin süresini belirlemek için başlangıç zamanını tamamlar. Process Mining çalışmalarında bitiş zamanı, her etkinliğin işlem süresini hesaplamak için başlangıç zamanıyla birlikte kullanılır. Süreçte en çok zaman alan adımları belirlemek ve kaynak verimliliğini incelemek için gereklidir. Neden önemli? Etkinliklerin işlem sürelerini hesaplamayı sağlar. Bu, uzun süren görevleri ve performans darboğazlarını belirlemek için temel oluşturur. Nereden alınır? Fenergo’nun denetim izi veya iş akışı geçmişi tablolarında bulunur; genellikle 'EndDate' ya da 'CompletionDate' olarak adlandırılır veya sonraki olayın başlangıç zamanından çıkarılır. Örnekler 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| İşlemi başlatan kullanıcı InitiatingUser | Etkinliği gerçekleştiren kişinin kullanıcı kimliği veya adı. | ||
| Açıklama Bu öznitelik, belirli bir görevi veya olayı gerçekleştirmekten sorumlu çalışanı ya da sistem kullanıcısını belirtir. Benzersiz bir kullanıcı kimliği, ad veya rol olabilir. Kullanıcı bazında analiz, iş yükü dağılımını ve bireysel performansı anlamaya, eğitim ihtiyaçlarını belirlemeye yardımcı olur. 'Personel etkinlik dağılımı' Dashboardu için ve belirli kişilerin ya da ekiplerin gerçekleştirdiği etkinlikleri ayrıntılı incelemek için önemlidir. Neden önemli? Bir işlemi hangi kullanıcının gerçekleştirdiğini izleyerek iş yükü dağılımını, ekip performansını ve kaynak tahsisini analiz etmenizi sağlar. Nereden alınır? Bu bilgi genellikle Fenergo’nun denetim günlüklerinde veya görev geçmişi tablolarında olay ayrıntılarıyla birlikte, 'UserID', 'UserName' ya da 'ModifiedBy' alanlarında saklanır. Örnekler j.doea.smithSİSTEM | |||
| Kullanıcı departmanı UserDepartment | İşlemi başlatan kullanıcının bağlı olduğu departman veya iş birimi. | ||
| Açıklama Bu öznitelik, etkinliği gerçekleştiren kullanıcının 'Uyumluluk', 'Müşteri kabul operasyonları' veya 'Satış' gibi kurumsal bağlamını belirtir. Genellikle kullanıcı profili bilgilerinden alınır. Bu boyut, farklı departmanlar arasındaki süreç devir teslimlerini analiz etmek ve departmanlar arası darboğazları belirlemek için önemlidir. İşlerin ekip veya departman düzeyinde toplanmasını sağlayarak 'Personel etkinlik dağılımı' Dashboardunu destekler. Neden önemli? Departman bazında süreç performansını analiz etmenizi, departmanlar arasındaki devir teslimleri, gecikmeleri ve iş yükü dağılımını görmenizi sağlar. Nereden alınır? Bu bilgi, 'İşlemi başlatan kullanıcı' kimliği kullanılarak ayrı bir kullanıcı veya İK ana veri tablosundan alınabilir. Fenergo, bu bilgiyi kullanıcı profilinde de saklıyor olabilir. Örnekler ComplianceMüşteri kabulüKalite güvencesi | |||
| Risk skoru RiskScore | Müşterinin hesaplanan risk düzeyini gösteren sayısal skor. | ||
| Açıklama Risk skoru, yargı bölgesi, sektör ve tarama sonuçları gibi çeşitli faktörlere göre hesaplanan, müşteriyle ilişkili potansiyel riskin sayısal ölçüsüdür. Bu skoru genellikle Fenergo’nun kural motoru hesaplar. Bu öznitelik, risk düzeyleri ile süreç davranışı arasındaki ilişkiyi incelemenizi sağlar. Örneğin analiz, yüksek riskli müşterilerin çevrim sürelerinin daha uzun olup olmadığını veya daha fazla manuel işlem gerektirip gerektirmediğini ortaya çıkarabilir. Bu bilgiler 'Risk ve uyumluluk incelemesine ayrıntılı bakış' Dashboardunda kullanılabilir. Neden önemli? Müşteri riskini sayısal olarak ifade eder ve risk düzeylerinin süreç süresini, yeniden çalışmayı ve sonuçları nasıl etkilediğini analiz etmenizi sağlar. Nereden alınır? Bu, Fenergo’nun Müşteri Risk Değerlendirme modülünün temel çıktılarından biridir. Vaka veya müşteri kaydında saklanır. Örnekler 154585 | |||
| SLA hedef tarihi SlaTargetDate | Müşteri kabul vakasının tamamlanmasının beklendiği tarih. | ||
| Açıklama SLA hedef tarihi, müşteri başvurusuna ait tüm müşteri kabul sürecinin tamamlanması için üzerinde anlaşılmış son tarihi belirtir. Gerçek performansın ölçüldüğü önemli bir ölçüttür. Bu öznitelik, 'SLA uyumluluğu izleme' Dashboardu ve 'SLA’ya uyum oranı' KPI’ının hesaplanması için gereklidir. SLA süresini aşma riski taşıyan vakaları önceden yönetmenize ve işlere öncelik vermenize yardımcı olur. Neden önemli? Hedef tamamlanma tarihini belirtir. SLA uyumluluğunu izlemek ve geciken vakalara öncelik vermek için önemlidir. Nereden alınır? Bu tarih genellikle başvuru gönderim tarihine ve Fenergo’nun SLA yönetimi modülünde tanımlanan iş kurallarına göre hesaplanır. Örnekler 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Başvuru kanalı ApplicationChannel | Müşteri başvurusunun gönderildiği kanal. | ||
| Açıklama Bu öznitelik, başvurunun çevrimiçi portal, fiziksel şube veya müşteri temsilcisi gibi hangi kaynaktan gönderildiğini belirtir. Kaynak, veri kalitesini ve işlem gerekliliklerini etkileyebilir. Farklı kanalların performansını karşılaştırmak için 'Başvuru kaynağı ve türüne göre verimlilik' Dashboardunda kullanılır. İşletmelerin hangi kanalların daha verimli olduğunu ve hangilerinde süreç iyileştirmesi gerekebileceğini anlamasına yardımcı olur. Neden önemli? Başvuruların kaynağını belirterek kanal verimliliğini, maliyetleri ve müşteri deneyimini analiz etmenizi sağlar. Nereden alınır? Bu bilgi, Fenergo’daki ilk veri giriş formunda toplanabilir veya önceki bir sistemden aktarılabilir. Örnekler Çevrimiçi portalŞubeMüşteri temsilcisiMobil uygulama | |||
| Ek bilgi talebi sayısı AdditionalInfoRequestCount | Bir başvuru için ek bilgi talep edilme sayısı. | ||
| Açıklama Bu metrik, her vaka için 'Ek bilgi istendi' etkinliğinin kaç kez gerçekleştiğini sayar. Sayının yüksek olması, süreci geciktirebilecek ve müşteri deneyimini olumsuz etkileyebilecek yoğun yazışma trafiğine işaret eder. Bu öznitelik, 'Ek bilgi talebi olan vakalar' KPI’ını doğrudan destekler. Aşırı sayıda talep alan başvuruları belirlemek için kullanılır; bu durum ilk veri toplama aşamasındaki sorunlara veya karmaşık vaka gerekliliklerine işaret edebilir. Analiz, bilgi toplama sürecini kolaylaştırmaya yardımcı olur. Neden önemli? İlk bilgilerin eksik olmasından kaynaklanan müşteri zorluklarını ve süreç gecikmelerini ölçerek veri toplama adımını iyileştirmeye yardımcı olur. Nereden alınır? Bu, her 'CustomerApplication' kimliği için 'Ek bilgi istendi' olaylarının sayılmasıyla hesaplanan bir metriktir. Örnekler 013 | |||
| Müşteri kimliği CustomerId | Müşteri kabulü yapılan müşterinin veya tüzel kişinin benzersiz kimliği. | ||
| Açıklama Müşteri kimliği, ana veri sistemindeki müşteri kaydına ait benzersiz referanstır. Başvuru numarası sürecin vaka kimliğiyken müşteri kimliği, müşteri kabulü etkinliğini belirli bir müşteriye bağlar. Bu öznitelik, örneğin aynı müşterinin zaman içinde birden fazla müşteri kabul sürecinden geçip geçmediğini incelemenizi sağlar. Ayrıca daha kapsamlı bir iş görünümü için süreç verilerini müşteriyle ilgili diğer verilerle birleştirebilirsiniz. Neden önemli? Müşteri kabul sürecini benzersiz bir müşteri kaydına bağlayarak müşteri odaklı analiz ve veri zenginleştirme olanağı sağlar. Nereden alınır? Bu kimlik, Fenergo’daki müşteri veya tüzel kişi kaydında saklanır ve müşteri kabul vakasıyla ilişkilendirilir. Örnekler CUST-98765CUST-98766CUST-98767 | |||
| Müşteri türü CustomerType | Müşteri kabulü yapılan müşterinin Bireysel, Kurumsal veya Vakıf gibi sınıflandırması. | ||
| Açıklama Bu öznitelik, müşterileri yasal yapılarına veya finans kuruluşuyla ilişkilerine göre farklı kategorilere ayırır. Müşteri türlerine göre müşteri kabul süreçlerinin izlediği yollar, karmaşıklık düzeyleri ve durum tespiti gereklilikleri değişebilir. Süreci müşteri türüne göre analiz etmek, segmentler arasındaki performans farklarını belirlemeye yardımcı olur. 'Başvuru kaynağı ve türüne göre verimlilik' Dashboardunda çevrim sürelerini ve onay oranlarını karşılaştırmak için kullanılır; böylece süreci iyileştirmeye yönelik adımlar belirlenebilir. Neden önemli? Genellikle karmaşıklık düzeyleri ve SLA’ları farklı olan müşteri segmentlerinin süreç performansını karşılaştırmanızı sağlar. Nereden alınır? Bu bilgi genellikle Fenergo’daki müşteri kaydında tutulur ve başvuru vakasıyla ilişkilendirilir. Örnekler BireyselKurumsalVakıfOrtaklık | |||
| Otomatik mi IsAutomated | Etkinliğin bir kullanıcı yerine sistem tarafından gerçekleştirilip gerçekleştirilmediğini belirten mantıksal değer. | ||
| Açıklama Bu öznitelik, sistemin otomatik olarak gerçekleştirdiği görevleri (ör. ilk tarama ve sistem kontrolleri) kullanıcının manuel olarak gerçekleştirdiği görevlerden ayırır. Genellikle işlemi gerçekleştiren kullanıcının sistem veya hizmet hesabı olup olmadığına bakılarak belirlenir. Bu değeri analiz etmek, süreçteki otomasyon düzeyini anlamak için önemlidir. Otomasyonun verimlilik, maliyet ve hız üzerindeki etkisini ölçmeye ve daha fazla otomasyon fırsatlarını belirlemeye yardımcı olur. Neden önemli? Kullanıcı etkinliklerini sistem etkinliklerinden ayırır. Otomasyon analizinde ve kaynak maliyetlerini anlamada önemlidir. Nereden alınır? Bu değer genellikle 'İşlemi başlatan kullanıcı' alanından çıkarılır. Bilinen sistem kullanıcı kimlikleri listesi kullanılarak değer doğru olarak ayarlanır. Örnekler truefalse | |||
| Ret nedeni RejectionReason | Başvurunun neden reddedildiğini açıklayan kod veya açıklama. | ||
| Açıklama Başvurunun son durumu 'Reddedildi' olduğunda bu öznitelik, ret nedenini belirtir. Örnekler arasında 'Arka plan kontrolü başarısız', 'Belgeler eksik' ve 'Yüksek risk profili' bulunur. Başarısız başvuruların temel nedenlerini analiz etmek için önemli bir özniteliktir. 'Başvuruda yeniden çalışma ve ret' Dashboardunu destekleyerek başarısızlıkları kategorilere ayırır. Böylece işletme yaygın sorunları belirleyip düzeltici adımlar atabilir ve ilk seferde doğru tamamlama oranını artırabilir. Neden önemli? Başvuruların neden başarısız olduğuna dair önemli bilgiler sunar ve ret oranlarını azaltmak için temel neden analizini mümkün kılar. Nereden alınır? Genellikle Fenergo’nun vaka iş akışında, son ret durumuyla ilişkili neden kodu veya notlar alanında bulunur. Örnekler Yaptırım listesi eşleşmesiGeçersiz belgelerPolitika ihlaliMüşteri başvurudan vazgeçti | |||
| SLA’ya uygun mu IsSlaCompliant | Vakanın SLA hedef tarihine kadar tamamlanıp tamamlanmadığını belirten mantıksal değer. | ||
| Açıklama Bu öznitelik, tamamlanmış bir vakanın SLA performansını ikili bir değerle gösterir. Son kapatma etkinliğinin zaman damgası 'SlaTargetDate' tarihine eşit veya daha erkense 'doğru', değilse 'yanlış' olarak ayarlanır. Bu hesaplanan alan, SLA izleme ve raporlamayı kolaylaştırır. Genel 'SLA’ya uyum oranı' KPI’ını hesaplamak için verileri kolayca toplamanızı ve uyumlu vakalarla uyumlu olmayan vakaların süreç özelliklerini incelemek için filtreleme yapmanızı sağlar. Neden önemli? SLA performansını doğrudan ölçerek SLA’ya uyum oranı KPI’ının kolayca hesaplanmasını ve uyumlu olmayan vakaların filtrelenmesini sağlar. Nereden alınır? Bu değer, son vaka etkinliğinin (ör. 'Başvuru onaylandı' veya 'Başvuru reddedildi') zaman damgası ile 'SlaTargetDate' karşılaştırılarak elde edilir. Örnekler truefalse | |||
| Ülke Country | Müşteri başvurusuyla ilişkili ikamet ülkesi veya yargı bölgesi. | ||
| Açıklama Bu öznitelik, müşteriyle ilişkili ülkeyi belirtir. Ülke, müşteri kabul sürecinde geçerli olan düzenlemeleri ve risk faktörlerini belirler. Süreci ülkeye göre analiz etmek, çevrim sürelerini, risk düzeylerini ve süreç karmaşıklığını yargı bölgeleri arasında karşılaştırmanızı sağlar. Bölgesel farklılıkların operasyonel performansı nasıl etkilediğini anlamaya ve yerel düzenlemelere uyumu sağlamaya yardımcı olur. Neden önemli? Süreci coğrafi bölgelere göre ayırmanızı sağlar. Bu, düzenlemelerin etkisini ve bölgesel performansı analiz etmek için önemlidir. Nereden alınır? Bu bilgi, başvuru sırasında toplanan temel müşteri verilerinin parçasıdır ve Fenergo’daki müşteri kaydında saklanır. Örnekler USAGBRSGPDEU | |||
| Vaka sorumlusu CaseOwner | Başvuruyu yaşam döngüsü boyunca yönetmekten sorumlu birincil kullanıcı veya ekip. | ||
| Açıklama Vaka sorumlusu, müşteri kabul vakasının birincil sorumluluğunu üstlenen kişi veya gruptur. Bu kişi genellikle vakanın zamanında ve başarıyla tamamlanmasından sorumludur. Bu öznitelik, vaka yöneticisi düzeyinde iş yükünü ve performansı analiz etmeye yardımcı olur. Bazı vaka sorumlularının çevrim sürelerinin daha uzun veya ret oranlarının daha yüksek olup olmadığını görmenizi sağlar. Bu durum eğitim ihtiyacına veya kaynak dengesizliğine işaret edebilir. Neden önemli? Vakadan sorumlu kişiyi veya ekibi belirterek vaka yöneticilerinin performansını analiz etmenizi sağlar. Nereden alınır? Bu genellikle Fenergo’daki birincil vaka kaydında, vaka atamasını belirten özel bir alandır. Örnekler s.jonesonboarding_team_am.chen | |||
| Yeniden çalışma mı IsRework | Bir etkinliğin yeniden çalışma döngüsünün parçası olup olmadığını belirten mantıksal değer. | ||
| Açıklama Bu öznitelik, 'Uyumluluk incelemesi' başladıktan sonra yeniden 'Belge incelemesi' adımına dönmek veya 'Ek bilgi istendi' etkinliğinin gerçekleşmesi gibi süreçte geriye dönüşü gösteren etkinlikleri belirler. Yeniden çalışmayı belirlemek, süreçteki verimsizlikleri ve aksaklıkları anlamak için önemlidir. Bu değer, 'Yeniden çalışma döngüsü oranı' KPI’ının doğrudan hesaplanmasını sağlar; süreç akışındaki gereksiz ve tekrarlanan adımların etkisini görselleştirip ölçmeye yardımcı olur. Neden önemli? Süreçteki verimsiz yeniden çalışma döngülerini öne çıkarır. İsrafı ölçmenize ve ilk seferde doğru tamamlama oranını artırmak için iyileştirme alanlarını belirlemenize yardımcı olur. Nereden alınır? Bu değer, etkinlik sırasını inceleyen Process Mining teknikleriyle elde edilir. Örneğin aynı vaka için 'Etkinlik A' önce 'Etkinlik B' tarafından izlenir ve ardından 'Etkinlik A' yeniden gerçekleşirse, ikinci 'Etkinlik A' yeniden çalışma sayılır. Örnekler truefalse | |||
KYC müşteri işe alımı etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Başvuru onaylandı | Bu etkinlik, müşterinin kabul başvurusunun onaylanmasına ilişkin nihai kararı gösterir. Vaka durumu son olarak 'Onaylandı' veya 'Müşteri kabulü onaylandı' olduğunda anlaşılır. | ||
| Neden önemli? Bu önemli aşama, hesabın etkinleştirilmesine yönelik son adımlardan önce başarılı bir sonuç alındığını gösterir. Onay oranlarını hesaplamak ve kabulü başarıyla tamamlanan müşterilerin özelliklerini analiz etmek için gereklidir. Nereden alınır? Vaka geçmişinde veya denetim günlüğünde, son durumun 'Onaylandı' ya da benzer bir olumlu son duruma geçtiği zaman damgası bulunarak anlaşılır. Kaydedin Son durumun 'Onaylandı' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Başvuru reddedildi | Bu etkinlik, müşterinin başvurusunu reddetmeye yönelik nihai kararı gösteren son olaydır. Vaka durumu son olarak 'Reddedildi' veya 'Kabul edilmedi' olduğunda anlaşılır. | ||
| Neden önemli? Sürecin önemli bir bitiş noktası olan bu etkinlik, 'Başvuru ret oranı’nı hesaplamak ve başarısızlık nedenlerini analiz etmek için gereklidir. Yaygın ret noktalarını belirlemeye ve başvuru kalitesini artırmaya yardımcı olur. Nereden alınır? Vaka denetim günlüğünde, son durumun 'Reddedildi' olarak değiştiği zaman damgası alınarak anlaşılır. Ret nedeni genellikle ilgili bir alanda saklanır. Kaydedin Son durumun 'Reddedildi' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Belge incelemesi tamamlandı | Müşterinin gönderdiği tüm belgelerin doğruluğunu ve gerçekliğini kontrol eden manuel veya otomatik sürecin tamamlandığını gösterir. Bu olay genellikle Fenergo’daki bir iş akışı görevinin tamamlanmasından veya durum değişikliğinden anlaşılır. | ||
| Neden önemli? Gecikmelerin sık yaşandığı önemli bir aşamadır. Bu etkinliğin süresini ve sonuçlarını analiz etmek, belge işleme darboğazlarını belirlemeye ve 'İlk seferde kabul oranı' gibi KPI’ları izlemeye yardımcı olur. Nereden alınır? Vaka iş akışındaki 'Belge doğrulama' görevinin tamamlanma zaman damgasından veya vaka geçmişi günlüğündeki 'Belgeler onaylandı' durum güncellemesinden anlaşılır. Kaydedin Belge inceleme görevinin tamamlanma zaman damgasını veya ilgili durum değişikliğini kullanın. Olay türü inferred | |||
| Risk değerlendirmesi tamamlandı | Müşteriye çeşitli etkenlere göre risk derecesi atanan kurum içi risk sınıflandırma sürecinin tamamlandığını gösterir. Bir durum değişikliğinden veya risk derecesi alanının doldurulmasından anlaşılır. | ||
| Neden önemli? Sonraki iş akışının yolunu belirleyen önemli bir karar aşamasıdır. Süresini analiz etmek, uyumluluk açısından önemli bir adımı sadeleştirmeye ve risk değerlendirmesinin tutarlı olmasını sağlamaya yardımcı olur. Nereden alınır? Vaka geçmişi günlüğünde, vakanın 'Risk değerlendirildi' gibi bir duruma geçtiği veya son 'Müşteri risk derecesi' alanının doldurulduğu zaman belirlenerek anlaşılır. Kaydedin Risk derecesi alanının kesinleştirildiği veya ilgili durumun ayarlandığı zaman damgasını kullanın. Olay türü inferred | |||
| Uyumluluk incelemesi başlatıldı | Bu etkinlik, uyumluluk departmanının çoğu zaman uzun süren önemli inceleme aşamasının başlangıcını gösterir. Vaka uyumluluk iş kuyruğuna atandığında veya durumu 'Uyumluluk incelemesi bekliyor' olarak değiştiğinde anlaşılır. | ||
| Neden önemli? Bu etkinlik, 'Ortalama uyumluluk inceleme süresi' KPI’ını ölçmek için başlangıç noktasıdır. Vakaların uyumluluk ekibi tarafından aktif olarak işleme alınmadan önce ne kadar beklediğini belirlemeye yardımcı olur. Nereden alınır? Fenergo vaka denetim günlüğünde, durumun 'Uyumluluk incelemesinde' olarak değiştiği zaman damgası veya vakanın bir uyumluluk sorumlusuna ya da ekibine atandığı zaman belirlenerek anlaşılır. Kaydedin 'Uyumluluk incelemesi altında' durumuna geçişin zaman damgasını veya atama olayını belirleyin. Olay türü inferred | |||
| Uyumluluk incelemesi tamamlandı | Uyumluluk departmanının resmî onayını ve tüm mevzuat koşullarının karşılandığını gösterir. Bir görevin tamamlanmasından veya durumun 'Uyumluluk onaylandı' olarak değişmesinden anlaşılır. | ||
| Neden önemli? Önemli bir aşama olan bu etkinliğin tamamlanması, toplam çevrim süresini etkiler. 'Ortalama uyumluluk inceleme süresi’ni ölçmek ve uyumluluk işlevindeki darboğazları belirlemek için bitiş noktasıdır. Nereden alınır? Fenergo iş akışındaki 'Uyumluluk incelemesi' görevinin tamamlanma zaman damgasından veya vaka geçmişindeki durum güncellemesi olayından anlaşılır. Kaydedin Uyumluluk inceleme görevinin tamamlanma zaman damgasını veya durum güncellemesini kullanın. Olay türü inferred | |||
| Vaka kapatıldı | Bu, son etkinliktir ve Fenergo’daki müşteri kabul vakasının idari olarak kapatıldığını, başka bir işlem beklenmediğini gösterir. Hem onaylanan hem de reddedilen başvurular için geçerlidir ve son durumun 'Kapalı' olmasından anlaşılır. | ||
| Neden önemli? Bu etkinlik, sürecin tamamı için kesin bitiş noktasını oluşturur. Sonuç ne olursa olsun tüm vakaların çevrim süresinin doğru hesaplanmasını sağlar ve sürecin sona erdiğini doğrular. Nereden alınır? Vaka durumunun 'Kapalı', 'Tamamlandı' veya başka bir son duruma geçtiği zaman damgası belirlenerek Fenergo vaka denetim günlüğünden çıkarılır. Kaydedin Son durumun 'Kapalı' veya 'Tamamlandı' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Vaka oluşturuldu | Bu etkinlik, Fenergo’da yeni bir müşteri başvurusu resmen oluşturulduğunda KYC müşteri kabul sürecinin başladığını gösterir. Genellikle vaka kaydı ilk kez kaydedildiğinde belirli bir zaman damgasıyla kaydedilen açık bir olaydır. | ||
| Neden önemli? Başlangıç olayı olan bu etkinlik, toplam müşteri kabul çevrim süresini hesaplamak ve işlem hacmini analiz etmek için gereklidir. Sonraki tüm süreç ölçümleri ve SLA takibi için başlangıç noktası sağlar. Nereden alınır? Bu bilgi genellikle Fenergo’daki ana vaka kaydının oluşturulma zaman damgasından alınır. Çoğunlukla müşteri kabul vakaları veya iş akışlarıyla ilgili tablolarda bulunur. Kaydedin Müşteri kabul vaka kaydının oluşturulma zaman damgasını kullanın. Olay türü explicit | |||
| Belgeler alındı | Bu etkinlik, müşterinin gerekli belgeleri yüklediğini veya gönderdiğini ve belgelerin artık Fenergo’da incelemeye hazır olduğunu gösterir. Genellikle vaka durumu 'Belgeler alındı' veya 'İnceleme bekliyor' olarak güncellendiğinde anlaşılır. | ||
| Neden önemli? Bu aşama, müşterinin bekleme süresinin sonunu ve kurum içi inceleme döngüsünün başlangıcını gösterir. Müşterinin yanıt süresini ve kurum içi işlem kuyruğunda geçen süreyi ölçmek için önemlidir. Nereden alınır? Vaka denetim kaydından, durumun 'Belgeler alındı' veya benzer bir duruma geçtiği zaman damgası alınarak anlaşılır. Belge yükleme olaylarıyla da ilişkilendirilebilir. Kaydedin 'Belgeler alındı' veya 'İncelemeye hazır' durumuna geçişin zaman damgasını belirleyin. Olay türü inferred | |||
| Ek bilgi istendi | Bu etkinlik, müşteri kabul ekibinin açıklama almak veya eksik belgeleri tamamlatmak için müşteriye yeniden başvurması gereken bir yeniden çalışma döngüsünü gösterir. Genellikle müşteriye ileti gönderildiğinde açık bir olay olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik, süreç verimsizliğinin ve kötü müşteri deneyiminin başlıca göstergelerindendir. Sıklığını izlemek, yeniden çalışmanın temel nedenlerini belirlemeye ve 'Yeniden çalışma döngüsü oranı' KPI’ını takip etmeye yardımcı olur. Nereden alınır? Müşteri iletişimlerine ait bir Event Logdan veya 'Ek bilgi bekleniyor' durumuna geçişten alınır. İlk yöntem, talebin tam olarak ne zaman yapıldığını daha doğru gösterir. Kaydedin Kaydedilmiş iletişim olaylarını veya 'Müşteri yanıtı bekleniyor' durumuna geçişi bulun. Olay türü explicit | |||
| Geçmiş kontrolleri başlatıldı | Bu etkinlik, harici geçmiş, kara para aklamayı önleme (AML) veya kredi kontrollerinin başlatıldığı noktayı gösterir. Genellikle üçüncü taraf bir hizmetle entegrasyon çağrıldığında açık bir olay olarak kaydedilir. | ||
| Neden önemli? Bu kontrollerin başlatılmasını ve tamamlanmasını izlemek, harici bağımlılıklardan kaynaklanan gecikmeleri anlamak için önemlidir. Kurum içi süreç süresini harici bekleme süresinden ayırmaya yardımcı olur. Nereden alınır? Genellikle harici tarama sağlayıcılarına yapılan API çağrılarını kaydeden sistem günlüklerinden veya Fenergo vakasında belirli bir 'Geçmiş kontrolü' görevinin oluşturulmasından alınır. Kaydedin Harici hizmet entegrasyonlarının günlüklerini veya bir 'Tarama' görevinin oluşturulmasını bulun. Olay türü explicit | |||
| Hesap etkinleştirildi | Müşteri hesabının, onaydan sonra ana bankacılık sisteminde veya ilgili alt sistemde başarıyla oluşturulup etkinleştirildiğini belirtir. Bu durum, Fenergo’da onay sonrasında kaydedilen son durum güncellemesinden çıkarılabilir. | ||
| Neden önemli? Bu etkinlik, müşteri kabul sürecinden etkin müşteri durumuna başarılı devir teslimi doğrular. Onay ile etkinleştirme arasındaki süreyi ölçmek, operasyonel kurulumdaki gecikmeleri ortaya çıkarabilir. Nereden alınır? Bu durum, 'Hesap etkin' veya 'Müşteri kabulü tamamlandı' gibi bir vaka durumundan çıkarılabilir. Ayrıca alt sistemle entegrasyon tarafından kaydedilen açık bir olay da olabilir. Kaydedin Onay sonrasında gerçekleşen bir durum değişikliğini veya entegrasyon başarı kaydını arayın. Olay türü inferred | |||
| İlk tarama yapıldı | Temel veri doğrulama veya yaptırım listesi taraması gibi ilk otomatik ya da manuel kontrollerin tamamlandığını gösterir. Genellikle Fenergo vaka iş akışındaki bir durum değişikliğinden anlaşılır; örneğin durumun 'Yeni' iken 'Tarama tamamlandı' olarak değişmesi. | ||
| Neden önemli? Bu erken aşamanın izlenmesi, ilk veri kalitesi sorunlarını ve ön yeterlilik aşamasındaki darboğazları belirlemeye yardımcı olur. İlk otomatik aşamayı daha yoğun manuel inceleme süreçlerinden ayırır. Nereden alınır? Vaka geçmişi veya denetim günlüğünde, vaka durumunun taramanın tamamlandığını gösteren bir duruma geçtiği zaman damgası belirlenerek anlaşılır. Bu durum 'Tarama başarılı' veya 'Belgeler bekleniyor' olabilir. Kaydedin Vaka geçmişinde 'Tarama tamamlandı' veya benzer bir durum değişikliğini belirleyin. Olay türü inferred | |||
| Veri ve belgeler istendi | Bu olay, sistemin veya müşteri kabul temsilcisinin müşteriden gerekli bilgi ve belgeleri resmen istediğini gösterir. Genellikle standart bir iletişim Templatei gönderildiğinde açık bir olay olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik, müşteriye bağlı aşamanın başlangıcını gösterir. Müşteri yolculuğunu analiz etmek ve iletişim gecikmelerini belirlemek için bu noktadan belgelerin alınmasına kadar geçen süreyi ölçmek önemlidir. Nereden alınır? Müşteri iletişimleriyle ilişkili bir Event Logdan veya 'Belge iste' görevinin tamamlanma kaydından alınır. 'Müşteri bilgisi bekleniyor' durumuna geçişten de anlaşılabilir. Kaydedin Müşteri iletişimi için kaydedilmiş bir olay veya tamamlanmış bir görev arayın. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Raporlama modülüne erişin: Raporlama ve Analitik modülünü kullanmak için yeterli izne sahip bir kullanıcı hesabıyla Fenergo uygulamasında oturum açın. Genellikle ana uygulama menüsünde bulunan modüle gidin.
- Yeni bir rapor oluşturun: Yeni bir özel rapor oluşturmayı başlatın. Amacını açıkça belirten bir ad ve açıklama seçin. Örneğin, 'Process Mining için KYC işe alım olay günlüğü'.
- Birincil veri kaynağını tanımlayın: Vaka yaşam döngüsü bilgilerini içeren temel veri nesnesini veya görünümü seçin. Bu genellikle
[CaseWorkflowHistory]ya da[LifecycleEventsView]gibi önceden yapılandırılmış bir görünümdür. Bu nesnede vaka tanımlayıcıları, olay adları veya durumları ve zaman damgaları bulunmalıdır. - Rapor sütunlarını yapılandırın (öznitelikler): Sütun eklemek için rapor oluşturucu arayüzünü kullanın. Fenergo veri modelindeki kaynak alanları, gerekli olay günlüğü öznitelikleriyle eşleştirin. Örneğin, Fenergo’daki
CaseIDalanınıCustomerApplication,EventTimestampalanınıEventStartTimeveEventPerformeralanınıInitiatingUserile eşleştirin. - Etkinlik mantığını oluşturun: Bu, en önemli adımdır. Rapor, gerekli 14 etkinliğin her biri için ayrı bir satır oluşturacak şekilde yapılandırılmalıdır. Bunun için her etkinliğe özel mantıksal bloklar veya filtrelenmiş veri kümeleri oluşturun ve rapor oluşturucuda bunları UNION ya da eşdeğer bir işlevle birleştirin.
- 'Vaka oluşturuldu' mantığını tanımlayın: İlk bloğu oluşturun. Veri kaynağını, vakanın ilk oluşturulma olayına göre filtreleyin. Bu genellikle vakayla ilişkili en erken zaman damgasına veya 'Vaka oluşturuldu' adlı bir olay türüne dayanır.
CreationDatealanınıEventStartTimeile eşleştirin. - Duruma dayalı etkinlik mantığını tanımlayın: Durum değişikliklerinden çıkarılan etkinlikler (ör. 'Belgeler alındı', 'Başvuru onaylandı') için ayrı bloklar oluşturun. Veri kaynağını ilgili
Durumalanı değerine göre filtreleyin veStatusChangeDatealanınıEventStartTimeolarak kullanın. - Göreve dayalı etkinlik mantığını tanımlayın: İş akışı görevleriyle ilişkili etkinlikler (ör. 'Uyumluluk incelemesi tamamlandı') için
TaskNameveTaskCompletionDatealanlarına göre filtrelenen bloklar oluşturun. Tamamlanma tarihiniEventStartTimeolarak kullanın. - Genel rapor filtrelerini ayarlayın: Verileri kapsamlandırmak için rapor düzeyinde filtreler uygulayın. Aşırı büyük dışa aktarımları önlemek için
EventStartTimealanına belirli birDate Rangebelirleyin. İlk analiz için 3 ila 6 aylık bir dönem önerilir. 'KYC müşteri işe alımı' gibi belirli vaka türlerine göre filtreleyin. - Raporu çalıştırıp önizleyin: Raporu Fenergo arayüzünde çalıştırın. Veri yapısının doğru olduğunu, tüm sütunların beklendiği gibi doldurulduğunu ve farklı etkinliklerin yer aldığını doğrulamak için ilk 100-200 satırı önizleyin.
- Verileri dışa aktarın: Raporun tüm sonuçlarını CSV veya Excel dosyasına aktarın. Bu, ham olay günlüğü dosyasıdır.
- Verileri son kez hazırlayın: Dışa aktarılan CSV dosyasını açın.
SourceSystemveLastDataUpdatesütunları doğrudan raporla oluşturulamadıysa bunları elle ekleyin. Tüm satırlardaSourceSystemdeğerini 'Fenergo',LastDataUpdatedeğerini ise dışa aktarma zaman damgası olarak ayarlayın.
Yapılandırma
- Ön koşullar: Kullanıcının özel raporlar oluşturup çalıştırma izniyle Fenergo Raporlama ve Analitik modülüne erişmesi gerekir.
- Temel veri kaynakları: Rapor öncelikle Fenergo’nun vaka yönetimi ve iş akışı geçmişi nesnelerinden oluşturulmalıdır. Yaygın kaynaklar arasında
[CaseDetails],[CaseStatusHistory]ve[WorkflowTaskHistory]bulunur. Adlar, Fenergo yapılandırmanıza göre değişebilir. - Tarih aralığı: Performansı yönetmek için olay zaman damgasına tarih aralığı filtresi uygulamak önemlidir. Son 3 ila 6 aylık dönemle başlayın. Geçmiş verileri analiz etmek için raporu gruplar halinde çalıştırın (ör. üç aylık veya yıllık dönemler).
- Temel filtreler: İlgisiz verileri dışarıda bırakmak için her zaman 'KYC müşteri işe alımı' gibi belirli bir sürece veya vaka türüne göre filtreleyin. Analiz hedeflerinize bağlı olarak tüzel kişi türüne ya da yargı alanına göre de filtreleme yapmanız gerekebilir.
- Etkinlik tanımı: Her etkinlik,
Durum,TaskNameveya özel birEventTypealanı gibi alanlara uygulanan belirli filtre ölçütleriyle tanımlanmalıdır. Süreçteki her bir olayı ayrı ayrı belirlemek için bu alanları kullanmak önemlidir. - Performansla ilgili noktalar: Birden fazla veri kaynağını birleştiren veya geniş bir tarih aralığını tarayan raporlar yavaş çalışabilir. Mümkünse raporu yoğun olmayan saatlerde çalışacak şekilde planlayın. Dışa aktarıma gereksiz sütunlar eklemeyin, çünkü bunlar işlem süresini artırır.
Örnek sorgu 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]' Başlamaya hazır mısınız?
Bu veri şablonundan yararlanarak Fenergo’daki KYC müşteri işe alım sürecinizdeki verimsizlikleri ortaya çıkarmaya ve süreci kolaylaştırmaya bir adım daha yaklaşın. Operasyonlarınızı iyileştirmeye ve müşteri memnuniyetini artırmaya bugün başlayın.
KYC müşteri işe alım sürecini kolaylaştırın, onayları hızlandırın
İşe alım süresini yalnızca 24 saate indiren işletmelere katılın.
Kredi kartı gerekmez. Dakikalar içinde başlayın.