Kasko ve trafik sigortasında dijital süreçler: tekliften hasara

Kasko ve trafik sigortası yazılımı, oto sigortalarında teklif, fiyatlama, poliçe düzenleme, tahsilat, yenileme ve hasar süreçlerini uçtan uca dijital olarak yöneten sistemlerin bütünüdür. Türkiye'de trafik sigortası, Karayolları Trafik Kanunu kapsamında zorunlu olan Karayolları Motorlu Araçlar Zorunlu Mali Sorumluluk Sigortası'dır ve aracın üçüncü kişilere verdiği zararları karşılar. Kasko ise aracın kendisinde oluşan zararları karşılayan isteğe bağlı bir üründür.

İki ürün aynı araç, aynı müşteri ve çoğu zaman aynı acente üzerinden satılır; ancak fiyatlama mantıkları, düzenleyici yükümlülükleri ve hasar süreçleri belirgin biçimde ayrılır. Oto branşı aynı zamanda fiyat karşılaştırmasının en hızlı yapıldığı, müşterinin her yıl yeniden karar verdiği alandır. Bu yüzden dijital süreçlerin hızı ve tutarlılığı, bu branşta doğrudan rekabet gücü anlamına gelir.

Kasko ve trafik sigortası arasında süreç farkları nelerdir?

Trafik sigortası zorunlu ve düzenleyici çerçevesi sıkı bir üründür; kasko ise şirketin ürün ve fiyatlama esnekliğine açık, rekabetçi bir üründür. Yazılım mimarisi bu farkı ürün bazında ayrı kurallar ve iş akışlarıyla yansıtmalıdır.

Bu farklar, iki ürünün aynı platformda ama bağımsız kural setleriyle yönetilmesi gerektiğini gösterir. Trafik tarifesindeki bir düzenleyici değişiklik kasko kurallarına dokunmadan, kaskodaki bir kampanya da trafik fiyatlamasını etkilemeden devreye alınabilmelidir. Tarife yapısının ayrıntıları sigorta tarife kurgusu yazısında ele alınmıştır.

Teklif ve poliçe süreci dijital olarak nasıl işler?

Dijital oto sigortası süreci, birkaç temel bilgiyle başlayıp saniyeler içinde fiyatlanmış bir teklif üretmeyi hedefler. Bunu mümkün kılan, dış veri kaynaklarının otomatik sorgulanması ve fiyatlama motorunun anlık çalışmasıdır.

1. Asgari girdi: Müşteri veya acente plaka, sigortalının kimlik numarası ve ruhsat belge seri numarası gibi temel bilgileri girer.
2. Dış sorgular: Araç marka, model, kullanım tarzı ve geçmiş poliçe ile hasar bilgisi SBM üzerinden sorgulanır. Kasko için araç değeri, sistemde güncel tutulan kasko değer listesinden alınır.
3. Risk verisinin tamamlanması: Sorgudan dönmeyen bilgiler, örneğin ek donanım, kullanım amacı veya sürücü bilgileri müşteriden istenir. Form, mümkün olduğunca varsayılan değerlerle kısa tutulur.
4. Fiyatlama: Trafik için düzenleyici kurallar ve şirket tarifesi, kasko için risk faktörleri ve kampanyalar fiyatlama motoru üzerinde çalıştırılır. Kaskoda birden fazla paket seçeneği aynı anda üretilir.
5. Risk kabul kontrolleri: Belirli araç tipleri, yüksek değerli araçlar veya olumsuz hasar geçmişi gibi durumlar otomatik reddedilir ya da manuel risk kabulüne yönlendirilir. Kaskoda gerekirse araç fotoğrafları veya ön ekspertiz istenir.
6. Ödeme: Kredi kartıyla 3D Secure doğrulamalı tahsilat, taksit seçenekleri ve banka kampanyaları işlenir.
7. Poliçe düzenleme ve bildirim: Poliçe numarası üretilir, poliçe SBM'ye bildirilir ve belge elektronik olarak müşteriye ve acenteye iletilir.

Bu akış web, mobil uygulama, acente ekranı ve karşılaştırma platformları gibi farklı kanallarda aynı servisleri kullanmalıdır. Kanal başına ayrı fiyatlama ya da ayrı kural seti tutmak tutarsız fiyatlara ve yönetilemez bir bakım yüküne yol açar. Kanal mimarisi için dijital sigorta satış kanalları yazısına bakılabilir.

SBM entegrasyonu neden kritiktir?

Oto sigortalarında Sigorta Bilgi ve Gözetim Merkezi (SBM) entegrasyonu hem veri kaynağı hem de bildirim noktasıdır; entegrasyon yavaşsa teklif yavaşlar, hatalıysa fiyat ve bildirim hatalı olur. Bu nedenle SBM servisleri oto sigortası yazılımının en kritik dış bağımlılığıdır.

