Metlivi Blog

Kullanıcıların sorudan kapanışa kadar takip edebileceği bir destek yolu oluşturun

Bir tamamlayıcı uygulama, her endişeyi tek bir sohbet robotunun veya genel bir iletişim formunun arkasına gizlememelidir. Net bir şekilde adlandırılmış üç rotaya ihtiyacı vardır: hesap, erişim, ödeme kaydı veya özellik sorunları için insan müşteri desteği; belirli bir öğe, hesap, etkileşim veya güvenlik endişesi için şikayet bildirimi; ve hizmet tarafından halihazırda verilmiş bir karara itiraz etmek için itiraz yolu. Otomasyon bir vakayı onaylayabilir ve yönlendirebilir, ancak uygulama bir insanın bunu ne zaman inceleyebileceğini, devir işlemiyle hangi bilgilerin aktarıldığını, vakanın hangi durumda olduğunu, bir sonraki güncellemenin ne zaman beklendiğini ve nasıl kapandığını açıklamalıdır. Bir alındı belgesi yalnızca başvurunun yapıldığını kanıtlar, belirli bir eylemin gerçekleştirildiğini değil. Benzer şekilde, bir itiraz yeni bir inceleme yolu sağlar, kararın bozulacağına dair bir söz değil. Pratik standart; kullanıcılardan özel materyalleri birden fazla ekibe tekrar tekrar anlatmalarını istemeden sorumlusu, kanıt sınırları, karar kapsamı ve bir sonraki adımı anlaşılır kalan, izlenebilir bir vakadır.

27 Ağustos 202611 dk okuma süresiEv, güvenlik, evcil hayvanlar ve sürdürülebilir yaşamYazan: Metlivi Editorial Team
Bölüm 1

Ayrıntıları sormadan önce destek, bildirim ve itiraz yollarını ayırın

İlk ekran, kullanıcının dahili departman adına göre değil, görevine göre bir rota seçmesine yardımcı olmalıdır. Müşteri desteği; erişim, hesap kurtarma, abonelik kayıtları, ayarlar ve açıklandığı gibi çalışmayan özellikleri kapsar. Şikayet bildirimi; içeriği, iletişimi, bir hesabı, paylaşılan bir alanı, bir öneriyi veya yayınlanan kuralları ihlal edebilecek gözlemlenebilir diğer bir olayı kapsar. İtiraz ise mevcut bir kararla başlar: içeriğin kaldırılması veya yayında bırakılması, bir hesabın veya özelliğin kısıtlanması ya da önceki bir şikayetin kapatılması gibi. Örnekler gösterin ve kullanıcının yanlış rotayı seçmesi durumunda düzeltme yapmasına izin verin. Ortak tek bir arka uç verimli olabilir, ancak herkese açık akış, iletişime geçme nedenini ve geçerli sonraki adımları korumalıdır. Otomatik rotanın anlayamadığı konular, özellikle erişim engelleri, itiraz edilen kararlar, yinelenen başarısız yönlendirmeler ve bağlam gerektiren vakalar için görünür bir insanla iletişim seçeneği veya açıkça belirtilmiş bir insana eskalasyon yolu bulundurun. Bir bot konuşmasını insan desteği olarak etiketlemeyin ve kullanıcı mevcut bir vaka hakkında soru sorarken onu yeni bir şikayet oluşturmaya zorlamayın.

Bölüm 2

Üzerinde işlem yapılabilecek en küçük kapsamlı şikayeti toplayın

