Bir acente yazılımında "bu müşteriyle bu hafta görüşmeniz önerilir" gibi bir öneri gören çalışanın aklına gelen ilk soru genellikle "neden?" olur. Bu sorunun cevabı ekranda yoksa iki sonuçtan biri ortaya çıkar: Çalışan öneriyi görmezden gelir ya da sorgulamadan uygular. İkisi de istenmeyen bir durumdur. Yapay zeka destekli veya kural tabanlı öneri sistemlerinde açıklanabilirlik, önerinin gerekçesini çalışanın anlayabileceği biçimde göstermek anlamına gelir. Bu yazıda acente bağlamında açıklanabilir bir öneri ekranının nasıl tasarlanabileceğini ve hangi tuzaklardan kaçınılması gerektiğini ele alıyoruz.
Açıklanabilirlik neden acentede ayrıca önemli?
Sigorta acentesinde öneri, sonunda bir insanla yapılan görüşmeye dönüşür. Çalışan müşteriyi aradığında neden aradığını bilmek zorundadır. "Sistem söyledi" bir gerekçe değildir; müşteriye de iletilemez. Öte yandan acente müşteriye karşı tavsiyelerinden sorumludur. Gerekçesi görünmeyen bir öneriye dayanarak yapılan bir görüşme, mesleki özenin gerisinde kalabilir. Bu nedenle açıklanabilirlik, kullanıcı deneyiminin ötesinde bir sorumluluk aracıdır.
İyi bir açıklamanın bileşenleri
1. Tetikleyen veri
Öneriye hangi kayıtların yol açtığı gösterilmelidir. Örneğin "Kasko poliçesi 30 gün içinde sona eriyor" ve "Son görüşmede müşteri araç değişikliğinden bahsetmiş" gibi iki satır, önerinin bağlamını hemen kurar.
2. Önerinin türü
Önerinin bir hatırlatma mı, bir fırsat mı yoksa bir risk uyarısı mı olduğu ayrıca belirtilmelidir. Bu ayrım çalışanın görüşmeye hangi tonla başlayacağını belirler.
3. Belirsizlik
Model tabanlı önerilerde sistemin ne kadar emin olduğu sade bir dille ifade edilebilir: güçlü, orta, zayıf gibi. Kesin görünen bir yüzde değeri, çalışana gerçekte olmayan bir hassasiyet hissi verebilir; bu yüzden kaba seviyeler çoğu zaman daha dürüst bir gösterimdir.
4. Eksik bilgi
Önerinin hangi bilginin yokluğunda üretildiği de gösterilmelidir. "Bu müşterinin iletişim tercihi kayıtlı değil" gibi bir not, çalışanın önce kaydı tamamlamasını sağlayabilir.
Örnek ekran kurgusu
Bir yenileme önerisi kartının nasıl görünebileceğini düşünelim:
- Başlık: Önerilen eylem; örneğin yenileme görüşmesi planlamak.
- Gerekçe satırları: Poliçe bitiş tarihi, son iletişim tarihi, son görüşme notundan ilgili bir ifade.
- Güç seviyesi: Önerinin dayandığı sinyallerin sayısına göre basit bir gösterge.
- Kaynağa git: Gerekçe satırına tıklandığında ilgili poliçe veya not açılır.
- Geri bildirim: "Uygun", "uygun değil" ve kısa bir neden seçimi.
Bu kurguda çalışan öneriyi değerlendirmek için ayrı ekranlara gitmek zorunda kalmaz; ancak isterse kaynağa tek adımda ulaşır.
Kural tabanlı ve model tabanlı öneriler
Kural tabanlı önerilerde açıklama kolaydır: Kural neyse gerekçe odur. "Bitiş tarihine 45 günden az kalan ve son 30 günde iletişim kurulmamış poliçeler" bir kuraldır ve açıkça gösterilebilir. Model tabanlı önerilerde ise sonuç birçok sinyalin birleşiminden doğar ve her sinyalin katkısını göstermek daha zordur. Bu durumda tam bir teknik açıklama yerine en etkili birkaç sinyali öne çıkarmak, çalışan için yeterli ve anlaşılır bir açıklama sunar.
Acenteler için pratik yaklaşım çoğu zaman ikisinin birleşimidir: Kesin ve denetlenebilir olması gereken hatırlatmalar kurallarla, daha esnek öncelik sıralamaları ise modelle yapılabilir. Her iki durumda da açıklama zorunlu bir alan olmalıdır.
Kaçınılması gereken tuzaklar
- Gerekçe yerine etiket: "Yüksek potansiyel" yazmak bir açıklama değildir; bu sonucu doğuran veri gösterilmelidir.
- Hassas veriyi gerekçe yapmak: Sağlık bilgisi veya özel nitelikli kişisel veri gibi alanların öneri gerekçesinde yer alması hem etik hem hukuki açıdan sorunludur.
- Branşları karıştırmak: Bir trafik poliçesinin verisiyle kasko önerisi yapılabilir, ancak açıklama bunu açıkça göstermeli ve kasko için ayrı teklif akışının başlatılması gerektiğini belirtmelidir. DASK önerileri ise konut ve adres verisine dayanır, araç verisinden türetilmez.
- Geri bildirimi toplamamak: Çalışanların "uygun değil" dediği öneriler incelenmezse, sistem aynı hatalı önerileri üretmeye devam eder.
Geri bildirimden öğrenmek
Açıklanabilir bir öneri ekranının en değerli yan ürünü, çalışan geri bildirimidir. Bir öneri neden reddedildi? Veri eksik miydi, yanlış mıydı, yoksa müşteri zaten başka bir kanaldan iletişime geçmiş miydi? Bu nedenler düzenli olarak gözden geçirildiğinde hem öneri kuralları hem de veri giriş alışkanlıkları iyileşir. Özellikle "veri yanlış" nedeniyle reddedilen öneriler, müşteri kayıtlarında bir düzeltme ihtiyacına işaret eder.
Altyapı ile bağlantısı
Açıklanabilir öneri, açıklayacak veri olduğunda mümkündür. Poliçe bitiş tarihleri, iletişim geçmişi ve teklif kayıtları tek bir yapıda tutulmadıysa önerinin gerekçesini göstermek de mümkün olmaz. InsureHub'da acente CRM kayıtları, poliçe ve yenileme takibi ile trafik, kasko ve DASK için ayrı teklif akışları aynı sistemde yer alır. Bu yazıda anlatılan öneri motoru tasarımı ise ürünün özellik vaadi değil, sektörde tartışılan bir yaklaşımın çerçevesidir. Genel altyapıyı sigorta acentesi yazılımı sayfasında inceleyebilirsiniz.
Açıklamanın dili
Gerekçe satırları teknik terimlerle değil, çalışanın günlük diliyle yazılmalıdır. "Sinyal skoru yüksek" yerine "son iki görüşmede araç değişikliğinden bahsedilmiş" gibi bir ifade, çalışanın müşteriyle konuşurken kullanabileceği bir bağlam sunar. Açıklamalar kısa tutulmalı; üç satırı aşan bir gerekçe genellikle okunmaz. Gerekirse ayrıntı, kaynağa git bağlantısının arkasında bırakılabilir.
Açıklamaların etkisini ölçmek için çalışanlardan kısa geri bildirim toplamak da yararlıdır; hangi gerekçelerin işe yaradığı ve hangilerinin anlaşılmadığı bu şekilde zamanla netleşir.
Sonuç
Bir öneri, çalışan onu anladığı ölçüde değerlidir. Tetikleyen veriyi, önerinin türünü, belirsizliği ve eksik bilgiyi gösteren bir ekran, öneriyi sorgulanabilir ve sorumlu bir araca dönüştürür. Verinizin bu tür bir yapıya ne kadar hazır olduğunu görmek için demo talebi oluşturabilirsiniz.