Bir acente çalışanı gün içinde onlarca teklif formu açar. Her form, ekrana yerleştirilmiş bir dizi sorudan ibarettir ve her soru kullanıcıdan biraz dikkat, biraz zaman ister. Formdaki alan sayısı arttıkça hata ihtimali, yarıda bırakılan kayıt sayısı ve müşteriyi telefonda bekletme süresi de artar. InsureHub olarak acentelere yazılım geliştirirken sık karşılaştığımız soru şudur: Bu alan gerçekten burada, şu anda, bu kullanıcıdan istenmeli mi?
Bu yazıda teklif formlarını sadeleştirmek için kullanılabilecek pratik yöntemleri ele alıyoruz. Amaç bilgiden vazgeçmek değil; doğru bilgiyi doğru anda, en az zahmetle toplamaktır.
Önce Envanter: Formdaki Her Alanın Bir Gerekçesi Olmalı
Sadeleştirme, formdaki alanların listesini çıkarmakla başlar. Her alan için üç soru sorulur:
- Bu bilgi teklif hesaplaması için zorunlu mu? Sigorta şirketine iletilmeyen ya da fiyatı etkilemeyen bir alan, teklif aşamasında beklemeye alınabilir.
- Bu bilgi başka bir kaynaktan gelebilir mi? Müşteri kaydında, önceki poliçede veya resmi bir sorgu sonucunda zaten bulunan veri yeniden yazdırılmamalıdır.
- Bu bilgiyi kim, ne zaman kullanıyor? Sadece raporlama için tutulan bir alan, teklifi yavaşlatmamalıdır.
Bu envanter çoğu zaman şaşırtıcı sonuçlar verir. Yıllar içinde "belki lazım olur" diye eklenmiş alanlar, kimsenin doldurmadığı ya da rastgele değerlerle geçiştirildiği alanlar ortaya çıkar. Doldurulmayan bir alan veri kalitesine katkı sağlamaz; yalnızca formu uzatır.
Branşa Göre Ayrışan Formlar
Trafik, kasko ve DASK teklifleri farklı bilgilere ihtiyaç duyar. Trafik teklifi için araç ve ruhsat bilgileri öne çıkarken, kasko teklifinde aracın kullanım şekli ve ek teminat tercihleri devreye girer. DASK ise tamamen farklı bir eksende, bina ve adres bilgileri üzerinden ilerler. Tek bir "genel teklif formu" içinde bütün bu alanları göstermek, kullanıcıyı kendisiyle ilgisiz sorularla meşgul eder.
Bu nedenle her branşın kendi sorgu akışına sahip olması hem teknik hem deneyim açısından doğru yaklaşımdır. Teklif programı içinde kullanıcı önce branşı seçer, ardından yalnızca o branşın gerektirdiği alanları görür. Ortak alanlar, örneğin müşteri kimlik bilgisi, bir kez girilir ve farklı branş akışlarında yeniden kullanılır.
Otomatik Doldurma ile Yazmayı Azaltmak
Bir alanı kaldıramıyorsanız, en azından kullanıcının o alanı yazmasını engelleyebilirsiniz. Bunun birkaç yolu vardır:
- Kayıtlı müşteriden aktarım: Müşteri CRM kaydında mevcutsa kimlik, iletişim ve adres bilgileri forma otomatik gelir.
- Sorgu sonuçlarından aktarım: Araç bilgisi sorgusu yapılabildiğinde marka, model ve yıl gibi alanlar elle seçilmek yerine sorgu sonucundan doldurulur.
- Önceki tekliften kopyalama: Aynı müşteri için daha önce teklif alınmışsa, yeni teklif bu kayıttan türetilebilir ve yalnızca değişen alanlar düzenlenir.
- Mantıklı varsayılan değerler: Acentenin en sık kullandığı seçenek varsayılan olarak işaretlenebilir; ancak fiyatı doğrudan etkileyen seçimlerde varsayılan değer kullanıcıya görünür biçimde sunulmalıdır.
Otomatik doldurulan alanlarda dikkat edilmesi gereken nokta şeffaflıktır. Kullanıcı hangi bilginin nereden geldiğini görebilmeli ve gerekirse düzeltebilmelidir. Görünmez biçimde doldurulan bir alan, hata çıktığında kimsenin fark etmediği bir kör nokta haline gelir.
Koşullu Alanlar: Sadece Gerektiğinde Göster
Bazı alanlar yalnızca belirli bir cevaptan sonra anlam kazanır. Örneğin kaskoda ek sürücü bilgisi, kullanıcı "ek sürücü var" seçeneğini işaretlediğinde gerekir. Bu tür alanları baştan göstermek yerine, ilgili seçimden sonra açılmalarını sağlamak formu kısa tutar.
Koşullu alan kullanırken iki kurala dikkat etmek gerekir:
- Yeni açılan alanlar, onları tetikleyen seçimin hemen altında belirmelidir. Sayfanın başka bir yerinde ortaya çıkan alan gözden kaçar.
- Kullanıcı seçimini geri aldığında, gizlenen alanlardaki veri sessizce gönderilmeye devam etmemelidir.
Ertelenebilir Bilgiyi Poliçeleşme Aşamasına Bırakmak
Teklif ve poliçeleşme aynı süreç değildir. Teklif aşamasında müşteri çoğu zaman fiyat ve teminat karşılaştırması yapmak ister. Bu aşamada fatura adresi, ikinci telefon numarası veya iletişim tercihleri gibi bilgileri istemek, henüz karar vermemiş bir müşteri için gereksiz bir yüktür.
Bu bilgileri müşteri teklifi kabul edip poliçeleşme adımına geçtiğinde istemek hem acente çalışanının hem de müşterinin zamanını korur. Böylece teklif formu hızlı kalır, poliçeleşme formu ise ihtiyaç duyulan tüm ayrıntıyı toplar.
Alan Birleştirme ve Akıllı Giriş
Bazen iki ayrı alan tek bir alanda birleştirilebilir. Ad ve soyad için ayrı kutular yerine kimlik numarasıyla başlayan bir akış, kayıtlı kişiyi bulup bilgileri getirebilir. Tarih girişinde gün, ay ve yıl için üç ayrı açılır liste yerine tek bir biçimlendirilmiş alan daha hızlıdır. İl ve ilçe seçiminde, il seçildikten sonra ilçe listesinin daraltılması kullanıcıyı uzun listelerde kaydırmaktan kurtarır.
Sadeleştirmenin Etkisini Nasıl Gözlemlersiniz?
Bir formu kısalttıktan sonra değişikliğin işe yarayıp yaramadığını anlamak için doğrudan kullanıcıları izlemek en değerli yöntemdir. Birkaç acente çalışanından gerçek bir müşteri senaryosuyla formu doldurmasını isteyin ve nerede duraksadıklarını not edin. Ek olarak yazılım tarafında şu sinyaller takip edilebilir:
- Formun başlatılıp tamamlanmadan bırakıldığı adımlar,
- En sık hata mesajı üreten alanlar,
- Kullanıcıların sıkça geri dönüp düzelttiği alanlar.
Bu sinyaller, bir sonraki sadeleştirme turunda hangi alana odaklanılacağını gösterir.
Örnek: Bir Kasko Formunun Sadeleştirilmesi
Bir kasko formunu düşünelim. Başlangıçta müşteri kimlik bilgileri, iletişim bilgileri, adres, araç bilgileri, kullanım tarzı, ek sürücüler, teminat tercihleri ve fatura bilgileri aynı ekranda istenir. Envanter çalışmasından sonra kimlik bilgisi girildiğinde kayıtlı müşterinin iletişim ve adres bilgileri otomatik gelir, plaka ile araç bilgileri sorgudan doldurulur, ek sürücü alanları yalnızca ilgili seçim yapıldığında açılır, fatura bilgileri ise poliçeleşme adımına taşınır. Kullanıcının elle doldurduğu alanlar belirgin biçimde azalır; ancak sistemin topladığı bilgi eksilmez.
Kısa Form, Eksik Veri Demek Değildir
Alan azaltmanın yanlış anlaşılan tarafı, verinin eksik kalacağı endişesidir. Oysa iyi tasarlanmış bir akışta veri azalmaz; doğru zamana ve doğru kaynağa taşınır. Otomatik doldurulan, koşullu açılan ve poliçeleşmeye ertelenen alanlar sayesinde kullanıcı daha az yazar, ama sistem yine de ihtiyaç duyduğu bilgiyi toplar.
InsureHub'da teklif formlarını tasarlarken bu ilkeyi temel alıyoruz: Kullanıcıya yalnızca o adımda cevaplayabileceği ve cevaplaması gereken soruları sormak. Kendi formlarınızı bu gözle incelemek isterseniz demo talebi üzerinden branş bazlı teklif akışlarını birlikte değerlendirebiliriz.