Yazılım destek kanalına gelen hata bildirimleri çoğu zaman eksik olur. Bu rehber, asistanın ne kadar bilgi toplaması gerektiğini değil, bu kapsamın nasıl belirleneceğini ve hangi yaklaşımın hangi durumda daha uygun olduğunu ele alır. Uygulama talimatı yerine karar ölçütlerine ağırlık verilmiştir.
Kapsam Hangi Soruyla Belirlenir?
Bir destek asistanı için ilk karar, hangi taleplerin kendisine ait olduğudur. Ürün kurulumu, belgelenmiş kullanım ve sık sorulan genel konular ile hesap, veri veya sistem içi kayıt gerektiren konular aynı kapsamda değerlendirilmemelidir. Kapsam sınırı yazılı değilse asistan her talepte farklı davranır ve müşteri tutarsız yanıtlarla karşılaşır.
Pratik bir kapsam sorusu şudur: Bu talebin doğru yanıtı kamuya açık bir kaynakta var mı, yoksa bir ekibin kendi kayıtlarına bakmasını mı gerektiriyor? İlk durumda asistan genel bilgiyle yanıt verebilir. İkinci durumda ise bağlamı sınırlı biçimde toplayıp devretmesi yeterlidir. Bu soru, hangi bilginin istenmesi gerektiğini de doğal olarak sınırlar.
Alternatifleri Hangi Ölçütlerle Karşılaştırmalı?
Hata bildirimi için üç yaklaşım düşünülebilir: doğrudan çözüm denemesi, yalnızca yönlendirme ve bağlam toplayıp devretme. Doğrudan çözüm denemesi hızlı görünür, ancak asistanın tanılama yetkisi olmadığı durumda yanlış güven yaratır. Yalnızca yönlendirme güvenlidir, fakat müşteriye somut bir bağlam kazandırmaz. Bağlam toplayıp devretme çoğu durumda dengeyi kurar; yeter ki toplanan bilgi sınırlı tutulsun.
Karşılaştırmada üç ölçüt kullanılabilir: gizli veriye ihtiyaç duyulup duyulmadığı, ekibin tekrar soru sorma yükü ve müşterinin beklentisinin doğru yönetilip yönetilmediği. Aşağıdaki tablo bu ölçütlerle üç alternatifi özetler.
| Alternatif | Müşteriye sağladığı | Risk | Uygun durum |
|---|---|---|---|
| Doğrudan çözüm denemesi | Hızlı görünüm | Doğrulanmamış adım ve yanlış güven | Yalnızca onaylı, belgelenmiş genel adım varsa |
| Yalnızca yönlendirme | Güvenli sınır | Ekip aynı soruları tekrar sorar | Hesap, veri veya yetki konuları |
| Bağlam toplayıp devretme | Konunun ekibe net iletilmesi | Gereksiz ayrıntı toplanabilir | Tanılama gerektiren hata bildirimleri |
Tüm sütunları görmek için tabloyu yana kaydırın.
Hangi Veri Hiç İstenmez?
Destek görüşmesinde sınır, bilginin hassasiyetiyle belirlenir. Parola, tek kullanımlık kod, API anahtarı, kart bilgisi, kimlik numarası ve tam günlük dosyası hatanın tespiti için nadiren gereklidir. Bu veriler hiçbir gerekçeyle istenmemelidir; ‘daha net yardım için’ ifadesi bu sınırı değiştirmez.
Müşteri bu verileri kendiliğinden paylaşırsa asistanın yapması gereken, veriyi kullanmamak, konuşmada tekrar etmemek ve güvenli kanala geçişi açıkça söylemektir. Veri minimizasyonu ilkesi burada rehberlik eder: toplanan her alan ekibe gerçekten gerekli olmalıdır.
Hata Metni Ve Adım Ayrımı Nasıl Yapılır?
Genel hata metni sorunun görünen yüzüdür. Asistan bu metni kelimesi kelimesine almalı, yorumlamamalıdır. Ardından müşterinin hangi adımda bu metni gördüğü tek bir cümleyle sorulmalıdır. İki bilgi ayrı tutulduğunda ekip, aynı hatanın farklı adımlardan gelip gelmediğini hızla görebilir.
Adım bilgisi bir modül adı gerektirmez; müşterinin kendi ifadesi yeterlidir. Asistan adını bilmediği bir bileşeni tahmin etmemeli, yalnızca müşterinin anlattığını kaydetmelidir. Ekran görüntüsü istenmesi de çoğu durumda gereksizdir ve kişisel veri riskini artırır.
Zaman Ve Sürüm Bilgisi Ne Kadar Ayrıntılı Olmalı?
Zaman bilgisi, sistem kayıtlarında arama aralığını daraltır. ‘Bugün sabah’ ya da ‘dün akşam’ gibi bir aralık çoğu durumda yeterlidir. Müşteri kesin saatini hatırlamıyorsa asistanın tahmini aralığı kaydetmesi, kesin saat uydurmasından daha doğrudur.
Sürüm bilgisi yalnızca müşterinin kolayca görebildiği ölçüde istenmelidir. Bulunamadığında bunu zorunlu koşul gibi sunmak müşteriyi konuşmadan uzaklaştırır. Bu noktada yazılım demo ve destek ayrımı yaklaşımı, talebin hangi kanala gideceğini netleştirmek için işe yarar.
Temsili Konuşma Örneği
Aşağıdaki konuşma temsili bir örnektir; gerçek bir görüşme değildir.
Müşteri: Formdan dosya gönderirken ‘Yükleme tamamlanamadı’ yazıyor. Ne olduğunu nasıl anlarım?
Asistan: Bu mesajın tam metnini yazabilir misiniz? Dosyayı hangi adımda seçtikten sonra gördünüz?
Müşteri: Dosyayı seçtim, gönder dediğimde çıktı. Bir de içinde telefon numaram olan bir ekran görüntüsü var, onu da eklesem olur mu?
Asistan: Lütfen kişisel bilgi içeren görüntüyü göndermeyin. Mesajın birebir metni ve gönder adımı yeterli. Bunları destek ekibinin inceleyebileceği bir özet olarak hazırlayabilirim. Ekibin yanıt süresi ekibe bağlıdır ve bu özet tek başına bir kayıt anlamına gelmez.
Bu konuşmada asistan, dosya yükleme sorununu kendisi çözmeye çalışmaz. Yalnızca hata metnini ve adımı alır, kişisel veri riskini erken durdurur ve sorunun ekip incelemesine gideceğini açıkça söyler.
Ekip Sorumluluğu Ve Devir Düzeni
Asistanın ürettiği özet, ekibin işini kolaylaştıran bir girdidir; karar yerine geçmez. Özetin hangi alanları içereceği, hangi hata türünün öncelikli sayılacağı ve müşteriye ne zaman dönüleceği önceden yazılı olmalıdır. Sorumluluk belirsiz kaldığında özet ekibe ulaşsa bile kimse üzerine almaz.
Bildirim ile çözüm farklı şeylerdir. Yeni bir görüşmenin ekibe düşmesi, sorunun incelendiği ya da birine atandığı anlamına gelmez. Müşteriye verilecek mesaj bu ayrımı açıkça söylemeli, bekleme süresini bir taahhüt gibi değil, ekibin çalışmasına bağlı bir durum olarak anlatmalıdır. Devir ayrıntıları için şikâyet mesajında insan desteği yazısına bakılabilir.
Test Planı Ve Karar Listesi
Kapsam kararlarını sınamak için gerçek konuşma kayıtları yerine kontrollü temsili senaryolar kullanılabilir. Her senaryoda beklenen davranış önceden yazılmalı; asistanın gizli veri istemediği, sınır dışı konularda yetki iddia etmediği ve devri doğru yaptığı ayrı ayrı kontrol edilmelidir.
Aşağıdaki liste karar ve test adımlarını sıralar:
- Her talep için kamuya açık yanıt mı yoksa ekip incelemesi mi gerektiği yazılı olarak sınıflandırılır.
- İstenen dört alan (ürün adı, hata metni, adım, yaklaşık zaman) dışında alan eklenmediği kontrol edilir.
- Parola, kart, kimlik, anahtar ve günlük gibi verilerin istenmediği, paylaşılırsa tekrar edilmediği senaryolarla sınanır.
- Sürüm bilgisi bulunamadığında konuşmanın durmadığı denenir.
- Tahmini zaman aralığının kesin saat gibi yazılmadığı doğrulanır.
- Devir özetinde gizli veri bulunmadığı ve ekibin okuyabileceği sade bir biçimde yazıldığı kontrol edilir.
- Her senaryoda bildirimin çözüm anlamına gelmediği ve bekleme süresinin ekibe bağlı olduğunun söylendiği görülür.
Sonuç olarak en az veriyle en net bağlam toplanmalı, kapsam dışı taleplerde ise yanlış güven verilmemelidir. Bu ölçütler sağlanmıyorsa ekip akışının yeniden gözden geçirilmesi gerekir.
