Teklif dönüşüm oranı, acentelerin en çok izlediği göstergelerden biridir. Ancak tek bir oran, sürecin neresinde sorun olduğunu söylemez. Yüz tekliften yirmisinin poliçeye dönüştüğünü bilmek, kalan sekseninin nerede kaybolduğunu açıklamaz. Müşteri teklifi hiç görmemiş olabilir, teklifi görmüş ama geri dönüş almamış olabilir ya da fiyatı inceleyip vazgeçmiş olabilir. Huni analizi, süreci aşamalara bölerek her aşamadaki kaybı ayrı ayrı görünür kılar. Bu yazıda teklif hunisinin nasıl tanımlanacağını, branş bazında neden ayrı huniler gerektiğini ve sonuçların nasıl okunacağını anlatıyoruz.
Huni aşamalarını tanımlamak
Bir teklif hunisinin aşamaları, yazılımda kayıt altına alınabilen olaylara dayanmalıdır. Kaydı olmayan bir aşama ölçülemez. Acente süreçleri için tipik bir huni şu aşamalardan oluşabilir:
- Talep: Müşteri bir branş için teklif istedi ya da temsilci bir fırsat oluşturdu.
- Sorgu: Gerekli bilgiler girildi ve sigorta şirketlerinden fiyat alındı.
- İletim: Teklif müşteriye iletildi.
- Geri dönüş: Müşteriyle teklif sonrası görüşme yapıldı.
- Poliçe: Teklif poliçeye dönüştü.
Her aşama için, bir önceki aşamaya ulaşan kayıtların ne kadarının bu aşamaya geçtiği hesaplanır. Böylece toplam dönüşüm oranı, aşama geçiş oranlarının çarpımına ayrışır.
Neden branş bazında ayrı huniler?
Trafik, kasko ve DASK tek bir "teklif" kavramı altında toplanabilir; ancak süreçleri birbirinden belirgin biçimde farklıdır ve ayrı sorgu akışlarıyla ilerler. Bu farklar, hunilerin aşama tanımlarını ve kayıp noktalarını da farklılaştırır:
Trafik hunisi
Trafik sigortasında sorgu için araç ve ruhsat bilgileri yeterli olduğundan talep ile sorgu arasındaki geçiş genellikle hızlıdır. Kayıp daha çok iletim sonrası, müşterinin karar sürecinde ya da poliçe bitişine yakın dönemde başka bir kanalı tercih etmesiyle yaşanabilir. Bu hunide zamanlama belirleyicidir: Bitiş tarihine yakın gelen talepler ile önceden planlanan yenilemeler ayrı izlenmelidir.
Kasko hunisi
Kaskoda teminat seçenekleri, muafiyetler ve ek hizmetler müşteriyle konuşulması gereken konulardır. Bu nedenle iletim ile geri dönüş arasındaki aşama kritik hale gelir. Teklif iletildiği halde geri dönüş yapılmayan kayıtların oranı yüksekse, sorun fiyattan çok takip disiplininde olabilir.
DASK hunisi
DASK sorgusunda adres kodu, yapı tarzı, inşa yılı ve brüt metrekare gibi bilgiler gerekir. Bu bilgilerin eksik olması talep ile sorgu arasında kayba yol açabilir. Talebi oluşturulmuş ama sorgusu yapılamamış DASK kayıtlarının fazla olması, bilgi toplama aşamasının iyileştirilmesi gerektiğini gösterir.
Bu üç akışı tek bir hunide birleştirmek, her birindeki farklı darboğazı ortalamanın içinde kaybettirir.
Huniyi doğru ölçmek için kurallar
- Kohort mantığı: Huni, aynı dönemde talebi oluşan kayıtların ilerleyişini izlemelidir. Ocak ayında oluşan talepleri şubat ayında poliçeleşenlerle karıştırmak oranları bozar.
- Olgunlaşma süresi: Son günlerde oluşan talepler henüz poliçe aşamasına ulaşmamış olabilir. Huni raporunda yeterince olgunlaşmamış dönemler ayrıca işaretlenmelidir.
- Tekrar sorguların temizlenmesi: Aynı araç ya da aynı konut için kısa aralıklarla yapılan tekrar sorgular tek fırsat sayılmalıdır.
- Kayıp nedeni: Huniden çıkan kayıtlar için kısa ve sabit bir kayıp nedeni listesi tutulmalıdır: fiyat, teminat, müşteri vazgeçti, başka kanal, ulaşılamadı.
Sonuçları okumak
Huni analizi sonuçlarını yorumlarken mutlak oranlardan çok, aşamalar arasındaki göreli kayıplara ve zaman içindeki değişime bakmak gerekir. Bazı yaygın örüntüler ve olası anlamları şunlardır:
- Sorgu aşamasında yüksek kayıp: Bilgi toplama zorluğu, eksik müşteri verisi ya da sorgu ekranlarında yaşanan aksaklıklar.
- İletim aşamasında yüksek kayıp: Fiyat alınmış ama müşteriye gönderilmemiş teklifler; çoğu zaman iş yükü ya da sahiplik belirsizliği işaretidir.
- Geri dönüş aşamasında yüksek kayıp: Takip görevlerinin oluşturulmaması ya da zamanında yapılmaması.
- Son aşamada yüksek kayıp: Kayıp nedenlerinin incelenmesini gerektirir; teminat uyumsuzluğu, zamanlama ya da müşteri ihtiyacının yanlış anlaşılması olabilir.
Huni ile kapasite ilişkisi
Huni analizinin çoğu zaman gözden kaçan bir faydası, iş yükü dağılımını göstermesidir. Belirli bir temsilcide iletim aşamasında biriken teklifler, o kişinin kapasitesinin aşıldığını gösterebilir. Bu durumda çözüm satış tekniği değil, görev dağılımıdır. Temsilci bazlı huniler incelenirken kayıt sayısının yeterli olduğundan emin olunmalı ve sonuçlar kişisel değerlendirmeden çok süreç iyileştirme amacıyla kullanılmalıdır.
Kayıt altyapısı
Huninin her aşaması bir kayıt olayı gerektirir. Sorgu ve iletim bilgisinin teklif programı içinde, geri dönüş ve temas bilgisinin ise acente CRM kayıtlarında tutulması, huninin ayrı tablolar tutmadan oluşturulmasını sağlar. InsureHub yaklaşımında trafik, kasko ve DASK sorgularının kendi akışlarında ilerlemesi, branş bazlı hunilerin doğal olarak ayrışmasına imkân verir.
Huniyi görselleştirmek
Huni sonuçlarını sunarken her branş için ayrı bir yatay çubuk dizisi kullanmak, aşamalar arasındaki kaybı en net biçimde gösterir. Çubukların yanında hem bir önceki aşamaya göre geçiş oranı hem de başlangıca göre kalan oran yer almalıdır. Önceki dönemin değerleri silik bir çizgiyle aynı grafiğe eklenirse, hangi aşamanın iyileştiği ya da kötüleştiği tek bakışta anlaşılır. Üç branşı tek grafikte üst üste bindirmek yerine yan yana küçük grafikler kullanmak, farklı ölçeklerin birbirini gölgelemesini önler.
İyileştirmeyi test etmek
Bir aşamadaki kaybı azaltmak için yapılan değişiklik, örneğin iletim sonrası otomatik geri dönüş görevi oluşturulması, birkaç dönem boyunca aynı huni tanımıyla izlenmelidir. Tanım sabit kalmazsa iyileşmenin değişiklikten mi yoksa ölçümden mi kaynaklandığı anlaşılamaz.
Sonuç
Tek bir dönüşüm oranı sonucu, huni ise nedeni gösterir. Aşamaları kayıt olaylarına bağlayıp branş bazında ayrı huniler oluşturduğunuzda, iyileştirme çabası tahmine değil veriye dayanır. Teklif kayıtlarınızın huni analizine nasıl kaynak olabileceğini görmek için demo talep sayfasını kullanabilirsiniz.