Destek Talebi Kök Neden Analizi Yapay Zeka Süreçleri

Bu yazıdaki iş senaryosu bir örnektir. Bir orta ölçekli şirketin destek ekibi, son birkaç haftada ürün güncellemesinden sonra aynı konuda gelen biletlerin arttığını fark etti. Bu makale, tekrar eden destek taleplerinde yapay zekâ ile kök neden ayrıştırmasının nasıl kurulacağını, insan onayının nerede zorunlu olduğunu ve hangi koşullarda önerilerin güvenilmez sayılacağını anlatır.

Giriş: Tekrar eden talepler neden görünmez kalır?

Çoğu destek ekibi biletleri zaten etiketler. Sorun, etiketlerin çoğu zaman bir nedeni değil bir belirtiyi kaydetmesidir. “Giriş yapamıyorum” etiketi; süresi dolmuş davet bağlantısını, SSO yapılandırma hatasını ya da kafa karıştıran bir şifre kuralını aynı kutuya koyabilir. Üç farklı neden, üç farklı sahip ve tek bir etiket demektir.

Yapay zekâ destekli analiz burada işe yarar, çünkü müşterinin kullandığı kelimelere ve ekibin verdiği yanıtlara birlikte bakar. Rework’ün destek kök neden analizi kaynağı, biletleri anlamsal olarak gruplayıp ana nedeni ortaya çıkarmanın mümkün olduğunu, ancak yanlış kümeleri önlemek için son doğrulamada insan uzmanlığına ihtiyaç duyulduğunu belirtir. Bu makalede bu ayrımı temel alıyoruz: model bir hipotez üretir, karar ekip lideri tarafından verilir.

Veri bağlamı ve yetersizlik sınırları

Yapay zekânın önerdiği kök neğin güvenilirliği, ona verilen bağlamın kalitesine bağlıdır. Aşağıdaki durumlarda önerileri doğrudan kabul etmemek gerekir:

• Ürün ve sürüm bilgisi yoksa: Aynı şikâyet iki farklı sürümde farklı kök nedenlere sahip olabilir. Sürüm bilgisi olmadan küme, iki ayrı sorunu tek bir başlık altında toplar.
• Müşteri tipi ayrılmıyorsa: Kurumsal hesap ile bireysel kullanıcının aynı kelimelerle yazdığı talepler farklı süreçlerden doğabilir.
• Kanal bilgisi eksikse: Canlı destek, e-posta ve form üzerinden gelen aynı cümleler farklı bağlamlarda anlam kazanır.
• Bilet metni kısa veya şablonsa: “Teşekkürler, sorunum çözüldü” gibi yanıtlar kümeleri kirletir.
• Kapatma notları tutarsızsa: Aynı çözüm farklı kelimelerle yazıldığında model bunu farklı nedenler gibi görebilir.

Bu sınırlar bir tasarım ilkesine dönüşmelidir: emin olunamayan kayıt yanlış kümeye atılmak yerine insan incelemesine gönderilmelidir. Yanlış bir kümeye düşen bilet, sayıya karışıp görünmez hale gelir ve bu, eksik bırakılmaktan daha zararlıdır.

Adım adım çalışma akışı: kümelemeden ekip lideri onayına

Aşağıdaki akış, örnek senaryoda uygulanabilecek bir değerlendirme çerçevesidir. Her adımın çıktısı bir sonrakine girdi olur ve her adımda bir kişi sorumluluk alır.

1. Metni hazırlayın: Müşterinin ilk mesajını, ajanın son çözüm notunu ve varsa dahili özeti alın. İmzaları, alıntılanmış yanıt zincirlerini ve şablon metinleri ayıklayın.
2. Bağlam alanlarını ekleyin: Ürün, sürüm, müşteri tipi ve kanal bilgisini her kayda bağlayın. Bu alanlar eksikse kayıt “eksik bağlam” olarak işaretlenir.
3. Anlamsal kümeleme yapın: Biletleri kelime benzerliğinden değil anlamdan gruplayın. Küme sayısını önceden sabitlemek yerine benzerlik eşiğiyle çalışmak, kümelerin yapısını daha iyi gösterebilir.
4. Sınırdaki kayıtları ayırın: Leverge’ın tekrarlayan sorun analizi sayfası, güven düzeyi sınırda kalan kümelerin doğrudan kabul edilmeyip incelemeye yönlendirilmesi gerektiğini savunur. Bu yaklaşımı benimseyin.
5. Kök neden hipotezini yazın: Her küme için “bu grup şu nedenden kaynaklanıyor olabilir” biçiminde bir hipotez ve dayandığı örnek biletlerin listesi çıkarılsın.
6. Ekip lideri onaylasın veya düzeltsin: Lider, kümenin tutarlı olup olmadığını ve nedenin doğru adlandırılıp adlandırılmadığını kontrol eder. Düzeltme yapılırsa gerekçesiyle birlikte kaydedilir.
7. Sahibine yönlendirin: Onaylanan neden ürün, süreç ya da bilgi tabanı sahibine iletilir. Bu noktada eyleme dönüşen her kararın izi tutulur.

