Acente yazılımlarında teklif süreci, yazılımın kendi kontrolünde olmayan bir halkaya bağlıdır: sigorta şirketlerinin servisleri. Bir şirketin servisi yavaşladığında, bakımdayken ya da beklenmedik bir hata döndürdüğünde, acente yazılımının nasıl davrandığı çalışanın o anki deneyimini doğrudan belirler. İyi tasarlanmış bir sistemde tek bir şirketteki sorun yalnızca o şirketin sonucunu etkiler; kötü tasarlanmış bir sistemde ise bütün teklif ekranını kilitleyebilir.
Bu yazıda entegrasyon kesintilerine dayanıklı bir teklif akışının hangi ilkelere dayandığını ve acente çalışanlarının bu tür durumlarda nasıl hareket edebileceğini ele alıyoruz.
Entegrasyon kesintilerinin türleri
Dış servislerle yaşanan sorunlar tek tip değildir. Doğru tepkiyi verebilmek için türlerini ayırmak gerekir:
- Tam kesinti: Servis hiç yanıt vermez ya da bağlantı kurulamaz.
- Yavaşlama: Servis yanıt verir ama normalden çok daha uzun sürede.
- Kısmi hata: Bazı ürünler ya da bazı sorgu tipleri için hata döner, diğerleri çalışır.
- Planlı bakım: Şirket, servisini belirli saatlerde kapatır.
- Format değişikliği: Şirket servisinde yapılan bir değişiklik, yanıtların beklenen biçimde gelmemesine yol açar.
Her türün kullanıcıya yansıması farklıdır ve her biri için farklı bir koruma mekanizması gerekir.
Dayanıklı tasarımın temel ilkeleri
Branş akışlarının ayrılması
Trafik, kasko ve DASK teklifleri farklı veri girdilerine ve farklı şirket servislerine dayanır. Bu akışların birbirinden ayrı tasarlanması, bir branştaki sorunun diğerlerini etkilememesini sağlar. Örneğin kasko servislerinde yaşanan bir yavaşlama, aynı müşteri için hazırlanan DASK teklifini bekletmemelidir.
Şirket bazında izolasyon
Aynı branş içinde de her sigorta şirketine yapılan istekler bağımsız yürütülmelidir. Bir şirketin yanıt vermemesi, diğer şirketlerden gelen sonuçların ekranda görüntülenmesini geciktirmemelidir. Kullanıcı gelen sonuçları görmeye başlarken bekleyen şirketler ayrıca işaretlenir.
Zaman aşımı
Her dış isteğe makul bir bekleme süresi tanımlanmalıdır. Bu süre aşıldığında istek sonlandırılır ve kullanıcıya o şirketten şu an sonuç alınamadığı bildirilir. Zaman aşımı olmayan bir istek, sistem kaynaklarını gereksiz yere meşgul eder ve kullanıcıyı belirsiz bir beklemede bırakır.
Devre kesici
Bir şirketin servisi art arda hata veriyorsa, her yeni teklif için o servise istek göndermeye devam etmek hem kaynak israfıdır hem de kullanıcıyı bekletir. Devre kesici yaklaşımında, belirli sayıda hata sonrasında o servise kısa bir süre istek gönderilmez; ardından deneme amaçlı birkaç istekle servisin düzelip düzelmediği kontrol edilir. Servis düzeldiğinde akış normale döner.
Kontrollü yeniden deneme
Geçici bağlantı sorunlarında isteğin otomatik olarak bir kez daha denenmesi faydalı olabilir. Ancak yeniden denemeler sınırlı tutulmalı ve aralıklı yapılmalıdır; aksi halde zaten zorlanan bir servise ek yük bindirilmiş olur.
Anlaşılır durum bilgisi
Kullanıcı, her şirket için sonucun geldiğini, beklendiğini ya da şu an alınamadığını açıkça görebilmelidir. "Bir hata oluştu" gibi genel mesajlar yerine "Bu şirketten şu anda yanıt alınamıyor, diğer sonuçlar aşağıdadır" gibi yönlendirici ifadeler kullanılmalıdır.
Format değişikliklerine karşı hazırlık
Şirket servislerinde yapılan değişiklikler bazen önceden duyurulmadan gerçekleşebilir. Bu tür durumların etkisini azaltmak için yazılım tarafında şu önlemler alınabilir:
- Gelen yanıtların beklenen yapıda olup olmadığının doğrulanması ve beklenmedik yanıtların ayrıca kayıt altına alınması.
- Her şirket entegrasyonunun hata oranının ayrı izlenmesi; ani bir artışın teknik ekibe hızla iletilmesi.
- Bir entegrasyondaki düzeltmenin diğer entegrasyonları etkilemeden yayınlanabilmesi.
Entegrasyon sağlığının görünür kılınması
Dayanıklı bir teklif akışının tamamlayıcı parçası, entegrasyonların sağlık durumunun hem teknik ekip hem de kullanıcı tarafından görülebilmesidir. Teknik tarafta her şirket ve her branş için yanıt süresi, başarı oranı ve devre kesici durumunun izlenmesi, sorunların şirkete hızla bildirilmesini sağlar. Kullanıcı tarafında ise bilinen bir sorunun teklif ekranında kısa bir uyarıyla gösterilmesi, çalışanın aynı sorguyu defalarca denemesini önler. Bu görünürlük, destek hattına gelen tekrar eden soruları da azaltır.
Çalışan açısından pratik davranış
Teknik tasarım ne kadar iyi olursa olsun, acente çalışanının da bu durumlara hazırlıklı olması faydalıdır:
- Bir şirketten sonuç gelmediğinde gelen diğer sonuçlarla müşteriyle görüşmeye devam edin.
- Eksik kalan şirket için teklifi daha sonra yeniden sorgulamak üzere bir görev ya da not oluşturun.
- Müşteriye karşılaştırmanın bir kısmının daha sonra tamamlanacağını açıkça belirtin.
- Sorun uzun sürüyorsa ve müşteri o şirketin teklifini özellikle istiyorsa, şirketin kendi acente kanallarını geçici olarak kullanmayı değerlendirin.
- Aynı sorunun tekrarlandığını fark ederseniz, saat ve branş bilgisiyle destek ekibine iletin.
Örnek akış: Kasko karşılaştırmasında bir şirketin yanıt vermemesi
Bir çalışan, müşterisi için kasko teklif akışını başlatır ve araç bilgisini plakadan getirir. Sorgu birkaç şirkete paralel olarak gönderilir. Sonuçların çoğu kısa sürede ekrana gelirken bir şirketin satırı "yanıt bekleniyor" olarak kalır ve belirlenen süre dolduğunda "şu an sonuç alınamıyor" bilgisine dönüşür. Çalışan gelen sonuçlarla karşılaştırmayı müşteriyle paylaşır, eksik şirket için bir hatırlatma görevi oluşturur ve PDF teklif formunu mevcut sonuçlarla hazırlar. Aynı gün içinde servis düzeldiğinde teklif yeniden sorgulanır ve müşteriye güncel karşılaştırma iletilir.
Bu akışta kritik olan, tek bir şirketin sorununun bütün görüşmeyi durdurmamasıdır.
InsureHub bakış açısı
InsureHub, sigorta acentelerine yazılım sağlayan bir şirket olarak trafik, kasko ve DASK tekliflerini ayrı sorgu akışları olarak ele alır; plakadan EGM araç sorgusu, şirket bazlı sonuç gösterimi ve PDF teklif formu bu akışların parçalarıdır. Teklif sürecinin yapısını sigorta teklif programı sayfasında, müşteri ve görev takibini ise acente CRM sayfasında inceleyebilirsiniz. Kendi iş akışınızı denemek için demo talebi oluşturabilirsiniz.
Sonuç
Sigorta şirketi servislerindeki kesintiler acente yazılımının kontrolü dışındadır; ancak bu kesintilerin acenteye nasıl yansıyacağı tamamen tasarımın sonucudur. Branş ayrımı, şirket bazında izolasyon, zaman aşımı ve anlaşılır durum bilgisi, dış bir sorunun acentenin gününü durdurmasını engeller.