Bir yazılım destek asistanına gelen ayar sorusu, aynı ekran adıyla anılan iki sürümde farklı bir yola denk gelebilir. Bu yazıda uygulama adımlarını değil, neyin kapsama alınacağını ve hangi yanıt biçiminin seçileceğini tartışıyoruz. Amaç, hangi sürümlerin ve planların destek kapsamında olacağına karar vermek ve alternatifleri aynı ölçütlerle kıyaslamaktır.
Kapsam Neden Önce Gelmeli?
Yazılım desteğinde ilk karar, asistanın hangi ürün sürümleri için yanıt verebileceğini belirlemektir. Kapsam net değilse her yeni sürüm ya da plan, fark edilmeden yanlış bir yanıtın kaynağına dönüşebilir. Ekip, desteklenen sürüm listesini yayın notlarının içinde dağınık biçimde değil, destek sorumlusunun onayladığı tek bir tabloda tutmalıdır.
Kapsam dışı bırakmak da bir karardır ve açıkça yazılmalıdır. Artık desteklenmeyen sürümler için asistanın yanıt vermemesi, insan ekibine yönlendirmesi ya da yalnızca genel bilgi vermesi gerekir. Hangi seçeneğin tercih edileceği, müşterinin yanlış yönlendirilme riskine ve destek ekibinin yüküne birlikte bakılarak tartılmalıdır.
Alternatifleri Hangi Ölçütlerle Karşılaştırmalı?
Bir yanıt için üç temel alternatif düşünülebilir: sürüme özgü kesin yanıt, koşullu yanıt ve yalnızca yönlendirme. Her birinin maliyeti farklıdır. Kesin yanıt kısa ve hızlıdır ama sürüm yanlışsa zarar verir. Koşullu yanıt daha uzundur, fakat yanlış yolu azaltır. Yönlendirme en güvenli seçenektir ancak müşteri için yavaş ilerleyebilir.
Karşılaştırmada dört ölçüt kullanmak işi somutlaştırır: yanlış yönlendirme riski, sürüm bilgisini toplama maliyeti, bakım yükü ve insan ekibinin ihtiyacı. Yalnızca yanıt hızına bakmak, yanlış sürüm riskini görünmez kılar. Ölçütler yazılı olduğunda farklı ekip üyeleri aynı alternatifi aynı biçimde değerlendirebilir.
Sürüm Bilgisi Eksik Olduğunda Seçenekler
Müşteri sürümünü bilmediğinde asistanın işi tahmin yürütmek değil, ayırt edici bilgiyi istemektir. Ancak istenebilecek bilgi sınırlıdır. Sürüm numarası ekranda görünmüyorsa, menü etiketi ya da ürünün hangi bölümünde olunduğu daha pratik bir ayırıcı olabilir. Bu bilgi de sorulamıyorsa seçenekler daralır.
Eksik bilgide üç yol bulunur: ayırt edici etiketi sormak, sürümden bağımsız genel bir açıklama vermek veya konuyu insan ekibine iletmek. Genel açıklama yalnızca her sürümde değişmeyen adımlar için güvenlidir. Ayar yolları sürümden sürüme değişiyorsa bu seçenek tek başına yeterli olmaz ve sorunun ne kadar sürüme bağlı olduğu önceden düşünülmelidir.
Eski Ad Ve Yeni Ad Arasındaki Mesafe
Ekran adı değişikliği, yanıt kalitesinde en sık gözden kaçan konulardan biridir. Eski adı hatırlayan müşteri yeni arayüzde aradığını bulamayınca aynı soruyu tekrar sorar. Bu nedenle eski ve yeni adın kaynakta birlikte tutulup tutulmayacağı baştan karara bağlanmalıdır.
Burada belirleyici ölçüt, eski adın müşteriler tarafından ne sıklıkla kullanıldığıdır. Sık sorulan eski adlar geçiş notu olarak saklanabilir; nadir kalanlar ise arşiv kaydında durabilir. Her iki durumda da yanıtın ana cümlesi güncel adı kullanmalı, eski ad yalnızca sürüm geçişini açıklamak için anılmalıdır.
Ekip Sorumluluğu: Kim Neyi Onaylar?
Bir yanıtın doğru sürümle eşleştiğini kimin onayladığı açık olmalıdır. Ürün ekibi yeni işlevin hangi sürümde yayımlandığını, destek ekibi müşterilerin hangi ifadelerle sorduğunu, içerik sorumlusu ise kaynak metnin güncelliğini bilir. Bu üç bilgi tek kişide toplanırsa sorumluluk darboğaza dönüşür ve onay gecikir.
Pratik bir ayrım, her sürüm değişikliğinde hangi kaynakların yeniden onaylanacağını önceden listelemektir. Onay sorumlusu değişiklik olmasa bile düzenli gözden geçirme yapmalıdır. Aksi hâlde kaynaklar sessizce eskir ve bunu ilk fark eden genellikle müşteri olur. Güncellik konusunda bilgi güncelliği kavramı bu ayrımı netleştirmek için yararlı bir çerçeve sunar.
Temsili Konuşma Örneği
Aşağıdaki görüşme temsilidir ve gerçek bir müşteri kaydı değildir. Konu, faturaların toplu dışa aktarılmasıdır.
Müşteri: Faturaları toplu indirmek için hangi menüye bakmalıyım?
Asistan: Doğru bölümü gösterebilmem için kullandığınız sürüm numarasını ve ekranda gördüğünüz menü etiketini yazabilir misiniz? Hesap bilgisi ya da ekran görüntüsü paylaşmanıza gerek yok.
Müşteri: Sürüm 3.8 kullanıyorum, sol menüde Veri Merkezi yazıyor ama fatura seçeneğini bulamadım.
Asistan: Teşekkürler. Bu etiketle kesin bir yol söyleyemiyorum, çünkü planınızda toplu dışa aktarmanın açık olup olmadığını doğrulamam gerekiyor. Bu doğrulamayı destek ekibi yapabilir. Verdiğim bilgi yalnızca sürüm 3.8 ve bu etiket için geçerlidir.
Bu örnekte asistan yolu tahmin etmedi ve bir sonraki adımın da kesin olmadığını açıkça söyledi. Bu dürüstlük, müşterinin yanlış menüde zaman kaybetmesini önler ve konuyu doğru ekibe taşır.
Karşılaştırma Tablosu
Aşağıdaki tablo üç yanıt biçimini aynı ölçütlerle karşılaştırır.
| Yanıt biçimi | Yanlış yönlendirme riski | Bilgi toplama maliyeti | Bakım yükü | Uygun olduğu durum |
|---|---|---|---|---|
| Sürüme özgü kesin yanıt | Yüksek, sürüm yanlışsa | Düşük | Her sürüm için ayrı kontrol | Sürüm ve plan kesin biliniyorsa |
| Koşullu yanıt | Orta | Orta | Ortak metin ve sürüm farkları | Birkaç sürüm birlikte destekleniyorsa |
| Yalnızca yönlendirme | Düşük | Düşük | Düşük | Sürüm bilinmiyorsa ya da kapsam dışıysa |
Tüm sütunları görmek için tabloyu yana kaydırın.
Tablo kesin bir sıralama değil, bir başlangıç noktasıdır. Kendi ürününüzdeki sürüm sayısı, plan çeşitliliği ve destek ekibinin kapasitesi farklı bir tercih doğurabilir. Her satırın hücrelerini ekibinizle birlikte doldurmak, varsayımları görünür kılar.
Karar Ve Test Listesi
Aşağıdaki liste karar vermeden önce ve sonra kullanabileceğiniz bir kontrol sırasıdır.
- Desteklenen sürüm ve plan listesini, destek sorumlusunun onayladığı tek bir tabloda tutun.
- Kapsam dışı sürümler için yanıt biçimini, yani yönlendirme ya da genel bilgi, önceden belirleyin.
- Her konu için hangi ayırt edici bilginin istenebileceğini yazın; hassas bilgi istemeyin.
- Eski ekran adlarını sorulma sıklığına göre geçiş notuna alın ya da arşivleyin.
- Her yanıt biçimini dört ölçütle değerlendirin: yanlış yönlendirme, bilgi toplama, bakım ve insan yükü.
- Sürüm değişikliği öncesinde etkilenen konuların listesini çıkarın ve onay sorumlusunu atayın.
- Gerçek müşteri ifadelerinden oluşan küçük bir örnek seti hazırlayın ve her sürümde çalıştırın.
- Yanlış sürüm yanıtı tespit edilen konuları düzenli aralıklarla gözden geçirin.
Bu kararlar tamamlandığında hangi kaynağın hangi sürümü kapsadığı, hangi durumda insan ekibine geçileceği ve hangi testlerin yeniden çalıştırılacağı açık hâle gelir. Test senaryolarını kurmak için asistan senaryo test listesi sayfasından, kaynak düzenini netleştirmek için ise PDF kaynak düzeni notlarından yararlanabilirsiniz. Karar kayıtlarını ekipler arasında tutarlı tutmak için kanallar arası bilgi tutarlılığı yaklaşımı da bu sürecin devamında işe yarar.
