Bir acentenin gelen kutusu gün içinde çok farklı taleplerle dolar: plaka bilgisi gönderip trafik teklifi isteyen biri, kasko poliçesinde adres değişikliği talep eden bir müşteri, DASK yenilemesini soran bir site yöneticisi, hasar sonrası hangi belgeleri göndermesi gerektiğini öğrenmek isteyen bir sürücü. Bu talepler e-posta, web formu ve mesajlaşma kanalları üzerinden karışık sırayla gelir. Hangi talebin kime ve hangi önceliğe gideceğine karar vermek, özellikle yoğun dönemlerde ciddi bir zaman alır. Yapay zeka destekli sınıflandırma bu ilk ayrıştırma adımını hızlandırmak için sıkça konuşulan bir yöntemdir. Bu yazıda bu yöntemin acente iş akışına nasıl yerleşebileceğini, hangi kategorilerle başlanabileceğini ve nerede insan müdahalesinin şart olduğunu ele alıyoruz.
Sınıflandırma neyi çözer, neyi çözmez?
Sınıflandırmanın amacı talebi cevaplamak değil, doğru masaya ulaştırmaktır. Model bir mesajı okuyup "bu bir kasko zeyil talebi gibi görünüyor" diyebilir; ancak zeyilin yapılıp yapılamayacağına, hangi belgenin gerektiğine ya da prim farkına karar vermez. Bu ayrımı baştan netleştirmek, beklentiyi doğru kurmak ve aracın yetki alanını sınırlamak açısından önemlidir.
Sınıflandırmanın en çok fayda sağladığı durumlar şunlardır:
- Aynı kanaldan farklı türde çok sayıda talep geliyorsa.
- Talepler farklı uzmanlıklara sahip çalışanlara yönlendirilmesi gerekiyorsa.
- Yoğun dönemlerde acil olanın sıradan olandan ayrılması zor hale geliyorsa.
Kategori yapısını tasarlamak
Sınıflandırmanın kalitesi büyük ölçüde kategori yapısına bağlıdır. Çok fazla kategori modelin kararsız kalmasına, çok az kategori ise ayrıştırmanın anlamsızlaşmasına yol açar. İki eksenli bir yapı pratik bir başlangıç sunar.
Birinci eksen: branş
Trafik, kasko, DASK, konut, sağlık ve diğer branşlar. Burada önemli bir nokta, trafik, kasko ve DASK'ın ayrı sorgu ve teklif akışlarına sahip olmasıdır. Bir mesajda hem araç hem konut geçiyorsa model iki ayrı talep olarak işaretlemeli, tek bir kategoriye sıkıştırmamalıdır.
İkinci eksen: işlem türü
- Yeni teklif talebi
- Yenileme sorusu
- Poliçe değişikliği veya zeyil
- Belge talebi (poliçe kopyası, makbuz vb.)
- Hasar bilgilendirmesi
- Tahsilat ve ödeme sorusu
- Diğer veya belirsiz
"Diğer veya belirsiz" kategorisi isteğe bağlı değil, zorunludur. Modelin emin olmadığı talepleri buraya bırakması, yanlış masaya giden bir talepten çok daha az zarar verir.
Örnek akış: sabah gelen kutusunun ayrıştırılması
- Gece boyunca gelen mesajlar tek bir listede toplanır.
- Her mesaj için model iki etiket önerir: branş ve işlem türü. Ayrıca önerisine ne kadar güvendiğini gösteren bir seviye üretir.
- Yüksek güven seviyesindeki talepler ilgili ekibin kuyruğuna önerilen etiketle düşer; ekip üyesi talebi açtığında etiketi onaylar veya düzeltir.
- Düşük güven seviyesindeki talepler ve "belirsiz" olarak işaretlenenler, ayrıştırmadan sorumlu bir çalışanın listesine gider.
- Hasar bilgilendirmesi olarak işaretlenen talepler, güven seviyesinden bağımsız olarak bir çalışan tarafından hemen görülür.
- Düzeltilen etiketler kaydedilir; haftalık olarak hangi kategorilerde hata yapıldığı incelenir.
Bu akışta yapay zeka bir ön ayıklama yapar, son kararı ise talebi açan kişi verir. Hasar gibi zaman açısından hassas konular için otomatik ayrıştırmaya tamamen güvenilmez.
Sık karşılaşılan sorunlar
Birden fazla konu içeren mesajlar
Müşteriler genellikle tek mesajda birkaç şey sorar: "Kaskomun yenilemesi ne zaman, bir de evime DASK yaptırmak istiyorum." Bu tür mesajların bölünmesi ya da çoklu etiketlenmesi gerekir. Tek etiket zorunluluğu, ikinci talebin gözden kaçmasına neden olabilir.
Bölgesel dil ve kısaltmalar
Müşteriler resmi terimleri kullanmaz. "Zorunlu sigorta", "trafik", "mecburi" aynı şeyi anlatabilir. Kategori tanımlarına bu tür örnek ifadelerin eklenmesi sonuçları iyileştirir.
Ekli belgeler
Mesajın metni boş, eki dolu olabilir. Bir ruhsat görüntüsüyle gelen sessiz bir mesaj çoğu zaman trafik veya kasko talebidir ama hangisi olduğunu yalnızca bağlam söyler. Bu tür durumlar belirsiz kategorisine bırakılmalıdır.
Kategori kaymaları
Yıl içinde talep türleri değişir. Yenileme yoğunluğu, bölgesel bir afet sonrası DASK soruları ya da yeni bir ürün tanıtımı, belirli kategorilerin ağırlığını artırabilir. Kategori yapısının yılda birkaç kez gözden geçirilmesi bu nedenle faydalıdır.
Kişisel veri boyutu
Gelen talepler doğası gereği kişisel veri içerir. Sınıflandırma için kullanılan aracın bu veriyi nerede işlediği, saklayıp saklamadığı ve kendi modelini eğitmek için kullanıp kullanmadığı, araç seçilmeden önce netleştirilmelidir. Mümkün olduğunda sınıflandırma için yalnızca mesajın konu ve gövde metni kullanılmalı, ekler ve iletişim bilgileri ayrı tutulmalıdır.
Sınıflandırmanın sonrası: kayda bağlamak
Doğru etiketlenmiş bir talep, ancak ilgili müşteri kaydıyla ilişkilendirildiğinde değer kazanır. Aksi halde ayrıştırma yapılmış ama talep yine bir gelen kutusunda kalmış olur. Talebin müşteri kartına işlenmesi, ilgili branşın teklif veya poliçe akışının başlatılması ve takip görevinin oluşturulması zincirin devamıdır.
InsureHub'da müşteri kayıtları, branşa göre ayrı teklif akışları ve poliçe takibi aynı yapıda yer alır; bu yazıda anlatılan sınıflandırma ise sektörde değerlendirilen bir yaklaşım olarak ele alınmıştır ve ürün özelliği olarak sunulmamaktadır. Taleplerin bağlanacağı müşteri yapısını acente CRM sayfasında, teklif akışlarını sigorta teklif programı sayfasında inceleyebilirsiniz.
Başlamadan önce sorulacak sorular
- Hangi kanallardan, günde yaklaşık ne tür talepler geliyor?
- Kategori yapısı ekipteki iş bölümünü yansıtıyor mu?
- Belirsiz talepleri kim ayrıştıracak?
- Hasar gibi acil konular için ayrı bir kural var mı?
- Etiket düzeltmeleri nasıl geri bildirim olarak toplanacak?
Bu soruların cevabı netleştiğinde sınıflandırma, ekibin yükünü artıran bir deney değil, iş bölümünü destekleyen bir araç haline gelir. Altyapınızı kendi talepleriniz üzerinden değerlendirmek isterseniz demo hesabı talep edebilirsiniz.