İçeriğe geç
Ölçüm10 dk okuma

Yenileme kayıp nedeni nasıl kodlanır? Basit rapor düzeni

Yenilenmeyen poliçeleri nedenlerine göre sınıflandırın. Takip kaynaklı kayıpları müşteri kararlarından ayıran sade bir rapor düzeni kurun.

Yenileme adayları, kayıp nedenleri ve açık işleri içeren sade rapor

Yenileme ekibi

Yayımlandı:

Yenileme kayıp nedeni kaydetmek, yalnızca yenilenmeyen poliçeleri saymaktan daha fazlasıdır. Bu yazıda acenteniz için sade bir kod sözlüğü, kayıt alanları ve takip kaynaklı kayıpları müşteri kararlarından ayıran bir rapor düzeni bulacaksınız.

Yenileme kayıp nedeni neden ayrı izlenmeli?

Yenilenmeyen poliçe, raporun yalnızca sonucudur. Yönetici için asıl soru, sonucun hangi aşamada oluştuğudur. İş hiç başlamadı mı? Müşteriye ulaşılamadı mı? Teklif gecikti mi? Yoksa müşteri teklif içeriğini uygun bulmadı mı?

Bu soruların her biri farklı bir yönetim aksiyonu gerektirir. Takip başlamadıysa iş dağılımını düzeltmek gerekir. Teklif geç gönderildiyse operasyon akışına bakılmalıdır. Müşteri fiyat veya teminat nedeniyle devam etmediyse, konu başka türlü incelenir.

Bu nedenle yenileme kayıp nedeni, yalnızca serbest metin olarak yazılmamalıdır. Önceden belirlenmiş bir ana kod seçilmeli, açıklama gerekiyorsa alt neden veya kısa not eklenmelidir.

Önce raporun kapsamını sabitleyin. Yenileme adayı hangi poliçedir? Aynı müşterinin farklı branşları ayrı mı izlenecektir? Şirket değişse bile acente içinde düzenlenen poliçe yenilenmiş mi sayılacaktır? İptal, zeyil, başlangıç tarihi değişikliği ve mükerrer kayıtlar nasıl ele alınacaktır?

Bu kararlar verilmeden yenileme oranı karşılaştırmaları anlamını kaybedebilir. Dolayısıyla önce tanım, sonra kod, en son rapor oluşturulmalıdır.

Kayıp nedeni kodları iki ana grupta toplanmalı

Başlangıçta çok ayrıntılı bir liste hazırlamak cazip görünebilir. Ancak fazla seçenek, çalışanların benzer olaylarda farklı kodlar seçmesine yol açar. Bu nedenle önce iki ana grup kurun: takip veya süreç kaynaklı nedenler ve müşteri ya da pazar kararı kaynaklı nedenler.

Her kayıt için tek bir ana kod seçin. Birden fazla sorun varsa, raporu en çok açıklayan nedeni ana kod yapın. Diğer ayrıntıları alt neden veya not alanına taşıyın.

Takip veya süreç kaynaklı nedenler

Bu gruptaki kodlar, acentenin kendi iş akışında incelenebilecek noktaları gösterir:

  • Ulaşılamadı.
  • İletişim bilgisi güncel değildi.
  • Takip başlamadı.
  • Takip geç başladı.
  • Teklif hazırlanmadı.
  • Teklif geç gönderildi.
  • Teklif gönderildi fakat takip edilmedi.
  • Gerekli bilgi veya belge alınamadı.
  • İç onay veya operasyon gecikmesi yaşandı.
  • Sorumlu atanmadı.
  • Teknik ya da sistemsel sorun oluştu.
  • Nedeni bilinmiyor.

Özellikle teklif hazırlanmadı ile müşteri teklif istemedi ayrılmalıdır. İlkinde süreç tamamlanmamıştır. İkincisinde müşteriye ulaşılmış, ancak müşteri teklif talep etmemiştir.

Benzer şekilde teklif gönderildi fakat takip edilmedi ile müşteri fiyat nedeniyle vazgeçti aynı kayıt değildir. İlk kayıt takip kalitesini gösterir. İkinci kayıt, teklif sonrasında alınan müşteri kararını gösterir.

Müşteri veya pazar kararı kaynaklı nedenler

