Tek form fikri neden cazip görünür?
Bir müşteri acenteye geldiğinde çoğu zaman birden fazla ihtiyaçla gelir. Aracının trafik sigortası yenilenecektir, kasko teklifi görmek ister ve konutunun DASK poliçesi de yaklaşmaktadır. Bu durumda tüm bilgileri tek bir formda toplayıp üç sorguyu birden başlatmak ilk bakışta verimli görünür. Daha az ekran, daha az tıklama ve tek seferde biten bir süreç vaat eder.
Ancak pratikte bu yaklaşım, formun karmaşıklaşmasına, doğrulama kurallarının iç içe geçmesine ve hataların kaynağının belirsizleşmesine yol açar. InsureHub'da trafik, kasko ve DASK için ayrı teklif sorgu akışları bulunmasının nedeni de budur. Bu yazıda ayrı akışların neden daha sağlıklı bir yapı olduğunu farklı açılardan ele alıyoruz.
Farklı branş, farklı veri
Üç branşın ihtiyaç duyduğu bilgiler büyük ölçüde birbirinden farklıdır. Trafik sigortasında araç ve ruhsat bilgisi merkezdedir. Kaskoda araç tanımı çok daha ayrıntılıdır; marka, model, paket, kullanım tarzı, ek teminatlar ve muafiyet tercihleri devreye girer. DASK ise araçla hiç ilgilenmez; adres kodu, yapı tarzı, inşa yılı ve brüt alan gibi konut bilgilerine dayanır.
Bu bilgileri tek bir formda toplamak, her kullanıcıyı kendi işiyle ilgisi olmayan alanlarla karşı karşıya bırakır. Yalnızca DASK teklifi isteyen bir müşteri için araç alanlarının gizlenmesi gerekir; yalnızca trafik isteyen biri için kasko alanlarının. Bu koşullu gizleme mantığı büyüdükçe form, bakımı zor ve hataya açık bir yapıya dönüşür.
Doğrulama kuralları birbirine karışır
Her branşın kendi zorunlu alanları ve kontrolleri vardır. Tek formda bu kuralların hangi durumda geçerli olduğunu yönetmek giderek zorlaşır.
Tek formda ortaya çıkan tipik sorunlar
- Bir branş seçilmediği halde onun zorunlu alanlarının sorguyu engellemesi
- Aynı alanın iki branşta farklı anlamlarla kullanılması
- Bir alandaki hatanın hangi sorguyu etkilediğinin anlaşılamaması
- Kuralların değiştirilmesi gerektiğinde diğer branşların beklenmedik biçimde etkilenmesi
Ayrı akışlarda her formun doğrulama kuralları yalnızca o branşı ilgilendirir. Kasko formunda yapılan bir değişiklik trafik formunu bozmaz; DASK formuna eklenen yeni bir alan araç formlarını etkilemez.
Hata yönetimi netleşir
Üç sorgunun tek bir işlem olarak başlatıldığını düşünelim. Trafik sorgusu tamamlanır, kasko sorgularından bazıları zaman aşımına uğrar ve DASK sorgusu adres kodu nedeniyle hata verir. Kullanıcıya bu durumu tek bir sonuç ekranında anlatmak oldukça zordur. Hangi hatanın hangi branşa ait olduğu, hangisinin yeniden denenmesi gerektiği karışır.
Ayrı akışlarda her sorgunun durumu bağımsızdır. Trafik teklifi tamamlanmış olarak işaretlenir, kasko için kısmi sonuç bilgisi gösterilir, DASK için ise adres düzeltmesi istenir. Çalışan her akışı kendi içinde yönetir ve sorunlu olanı diğerlerini etkilemeden yeniden çalıştırabilir.
Sigorta şirketi entegrasyonları açısından
Sigorta şirketleriyle yapılan entegrasyonlar da branş bazında farklı çalışır. Bir sigorta şirketinin trafik sorgusu için beklediği bilgiler ve yanıt biçimi, aynı şirketin DASK sorgusundan farklıdır. Entegrasyon katmanında branşların ayrı ele alınması, her bağlantının kendi kurallarıyla bakımının yapılmasını kolaylaştırır. Bir şirketin kasko sorgusunda yaşanan bir değişiklik, aynı şirketin trafik sorgularını etkilemeden düzeltilebilir.
Ayrı akış, tekrar veri girişi demek değildir
Ayrı akışlara yöneltilen en yaygın itiraz, aynı müşteri bilgilerinin üç kez girilmesi gerekeceğidir. Doğru kurgulanmış bir sistemde bu böyle olmamalıdır. Müşterinin kimlik ve iletişim bilgileri ortak müşteri kaydında tutulur; her akış bu kayıttan beslenir.
Ortak ve branşa özgü bilgilerin ayrılması
- Kimlik, iletişim ve adres gibi müşteri bilgileri ortak kayıtta tutulur
- Araç bilgisi araç kaydında tutulur ve trafik ile kasko akışlarına aktarılabilir
- Konut bilgisi konut kaydında tutulur ve DASK akışında kullanılır
- Branşa özgü seçimler, örneğin kasko teminatları, yalnızca ilgili teklif kaydında yer alır
Bu yapı sayesinde çalışan trafik teklifini tamamladıktan sonra tek bir kısayolla aynı araç için kasko akışını başlatabilir. Araç ve müşteri bilgileri hazır gelir; yalnızca kaskoya özgü sorular sorulur. Bu yaklaşım müşteri verisini acente CRM üzerinde tek bir yerde tutarken akışları ayrı bırakır.
Raporlama ve sorumluluk
Ayrı akışlar raporlamayı da netleştirir. Yönetici hangi branşta ne kadar teklif hazırlandığını, hangi branşta daha sık hata yaşandığını ya da hangi branşın poliçeye dönüşme sürecinin daha uzun sürdüğünü ayrı ayrı görebilir. Tek formda başlatılan birleşik işlemlerde bu ayrımı sonradan yapmak hem teknik olarak zorlaşır hem de raporların güvenilirliği azalır.
Ekip içi sorumluluk dağılımı da kolaylaşır. Bazı acentelerde kasko teklifleriyle daha deneyimli çalışanlar ilgilenirken trafik yenilemeleri farklı bir ekip tarafından yürütülebilir. Ayrı akışlar bu iş bölümünü doğal biçimde destekler.
Müşteri deneyimi açısından
Müşteri için önemli olan, ihtiyaçlarının hızlı ve doğru biçimde karşılanmasıdır. Ayrı akışlar, müşteriye her branş için ayrı ve anlaşılır bir sunum yapılmasını sağlar. Trafik sonuçları ile kasko seçenekleri aynı tabloda karışık biçimde gösterilmez; her biri kendi bağlamında değerlendirilir. Bu, müşterinin karar vermesini kolaylaştırır.
Geçiş kısayolları
Ayrı akışların kullanım kolaylığını artırmanın en pratik yolu, akışlar arasında akıllı geçiş kısayolları sunmaktır. Trafik teklifi tamamlandığında "aynı araç için kasko teklifi başlat", DASK teklifi açıldığında ise "müşterinin kayıtlı adresini kullan" gibi kısayollar, çalışanın bağlamı kaybetmeden ilerlemesini sağlar.
Sonuç
Trafik, kasko ve DASK sorgularını tek formda birleştirmek kısa vadede pratik görünse de veri modeli, doğrulama, hata yönetimi ve raporlama açısından ciddi karmaşıklık yaratır. Ortak müşteri, araç ve konut kayıtlarından beslenen ayrı akışlar ise hem sadeliği hem de hızı birlikte sağlar. Bu yapının sigorta teklif programı içinde nasıl çalıştığını görmek için demo talebi oluşturabilirsiniz.