Hasar taleplerinin işlenmesi için Veri Templateiniz
Hasar taleplerinin işlenmesi için Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Salesforce Financial Services Cloud’dan veri çıkarma yönergeleri
Hasar taleplerinin işlenmesine ilişkin öznitelikler
| Ad | Açıklama | ||
|---|---|---|---|
|
Hasar Talebi Kimliği
ClaimId
|
Her sigorta talebine verilen ve süreç analizinde temel vaka kimliği olarak kullanılan benzersiz tanımlayıcı. | ||
|
Açıklama
Hasar Talebi Kimliği, başvurudan kapanışa kadar tek bir sigorta talebine ait tüm etkinlikleri, olayları ve veri noktalarını birbirine bağlayan temel vaka tanımlayıcısıdır. Process Mining çalışmalarında bu öznitelik, her talebin baştan sona izlediği yolu yeniden oluşturmak için gereklidir. İlişkili tüm olayları tek bir vakada bir araya getirerek çevrim sürelerini, süreç varyantlarını ve münferit taleplerdeki darboğazları analiz etmenizi sağlar.
Neden önemli?
Bu, bir hasar talebinin yaşam döngüsünü izlemek için gereken temel anahtardır. Benzersiz bir Hasar Talebi Kimliği olmadan farklı süreç adımlarını analiz edilebilir, tutarlı bir akışta birleştirmek mümkün değildir.
Nereden alınır?
Bu değer genellikle Case nesnesindeki 'CaseNumber' alanında veya 'Claim' (FinancialServicesCloud.Claim) nesnesindeki özel benzersiz kimlik alanında bulunur.
Örnekler
CL-00012345CL-00012346CL-00012347
|
|||
|
Etkinlik Adı
ActivityName
|
Hasar talebinin yaşam döngüsünde belirli bir anda gerçekleşen iş etkinliğinin veya olayın adı. | ||
|
Açıklama
Bu öznitelik, 'Claim Submitted', 'Initial Review Performed' veya 'Payment Issued' gibi hasar sürecindeki tek bir adımı ya da kilometre taşını tanımlar. Süreç haritasının temelini oluşturur. Etkinliklerin sırasını ve sıklığını analiz ederek en yaygın süreç yollarını (varyantları) belirleyebilir, standart süreçten sapmaları bulabilir ve yeniden çalışmaya işaret eden sık tekrarlanan etkinlikleri saptayabilirsiniz.
Neden önemli?
Süreçte 'ne' olduğunu tanımlar; süreç akışını görselleştirmenizi, darboğazları, yeniden çalışma döngülerini ve süreç farklılıklarını belirlemenizi sağlar.
Nereden alınır?
Claim/Case nesnesindeki 'Status' alanı değişikliklerinden veya ilişkili Task ya da Event kayıtlarının 'Subject' alanından elde edilir.
Örnekler
Hasar bildirimi alındıİlk inceleme tamamlandıEk bilgi istendiHasar Talebi Kapatıldı
|
|||
|
Kaynak sistem
SourceSystem
|
Olay verilerinin kaydedildiği kaynak sistemi belirtir. | ||
|
Açıklama
Bu öznitelik, verilerin alındığı kaynak uygulamayı veya platformu belirtir. Bu süreçte değer her zaman 'Salesforce Financial Services Cloud' olur. Değeri sabit görünse de, özellikle birden fazla sistemden veri alınan ortamlarda kaynak sistemi açıkça izlemek iyi bir uygulamadır. Verinin nereden geldiğini netleştirir; veri yönetişimi ve doğrulama çalışmalarına yardımcı olur.
Neden önemli?
Verinin kaynağını doğrular. Bu bilgi, veri yönetişimi ve sorun giderme çalışmalarının yanı sıra birden fazla kurumsal sistemden veri alırken de önemlidir.
Nereden alınır?
Genellikle veri çıkarma ve dönüştürme sırasında eklenen sabit bir değerdir; veri setinin kaynağını belirtir.
Örnekler
Salesforce Financial Services Cloud
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Olay Zamanı, hasar talebinin yaşam döngüsündeki her etkinliğin kesin tarih ve saatini verir. Bu zaman verisi, olayları kronolojik sıraya koymak ve süreleri hesaplamak için gereklidir. Analizde zaman damgaları; etkinlikler arasındaki çevrim süreleri, bekleme süreleri ve toplam vaka süresi dâhil olmak üzere zamanla ilgili tüm metrikleri hesaplamak için kullanılır. Dinamik bir süreç animasyonu oluşturmanın, gecikmelerin ne zaman ve nerede yaşandığını belirlemenin temelini oluşturur.
Neden önemli?
Bu öznitelik, her olayın 'ne zaman' gerçekleştiğini gösterir. Böylece süreleri hesaplayabilir, süreç performansını zaman içinde analiz edebilir ve zamana bağlı darboğazları belirleyebilirsiniz.
Nereden alınır?
Durum değişikliklerinde nesnenin alan geçmişindeki 'CreatedDate' (ör. CaseHistory) kullanılır. Görevlerde ise 'CompletedDateTime' veya 'CreatedDate' kullanılır.
Örnekler
2023-04-15T10:22:05Z2023-04-16T14:05:10Z2023-04-18T09:00:00Z
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemden en son veri yenileme veya çıkarma işleminin zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin Salesforce Financial Services Cloud üzerinden en son alındığı tarih ve saati gösterir. Analiz edilen verilerin ne kadar güncel olduğunu anlamanıza yardımcı olur. Dashboard kullanıcılarının analizlerin güncelliğini bilmesi önemlidir. Verilerin ne kadar yeni olduğuna ilişkin beklentileri yönetmeye ve veri hatlarının planlandığı gibi çalıştığını doğrulamaya yardımcı olur.
Neden önemli?
Verilerin güncelliğini anlamak için gerekli bağlamı sunar; analistlerin ve iş kullanıcılarının süreç görünümünün ne kadar güncel olduğunu bilmesini sağlar.
Nereden alınır?
Bu değer, veri çıkarma aracı veya ETL süreci çalıştığı sırada oluşturulur ve veri setine eklenir.
Örnekler
2023-10-27T02:00:00Z
|
|||
|
Atanan Eksper
AssignedAdjuster
|
Hasar talebini yürütmekle sorumlu kullanıcı veya eksperin adı. | ||
|
Açıklama
Bu öznitelik, bir etkinlikten veya vakanın tamamından sorumlu hasar eksperini belirtir. Genellikle hasar talebi vakasının sahibinden ya da belirli bir görevi tamamlayan kişiden elde edilir. Eksper bazında performans analizi, operasyon yönetimi açısından önemlidir. 'Adjuster Workload & Performance' gibi Dashboardlar bu özniteliği kullanarak kişi başına talep hacmini, açık vakaları ve çevrim sürelerini izler. Böylece iş yükünün dengeli dağıtılmasına ve koçluk fırsatlarının belirlenmesine yardımcı olur.
Neden önemli?
Ekip ve kişi performansını analiz etmek, iş yüklerini yönetmek, iyi uygulamaları ve eğitim ihtiyaçlarını belirlemek için gereklidir.
Nereden alınır?
Case veya Claim nesnesindeki 'OwnerId' alanıdır. Eksperin adını almak için User nesnesine bağlanır.
Örnekler
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
Başvuru Kanalı
SubmissionChannel
|
Hasar talebinin ilk iletildiği yöntem veya kanal. | ||
|
Açıklama
Bu öznitelik, hasar talebinin ilk olarak nasıl bildirildiğini gösterir. Örneğin web portalı, mobil uygulama, telefon veya e-posta kullanılabilir. Başvuru kanalı, ilk bilgilerin kalitesini ve sonraki işlem adımlarını önemli ölçüde etkileyebilir. Hasar taleplerini başvuru kanalına göre analiz etmek, talep eğilimlerini ve farklı başvuru yöntemlerinin verimliliğini anlamaya yardımcı olur. 'Claims Throughput & Volume' Dashboardu, her kanaldan zaman içinde kaç talep geldiğini izlemek için bu özniteliği kullanır. Bu veriler, kaynak dağılımı ve teknoloji yatırımlarıyla ilgili kararlara yön verebilir.
Neden önemli?
Farklı başvuru kanallarının verimliliğini değerlendirmenize ve belirli kanalların daha fazla yeniden çalışmaya ya da daha uzun çevrim sürelerine yol açıp açmadığını anlamanıza yardımcı olur.
Nereden alınır?
Genellikle Claim/Case nesnesindeki, 'Origin' veya 'Channel' olarak adlandırılan özel bir seçim listesi alanıdır.
Örnekler
Web PortalıMobil UygulamaTelefonE-posta
|
|||
|
Bitiş Zamanı
EndTime
|
Bir etkinliğin tamamlandığı anı gösteren zaman damgası. Süreleri hassas biçimde hesaplamak için kullanılır. | ||
|
Açıklama
Bitiş Zamanı özniteliği, bir etkinliğin tamamlandığı kesin anı kaydeder. Başlangıç Zamanı (EventTime) başlangıcı gösterirken Bitiş Zamanı, etkinliğin ne kadar sürdüğünü ölçmek için gereken diğer sınırı belirtir. Analizde hem Başlangıç Zamanı hem de Bitiş Zamanı bulunduğunda, etkinliklerin işlem süreleri hassas biçimde hesaplanabilir ve bunlar etkinlikler arasındaki bekleme sürelerinden ayrılabilir. Bu, 'Process Step Duration Breakdown' gibi Dashboardlar oluşturmak ve yalnızca etkinlikler arasındaki değil, belirli görevlerdeki verimsizlikleri de saptamak için gereklidir.
Neden önemli?
Her etkinliğin fiilî işlem süresini hassas biçimde hesaplamanızı sağlar. Katma değer yaratan süreyi bekleme süresinden ayırmak için önemlidir.
Nereden alınır?
Zaman damgası verilerinden elde edilir. Örneğin, 'Initial Review Performed' bir durum değişikliğiyle tetikleniyorsa EndTime olarak bir sonraki durum değişikliğinin zaman damgası kullanılabilir.
Örnekler
2023-04-15T11:05:30Z2023-04-16T17:20:00Z2023-04-18T09:45:12Z
|
|||
|
Departman
Department
|
Hasar talebini yürütmekten sorumlu kurum içi departman veya ekip. | ||
|
Açıklama
Bu öznitelik, hasar talebinin atandığı iş birimini veya departmanı belirtir. Örnekler arasında 'Personal Lines', 'Commercial Auto' ve 'Special Investigations Unit' bulunur. Süreci departman bazında analiz etmek, ekipler arasındaki performans farklarını görmeye, iş yüklerinin nasıl dağıldığını anlamaya ve departmana özgü süreç sapmalarını veya darboğazları belirlemeye yardımcı olur. Kuruluşun farklı birimlerinin performansını görmek için 'Claim SLA Compliance Overview' gibi Dashboardlarda kullanılır.
Neden önemli?
Farklı iş birimlerinin performansını karşılaştırmanızı, iyi uygulamaları belirlemenizi ve kaynakları daha verimli dağıtmanızı sağlar.
Nereden alınır?
Claim/Case nesnesindeki özel bir alan olabilir veya User nesnesindeki atanmış kullanıcının profili ya da rolünden çıkarılabilir.
Örnekler
Bireysel Araç Hasar TalepleriTicari MülkDolandırıcılık İnceleme Birimi
|
|||
|
Hasar Talebi Durumu
ClaimStatus
|
Olayın gerçekleştiği sırada hasar talebinin mevcut durumu (ör. Open, Under Review, Closed). | ||
|
Açıklama
Hasar Talebi Durumu, talebin yaşam döngüsündeki yerini 'New', 'Investigation', 'Pending Customer' veya 'Closed' gibi değerlerle gösterir. Sürecin mevcut durumunu anlamak için önemli bir özniteliktir. Bu öznitelik, mevcut iş yükünü görselleştirmek ve belirli bir durumda gereğinden uzun süre bekleyen talepleri belirlemek için 'Open Claims Ageing Report' gibi operasyonel Dashboardlarda yoğun biçimde kullanılır. Durumlar arasındaki geçişleri analiz etmek de süreç haritasındaki etkinlikleri tanımlamanın temel yollarından biridir.
Neden önemli?
Açık hasar taleplerinin mevcut durumunu anlık olarak görmenizi sağlar; birikmiş işleri yönetmeye ve ilerlemeyen vakaları belirlemeye yardımcı olur.
Nereden alınır?
Case veya Claim nesnesindeki standart 'Status' alanıdır.
Örnekler
KaydedildiİnceleniyorUzlaşma Teklifi SunulduKapandı - ÖdendiKapandı - Reddedildi
|
|||
|
Hasar Talebi Türü
ClaimType
|
Otomobil, konut veya sorumluluk gibi sigorta talebinin kategorisi. | ||
|
Açıklama
Hasar Talebi Türü, hasar sürecini gruplandırmak ve analiz etmek için önemli bir boyuttur. Farklı talep türleri genellikle farklı süreçlerden geçer, farklı karmaşıklık düzeylerine sahiptir ve farklı SLA’lara tabidir. Analistler, Hasar Talebi Türüne göre filtreleme veya performans karşılaştırması yaparak türe özgü darboğazları ortaya çıkarabilir, belirlenen SLA’lara uyumluluğu değerlendirebilir ve süreç farklılıklarının kategorilere göre nasıl değiştiğini anlayabilir. Daha hedefli içgörüler sunmak için 'Claim SLA Compliance Overview' ve 'Claim Rejection Reason Analysis' gibi Dashboardlarda kullanılır.
Neden önemli?
Hasar taleplerini gruplandırarak süreçleri karşılaştırmanızı, türe özgü sorunları belirlemenizi ve iyileştirme çalışmalarını ihtiyaca göre şekillendirmenizi sağlar.
Nereden alınır?
Genellikle Case veya Claim nesnesindeki standart 'Type' alanı ya da özel bir seçim listesi alanıdır.
Örnekler
OtomobilKonutTicari MülkGenel Sorumluluk
|
|||
|
Toplam Hasar Talebi Tutarı
TotalClaimAmount
|
Poliçe sahibinin başlangıçta talep ettiği toplam parasal tutar. | ||
|
Açıklama
Bu öznitelik, müşterinin sürecin başında talep ettiği toplam hasar veya zarar tutarını gösterir. Bu tutar, talebin karmaşıklığını, gereken inceleme düzeyini ve izlenecek işlem yolunu etkileyebilir. Hasar talebi tutarına göre süreç metriklerini analiz etmek önemli örüntüleri ortaya çıkarabilir. Örneğin, yüksek tutarlı taleplerin çevrim süresi daha uzun olabilir, daha fazla adım içerebilir veya uzman ekiplere yönlendirilebilir. Bu analiz, gerçekçi SLA’lar belirlemeye ve finansal karşılıkları öngörmeye yardımcı olur.
Neden önemli?
Her vakaya finansal bağlam kazandırır; hasar talebi tutarının süreç karmaşıklığını, süresini ve sonuçlarını nasıl etkilediğini analiz etmenizi sağlar.
Nereden alınır?
Financial Services Cloud içindeki Claim nesnesinde bulunan, örneğin 'ClaimedAmount__c' adlı özel bir para birimi alanı olabilir.
Örnekler
1500.0025000.50125.75
|
|||
|
Hasar Tarihi
LossDate
|
Hasar talebine yol açan olayın veya zararın gerçekleştiği tarih. | ||
|
Açıklama
Hasar Tarihi, sigorta poliçesi kapsamındaki olayın ne zaman gerçekleştiğini kaydeder. Hasar talebinin iletildiği tarihten farklıdır. Bu öznitelik, uyumluluk ve olayın gerçekleşmesiyle bildirilmesi arasındaki süreyi analiz etmek açısından önemlidir. Aradaki uzun süreler olası sorunlara işaret edebilir veya farklı işlem yöntemleri gerektirebilir. Olayların zaman çizelgesini bütünüyle anlamak için değerli bir bağlam sunar.
Neden önemli?
Olayın gerçekleşmesiyle bildirilmesi arasındaki süreyi analiz etmeye yardımcı olur. Bu süre, inceleme ve uzlaşma sürecini etkileyebilir.
Nereden alınır?
Claim nesnesindeki, örneğin 'DateOfLoss__c' adlı özel bir tarih alanı olabilir.
Örnekler
2023-04-122023-05-202023-06-01
|
|||
|
Konum
Location
|
Hasar talebi veya poliçeyle ilişkili coğrafi konum (ülke, eyalet ya da bölge). | ||
|
Açıklama
Bu öznitelik, hasarın meydana geldiği eyalet veya poliçe sahibinin ülkesi gibi, hasar talebine ilişkin coğrafi bağlamı gösterir. Bu veri, poliçe sahibinin adresinden ya da hasar ayrıntılarından elde edilebilir. Coğrafi analiz, hasar türleri, sıklıkları ve işlem sürelerindeki bölgesel eğilimleri ortaya çıkarabilir. Ayrıca farklı bölge ofislerinin performansını değerlendirmek ve konuma özgü düzenlemelere uyumu sağlamak için kullanılabilir.
Neden önemli?
Hasar taleplerinin coğrafi analizini sağlar; bölgesel performans farklılıklarını, dolandırıcılık örüntülerini veya yerel olayların etkilerini ortaya çıkarabilir.
Nereden alınır?
Genellikle ilgili Account veya Contact nesnesindeki adres alanlarından (ör. 'BillingState', 'BillingCountry') elde edilir.
Örnekler
USAKaliforniyaBirleşik Krallık
|
|||
|
Müşteri Kimliği
CustomerId
|
Hasar talebini ileten müşterinin veya poliçe sahibinin benzersiz tanımlayıcısı. | ||
|
Açıklama
Müşteri Kimliği, hasar talebini başvuruyu yapan kişi veya kuruluşa bağlar. Salesforce’ta bu genellikle Account veya Contact nesnesine yönelik bir arama alanıdır. Bu öznitelik, hasar sürecini müşteri odaklı biçimde görmenizi sağlar. Müşteri başına hasar geçmişini analiz etmek, sık başvuru yapan müşterileri belirlemek ve hizmeti kişiselleştirmek için kullanılabilir. Ayrıca bütünsel bir iş görünümü elde etmek amacıyla hasar talebi verilerini CRM’deki diğer müşteri verileriyle birleştirmek için de gereklidir.
Neden önemli?
Müşteri odaklı analiz yapmanızı sağlar; bireysel müşterilerin hasar örüntülerini anlamaya ve hasar sürecinin müşteri ilişkilerine etkisini ölçmeye yardımcı olur.
Nereden alınır?
Claim/Case nesnesinde bulunan ve Account veya Contact nesnesine işaret eden bir arama alanıdır (ör. 'AccountId' veya 'ContactId').
Örnekler
0018d00000abcdeFAA0018d00000fghijKLM0018d00000mnopqrSTU
|
|||
|
Otomatik mi
IsAutomated
|
Etkinliğin bir kullanıcı yerine otomatik bir sistem tarafından gerçekleştirilip gerçekleştirilmediğini belirten mantıksal değer. | ||
|
Açıklama
Bu gösterge, insan eksperlerin tamamladığı görevlerle otomatik iş akışları, kurallar veya sistem entegrasyonları tarafından yürütülenleri birbirinden ayırır. Örneğin, ilk hasar kaydı tamamen otomatik olarak oluşturulabilir. Otomasyonun analizi, süreç verimliliğini anlamak açısından önemlidir. Otomasyon girişimlerinin başarısını ölçmeye, gelecekte otomatikleştirilebilecek adımları belirlemeye ve otomatik görevlerin hızını ve tutarlılığını manuel görevlerle karşılaştırmaya yardımcı olur.
Neden önemli?
İnsanlar tarafından yürütülen etkinliklerle sistemlerin yürüttüklerini ayırır; otomasyonun etkisini ve verimliliğini değerlendirmek için önemlidir.
Nereden alınır?
Bu değer genellikle türetilir. Bir olayla ilişkili kullanıcı genel bir 'System' veya 'Integration' kullanıcısıysa bu gösterge true olarak ayarlanır.
Örnekler
truefalse
|
|||
|
Poliçe Numarası
PolicyNumber
|
Hasar talebiyle ilişkili sigorta poliçesinin benzersiz tanımlayıcısı. | ||
|
Açıklama
Poliçe Numarası, hasar talebini müşterinin etkin sigorta poliçesine bağlar. Teminat, limitler ve poliçe sahibinin geçmişi hakkında gerekli bağlamı sunar. Süreç akışını her zaman doğrudan etkilemese de önemli bir bağlam verisidir. Daha ayrıntılı analiz için hasar talebi verilerini poliçe verileriyle birleştirmekte kullanılabilir. Örneğin, belirli poliçe türlerinin daha sık veya daha karmaşık taleplerle ilişkili olup olmadığını anlamaya yardımcı olur.
Neden önemli?
Hasar talebini ilgili sigorta poliçesine bağlar. Böylece belirli poliçeler veya teminat türleriyle ilişkili hasar örüntülerini daha geniş kapsamda analiz edebilirsiniz.
Nereden alınır?
Financial Services Cloud içindeki 'InsurancePolicy' nesnesine başvuran, Claim nesnesindeki bir arama alanı olabilir.
Örnekler
POL-987654321POL-123456789POL-555444333
|
|||
|
Ret Nedeni
ReasonForRejection
|
Hasar talebi reddedildiğinde belirtilen özel neden. | ||
|
Açıklama
Hasar talebinin nihai kararı 'Rejected' olduğunda bu öznitelik, 'Not Covered by Policy', 'Fraud Suspected' veya 'Incomplete Information' gibi ret nedenini belirtir. Bu, 'Claim Rejection Reason Analysis' Dashboardu için temel özniteliktir. Kuruluş, farklı ret nedenlerinin sıklığını genellikle talep türüne veya departmana göre gruplandırarak analiz edebilir. Böylece sigorta kabul sürecini iyileştirme, poliçe metinlerini netleştirme veya geçersiz başvuruları azaltmak için bilgi toplama sürecini geliştirme fırsatlarını belirleyebilir.
Neden önemli?
Hasar taleplerinin neden reddedildiğini doğrudan gösterir. Sigorta kabul politikalarını iyileştirmek ve geçersiz taleplerin işlenmesiyle oluşan kaybı azaltmak için gereklidir.
Nereden alınır?
Genellikle Claim/Case nesnesinde bulunan ve durum 'Rejected' veya 'Closed - Denied' olarak değiştirildiğinde doldurulması zorunlu olan özel bir seçim listesi alanıdır.
Örnekler
Teminat Süresi DolduHasar Teminat Kapsamında DeğilDolandırıcılık ŞüphesiMükerrer Hasar Talebi
|
|||
|
SLA durumu
SlaStatus
|
Hasar talebinin tanımlı Hizmet Seviyesi Anlaşması (SLA) içinde çözümlenip çözümlenmediğini belirtir. | ||
|
Açıklama
Bu öznitelik, genellikle 'Karşılandı' veya 'Aşıldı' gibi değerler alan kategorik bir sonuçtur. Hasar talebinin gerçek tamamlanma tarihi (son etkinliğin zaman damgası), 'SlaTargetDate' ile karşılaştırılarak belirlenir. 'SLA Hedefine Uyum Oranı' KPI’ının ve 'Hasar SLA Uyumluluğu Genel Bakışı' Dashboardının temel metriğidir. Hedeflere göre performansı açıkça gösterir; uyumluluk raporlaması ve operasyon yönetimi için gereklidir.
Neden önemli?
Zaman hedeflerine göre performansı açıkça gösterir; müşteri memnuniyeti ve mevzuata uyum açısından önemlidir.
Nereden alınır?
Hesaplanan alan: Son olayın 'EndTime' değeri 'SlaTargetDate' değerinden küçük veya ona eşitse 'Karşılandı', değilse 'Aşıldı' olarak belirlenir. Bu mantık, veri dönüştürme sırasında veya Process Mining aracı içinde uygulanır.
Örnekler
KarşılandıAşıldı
|
|||
|
SLA Hedef Tarihi
SlaTargetDate
|
Hizmet seviyesi anlaşmalarına göre hasar talebinin sonuçlandırılmasının beklendiği son tarih. | ||
|
Açıklama
SLA Hedef Tarihi, hasar talebinin sonuçlandırılması için belirlenen son tarihi gösteren, hesaplanmış veya elle girilmiş bir tarihtir. Zamanında tamamlanma performansı bu tarihe göre ölçülür. Bu öznitelik, müşterilere veya düzenleyici kurumlara verilen taahhütlerin yerine getirilip getirilmediğini izlemek için gereklidir. 'SLA Adherence Rate' KPI’ının ve 'Claim SLA Compliance Overview' Dashboardunun temelini oluşturur. Kuruluş, taleplerin yüzde kaçının zamanında sonuçlandığını izleyebilir ve hedeflerini tutturmakta zorlanan talep türlerini veya departmanları belirleyebilir.
Neden önemli?
Hasar talebinin sonuçlandırılma süresi için performans hedefini belirler ve SLA uyumluluğunu doğrudan ölçmenizi sağlar.
Nereden alınır?
Genellikle Claim/Case nesnesindeki özel bir formül alanı veya tarih alanıdır. Başvuru tarihine ve hasar talebi türüne göre hesaplanır.
Örnekler
2023-05-15T23:59:59Z2023-06-20T23:59:59Z2023-07-01T23:59:59Z
|
|||
|
Uzlaşma Tutarı
SettlementAmount
|
Hasar talebi uzlaşmayla sonuçlandığında talepte bulunan kişiye ödenen nihai parasal tutar. | ||
|
Açıklama
Bu öznitelik, hasar talebi kapatılıp uzlaşma sağlandığında talepte bulunan kişiye fiilen ödenen tutarı kaydeder. Değerlendirme, muafiyetler ve poliçe limitleri nedeniyle bu tutar başlangıçta talep edilenden farklı olabilir. Özellikle başlangıçta talep edilen tutarla karşılaştırıldığında, uzlaşma tutarının analizi hasar değerlendirmesinin doğruluğu ve uzlaşma görüşmelerinin sonuçları hakkında bilgi verir. Hasar taleplerinin toplam maliyetini anlamak için önemli bir finansal metriktir.
Neden önemli?
Bir hasar talebinin nihai mali etkisini gösterir. Finansal analiz, karşılık ayırma ve ilk hasar değerlendirmelerinin doğruluğunu ölçme açısından önemlidir.
Nereden alınır?
Financial Services Cloud içindeki Claim nesnesinde veya ilişkili bir Payment nesnesinde bulunan özel bir para birimi alanı olabilir.
Örnekler
1450.0022500.000.00
|
|||
|
Vaka süresi
CaseDuration
|
Tek bir hasar talebindeki ilk olaydan son olaya kadar geçen toplam süre. Çevrim süresi olarak da bilinir. | ||
|
Açıklama
Bu metrik, bir hasar vakasının ilk başvurudan nihai kapanışa kadar geçen toplam süresini ölçer. Belirli bir Claim ID için son olayın zaman damgası ile ilk olayın zaman damgası arasındaki fark hesaplanır. Bu, süreç performansını ölçen en önemli KPI’lardan biridir. 'Ortalama Hasar Çevrim Süresi' KPI’ı ve 'Hasar Uçtan Uca Çevrim Süresi' Dashboardı bu metriği doğrudan ele alır. Süreç iyileştirme projelerinde bu değeri düşürmek çoğu zaman temel hedeflerden biridir.
Neden önemli?
Sürecin uçtan uca genel verimliliğini ölçer ve müşteri deneyiminin önemli göstergelerinden biridir.
Nereden alınır?
Hesaplanan alan: Her 'ClaimId' için son olayın zaman damgasından ilk olayın zaman damgası çıkarılır. Bu hesaplama Process Mining aracı tarafından yapılır.
Örnekler
30 gün 5 saat15 gün 10 saat90 gün 2 saat
|
|||
|
Yeniden çalışma mı
IsRework
|
Bir etkinliğin veya etkinlik dizisinin yeniden çalışmayı temsil edip etmediğini belirten mantıksal değer. | ||
|
Açıklama
Bir hasar talebi süreçte önceki bir aşamaya döndüğünde bu gösterge true olarak ayarlanır. Bunun tipik bir örneği, 'İnceleme tamamlandı' aşamasından 'Ek bilgiler istendi' aşamasına geri dönülmesidir. Yeniden çalışmayı belirleme mantığı, süreç bilgisine göre tanımlanır. Bu öznitelik, 'Hasar Taleplerinde Yeniden Çalışma Döngüsü Analizi' Dashboardı ve 'Yeniden Çalışma Oranı' KPI’ı için temel oluşturur. Verimsizliğin, artan maliyetlerin ve uzayan çevrim sürelerinin başlıca nedenlerinden biri olan yeniden çalışmanın sıklığını ve etkisini doğrudan ölçmeyi sağlar.
Neden önemli?
Verimsiz süreç döngülerini doğrudan işaretler; yeniden çalışmayı kolayca ölçmenizi ve temel nedenlerini hedefli biçimde analiz etmenizi sağlar.
Nereden alınır?
Hesaplanan alan. Her vaka için etkinlik dizisi analiz edilerek türetilir. Örneğin, 'Etkinlik A’nın ardından 'Etkinlik B' ve sonra yeniden 'Etkinlik A' geliyorsa, 'A’nın ikinci örneği yeniden çalışma sayılır.
Örnekler
truefalse
|
|||
Hasar taleplerinin işlenmesine ilişkin etkinlikler
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Ek bilgi istendi
|
Hasar uzmanının sigortalıdan veya üçüncü bir taraftan ek bilgi gerektiğine karar verdiği noktayı gösterir. Bu olay, durumun Müşteri bilgisi bekleniyor olarak değişmesinden veya ilişkili bir Task ya da EmailMessage kaydının oluşturulmasından çıkarılabilir. | ||
|
Neden önemli?
Bu etkinlik, yeniden çalışma döngülerini belirlemek açısından önemlidir. Bu olayın sık yaşanması, ilk veri toplama aşamasındaki sorunlara işaret eder ve süreçte gecikmelere, çevrim sürelerinin uzamasına yol açar.
Nereden alınır?
Claim nesnesinin Status alanının Bilgi bekleniyor durumuna değişmesinden çıkarılır. Alternatif olarak, belirli türde ilişkili bir Task veya EmailMessage kaydının oluşturulma tarihi kullanılabilir.
Kaydedin
Status alanının Bilgi bekleniyor durumuna değiştiği zaman damgası veya ilişkili iletişim kaydının oluşturulma zamanı.
Olay türü
inferred
|
|||
|
Hasar bildirimi alındı
|
Yeni bir hasar dosyasının Salesforce’a ilk kez girilmesiyle sürecin başladığını gösterir. Bu olay genellikle yeni bir Claim nesne kaydının oluşturulmasıyla yakalanır. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Bildirimden sonraki adıma kadar geçen süreyi analiz etmek, ilk kabul aşamasındaki gecikmeleri belirlemeye ve toplam çevrim süresini ölçmek için başlangıç noktası oluşturmaya yardımcı olur.
Nereden alınır?
Claim standart nesnesindeki CreatedDate zaman damgasından alınır. Bu, her hasar dosyası için kesin ve güvenilir bir başlangıç noktası sağlar.
Kaydedin
Claim nesnesi kaydının oluşturulma zaman damgası.
Olay türü
explicit
|
|||
|
Hasar Talebi Hakkında Karar Verildi
|
Hasar talebinin onaylanması veya reddedilmesi yönündeki resmî kararı ifade eder. 'Approved' veya 'Rejected' gibi nihai bir duruma geçişten çıkarılan bu kilometre taşı önemlidir. | ||
|
Neden önemli?
Sonraki süreç yolunu belirleyen önemli bir karar noktasıdır. Karara kadar geçen süreyi analiz etmek, eksper verimliliğini ve SLA uyumluluğunu ölçmek için temel bir KPI’dır.
Nereden alınır?
'Claim' nesnesindeki 'Status' alanının karar durumuna (ör. 'Approved', 'Rejected') değiştiği zaman damgasından çıkarılır ve Field History Tracking ile kaydedilir.
Kaydedin
'Status' alanının 'Approved' veya 'Rejected' olarak değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Hasar Talebi Kapatıldı
|
Ödeme dâhil tüm etkinlikler tamamlandıktan sonra hasar talebinin sistemde başarıyla sonuçlandırıldığını gösterir. 'Claim' nesnesindeki son durum değişikliğinin 'Closed' olmasıyla kaydedilir. | ||
|
Neden önemli?
Sürecin başarıyla tamamlandığını gösteren temel son olaydır. Baştan sona çevrim süresini hesaplamak ve genel süreç hacmini ölçmek için gereklidir.
Nereden alınır?
'Claim' nesnesinin 'Status' alanındaki Field History Tracking verilerinden çıkarılır ve durumun 'Closed' olarak değiştiği zaman damgasını kaydeder.
Kaydedin
'Status' alanının 'Closed' olarak değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
İlk inceleme tamamlandı
|
Atanan hasar uzmanının dosya ayrıntılarını ilk kez kapsamlı biçimde inceleyip tamamladığını gösterir. Bu olay genellikle Claim nesnesindeki durum değişikliğinden, örneğin Yeni durumundan İnceleniyor veya İlk değerlendirme tamamlandı durumuna geçişten çıkarılır. | ||
|
Neden önemli?
Bu aşama, ilk bekleme süresinin sonunu ve etkin işlem sürecinin başlangıcını gösterir. Bu adıma ulaşmak için geçen süre, hasar uzmanının iş yükünü ve ilk kabul sürecinin verimliliğini gösteren önemli bir ölçüttür.
Nereden alınır?
Field History Tracking aracılığıyla kaydedilen Claim nesnesinin Status alanı değişikliğinin zaman damgasından çıkarılır.
Kaydedin
Status alanının İnceleniyor veya benzer bir duruma değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Ödeme Yapıldı
|
Hasar talebinde bulunan kişiye paranın fiilen ödendiğini gösterir. Bu önemli finansal olay, genellikle taleple ilişkili ödeme kaydının 'Paid' veya 'Issued' olarak işaretlenmesiyle kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, hasar talebinin sonuçlandırılma sürecinin son aşamasını ölçmek için önemli bir kilometre taşıdır. Onaydan ödemeye kadar geçen süreyi analiz etmek, finansal operasyonları iyileştirmeye yardımcı olur.
Nereden alınır?
İlişkili özel 'Claim Payment' nesnesindeki durum değişikliğinden çıkarılır. Durumun 'Paid' veya 'Sent' olarak değiştiği zaman damgası bu olayı gösterir.
Kaydedin
İlişkili 'Claim Payment' nesnesindeki durum değişikliğinin zaman damgası.
Olay türü
inferred
|
|||
|
Ek bilgi alındı
|
İstenen bilgilerin alındığını ve hasar dosyasının işleme devam edebileceğini gösterir. Claim nesnesinin durumu Beklemede durumundan İnceleniyor gibi etkin bir duruma döndüğünde bu olay çıkarılır. | ||
|
Neden önemli?
Bilgi talebi ile bilginin alınması arasında geçen süre çoğu zaman önemli bir darboğazdır. Bu süreyi analiz etmek, dış taraflara bağlı süreçleri ve iletişimin etkinliğini anlamaya yardımcı olur.
Nereden alınır?
Claim nesnesinin Status alanındaki değişiklikleri kaydeden Field History Tracking verilerinden çıkarılır. Bekleyen bilgi durumundan etkin bir duruma geçişin zaman damgası alınır.
Kaydedin
'Status' alanının beklemede durumundan değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Hasar dosyası atandı
|
Hasar dosyasının ilgilenilmesi için belirli bir hasar uzmanına veya ekibe atandığını gösterir. Claim nesnesindeki OwnerId alanının doldurulduğu ya da kuyruktan bir kullanıcıya değiştirildiği izlenerek kaydedilir. | ||
|
Neden önemli?
Atamaları izlemek, kaynak iş yükünü analiz etmek ve hasar uzmanı çalışmaya başlamadan önceki gecikmeleri belirlemek açısından önemlidir. Dosyanın etkin biçimde ele alınmadan önce kuyrukta ne kadar beklediğini ölçmeye yardımcı olur.
Nereden alınır?
Claim nesnesinin OwnerId alanındaki değişiklikleri kaydeden Field History Tracking verilerinden alınır. Kuyruktan belirli bir kullanıcıya geçişin zaman damgası bu olayı gösterir.
Kaydedin
OwnerId alanının kuyruktan bir kullanıcıya değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Hasar dosyası kaydedildi
|
İlk veri girişi sonrasında hasar dosyasının sistemde resmen kabul edilip kaydedildiğini gösterir. Bu olay çoğu zaman Claim nesnesindeki durum değişikliğinden, örneğin Taslak durumundan Yeni veya Bildirildi durumuna geçişten çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, hasar dosyasının resmen işlem kuyruğuna alındığını doğrular. Bildirim ile kayıt arasındaki süre, ilk veri doğrulama veya kabul ekibindeki birikmeleri gösterebilir.
Nereden alınır?
Claim nesnesinin Status alanındaki değişiklikleri kaydeden Field History Tracking verilerinden çıkarılır. Kayıtlı bir duruma (ör. Yeni, Açık) geçişin zaman damgası alınır.
Kaydedin
Status alanının Yeni veya Kayıtlı olarak değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Hasar Talebi Reddedildi
|
Reddedilen bir hasar talebinin nihai sonucunu ifade eder. 'Claim' nesnesinin durumu 'Rejected' veya 'Denied' olarak güncellendiğinde kaydedilen bir son olaydır. | ||
|
Neden önemli?
Başarılı sonuçlanmadan farklı olarak, sürecin nihai durumunu gösterir. Reddedilen talepleri ve ret nedenlerini analiz etmek, sigorta kabul veya ilk değerlendirme süreçlerini iyileştirmeye yardımcı olur.
Nereden alınır?
'Claim' nesnesindeki 'Status' alanının 'Rejected' olarak değiştiği zaman damgasından çıkarılır. 'Reason for Rejection' özniteliği ilgili alandan alınabilir.
Kaydedin
'Status' alanının 'Rejected' olarak değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Hasar Tutarı Değerlendirildi
|
Hasarın mali etkisinin değerlendirildiğini ve kaydedildiğini gösterir. Bu olay, 'Claim' nesnesindeki 'Loss Estimate' veya 'Settlement Amount' alanına ilk kez değer girildiği zamandan çıkarılabilir. | ||
|
Neden önemli?
Bu etkinlik, önemli bir finansal kilometre taşıdır. Gerçekleştiği zamanı izlemek, nihai karar öncesinde darboğaz oluşturabilecek finansal değerlendirme gecikmelerini anlamaya yardımcı olur.
Nereden alınır?
'Claim' nesnesindeki bir para birimi alanına (ör. 'Loss_Estimate__c') ait Field History Tracking verilerinden çıkarılır. Zaman damgası olarak alanın boş veya sıfır değerinden ilk kez güncellendiği an kullanılır.
Kaydedin
Finansal değerlendirme alanına ilk kez değer girildiği zaman damgası.
Olay türü
inferred
|
|||
|
İnceleme Başlatıldı
|
Hasar talebinin ayrıntılı inceleme aşamasının resmen başladığını gösterir. Bu olay, 'Claim' nesnesindeki durumun 'Investigation in Progress' gibi bir değere değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, önemli ve çoğu zaman uzun süren bir alt sürecin başlangıcını tanımlar. Kanıt toplama ve analiz aşamalarındaki darboğazları belirlemek için inceleme çevrim süresini ölçmek önemlidir.
Nereden alınır?
Field History Tracking aracılığıyla kaydedilen Claim nesnesinin Status alanı değişikliğinin zaman damgasından çıkarılır.
Kaydedin
'Status' alanının 'Investigation' olarak değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
İnceleme Tamamlandı
|
Hasar talebinde kanıt toplama ve analiz aşamasının tamamlandığını gösterir. Genellikle durumun 'Investigation in Progress' değerinden 'Pending Decision' veya benzer bir değere değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu kilometre taşı, inceleme alt sürecinin sonunu gösterir. İnceleme çevrim süresinin hassas biçimde ölçülmesini sağlayarak bu önemli aşamanın iyileştirilmesine yardımcı olur.
Nereden alınır?
'Claim' nesnesinin 'Status' alanındaki Field History Tracking verilerinden çıkarılır ve inceleme durumundan çıkışın zaman damgasını kaydeder.
Kaydedin
'Status' alanının 'Investigation' değerinden değiştiği zaman damgası.
Olay türü
inferred
|
|||
|
Ödeme Onaylandı
|
Uzlaşma tutarının kurum içinde onaylandığını ve ödemeye hazır olduğunu gösterir. Bu, ilişkili bir 'Payment Request' nesnesinden alınan açık bir olay veya 'Approved for Payment' gibi bir durum değişikliğinden çıkarılan bir olay olabilir. | ||
|
Neden önemli?
Bu, önemli bir iç kontrol noktasıdır. Karar ile ödeme onayı arasındaki gecikmeler, finansal onay iş akışlarındaki darboğazlara işaret edebilir.
Nereden alınır?
'Claim' nesnesindeki 'Status' alanının değiştiği zaman damgasından çıkarılır. Daha güvenilir bir yöntem olarak, ilişkili bir 'Claim Payment' veya benzer özel nesnenin 'CreatedDate' değeri kullanılabilir.
Kaydedin
'Claim Payment' nesnesinin oluşturulma zaman damgası.
Olay türü
explicit
|
|||
|
Uzlaşma Teklifi Sunuldu
|
Hasar talebinde bulunan kişiye resmî olarak bir uzlaşma tutarı teklif edildiğini gösterir. Bu olay, durumun 'Settlement Offered' olarak değişmesiyle veya bir iletişim kaydının oluşturulmasıyla kaydedilebilir. | ||
|
Neden önemli?
Bu etkinlik, son müzakere veya kabul aşamasını başlatır. Hasar talebinde bulunan kişinin yanıt süresini analiz ederek iletişim yöntemlerini iyileştirebilir ve sürecin son aşamalarını kısaltabilirsiniz.
Nereden alınır?
'Claim' nesnesindeki 'Status' alanının değişmesinden çıkarılır. Teklif mektubunu temsil eden ilişkili bir 'EmailMessage' veya 'Document' kaydının oluşturulma tarihi de kullanılabilir.
Kaydedin
'Status' alanının 'Settlement Offered' olarak değiştiği zaman damgası.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Template, hasar taleplerinin işlenmesini iyileştirme çalışmalarına başlamanız için gereken her şeyi sunar. İçgörüleri ortaya çıkarmak ve verimliliği artırmak için verilerinizi bugünden hazırlamaya başlayın.
Hasar taleplerindeki birikmeyi azaltın: İşlemleri hızlandırmaya hemen başlayın
Hasar taleplerinin %70'ini uçtan uca otomatik işleyin ve müşteri memnuniyetini artırın.
Kredi kartı gerekmez. Kurulumu birkaç dakikada tamamlayın.