Bu grupta, acente temas kurmuş ve süreci işletmiş olsa da sonucu müşterinin veya teklif koşullarının belirlediği durumlar yer alır:

  • Fiyat nedeniyle vazgeçti.
  • Teminat kapsamı nedeniyle vazgeçti.
  • Muafiyet veya ödeme koşulları nedeniyle vazgeçti.
  • Başka şirketi tercih etti.
  • Başka acenteyi tercih etti.
  • Aracı sattı veya risk ortadan kalktı.
  • Sigorta yaptırmamaya karar verdi.
  • Poliçeyi askıya aldı.
  • Müşteri başka bir nedenle devam etmedi.
  • Müşteri kayıp nedenini paylaşmadı.

Bu kodlar, müşteriyi suçlamak için değil, kaybın niteliğini anlamak için kullanılır. Örneğin başka şirketi tercih etti kaydı, teklifin gönderilmediği bir dosyada kullanılmamalıdır.

Ulaşılamadı kodunu alt nedenlerle açıklayın

Ulaşılamadı, pratik bir ana koddur. Ancak tek başına bırakılırsa farklı sorunları aynı yerde toplar. Telefon numarası hatalı olan müşteriyle aramaya cevap vermeyen müşteri aynı durumda değildir.

Bu nedenle alt neden alanında iletişim durumunu belirtin. Telefon kapalı olabilir. Arama yapılmış, ancak cevap alınmamış olabilir. WhatsApp mesajı teslim edilmemiş olabilir. Mesaj teslim edilmiş, fakat yanıt alınmamış olabilir. E-posta geri dönmüş olabilir.

Müşteri geri dönüş yapacağını söylemiş, ancak geri dönmemişse bu durum da ayrıca yazılabilir. İletişim izni veya kanal tercihi nedeniyle temas kurulamadıysa, bunu müşteri kararı gibi kaydetmeyin.

Sonuçta amaç, ulaşılamadı kodunu ortadan kaldırmak değildir. Amaç, bu kodun hangi operasyonel durumu ifade ettiğini görmektir. Böylece iletişim bilgisi güncelleme, kanal tercihi ve takip akışı ayrı ayrı incelenebilir.

Kayıtta yalnızca neden değil, işlem izi de olsun

Bir raporun güvenilirliği, çalışanın notuna değil, kaydın tamamına dayanmalıdır. Her yenileme adayı için poliçe bitiş tarihi, yenileme adayı durumu ve sonuç alanı tutulmalıdır.

Bunlara ana kayıp nedeni, varsa alt neden, ilk takip tarihi ve son temas tarihi eklenmelidir. Son temas kanalı da yazılmalıdır. Böylece telefon, WhatsApp veya e-posta üzerinden yürüyen işler birbirine karışmaz.

Teklif hazırlanıp hazırlanmadığı, teklifin gönderim tarihi ve müşteriye ulaşılıp ulaşılmadığı da ayrı alanlar olmalıdır. Kaydı kapatan kişi ve kapanış tarihi ayrıca görünmelidir.

Not alanı, ana kodun yerine geçmemelidir. Serbest metin tek başına kullanılırsa aynı olay farklı ifadelerle yazılır. Fiyat yüksek, prim pahalı ve bütçesine uymadı gibi notlar zamanla ayrı nedenler sanılabilir.

Daha iyi yöntem, önce standart kodu seçmektir. Ardından kısa ve ölçülü bir not eklemektir. Örneğin müşterinin başka şirketi tercih ettiği kaydedilebilir. Ancak müşterinin paylaşmadığı kişisel ayrıntılar not alanına taşınmamalıdır.

SEDDK’nın teknik personel standardında mevcut müşteri ilişkilerinde poliçe bitişlerinin takip edilmesi, müşterinin önceden bilgilendirilmesi ve yenileme işlemlerinin başlatılması iş akışı içinde ele alınır. Bu yaklaşım, poliçe yenileme takibi için sonuçtan önceki işlem izini de tutmayı destekler.

Basit bir yenileme kaybı raporu nasıl kurulur?

Her satırın bir yenileme adayını temsil ettiği sade bir raporla başlayabilirsiniz. Önce havuzu görünür yapın. Ardından sonucu ve ana nedeni aynı ekranda izleyin.

Raporun temel alanları şöyle olabilir:

Rapor alanıNe gösterir?
Yenileme adayıİncelenecek poliçe havuzunu gösterir.
SonuçYenilendi veya yenilenmedi durumunu gösterir.
Ana kayıp nedeniYenilenmeme sonucunun ana açıklamasıdır.
Alt nedenAna kodun operasyonel ayrıntısını verir.
Son temas kanalıMüşteriye hangi kanaldan ulaşıldığını gösterir.
Teklif durumuTeklifin hazırlanıp gönderilip gönderilmediğini gösterir.
SorumluDosyanın kim tarafından takip edildiğini gösterir.
Açık işTamamlanmamış veya gecikmiş adımı gösterir.

