Bir teklif hangi durumda?
Acentede gün içinde onlarca teklif kaydı açılır. Bazıları henüz bilgi bekleyen taslaklardır, bazıları sorgulanmaktadır, bazılarının sonuçları gelmiş ve müşteriye sunulmayı beklemektedir. Bu kayıtların hangi durumda olduğu net değilse, ekip içinde "Bu teklif gönderildi mi?" ya da "Bu sorgu neden yarım kaldı?" gibi sorular sürekli tekrarlanır.
Teklif kaydı için tanımlanmış açık bir durum modeli, bu belirsizliği ortadan kaldırır. Her kayıt belirli bir durumdadır, bu durumlar arasındaki geçişler tanımlıdır ve her geçiş kayıt altına alınır. Bu yazıda teklif yaşam döngüsünün nasıl modellenebileceğini ve bu modelin günlük operasyona nasıl katkı sağladığını ele alıyoruz.
Durum modelinin temel durumları
Durumların sayısı ne çok az ne de çok fazla olmalıdır. Çok az durum, önemli ayrımları gizler; çok fazla durum ise kullanıcının hangisini seçeceğini karıştırır. Aşağıdaki liste pratik bir başlangıç noktası sunar.
Önerilen durumlar
- Taslak: bilgiler giriliyor, sorgu henüz başlatılmadı
- Sorgulanıyor: sorgu sigorta şirketlerine gönderildi, yanıtlar bekleniyor
- Tamamlandı: tüm sorgulanan şirketlerden yanıt alındı
- Kısmi: bazı şirketlerden yanıt alındı, bazıları hata ya da zaman aşımıyla sonuçlandı
- Hatalı: hiçbir şirketten geçerli sonuç alınamadı
- Sunuldu: sonuçlar müşteriye iletildi
- Kapandı: teklif poliçeye dönüştü ya da müşteri vazgeçti
Kısmi durumun ayrı tutulması önemlidir. Tamamlandı ve hatalı arasındaki bu ara durum, çalışanın yeniden deneme gerektiren kayıtları kolayca bulmasını sağlar.
Geçiş kuralları
Durumların kendisi kadar, hangi durumdan hangisine geçilebileceği de tanımlanmalıdır. Serbest geçişlere izin veren bir model zamanla tutarsız kayıtlar üretir.
Örnek geçiş kuralları
- Taslaktan yalnızca sorgulanıyor durumuna geçilebilir
- Sorgulanıyor durumundan tamamlandı, kısmi ya da hatalı durumuna sistem tarafından geçilir
- Kısmi ve hatalı durumlardan yeniden deneme ile tekrar sorgulanıyor durumuna dönülebilir
- Tamamlandı ya da kısmi durumdan sunuldu durumuna kullanıcı tarafından geçilir
- Sunuldu durumundan kapandı durumuna geçilirken kapanış nedeni zorunlu olarak seçilir
Bazı geçişlerin sistem, bazılarının kullanıcı tarafından yapılması doğal bir ayrımdır. Sorgunun sonucuna bağlı durumlar sistem tarafından belirlenirken, müşteriyle ilgili durumlar kullanıcının kararıyla değişir.
Durum değişikliklerini kayıt altına almak
Her durum geçişinin zamanı, geçişi yapan kullanıcı ya da sistem bileşeni ve varsa açıklaması kaydedilmelidir. Bu geçmiş, bir teklifin hangi süreçlerden geçtiğini adım adım gösterir. Bir müşteri "Bana teklif ne zaman gönderilmişti?" diye sorduğunda ya da bir yönetici bir sorgunun neden uzun sürdüğünü merak ettiğinde, cevap bu kayıtlardadır.
Durum geçmişi, raporlama açısından da değerlidir. Taslak durumunda uzun süre bekleyen kayıtlar eksik bilgi sorununa, kısmi durumda sık kalan kayıtlar entegrasyon sorununa işaret edebilir.
Durumlara göre iş listeleri
Durum modeli, çalışanın günlük iş listesini oluşturmanın da temelidir. Teklif ekranında kayıtların duruma göre gruplanması, her çalışanın neye odaklanması gerektiğini netleştirir.
- Taslaklar: tamamlanması gereken bilgiler
- Kısmi ve hatalı kayıtlar: yeniden deneme ya da düzeltme gerektiren sorgular
- Tamamlanan kayıtlar: müşteriye sunulmayı bekleyen sonuçlar
- Sunulan kayıtlar: müşteri geri dönüşü beklenen teklifler
Bu gruplama, acente CRM üzerindeki görev ve hatırlatma yapısıyla birleştiğinde, hiçbir teklifin unutulmadığı bir çalışma düzeni oluşturur.
Branş akışları ve ortak durum modeli
Trafik, kasko ve DASK ayrı teklif akışları olarak çalışsa da durum modelinin ortak olması yönetimi kolaylaştırır. InsureHub'da bu üç branş ayrı sorgu akışlarına sahiptir; ancak her akıştaki teklif kaydı aynı temel durumlardan geçer. Böylece bir yönetici, branştan bağımsız olarak kısmi durumdaki tüm teklifleri tek listede görebilir. Branşa özgü ayrıntılar, örneğin DASK'ta adres teyidi beklenmesi, ana durumun altında açıklama olarak tutulabilir.
Durum ve süre ilişkisi
Bazı durumlar doğası gereği kısa sürelidir. Sorgulanıyor durumunda saatlerce kalan bir kayıt, bir sorun olduğuna işaret eder. Durumlar için beklenen süre sınırları tanımlanabilir ve bu sınırları aşan kayıtlar otomatik olarak işaretlenebilir. Benzer biçimde, sunuldu durumunda belirli bir süre bekleyen teklifler için müşteri geri dönüş hatırlatması oluşturulabilir.
Sık yapılan hatalar
- Durumları serbest metin alanı olarak tutmak ve her çalışanın farklı ifade kullanmasına izin vermek
- Kısmi sonuçları tamamlandı olarak işaretlemek
- Kapanış nedenini kaydetmemek
- Durum geçişlerini geçmişte tutmadan yalnızca son durumu saklamak
Bu hataların ortak sonucu, teklif sürecinin geçmişe dönük olarak anlaşılamamasıdır.
Durum modelini ekiple birlikte tanımlamak
Durum modeli teknik bir tasarım gibi görünse de aslında acentenin çalışma biçimini yansıtır. Bu nedenle durumların adları ve geçiş kuralları, teklif sürecini günlük olarak yürüten çalışanlarla birlikte belirlenmelidir. Çalışanların gündelik dilde kullandığı ifadelerle uyumlu durum adları, modelin benimsenmesini kolaylaştırır. Örneğin ekip "müşteriye gönderildi" ifadesini kullanıyorsa, sistemdeki "sunuldu" durumunun bu anlama geldiği açıkça belirtilmelidir.
Model yürürlüğe girdikten sonra da gözden geçirilmelidir. Hiç kullanılmayan bir durum gereksiz olabilir; sürekli açıklama alanıyla desteklenen bir durum ise iki ayrı duruma bölünmeyi hak ediyor olabilir. Kapanış nedenlerinin listesi de benzer biçimde, gerçek kayıtlara bakılarak güncellenebilir.
Durumların ekranda görünümü
Durumların her ekranda aynı renk ve simgeyle gösterilmesi, çalışanın kayıtları hızla taramasını sağlar. Liste görünümünde, kayıt ayrıntısında ve mobil uygulamada aynı görsel dilin kullanılması, durum modelinin ekip içinde ortak bir dile dönüşmesine yardımcı olur.
Sonuç
Teklif kaydında net bir durum modeli, operasyonun görünürlüğünü artırır, iş listelerini anlamlı hale getirir ve sorunların erken fark edilmesini sağlar. Tanımlı durumlar, kurallı geçişler ve kayıt altına alınan geçmiş, her teklifin hikayesini izlenebilir kılar. Teklif yaşam döngüsünün sigorta acentesi yazılımı içinde nasıl yönetildiğini görmek için demo talebi oluşturabilirsiniz.