Şikayet bildirimini mümkün olduğunda ilgili öğenin veya etkileşimin yanına yerleştirin; aynı zamanda eksik bir öğe veya oturum açamayan bir kişi için bir yardım merkezi rotası da sunun. Kullanıcının etkilenen yüzeyi, içeriği veya hesabı, yaklaşık zamanı, geçerli endişeyi ve kısa bir serbest metin açıklamasını belirtmesine izin verin. Sabit bir kategori yönlendirmeyi hızlandırır, ancak bir olayı tanımlamanın tek yolu olmamalıdır. Politika izin verdiğinde hizmet tarafında bir öğe tanımlayıcısını, sürümünü ve ilgili bağlamı koruyun; kullanıcının yalnızca materyalin var olduğunu kanıtlamak için onu tekrar tekrar açmasını veya yeniden dağıtmasını zorunlu kılmayın. Nelerin dahil edileceğini, bunlara kimlerin erişebileceğini ve vaka kaydının ne kadar süreyle saklanacağını açıklayın. Asla bir şifre, kurtarma kodu veya konuyla ilgisi olmayan konuşma geçmişi istemeyin. Oturum açmadan veya üçüncü tarafça bildirim yapma imkanı sunuluyorsa, bunun sınırlarını ve güncellemelerin nasıl iletileceğini belirtin. eSafety'nin tasarım rehberi, özellikle bulunması zor araçların, zorunlu hesap oluşturmanın, belirsiz alanların ve şikayet edilen materyalle tekrar tekrar yüzleşmek zorunda kalmanın bildirimde bulunmayı caydırabileceğini belirtmektedir.

Bölüm 3

Alındı belgesini okunabilir bir vaka durumuna dönüştürün

Gönderimden sonra bir vaka kimliği ve bunu kontrol etmek için kalıcı bir yer sağlayın. Kullanışlı bir durum modeli şunları birbirinden ayırır: alındı, bilgi gerekiyor, sırada, incelemede, işlem yapıldı, belirtilen kural kapsamında işlem yapılmadı, itiraz edildi, değiştirildi ve kapatıldı. Bu etiketler, kalıcı bir 'devam ediyor' rozeti göstermek yerine hizmetin ne bildiğini açıklamalıdır. Bilgilendirme mesajı; nesneyi ve rotayı tekrarlamalı, saklanan kanıtları listelemeli, engelleme veya sessize alma gibi acil bir kişisel denetimin kullanılabilir durumda olup olmadığını belirtmeli ve bir sonraki güncelleme zaman aralığını vermelidir. Bir zaman aralığı, bir sonuç vaadi değil, bir hizmet beklentisidir; değişirse tarihi sessizce ileri almak yerine yeni bir güncelleme gönderin. Durum mesajlarında başka bir kişinin hesap verilerini ifşa etmeyin veya şikayetçinin kimliğini açık etmeyin. Bir vakanın parçaları iki farklı ekibin sorumluluğundayken, tek bir genel vaka kimliği kullanın ve kullanıcıdan baştan başlamasını istemek yerine devir sürecini gösterin. Bu, çözüm birden fazla dahili sistem gerektirse bile süreklilik sağlar.

Bölüm 4

Otomasyonun vakayı yetkili bir kişiye ne zaman devredeceğini tanımlayın

Otomasyon; alındıyı onaylayabilir, eksik alanları tespit edebilir, dili yönlendirebilir, yinelenen şikayetleri bağlayabilir ve acil denetimler sunabilir. Ancak görünmez bir çıkmaz sokak haline gelmemelidir. Bir insana yönlendirmeyi sağlayan koşulları yayımlayın: kullanıcının insanla iletişim talep etmesi, sorunun mevcut kategorilerle eşleşmemesi, erişim veya erişilebilirliğin tamamlamayı engellemesi, aynı yönlendirmenin art arda başarısız olması, önemli bir bağlamın ihtilaflı olması veya uygun bir itirazın inceleme gerektirmesi. Avrupa Komisyonu'nun DSA (Dijital Hizmetler Yasası) açıklaması, yargı alanına özgü bir kıstas sunar: Kapsam dahilindeki platformlar, yalnızca otomatik araçlara dayanmayan doğrudan kullanıcı iletişimine ihtiyaç duyar ve şikayetler nitelikli personel tarafından ele alınır. Başka bir yerde faaliyet gösteren bir uygulama, bir uyumluluk etiketini ödünç almak yerine fiilen geçerli olan rotaları açıklamalıdır. İnsan temsilciler vaka geçmişine, izin verilen kanıtlara, dil ve erişilebilirlik ihtiyaçlarına ve ilgili kararı verme veya üst makama iletme yetkisine ihtiyaç duyar. Özel kayıtlara erişim iş rolüne uygun olmalı ve taşeron bir ekip, çalışan kimliklerini ifşa etmeden denetim kaydında görünür kalmalıdır.

Bölüm 5