Yenileme oranı, yenilenen poliçelerin yenileme adaylarına bölünmesiyle izlenebilir. Kayıp oranı ise yenilenmeyen poliçelerin aynı aday havuzuna göre değerlendirilmesiyle bulunur.

Takip kaynaklı kayıp oranını ayrıca izlemek, operasyon sorunlarını görünür kılar. Bunun yanında müşteri kararı, fiyat ve teminat kaynaklı kayıplar ayrı tutulmalıdır. Nedeni bilinmeyen kayıtlar da ayrı bir başlık olmalıdır.

Raporu toplam sonuçla sınırlamayın. Branşa, sorumlu çalışana ve dönem içindeki işlem durumuna göre filtreleyin. Örneğin teklif geç gönderildi kodu belirli bir çalışan veya branşta yoğunlaşıyorsa, süreç orada incelenebilir.

Aynı raporda açık işleri de gösterin. Kayıp nedeni henüz kapanmamışsa, dosyayı tamamlanmış kayıp gibi saymayın. Böylece yönetici, hem gerçekleşen kayıpları hem de hâlâ müdahale edilebilecek işleri görür.

Bu yapı, yenileme kaçağı nasıl ölçülür yazısındaki temel ölçüm yaklaşımıyla birlikte kullanılabilir. Önce doğru aday havuzunu çıkarın. Sonra neden kırılımına geçin.

Takip kaynaklı kayıp ile müşteri kararını ayıran akış

Her yenilenmeyen poliçede aynı soruları sırayla sorun. İlk soru müşteriye ulaşılıp ulaşılmadığıdır. Ulaşılmadıysa, doğrudan fiyat veya teminat kodu seçmeyin.

Müşteriye ulaşıldıysa, teklif talep edip etmediğine bakın. Müşteri teklif istemediyse, bunu teklif hazırlanmadı olarak kapatmayın. Çünkü bu iki kayıt farklı bir işaret taşır.

Teklif talep edildiyse, teklifin hazırlanıp hazırlanmadığını kontrol edin. Hazırlanmadıysa veya geç gönderildiyse, bu süreç grubunda kalır. Teklif gönderildiyse, sonrasında takip yapılıp yapılmadığına bakın.

Teklif gönderilmiş, takip yapılmış ve müşteri fiyatı uygun bulmamışsa, müşteri kararı grubunu kullanın. Teminat kapsamı, muafiyet veya ödeme koşulu için de aynı mantık geçerlidir.

Müşteri nedenini söylemediyse tahminde bulunmayın. Nedeni bilinmiyor veya müşteri kayıp nedenini paylaşmadı kodlarından uygun olanı seçin. Eksik veriyi yapay biçimde tamamlamak, aylık raporu daha doğru göstermez.

Bu ayrımın çalışması için her dosyada bir sahip olmalıdır. Ayrıca açık işlerin yöneticiye görünmesi gerekir. Geciken kayıtlar, kapanmadan önce yeniden ele alınmalıdır.

Sigorta yenileme takibi için adım adım düzen yazısındaki görev ve temas yaklaşımı, bu rapor düzeninin operasyon tarafını tamamlar. Rapor, iş akışından kopuk bir tablo olmamalıdır.

Kanal ve kişisel veri kayıtlarını ölçülü tutun

Yenileme kaydı, müşteri hakkında her ayrıntının yazılacağı bir alan değildir. Sadece neden analizi için gerekli bilgileri tutun. Sağlık, aile, özel hayat veya müşterinin paylaşmadığı hassas ayrıntıları serbest nota eklemeyin.

Kayıtlarda müşteri hakkında damgalayıcı yorumlardan da kaçının. Müşteri fiyat nedeniyle devam etmedi ifadesi, müşteriye ilişkin kişisel bir yargıdan daha ölçülüdür. Müşteri başka acenteyi tercih etti ifadesi de aynı şekilde sınırlı bir açıklama sağlar.

Erişim yetkilerini raporun amacıyla sınırlayın. Her çalışanın tüm müşteri notlarını görmesi gerekmeyebilir. Saklama ve imha düzenini de acentenizin veri envanteri, politikası ve güncel mevzuatla birlikte değerlendirin.

Telefon, WhatsApp ve e-posta temaslarında kanal kurallarını ayrıca kontrol edin. Yenileme amacı taşıyan bir temasın içeriği, kullanılan kanal ve izin durumu birlikte değerlendirilmelidir. Kesin varsayımlar yerine güncel metni ve gerektiğinde uzman görüşünü esas alın.

