Yenileme otomasyonu kurulduğunda ekip genellikle rahatlar: Hatırlatmalar zamanında oluşur, görevler doğru kişilere atanır, liste düzenli ilerler. Ancak bir süre sonra bazı poliçelerin bu düzene uymadığı fark edilir. Bir poliçe için hatırlatma gereksizdir çünkü müşteri yenilemeyi istemediğini önceden bildirmiştir; bir diğeri için standart hazırlık penceresi yetersizdir çünkü kurumsal bir onay süreci gerekir. Bu poliçeler otomatik akışta kaldıkça hem ekibin otomasyona güveni azalır hem de istisnai durumlar gözden kaçar. İstisna yönetimi, bu kayıtları tanımlamak ve ayrı bir düzende yönetmek üzerine kuruludur.
İstisna nedir, ne değildir?
İstisna, standart yenileme kurallarının o kayıt için uygun olmadığı bilinen durumdur. Burada iki ayrım önemlidir. Birincisi, istisna bir hata değildir; veri eksikliği veya yanlış kayıt gibi sorunlar istisna değil, düzeltilmesi gereken veri kalitesi sorunlarıdır. İkincisi, istisna kalıcı olmak zorunda değildir; bir dönem için geçerli olup bir sonraki dönemde standart akışa dönebilir.
Sık görülen istisna türleri
- Yenilememe kararı önceden bildirilmiş poliçeler: Müşteri aracını satacağını veya taşınacağını önceden söylemiştir.
- Uzun hazırlık gerektiren poliçeler: Kurumsal müşterilerde iç onay süreci, filo poliçelerinde araç listesinin güncellenmesi gibi ek adımlar vardır.
- Özel iletişim talebi olan müşteriler: Otomatik mesaj almak istemeyen veya yalnızca belirli bir kişiyle görüşmek isteyen müşteriler.
- Hukuki veya özel süreçteki kayıtlar: Devam eden bir uyuşmazlık veya özel inceleme altındaki poliçeler.
- Ana sorumlu tarafından bizzat yönetilen kayıtlar: Acente sahibinin kişisel olarak takip ettiği müşteriler.
- Vade hizalama sürecindeki poliçeler: Bitiş tarihinin müşteriyle birlikte yeniden planlandığı kayıtlar.
İstisnayı kayda işlemek
Bir poliçenin istisna olduğunu ekipteki bir kişinin bilmesi yeterli değildir; bilginin kayıtta yer alması gerekir. Bir istisna kaydı şu unsurları içermelidir:
- İstisna türü: Standart bir listeden seçilir.
- Gerekçe: Kısa ve anlaşılır bir açıklama.
- Geçerlilik süresi: İstisnanın hangi tarihe veya hangi döneme kadar geçerli olduğu.
- Etkilediği otomasyonlar: Yalnızca müşteri mesajları mı durdurulacak, yoksa görev oluşturma da mı değişecek?
- Tanımlayan kullanıcı: Kararı kimin verdiği.
Dördüncü madde istisna yönetiminin en kritik noktasıdır. Bir istisna, otomasyonun tamamen durması anlamına gelmemelidir. Örneğin özel iletişim talebi olan bir müşteri için müşteriye giden otomatik mesajlar durdurulurken, sorumlu kullanıcıya iç görev oluşturulmaya devam edilebilir. Bu ayrım yapılmazsa istisna, poliçenin tamamen unutulmasına yol açar.
İstisna kuyruğu
İstisna olarak işaretlenen kayıtların standart yenileme listesinden çıkıp kaybolması yerine, ayrı bir kuyrukta görünmesi gerekir. Bu kuyruk şu soruları yanıtlar:
- Şu anda kaç kayıt istisna olarak yönetiliyor?
- Bunların bitiş tarihleri ne zaman?
- Hangi istisnaların geçerlilik süresi dolmak üzere?
- Her istisnanın sorumlusu kim?
İstisna kuyruğunun yönetici tarafından düzenli olarak gözden geçirilmesi, istisnaların kontrolsüz biçimde artmasını engeller. Kuyruk sürekli büyüyorsa, bu durum standart kuralların yeterince iyi tasarlanmadığına işaret edebilir.
İstisnaların süresiz kalmasını önlemek
İstisna yönetiminde en yaygın sorun, bir kez tanımlanan istisnanın unutulup yıllarca geçerli kalmasıdır. Müşteri bir dönem otomatik mesaj istemediğini söylemiştir, ancak bu tercih yıllar sonra da sorgulanmadan uygulanmaktadır. Bunu önlemek için:
- Her istisnanın bir bitiş tarihi olmalı veya belirli aralıklarla yeniden onaylanmalıdır.
- Geçerlilik süresi dolan istisnalar için sorumlu kullanıcıya hatırlatma gitmelidir.
- Süresi dolan istisna otomatik olarak kaldırılmalı ve kayıt standart akışa dönmelidir.
İstisnalardan kural çıkarmak
İstisnalar, standart kuralların nerede yetersiz kaldığını gösteren değerli bir geri bildirim kaynağıdır. Belirli bir istisna türü sürekli tekrar ediyorsa, o durumu kapsayan yeni bir standart kural tanımlamak düşünülebilir. Örneğin kurumsal müşteriler için sürekli "uzun hazırlık" istisnası tanımlanıyorsa, kurumsal müşteriler için ayrı bir hazırlık penceresi olan bir kural oluşturmak daha verimli bir çözümdür.
Bu dönüşüm, istisna kuyruğunu küçültür ve otomasyonun kapsamını genişletir. İyi işleyen bir sistemde istisnalar gerçekten istisnai kalır.
Branşlara göre istisna farkları
İstisna türlerinin sıklığı branşa göre değişebilir. Trafik yenilemelerinde araç satışı nedeniyle önceden bildirilen yenilememe kararları daha sık görülürken, DASK'ta taşınma kaynaklı istisnalar öne çıkabilir. Kaskoda ise teminat yapısının müşteriyle uzun süre konuşulması gereken durumlar ek hazırlık istisnalarına yol açabilir. Trafik, kasko ve DASK'ın teklif tarafında ayrı sorgu akışları olduğu için istisna türlerinin de branş bazında izlenmesi, her akışa özgü iyileştirmeleri görmeyi kolaylaştırır.
Ekip disiplini
İstisna tanımlama yetkisinin herkese açık olması, kuralların kolayca aşılmasına neden olabilir. Bu yetkinin belirli rollerle sınırlanması veya istisnaların yönetici onayına bağlanması, sistemin bütünlüğünü korur. Aynı zamanda istisnayı tanımlayan kişinin gerekçe yazmak zorunda olması, kararların bilinçli verilmesini sağlar. Bu kurallar ekip içinde açıkça paylaşıldığında, istisnalar bir kaçış yolu değil, yönetilen bir süreç olarak görülür.
İstisnaları raporlamak
Dönem sonunda istisna kuyruğunun kısa bir özeti, yenileme sürecinin gerçek resmini tamamlar. Kaç poliçenin istisna olarak yönetildiği, bunların ne kadarının yenilendiği ve hangi türlerin öne çıktığı, otomasyon başarısını değerlendirirken göz ardı edilmemesi gereken bir bilgidir. İstisnalar raporlara dahil edilmediğinde, otomatik akışın başarısı olduğundan farklı görünebilir.
InsureHub yaklaşımı
InsureHub, acentelere sunduğu sigorta acentesi yazılımı ile poliçe, müşteri ve görev kayıtlarını aynı yapıda tutmayı hedefler. Müşteri iletişim tercihlerinin ve notlarının acente CRM içinde yer alması, istisnaların gerekçesiyle birlikte kayıtta görünmesine zemin hazırlar. Yenileme sürecinizdeki istisnaları nasıl yönetebileceğinizi konuşmak için demo talebinde bulunabilirsiniz.