Panelde çözüm oranı yükseliyor, grafik yeşil, aylık rapor gayet iyi görünüyor. Aynı dönemde çağrı merkezine gelen "botla konuştum, olmadı" cümlesi de artıyor. İkisi çelişmiyor aslında: kullanıcı pes edip pencereyi kapattığında konuşma da "kapandı" sayılıyor. AI chatbot performansını iyileştirmek, önce bu tür yanılmaları ayıklamakla başlıyor. Aşağıda hangi sayının neyi gizlediğini, başarısız konuşmaların nasıl sınıflandırılacağını ve iyileştirme döngüsünün hangi ritimde döneceğini anlatıyorum.
Panelin söylemediği şey
Çoğu sistemde "çözülmüş konuşma" tanımı teknik bir tanımdır: insana devredilmemiş olan. Oysa devredilmeden biten üç farklı son var — kullanıcı cevabını aldı, kullanıcı vazgeçti, kullanıcı başka kanala gitti. Panel üçünü de aynı hanede topluyor.
Bu yüzden ilk iş, tek bir sayıya bakmayı bırakmak. Çözüm oranını yalnız okuyan ekip, botu daha inatçı hale getirerek "iyileştirme" yapar. Sayı yükselir, memnuniyet düşer.
Pratik bir düzeltme: konuşma sonrası 24 saat içinde aynı kullanıcıdan gelen çağrı veya mesajı işaretleyin. Tekrar temas eden her kullanıcı, kapanmış görünen bir konuşmanın aslında kapanmadığını söyler.
Dört sayı, birlikte okunur
Metrik | Neyi gösterir | Tek başına neden yanıltır |
|---|---|---|
Çözüm oranı | Botun devretmeden bitirdiği konuşmalar | Vazgeçen kullanıcıyı da başarı sayar |
Fallback oranı | Anlaşılamayan mesajların payı | Düşük olması iyi değil; bot yanlış cevap üretiyor olabilir |
Tekrar temas oranı | Konuşmanın gerçekten kapanıp kapanmadığı | Mevsimsel yoğunlukla karışabilir, dönem karşılaştırması ister |
Devir sonrası çözüm süresi | Botun temsilciye ne kadar hazır devrettiği | Temsilci performansıyla karışır, konu bazında ayrıştırın |
Bu dördü aynı grafikte durduğunda tablo netleşiyor. Çözüm oranı artarken tekrar temas da artıyorsa, iyileşme değil erteleme yapıyorsunuz demektir.
Segment kırılımını da atlamayın. Ortalama, en çok yanılttığı yerde en ikna edici görünür: yeni müşteri ile mevcut müşteri, yazılı kanal ile sesli kanal, mesai içi ile gece — bunlar ayrı davranıyor. Raporlamayı baştan bu kırılımlarla kurun; sonradan eklemek zor oluyor.
Fallback'i sınıflandırmadan iyileştirilemez
"Fallback oranımız yüksek" cümlesi tek başına hiçbir aksiyon üretmez. Çünkü aynı çatı altında birbirinden bağımsız dört problem var ve her birinin çözümü farklı ekipte.
Bilgi yok. Soru anlaşıldı ama cevabı bilgi bankasında yok. Çözümü içerik yazmak — en kolayı ve en hızlı getiri sağlayanı.
Soru anlaşılmadı. Cevap sistemde var, kullanıcının ifadesi eşleşmedi. Çözümü örnek cümle eklemek veya eş anlamlıları tanıtmak. Türkçede bu kalem beklenenden büyük çıkıyor: kısaltmalar, ekler ve yazım hataları eşleşmeyi bozuyor.
Entegrasyon düştü. Bot doğru anladı, sisteme sordu, cevap gelmedi. Bu bir içerik sorunu değil, teknik arıza. Bilgi bankasına yeni madde eklemek burada hiçbir işe yaramaz.
Kullanıcı zaten insan istedi. Bunu başarısızlık hanesine yazmayın. Ayrı bir kutuda tutun; oranı yüksekse mesele tasarım değil, güven.
Bu ayrımı yapan ekipler haftalık toplantıda "şu kadar fallback var" demeyi bırakıp "bu hafta on iki içerik açığı, üç entegrasyon hatası" demeye başlıyor. Aradaki fark, gerçek bir iş listesi.
Yeniden eğitim ritmi
Sürekli değişiklik, hiç değişiklik yapmamak kadar zararlı. Her gün akışa dokunulan bir sistemde neyin işe yaradığını anlayamazsınız.
İşe yarayan ritim genelde şöyle kuruluyor: haftada bir kez başarısız konuşmaların okunması, iki haftada bir içerik ve örnek cümle güncellemesi, ayda bir akış ve devir eşiği değişikliği. Model veya altyapı tarafındaki güncellemeler ise takvime değil, sağlayıcının duyurusuna bağlı.
Bir de olay tetikleyicileri var: yeni ürün, kampanya başlangıcı, fiyat değişikliği, mevzuat güncellemesi. Bunlar takvimi beklemez. Bilgi bankasını bu olayların sahibi olan ekiple aynı takvime bağlayın; pazarlama kampanyayı duyurmadan önce içerik hazır olsun.
Trade-off net: hızlı değişiklik hızlı düzelme demek, ama her değişiklik daha önce çalışan bir şeyi bozma riski taşıyor. Bunun ilacı bir sonraki bölüm.
Altın soru seti
Her değişiklikten önce çalıştırdığınız sabit bir soru listesi tutun. İçinde en sık gelen sorular, geçmişte bozulmuş senaryolar ve kritik işlem akışları olsun. Elli soru fazlasıyla yeterli.
Bir akışa dokundunuz, içerik eklediniz, model güncellendi — listeyi çalıştırın, cevapları önceki turla karşılaştırın. Bozulan varsa yayına almadan görürsünüz.
Bunu yapmayan ekiplerde tipik senaryo şu: iade akışı düzeltilir, iki hafta sonra kargo sorularının bozulduğu fark edilir, arada kimse bağlantıyı kuramaz. Sabit set, o bağlantıyı kurar.
Geri bildirim kimden gelir?
Üç kaynak var, üçü de eksik.
Kullanıcı puanı en kolay toplanan, en az güvenilir olan. Katılım düşüktür, çoğu zaman yalnızca çok memnun ya da çok kızgın olan puan verir.
Temsilci geri bildirimi en değerlisi. Botun devrettiği konuşmayı devralan kişi, sorunu ilk elden görüyor. Temsilcinin tek tıkla "bot burada şunu kaçırdı" diyebileceği bir alan açın; anket yapmayın, akışın içine koyun.
Konuşma kayıtları ise en zahmetlisi ve en dürüstü. Haftada yarım saat okumak, üç aylık rapordan fazlasını anlatıyor.
Haftada iki saatlik iş
Bu döngünün sahibi belli olmalı. Belli olmadığında herkes bakar, kimse yapmaz.
Gerçekçi yük, tek kişi için haftada yaklaşık iki saat: başarısız konuşmaları okumak, fallback'leri sınıflandırmak, içerik açıklarını kapatmak, ayda bir de akışı gözden geçirmek. Chatbot geliştirme sürecinin baştan sona nasıl kurulduğunu bu rehberde anlatmıştık; buradaki döngü, o kurulumun devamı sayılır.
İki saati ayıramıyorsanız beklentiyi de buna göre kurun. Bakılmayan bir asistan kötüleşmez, yerinde sayar — ama etrafındaki her şey değiştiği için sonuç aynı kapıya çıkar.
Sıkça Sorulan Sorular
İyileşme ne zaman görünür olur?
İçerik açıklarını kapatmanın etkisi genelde günler içinde görülür. Akış ve devir eşiği değişikliklerinin etkisi ise birkaç hafta ister; erken yorum yapmayın.
Hangi metriği tek başına takip etmeliyim?
Tek metrikle çalışmak istemiyorsanız en dürüst ikili, çözüm oranı ile tekrar temas oranıdır. İkisi birlikte iyileşiyorsa gerçekten ilerliyorsunuz.
Duygu analizi gerekli mi?
Şart değil, faydalı. Asıl işi, kızgın kullanıcıyı erken tespit edip devri hızlandırmak. Rapor için değil, akış için kullanın.
Modeli yeniden eğitmek her sorunun çözümü mü?
Hayır. Sorunların çoğu içerik eksikliği veya entegrasyon hatası. Model değişikliği en son bakılacak yer.
Kaç konuşma okumak yeterli?
Haftada yirmi başarısız konuşma, çoğu operasyon için deseni görmeye yeter. Hepsini okumaya çalışmak, hiç okumamakla sonuçlanıyor.
Mevcut asistanınızın hangi başlıkta tıkandığını kendi konuşma kayıtlarınız üzerinden görmek isterseniz, AI Agent TR ekibiyle bir demo ayarlayın; ilk okumayı birlikte yapalım.