Bu konuda acente çalışanı iletişim kayıt düzeni ve acentede WhatsApp ile müşteri takibi içerikleri, kayıt ve kanal tarafında yardımcı olabilir.

Uygulamaya başlamak için sade bir plan

Önce yenileme kaybı raporunun kapsamını yazılı hâle getirin. Hangi poliçelerin aday olduğu ve hangi sonuçların rapora gireceği belli olsun.

Sonra ana kodları sınırlı tutun. Takip veya süreç kaynaklı nedenleri müşteri ve pazar kararlarından ayırın. Ayrıntı gerektiğinde alt neden ekleyin.

Ardından kayıt ekranındaki zorunlu alanları belirleyin. Sonuç, ana neden, sorumlu, son temas tarihi ve teklif durumu boş kalmasın. Serbest not, bu alanların yerine geçmesin.

Son olarak raporu düzenli gözden geçirin. Nedeni bilinmeyen kayıtlar artıyorsa, çalışanların temas ve kapanış sürecini inceleyin. Teklif geç gönderildi kayıtları çoğalıyorsa, teklif hazırlama akışını kontrol edin.

Bu yaklaşım, yenileme kayıp nedeni verisini suçlama aracına değil, süreç iyileştirme aracına dönüştürür. Böylece toplam kaybın arkasındaki gerçek dağılım daha anlaşılır hâle gelir.

Kendi çalışma düzeniniz için yenileme maliyeti hesaplayıcısını da inceleyebilirsiniz. Önce hangi hacmi ve iş yükünü ölçtüğünüzü netleştirmek, sonraki değerlendirmeleri kolaylaştırır.

Portföyünüzü birlikte gözden geçirin

Ücretsiz yenileme kaçağı kontrolünde, geçen yıl yenilenip bu yıl yenilenmeyen poliçeleri kendi portföyünüz üzerinden birlikte çıkarabilirsiniz.

Sık sorulan sorular

Yenileme kayıp nedeni kodları resmî bir liste midir?

Hayır. Bu yazıdaki kodlar, acentenin iç ölçüm ve yönetim düzeni için önerilen sınıflandırmadır.

Her yenilenmeyen poliçeye birden fazla ana neden verilmeli mi?

Hayır. Her kayıt için tek bir ana neden seçmek daha ölçülebilir bir rapor sağlar. Gerekirse alt neden veya kısa not eklenebilir.

Ulaşılamadı kodu neden alt nedenlere ayrılmalı?

Çünkü hatalı telefon numarası, cevapsız arama ve yanıtlanmayan mesaj aynı operasyonel durumu göstermez. Alt nedenler iletişim sorununu daha anlaşılır kılar.

Teklif gönderildiği hâlde müşteri yenilemediyse hangi grup kullanılmalı?

Teklif gönderilmiş ve takip edilmişse, müşterinin belirttiği fiyat, teminat veya başka tercih nedeni müşteri ya da pazar kararı grubunda izlenebilir. Müşteri nedenini paylaşmadıysa neden bilinmiyor seçilmelidir.

Rapor hangi tarihleri içermeli?

Poliçe bitiş tarihi, ilk takip tarihi, son temas tarihi, teklif gönderim tarihi ve kaydı kapatma tarihi ayrı alanlar olarak tutulmalıdır.

yenilemeölçümacenteraporlama
Mevzuat
9 Ekim 2026Akıllı Arama9 dk okuma

2026 basamak düzeltmesi trafik: araç değişiminde acente rehberi

Ocak 2026 sonrası araç değişiminde basamak aktarımı için kim, ne zaman ve nasıl başvurur? Acentenin müşteriye adım adım nasıl rehberlik edeceğini, resmi dayanaklarla anlatıyoruz.

trafikbasamakmevzuat
Mevzuat
23 Ekim 2026Akıllı Arama10 dk okuma

Hasar bildirimi sonrası basamak nasıl kontrol edilir?

Hasar bildirimi alınan trafik dosyasında basamak etkisini anlamak için ödeme, poliçe ve kayıtları birlikte kontrol edin. Müşteriye kesin sonuç vermeden ilerleyin.

trafik sigortasıhasarbasamak
Mevzuat
22 Ekim 2026Akıllı Arama9 dk okuma

Teklif Platformu ve gün sonu: SEDDK poliçe kaçınma 2025

Teklif Platformu’nda teklif–poliçe zincirinin gün sonu kuralı yenileme akışını değiştiriyor. Kaçınma sayılan halleri ve ekip zamanlamasını adım adım sadeleştiriyoruz.

teklif platformugün sonuyenileme