Bağlantının tamamen kesildiği durum aslında yönetmesi daha kolay olanıdır; uygulama bunu fark eder ve kullanıcıyı bilgilendirir. Asıl zorlu senaryo, sinyalin ne tam var ne tam yok olduğu ara durumlardır. Telefon çekiyor görünür, istekler gider ama yanıtlar gecikir, bazıları yarıda kalır. Sahada teklif almaya çalışan bir acente çalışanı için bu belirsizlik hem zaman kaybı hem de müşteri önünde güven kaybı demektir.
Bu yazıda, zayıf sinyal altında bir teklif isteğinin yolculuğunu adım adım ele alıyor ve bir acente uygulamasının her adımda nasıl davranması gerektiğini InsureHub'ın yazılım sağlayıcı bakış açısıyla değerlendiriyoruz.
Teklif isteği neden hassastır?
Teklif, birden fazla sigorta şirketinin sisteminden yanıt beklenen bir işlemdir. Uygulama isteği acente yazılımının sunucusuna iletir, sunucu ilgili şirketlerle iletişim kurar ve yanıtlar geldikçe ekrana yansır. Bu zincirin herhangi bir halkasında yaşanan gecikme, kullanıcıya aynı şekilde "bekliyor" olarak görünür. Zayıf bağlantıda ise gecikmenin nereden kaynaklandığı daha da bulanıklaşır.
Ayrıca trafik, kasko ve DASK ayrı sorgu akışlarıdır. Her birinin istediği bilgiler, sorgulama adımları ve yanıt yapısı farklıdır. Bu yüzden zayıf bağlantı tasarımında "teklif" tek bir işlem gibi değil, branşa özgü ayrı istekler olarak ele alınmalıdır.
Bir isteğin yolculuğu: Altı adım
- Form doğrulaması cihazda yapılır. Eksik plaka, hatalı kimlik numarası biçimi ya da boş adres alanı gibi hatalar sunucuya gitmeden yakalanmalıdır. Zayıf bağlantıda her gereksiz gidiş dönüş, dakikalar kaybettirir.
- İstek önce cihazda kayda alınır. Gönder düğmesine basıldığı anda form verisi cihazda saklanmalıdır. Bağlantı yarıda kalırsa kullanıcı formu yeniden doldurmak zorunda kalmamalıdır.
- İsteğe benzersiz bir kimlik verilir. Aynı istek ağ sorunu nedeniyle iki kez gönderilirse, sunucu bunu tek bir istek olarak tanımalıdır. Aksi hâlde aynı müşteri için mükerrer teklif kayıtları oluşur.
- Sunucuya ulaşma ile sonuç bekleme ayrılır. Uygulama, isteğin sunucuya ulaştığını teyit ettiği anda kullanıcıya bunu bildirmelidir. Sonuçların gelmesi ayrı bir aşamadır ve bağlantı kopsa bile sunucu tarafında devam edebilir.
- Yeniden deneme kademeli yapılır. Başarısız gönderimler hemen ve sürekli tekrarlanırsa hem pil hem veri tüketilir, hem de zaten zorlanan bağlantı daha da yorulur. Denemeler arasında giderek artan bekleme süreleri kullanmak daha sağlıklıdır.
- Sonuçlar bağlantı gelince çekilir. Kullanıcı başka bir ekrana geçse ya da uygulamayı kapatsa bile, teklif sonuçları bağlantı sağlandığında ilgili kayıtta hazır olmalıdır.
Kullanıcıya ne söylenmeli?
Zayıf bağlantıda en büyük sorun belirsizliktir. Dönen bir yükleme simgesi, çalışana hiçbir şey anlatmaz. Ekranda şu ayrımların yapılması, temsilcinin müşteriyle konuşmasını da kolaylaştırır:
- "Bilgiler cihazda saklandı, gönderiliyor"
- "İstek sunucuya ulaştı, şirket yanıtları bekleniyor"
- "Bazı şirketlerden yanıt geldi, diğerleri bekleniyor"
- "Bağlantı zayıf, yeniden denenecek; isterseniz ekrandan ayrılabilirsiniz"
Bu ifadeler sayesinde temsilci, müşteriye gerçekçi bir bilgi verebilir: "Talebiniz sisteme ulaştı, sonuçları birkaç dakika içinde size iletebilirim." Belirsiz bir bekleme yerine kontrollü bir süreç yönetilmiş olur.
Zaman aşımını doğru ayarlamak
Çok kısa zaman aşımı süresi, aslında yolda olan isteklerin başarısız sayılmasına neden olur. Çok uzun süre ise kullanıcıyı gereksiz yere bekletir. Bu dengeyi kurmanın yolu, zaman aşımını tek bir değer olarak değil, aşamalara göre düşünmektir. Bağlantı kurma, isteği iletme ve yanıt bekleme aşamaları için ayrı sınırlar belirlemek, sorunun nerede olduğunu da görünür kılar.
Sigorta şirketlerinin yanıt süreleri acente yazılımının kontrolünde değildir. Bu nedenle uygulama, şirket tarafındaki gecikmeyi kullanıcının bağlantı sorunu gibi göstermemelidir. Bu ayrım, sahadaki çalışanın gereksiz yere cihazını ya da hattını suçlamasını önler.
Sunucu tarafında neler beklenmeli?
Zayıf bağlantı yalnızca mobil uygulamanın sorunu değildir; sunucunun da bu duruma göre tasarlanması gerekir. Uygulamadan gelen bir teklif isteği sunucuya ulaştıktan sonra, cihazla bağlantı kopsa bile işlem devam edebilmelidir. Sunucu, gelen yanıtları ilgili teklif kaydına yazmalı ve cihaz yeniden bağlandığında yalnızca eksik kalan kısmı göndermelidir. Her bağlantıda tüm sonuçların baştan indirilmesi, zaten sınırlı olan bant genişliğini gereksiz yere tüketir.
Bunun yanında sunucunun aynı benzersiz kimlikle gelen ikinci isteği tanıması, mükerrer kayıt oluşmasını engelleyen son savunma hattıdır. Uygulama tarafında yapılan önlemler ne kadar iyi olursa olsun, ağ katmanında yaşanan tekrarlar ancak sunucu tarafında güvenle ayıklanabilir. Acente yöneticisi açısından bunun karşılığı nettir: Raporlarda görünen teklif sayıları, gerçekte yapılan sorguları yansıtır.
Ekip için pratik alışkanlıklar
- Bağlantının zayıf olduğu bilinen bölgelere gitmeden önce müşteri bilgilerini ve gerekli belgeleri mümkün olduğunca önceden sisteme girin.
- Teklif isteği gönderdikten sonra ekranda beklemek yerine, müşteriyle görüşmeye devam edin; sonuçlar kayda düşecektir.
- Aynı isteği art arda göndermeyin. Uygulama yeniden denemeyi kendisi yönetiyorsa, tekrar basmak yalnızca karışıklık yaratır.
- Ziyaret bitiminde bekleyen istek olup olmadığını kontrol edin.
Branşa göre farklı bekleme davranışı
Trafik, kasko ve DASK akışlarının ayrı tutulması, zayıf bağlantıda da avantaj sağlar. Örneğin aynı müşteri için hem trafik hem DASK sorgusu yapılacaksa, uygulama iki isteği bağımsız kuyruklarda yönetebilir. Trafik isteği sunucuya ulaşıp sonuç beklerken DASK isteği adres bilgisinin tamamlanmasını bekleyebilir. Tek bir birleşik istek kurgusunda ise bir branştaki sorun diğerini de bekletir. Ayrı akışlar, çalışanın hangi işin tamamlandığını ve hangisinin beklediğini daha net görmesini sağlar.
Değerlendirme notu
Bir sigorta teklif programı değerlendirirken ideal bağlantıda yapılan demolar yanıltıcı olabilir. Telefonunuzun geliştirici ayarlarından ya da bilinçli olarak zayıf sinyal alan bir noktadan deneme yapmak, uygulamanın gerçek saha davranışını gösterir. Formu doldurup gönderin, ardından bağlantıyı kısa süreliğine kesin ve geri açın. İstek kayboldu mu, mükerrer oldu mu, yoksa kaldığı yerden devam mı etti?
InsureHub'ın mobil tarafını kendi saha koşullarınızda denemek için mobil uygulama sayfamızı inceleyebilir, ekibinizle birlikte gerçek bir rota üzerinde test planı yapabilirsiniz.