Gerekçeli bir karar ve kullanılabilir bir itiraz hakkı sunun

Bir karar bildirimi; incelenen nesneyi, kural kategorisini, bir işlem yapılıp yapılmadığını, bu işlemin kapsamını ve süresini ve mevcut bir sonraki adımı belirtmelidir. Şikayetçinin kimliğini, gizli tespit ayrıntılarını ve gereksiz özel içeriği gizli tutarken, anlaşılabilecek kadar da spesifik olmalıdır. Hizmet, gerekçenin bir kısmını açıklayamıyorsa, açıklamanın yerine boş bir şablon koymak yerine bu sınırlamayı belirtebilir. İtiraz formu orijinal vaka kimliğini, kararı ve saklanan kanıtları ileriye taşımalı, ardından kişinin gerçekleri düzeltmesine veya bağlam eklemesine izin vermelidir. Bu, kontrolleri atlatmanın veya aynı iddiayı süresiz olarak yeniden sunmanın bir yolu değildir. İlk kararı yeniden değerlendirebilecek bir incelemeci veya inceleme süreci kullanın; kararın onandığını, değiştirildiğini veya daha fazla çalışma için iade edildiğini kaydedin ve yapılan her türlü düzeltmeyi etkilenen tüm yüzeylere uygulayın. Net gerekçeler ve anlamlı incelemeler, hem şikayette bulunan kullanıcıları hem de moderasyon kararlarından etkilenen kişileri destekler.

Bölüm 6

Çıkarılan dersleri hizmete geri aktarırken vakayı kapatın

Kapanış; nihai vaka durumunu, tarihi, eylem kapsamını, kalan kişisel denetimleri, itirazın mevcudiyetini veya tükenip tükenmediğini ve kullanıcının kayda ne kadar süreyle erişebileceğini belirtmelidir. Hizmetin gelecekteki her riski ortadan kaldırdığını iddia etmemelidir. Dahili olarak, yalnızca toplam şikayet veya kaldırma sayılarını değil, daha fazlasını karşılaştırın: gönderilmeden önce terk edilen rotalar, tekrarlanan açıklamaya ihtiyaç duyan şikayetler, ilk anlamlı yanıta kadar geçen süre, devir hataları, yeniden açılan vakalar, itiraz sonuçları, geri yüklenen öğeler, yinelenen kategoriler ve talimatlardaki veya ürün denetimlerindeki değişiklikler. eSafety'nin şeffaflık rehberi ve UNESCO'nun yönetişim ilkeleri; tek bir hacim metriğine değil sonuçlara, şikayetlere, itirazlara ve sistem değişikliklerine bakılmasını destekler. Sıradan bir denetim için dokuz alanlı bir kart kullanın: rota, etkilenen nesne, vaka kimliği, saklanan kanıt, mevcut durum, sorumlu veya devir, bir sonraki güncelleme penceresi, karar ve kapsam, itiraz veya kapanış. Eksik alanlar, canlı bir kuyruk testi veya vaat edilmiş bir sonuç gerektirmeden sürekliliğin tam olarak nerede koptuğunu ortaya çıkarır.

İlgili sorular

Sık sorulan sorular

İnsan desteği, her ilk yanıtın bir kişiden gelmesi gerektiği anlamına mı gelir?

Hayır. Otomasyon bir vakayı onaylayabilir ve yönlendirebilir; ancak uygulama, nitelikli bir kişiye ne zaman ve nasıl ulaşılabileceğini açıklamalı ve otomatik bir çıkmaz sokaktan kaçınmalıdır.

Bir şikayet alındı belgesi, işlem yapıldığının kanıtı mıdır?

Hayır. Bu sadece bildirimin alındığını kanıtlar. Vaka durumu, karar bildirimi, işlem kapsamı ve itiraz rotası sonrasında ne olduğunu gösterir.

Bir itiraz, ilk şikayeti kimin yaptığını ortaya çıkarmalı mıdır?

Hayır. Kullanışlı bir itiraz süreci; şikayetçinin kimliğini veya konuyla ilgisi olmayan özel ayrıntıları ifşa etmeden kararı, kuralı, nesneyi ve izin verilen kanıtları aktarabilir.

İlgili okumalar

Bu konuyu keşfetmeye devam et