İyi bir tasarımda SBM çağrıları tek bir entegrasyon katmanında toplanır; zaman aşımları, yeniden deneme kuralları ve hata kodlarının iş anlamına çevrilmesi burada yönetilir. SBM sorgu sonuçları, teklifin fiyatlandığı andaki verinin kanıtı olarak teklifle birlikte saklanmalıdır; sonradan gelen itirazlarda fiyatın hangi veriye dayandığı gösterilebilmelidir. Bildirim tarafında poliçe, zeyil ve iptal kayıtlarının SBM'ye ulaşıp ulaşmadığı izlenmeli, başarısız bildirimler otomatik olarak yeniden işlenecek bir kuyruğa alınmalıdır. Ayrıntılar SBM ve TRAMER entegrasyonu yazısında ele alınmıştır.

Oto hasar süreci nasıl dijitalleştirilir?

Oto hasar sürecinin dijitalleşmesi, ihbarın ilk dakikasından ödemeye kadar belge, fotoğraf ve karar akışını tek bir dosyada toplamak demektir. Kaskoda odak aracın onarımı, trafik sigortasında ise karşı tarafın zararının tespiti ve ödenmesidir.

İhbar ve ilk bildirim

Hasar ihbarı mobil uygulama, web, çağrı merkezi veya acente üzerinden alınabilir. Kaza tespit tutanağının mobil ortamda düzenlenebilmesi, fotoğrafların konum ve zaman bilgisiyle yüklenmesi ve karşı taraf araç bilgisinin plaka üzerinden sorgulanması ilk bildirimin kalitesini artırır. Eksik bilgiyle açılan dosya sonraki her adımı yavaşlatır; bu yüzden ihbar ekranları hasar tipine göre gerekli bilgileri yönlendirmeli ve eksikleri anında göstermelidir.

Ekspertiz ve onarım

Dosya, hasar tipine ve tahmini tutara göre eksperliğe atanır. Düşük tutarlı ve görünür hasarlarda fotoğraf üzerinden uzaktan ekspertiz, büyük veya karmaşık hasarlarda yerinde ekspertiz tercih edilir. Anlaşmalı servis ağının, parça fiyat listelerinin ve işçilik sürelerinin sistemde tanımlı olması, eksper raporu ile servis faturası arasındaki mutabakatı otomatikleştirir. Görüntü işleme tabanlı hasar tespiti bu aşamada karar desteği sağlar; yöntemler yapay zekâ ile hasar tespiti yazısında anlatılmıştır.

Ödeme, rücu ve pert

Onarım sonrası servise ya da sigortalıya ödeme yapılır. Kusur oranına göre karşı tarafın sigortacısına rücu talepleri oluşturulur; şirketler arası rücu ve mutabakat süreçleri hasar sisteminin ayrı bir modülü olarak yönetilmelidir. Onarımın ekonomik olmadığı durumlarda pert süreci, sovtaj (hasarlı aracın satışı) ve araç kayıt işlemleri ayrı bir iş akışı gerektirir. Sigortasız veya tespit edilemeyen araçların karıştığı kazalarda Güvence Hesabı ile ilişkiler de bu akışın parçasıdır.

Yenileme ve müşteri yaşam döngüsü nasıl yönetilir?

Oto sigortaları yıllık yenilenir ve müşteri her yenilemede yeniden fiyat karşılaştırır; bu nedenle yenileme, yeni satış kadar önemli bir dijital süreçtir. Yenilemenin başarısı, doğru zamanda, doğru fiyatla ve en az sürtünmeyle teklif sunmaya bağlıdır.

• Poliçe bitiş tarihinden yeterli süre önce otomatik yenileme teklifi üretin ve teklifi güncel SBM verisiyle yeniden fiyatlayın.
• Yenileme teklifini acenteye ve müşteriye aynı anda, müşterinin iletişim tercihine göre iletin.
• Trafik ve kasko poliçesi aynı müşteride ise iki ürünün yenilemesini tek bir akışta sunun.
• Yenilemeyen müşterilerin nedenini, örneğin fiyat, hizmet veya araç satışı, yapılandırılmış biçimde kaydedin ve raporlayın.
• Araç satışı, plaka değişikliği ve iletişim bilgisi güncellemesi gibi zeyilleri self servis kanallara açın.

ProdayTech olarak oto branşı projelerinde trafik ve kasko kurallarını aynı platformda ama birbirinden bağımsız sürümlenebilen parametre setleri olarak kurgulamayı tercih ediyoruz; düzenleyici değişikliklerin hızla devreye alınabilmesi büyük ölçüde bu ayrıma bağlıdır.

Kasko ve trafik yazılımı için kontrol listesi

• Teklif en az girdiyle başlayıp dış sorgularla otomatik tamamlanıyor mu?
• Trafik tarife kuralları ve azami prim değişiklikleri kod değişikliği olmadan güncellenebiliyor mu?
• Kasko değer listesi güncellemeleri otomatik yükleniyor ve sürümleniyor mu?
• Tüm kanallar aynı fiyatlama ve risk kabul servislerini kullanıyor mu?
• SBM sorgu sonuçları teklifle birlikte saklanıyor, başarısız bildirimler izleniyor mu?
• Hasar ihbarında fotoğraf, konum ve tutanak bilgisi dijital olarak alınabiliyor mu?
• Anlaşmalı servis, parça ve işçilik fiyatları sistemde tanımlı mı?
• Rücu, pert ve sovtaj süreçleri ayrı iş akışlarıyla yönetiliyor mu?
• Yenileme teklifleri otomatik üretiliyor ve kayıp nedenleri raporlanıyor mu?