Bir acentenin poliçe listesine bakıldığında her şey düzenli görünebilir: numara, müşteri adı, başlangıç ve bitiş tarihi. Sorun, bu listeden bir soru sorulduğunda ortaya çıkar. "Geçen yıl kaskosunu yenilemeyen müşterilerin kaçının trafik poliçesi hâlâ bizde?" gibi bir soruya cevap verilemiyorsa, eksik olan çoğu zaman veri değil, verinin nasıl modellendiğidir. Poliçe veri modeli, acente yazılımının üzerine kurulduğu iskelettir ve yenileme otomasyonundan raporlamaya kadar her şeyin kalitesini belirler.
Poliçe kaydı neden tek bir satır değildir?
Tablolarla çalışan acentelerde poliçe genellikle tek bir satır olarak tutulur. Bu yaklaşım ilk aşamada pratiktir ancak poliçenin doğasıyla uyuşmaz. Bir poliçe; bir müşteriye, bir sigorta şirketine, bir branşa, bir sigortalı nesneye (araç, konut, kişi) ve zaman içinde değişen bir dizi işleme bağlıdır. Bu ilişkileri tek satıra sıkıştırmak, aynı bilginin farklı satırlarda farklı yazılmasına ve zamanla tutarsızlığa yol açar.
Sağlıklı bir model, poliçeyi merkezde tutar ve onu çevreleyen varlıkları ayrı kayıtlar olarak tanımlar. Böylece müşteri adresi değiştiğinde onlarca poliçe satırını tek tek düzeltmek gerekmez; müşteri kaydı güncellenir, bağlı poliçeler doğru bilgiyi gösterir.
Temel varlıklar ve aralarındaki ilişkiler
Acente yazılımında poliçe veri modelini kurarken aşağıdaki varlıkları ayrı düşünmek işinizi kolaylaştırır:
- Müşteri: Bireysel veya kurumsal kimlik bilgileri, iletişim kanalları ve izin tercihleri.
- Sigortalı nesne: Trafik ve kaskoda araç, DASK ve konut branşında adres ve yapı bilgisi, sağlık branşında kişi.
- Sigorta şirketi ve ürün: Poliçenin düzenlendiği şirket ve ürün tanımı.
- Poliçe: Numara, dönem, prim, durum ve sorumlu kullanıcı.
- Poliçe hareketleri: Zeyil, iptal, yenileme gibi poliçenin ömrü boyunca yaşanan işlemler.
- Dokümanlar: Poliçe belgesi, bilgilendirme formları ve ekler.
Bu yapıda bir müşterinin birden fazla poliçesi, bir aracın ise yıllar içinde birbirini izleyen poliçeleri olabilir. İlişkiler net kurulduğunda "bu araç için daha önce hangi poliçeler düzenlendi?" sorusu tek bir sorguyla cevaplanır.
Zorunlu alanlar ile opsiyonel alanları ayırmak
Her alanı zorunlu yapmak kullanıcıyı yorar; hiçbir alanı zorunlu tutmamak ise eksik kayıtlarla dolu bir veri tabanı üretir. Dengeyi kurmak için şu soruyu sorun: Bu alan boş kalırsa hangi süreç bozulur?
Mutlaka dolu olması gerekenler
- Poliçe numarası ve sigorta şirketi
- Branş bilgisi
- Başlangıç ve bitiş tarihleri
- Bağlı müşteri kaydı
- Poliçe durumu
- Sorumlu kullanıcı veya şube
Branşa göre zorunlu hale gelenler
Trafik ve kasko poliçelerinde plaka ve araç bilgisi, DASK poliçelerinde adres ve yapı bilgisi olmadan yenileme süreci sağlıklı yürümez. Bu nedenle bazı alanlar genel olarak değil, branş seçildiğinde zorunlu olmalıdır. Trafik, kasko ve DASK'ın teklif tarafında ayrı sorgu akışlarına sahip olması gibi, poliçe kaydında da her branşın kendi alan setine ihtiyacı vardır.
Opsiyonel ama değerli olanlar
Kaynak kanal, müşteriyle yapılan son görüşme notu ve iç etiketler zorunlu olmasa da analiz ve takip açısından değer üretir. Bunları opsiyonel tutup düzenli doldurmayı ekip alışkanlığına dönüştürmek daha sürdürülebilir bir yoldur.
Tarih alanlarında sık yapılan modelleme hataları
Poliçe modelinde en çok sorun çıkaran alanlar tarihlerdir. Tanzim tarihi, başlangıç tarihi, bitiş tarihi ve kayıt oluşturma tarihi birbirine karıştırıldığında vade takibi yanlış listeler üretir. Her tarih alanının ne anlama geldiği yazılımda açıkça tanımlanmalı ve ekranlarda tutarlı etiketlerle gösterilmelidir.
Bir diğer hata, bitiş tarihini elle girilen serbest metin olarak saklamaktır. Tarih alanları gerçek tarih tipinde tutulmadığında sıralama, filtreleme ve hatırlatma kuralları güvenilir çalışmaz. Veri aktarımı sırasında farklı formatlarda gelen tarihlerin standart biçime çevrilmesi bu yüzden kritik bir adımdır.
Durum alanı: Modelin en çok ihmal edilen parçası
Bir poliçenin yürürlükte mi, iptal edilmiş mi, süresi dolmuş mu yoksa yenilenmiş mi olduğu bilgisi çoğu zaman tarihlerden çıkarılmaya çalışılır. Oysa tarihler tek başına iptal edilen bir poliçeyi yürürlükteki bir poliçeden ayıramaz. Açık bir durum alanı, portföy raporlarının ve yenileme listelerinin doğru çalışması için gereklidir. Durum geçişlerinin kim tarafından ve ne zaman yapıldığının kaydedilmesi de denetim açısından önemlidir.
Modeli büyümeye hazır tutmak
Bugün yalnızca birkaç branşta çalışan bir acente, yarın yeni ürünler ekleyebilir veya şube açabilir. Esnek bir veri modeli şu özellikleri taşır:
- Yeni branş eklemek için tüm yapıyı değiştirmeyi gerektirmez.
- Şube ve kullanıcı bilgisini poliçeye bağlayarak yetkilendirmeye zemin hazırlar.
- Poliçe hareketlerini ayrı kayıtlar olarak tutar, böylece geçmiş silinmez.
- Dış kaynaklardan gelen verinin hangi kaynaktan geldiğini işaretler.
Kaynak bilgisini kayda işlemek
Poliçe verisi acenteye farklı yollardan ulaşır: kullanıcı elle girer, eski tablolardan aktarılır veya sigorta şirketi tarafındaki bir işlem sonucunda oluşur. Her kaydın hangi kaynaktan geldiğini gösteren basit bir alan, veri kalitesi sorunlarının nereden çıktığını anlamayı kolaylaştırır. Aktarılan kayıtlarda eksik alan oranı yüksekse, sorunun kullanıcı alışkanlığında değil aktarım şablonunda olduğu hemen görülür.
InsureHub bakış açısıyla
InsureHub, acentelere yazılım sağlayan bir platform olarak poliçe kaydını müşteri kartından ve teklif geçmişinden kopuk bir liste olarak ele almaz. Müşteri, teklif ve poliçe arasındaki bağın korunması; acente CRM ekranlarında müşterinin tüm geçmişinin görünmesini ve yenileme zamanı geldiğinde doğru bilgiyle hareket edilmesini sağlar. Platformun genel yapısını sigorta acentesi yazılımı sayfasında inceleyebilirsiniz.
Uygulamaya geçmeden önce
Mevcut poliçe listenizi açın ve her sütunun hangi varlığa ait olduğunu işaretleyin. Aynı bilginin birden fazla yerde tekrarlandığı sütunlar, modelinizde ayrıştırılması gereken noktaları gösterir. Bu basit egzersiz, yazılıma geçiş veya mevcut sistemi iyileştirme kararında size somut bir başlangıç sağlar. Kendi veri yapınızı bir platform üzerinde görmek isterseniz demo talebi oluşturabilirsiniz.