Yapay zeka yönlendirmesinin işleyebileceği bir talep sınıflandırması nasıl tasarlanır?

Yönlendirme pilotu, biri etiketleri kontrol edene kadar umut verici görünüyordu. Model “Para iadem nerede?” diye soran bir e-postayı iade kuyruğuna göndermişti; ekibin yarısı bunun ödemeler ekibine ait olduğunu söyledi. Kimse hangi tarafın haklı olduğunu kanıtlayamadı, çünkü eski listede hem “Para iadesi durumu” hem de “İade – para iadesi sorusu” vardı ve temsilciler yıllardır ikisini birbirinin yerine kullanıyordu.

Sorun genellikle böyle ortaya çıkar: yönlendirme çoğu zaman modelden değil, kategorilerden takılır. İyi bir talep sınıflandırması, her birinin örnekleri ve sahibi olan, birbirini dışlayan daha az sayıda talep türünden oluşur ve yapay zeka yönlendirmesini ölçülebilir kılar. Aşağıdaki şablonu bir ekip lideri tek bir öğleden sonrada doldurabilir.

Yönlendirme projeleri neden kategorilerde takılır?

• Örtüşme. İki kategori de uyduğunda modelin “hatası”, ikisi arasında yazı tura atmaktan farksızdır ve hiçbir ayar bunu düzeltmez.
• Çok fazla kod. Yüz tane temas nedeni kodu; temsilciler bunların bir avucunu tutarlı biçimde, gerisini ara sıra ve alışkanlıkla kullanır.
• Karışık amaçlar. Tek bir liste aynı anda yönlendirmeye, raporlamaya ve kök neden analizine hizmet etmeye çalışır; tek bir kod üç ayrı bilgi taşır.
• Sahip yok. Arkasında bir kuyruk olmayan kategori, doğru yönlendirilmiş bir talebin hiçbir yere varmaması demektir.

İnsanların üzerinde anlaşamadığı etiketlere göre değerlendirilen bir model hiç ölçülemez.

Kaç talep türü olmalı?

Yalnızca sonrasında olanı değiştiren türler kadar. Bir talep türü farklı bir kuyruğa, farklı bir işlem sürecine ya da farklı bir aciliyete yol açıyorsa yerini hak eder. İki talep türü aynı ekibe gidiyor ve aynı şekilde işleniyorsa yönlendirme için onları birleştirin, ayrımı başka bir yerde tutun. Hacme de bakın: çok az talep alan bir tür ölçülemez; büyüyene kadar onu daha geniş bir türe ya da “Diğer”e katın.

O “başka yer” ikinci bir düzeydir: raporlama için bir detay alanı. Bu alan daha uzun olabilir; vaka kapanırken değerini yapay zeka da önerebilir. Yönlendirme için yeni bir temsilcinin öğrenebileceği kadar kısa bir liste gerekir. Raporlama ise analistlerin gerçekten kullanacağı kadar ayrıntılı olabilir.

Bir talep türü nasıl tanımlanır?

Her talep türü için bir satır, bütün ekibin okuyabileceği ortak bir belgede:

İşin çoğunu hariç tutulacak örnekler yapar. Örtüşmeler orada, bir kez ve yazılı olarak çözülür.

Hiçbir türe uymayan taleplere ne olur?

“Diğer”e giderler; “Diğer” de deneyimli temsilcilere yönlendirilir. Bu kategori gereklidir. Modelin güvenle bir yere yerleştiremediği vakaları göndermesi gereken yer de burasıdır.

“Diğer”in bir çöplüğe dönüşmesini haftalık bir inceleme engeller. Adı belli bir kişi haftanın “Diğer” taleplerini okur ve ayırır: tekrar eden bir talep yeni bir talep türü adayı olur; bir türle eşleşmesi gereken bir talep, üzerinde çalışılması gereken bir tanıma işaret eder; gerisi yerinde kalır. Kategori büyümeye devam ediyorsa sınıflandırmayı gözden geçirme zamanı gelmiştir.

“Siparişim nerede, bir de adresi değiştirebilir miyim?” gibi iki talep içeren mesajlar için de bir kural gerekir: önce işlem gerektiren talebe göre yönlendirin, diğerini kaydedin.

Sınıflandırma, modele verilmeden önce nasıl test edilir?

İki kişiye yazılı tanımları ve aynı gerçek talep örneklemini verin: farklı kanallardan gelen birkaç yüz talep. Örneklemi birbirinden bağımsız olarak etiketlesinler. Sonra karşılaştırın.

Bir model, aynı tanımları okuyan iki insandan daha tutarlı olamaz.

Her anlaşmazlık bir bulgudur. Genellikle iki talep türünün örtüştüğü, bir açıklamanın muğlak olduğu ya da bir hariç örneğin eksik olduğu anlamına gelir. Tanımları düzeltin ve uyum yüksek ve istikrarlı olana kadar yeni bir örneklem etiketletin. Ulaştığınız uyum, model için gerçekçi tavandır; etiketlenmiş örneklem de değerlendirme setinizin başlangıcı olur. Değerlendirme seti şablonumuz bu seti yapılandırmanıza yardım eder.

Sınıflandırma, raporları bozmadan nasıl değiştirilir?

Sınıflandırmayı sürümleyin. Neyin neden değiştiğini bir değişiklik kaydında tutun ve her eski temas nedeni kodundan yeni bir talep türüne giden bir eşleme tablosu saklayın. Değerlendirme setini yeniden çalıştırın, yönlendirme kurallarını güncelleyin ve gösterge panellerini de aynı sürümle uyarlayın. Müşteri hizmetlerinde yapay zeka ölçümü notumuzun gösterdiği gibi, talep türüne göre raporlanan her hizmet metriği sınıflandırmaya bağlıdır.

Temsili bir vakada, uzun bir eski temas nedeni kodları listesi olan bir e-ticaret destek ekibi bu listeyi kısa bir talep türleri listesine indiriyor: sipariş durumu, teslimat sorunu, iade talebi, para iadesi durumu, ödeme sorunu, ürün sorusu, hesap ve diğer. Eski kodların çoğu tam olarak tek bir yeni türe karşılık geliyor; örneğin “Kargo gecikmesi” de “Late delivery complaint” de teslimat sorunu oluyor. İadeleri ve para iadelerini karıştıran birkaç kod ise yazılı bir kurala göre ayrılıyor. Trend raporları eski kodları eşleme tablosu üzerinden okuyor; böylece iadeler çizgisi değişiklikte sıfırdan başlamıyor, kesintisiz devam ediyor.

Nereden başlamalı?

Son taleplerden bir örneklemi, temsilcilerin seçtiği kodlarla birlikte dışa aktarın ve iki kişiden bu örneklemi taslak bir listeye göre etiketlemesini isteyin. Talep yönlendirme, müşteri operasyonlarında ilk adımlardan biridir. Yönlendirmenin kendisi de genellikle destek talebi sisteminiz ve kuyruklarınız etrafında özel yapay zeka yazılımı olarak geliştirilir.