Güven eşiği ve karar tablosu

Aşağıdaki tablo, bir kümenin ne zaman otomatik olarak incelemeye alınacağını, ne zaman ekip lideri onayına gideceğini ve ne zaman yalnızca gözlem olarak kalacağını belirlemek için bir değerlendirme ölçütü sunar. Bu eşikler kural değil, ekibin kendi verisiyle kalibre edilmesi gereken başlangıç noktalarıdır.

Tabloda “yüksek güven” ifadesinin sayısal bir değeri yoktur. Bu kasıtlıdır: eşiği ekibinizin geçmiş verisiyle, lider onayının ne sıklıkla değiştirdiğine bakarak belirleyin.

Kök neden kayıtlarının tutulması ve bilet kapatma hiyerarşisi

Onaylanan her kök neden bir kayıt olarak saklanmalıdır. Kayıtta en azından şu alanlar bulunmalıdır: neden, kategori (süreç, ürün ya da bilgi tabanı), dayanak bilet kimlikleri, onaylayan kişi, onay tarihi ve düzeltme geçmişi. Bu yapı, bir nedenin neden kapandığını veya neden yeniden açıldığını sonradan izlemeyi mümkün kılar.

Thematic’in destek biletlerinde kök neden konusundaki yazısı, her temanın kendisini destekleyen bireysel yorumlara bağlanabilmesinin ekiplerin bulguyu ürün ekibine savunmasını kolaylaştırdığını anlatır. Bu, bir vendor’ın kendi ürününü anlattığı bir iddiadır; kendi ekibinizde de aynı izlenebilirlik ilkesini uygulamak yeterlidir.

Kapatma hiyerarşisi için şu sırayı önerebilirsiniz:

• Bilet çözüldüğünde önce belirti kapatılır, ardından neden kaydına bağlanır.
• Neden onaylanmadan “kök neden çözüldü” durumu verilmez.
• Süreç kaynaklı nedenler süreç sahibine, ürün kaynaklı olanlar ürün yöneticisine, bilgi tabanı kaynaklı olanlar içerik ekibine atanır.
• Bir neden üç ay boyunca yeni bilet üretmezse “kapalı” değil “izleniyor” olarak işaretlenir.

Cockpit yaklaşımı: güvenli ve onaylı yönetim

Bu çalışma akışını yönetmek için araç seçiminde ana soru, kullanılan platformun insan onayını ve izlenebilir kaydı destekleyip desteklemediğidir. Cockpit Müşteri Desteği Yönetimi sayfasında destek süreçlerinin nasıl yönetildiğini inceleyebilirsiniz. Cockpit, Logitera’nın ürünüdür ve CRM, finans, proje, insan kaynakları, iş zekâsı, pazarlama ve müşteri desteğini bir araya getiren modüler bir platformdur.

Cockpit’in yapay zekâ kapsamı modüllere, sağlayıcı yapılandırmasına ve kullanılabilir veriye bağlıdır. Son karar her zaman kullanıcıdadır. Bu nedenle, bu makalede anlatılan kümeleme ve kök neden ayrıştırmasının Cockpit içinde hazır bir özellik olarak bulunduğunu varsaymayın. Hangi yapay zekâ işlevlerinin sizin kullanım senaryonuzda kullanılabileceğini Cockpit AI sayfasından ve satış görüşmesinde netleştirin. Fiyat, kurulum ve entegrasyon kapsamı ihtiyaç görüşmesinde belirlenir.

Değerlendirme sırasında Cockpit’in modüler yapısını, özellikle destek, raporlama ve görev yönetimi bağlantılarını, platform sayfasında ekibinizin iş akışına göre kontrol etmeniz faydalı olur.

Bir kamu destek masasında yapılan bir çalışmada, sorular ürün kapsamına göre sınırlandırıldığında geri çağırma başarısının belirgin biçimde arttığı görülmüştür. Bu, MdsAI proje sayfasında anlatılan çevrimdışı bir değerlendirmedir ve kendi ortamınız için aynı sonucu garanti etmez; ancak aramayı ürün bağlamına göre daraltmanın ayrıştırma kalitesine etkisini gösterir.

Uygulama kontrol listesi

1. Son üç aylık biletlerde ürün, sürüm, müşteri tipi ve kanal alanlarının ne oranda dolu olduğunu ölçün.
2. Şablon ve teşekkür yanıtlarını ayıklayan bir ön filtre tanımlayın.
3. Kümeleme çıktısında her küme için en az beş örnek bilet listeleyin.
4. Sınırdaki kümeleri otomatik kabul etmeyecek bir inceleme kuyruğu oluşturun.
5. Ekip liderinin her onayda ve düzeltmede kaydedeceği alanları belirleyin.
6. Kök neden kayıtlarının sahibini ve kapanış koşulunu her kayıt için tanımlayın.
7. İlk ay için bir değerlendirme seti hazırlayın: liderin “doğru” ve “yanlış” dediği kümeleri ayrı tutun.
8. Bir aylık çalışmadan sonra eşikleri ve kural setini ekip verisine göre gözden geçirin.