Omnichannel Yolculukta Destek Çağrısını Azaltmak
Bir kullanıcı destek hattını aradığında tasarım çoktan başarısız olmuştur, ama çağrının kendisi nerede başarısız olduğunu söylemez. Kaydın üstünde yazan sebep çoğu zaman temsilcinin listeden seçtiği kategoridir, kullanıcının yaşadığı şey değil. Peki yolculuğun gerçekte hangi adımda koptuğunu nereden okuyacağız?
Çağrının sebebi çağrı kaydında yazmaz
Destek talepleri kabaca dört yerden gelir: hizmetin kendisi bozuktur (sipariş eksik geldi, promosyon uygulanmadı), dijital kanal tıkanmıştır, sunulan bilgi yetersizdir, ya da kullanıcı süreci kendi başına götüremeyeceğini düşünmüştür. Bu dördünden yalnızca ilki arayüzle çözülmez. Formu ne kadar iyileştirirseniz iyileştirin, kutudan kırık ürün çıktığında insan arar.
Bu ayrım pratik bir sonuç doğuruyor: toplam çağrı sayısını hedef almak yanlış hedeftir. Tasarımla çözülebilir alt kümeyi ayırmadan yapılan her iyileştirme, kendi etkisini ölçemez hale gelir. Kategori dağılımına bakıp "çağrıların yarısı kargo" demek de yardımcı olmaz, çünkü o dağılım temsilcinin ekranındaki kategori listesinin şeklini yansıtır. Kullanıcı ne dediyse onu okumak istiyorsanız, kategoriye değil çağrı öncesindeki son otuz dakikanın oturum kaydına bakmak gerekir.
Sessiz hatalar, gürültülü hatalardan daha pahalı
Hata mesajı gösteren bir ekran, en azından kullanıcıya ne olduğunu söyler. Asıl sorun hiçbir şey söylemeyen adımlarda: buton basılır, istek düşer, ekran aynı kalır. Kullanıcı bir daha dener, sonra bir daha, sonra telefonu eline alır.
Bir projede destek kayıtlarını işlem loglarıyla eşleştirdiğimizde çağrıların büyük kısmının hata mesajı gösterdiğimiz adımlardan değil, hiçbir iz bırakmadan başarısız olan adımlardan geldiğini gördük. Peki bir başarısızlık hiç kaydedilmiyorsa raporda nasıl görünecek? Görünmez. İstemci tarafındaki yakalanmış istisnaları ve zaman aşımına uğrayan istekleri sunucuya taşımıyorsanız, en çok çağrı üreten adımlar analitik panelinizde temiz görünür.
Tutarlılık mı, bağlama uygunluk mu?
Omnichannel anlatısında iki tavsiye yan yana durur ve birbirini çeker: "her kanalda aynı deneyimi verin" ve "kullanıcının bağlamına uygun kanalı öne çıkarın". İkisi aynı anda doğru olamaz, çünkü biri farklılığı siler diğeri farklılığı ister.
Tutarlı olması gereken şey ekran değil, durumdur. Kullanıcının işlem durumu, hakları, geçmişi ve gördüğü fiyat her kanalda aynı olmalı. Yerleşim, adım sayısı, hatta hangi iletişim yolunun öne çıktığı kanala göre değişebilir ve değişmelidir. Mobilde masaüstü menüsünü küçültüp koymak tutarlılık değil, kopyadır.
"Bir kanalda bıraktığı işlemi diğerinde sürdürebilsin" maddesinin de sessiz bir koşulu var: kullanıcıyı iki kanalda da aynı kişi olarak tanıyabilmek. Oturum açmamış bir ziyaretçide bunu taşıyan tek şey tarayıcıdaki çerezdir, o da telefondan masaüstüne geçtiği anda biter. Yani kimlik doğrulamadan önceki adımlarda kaldığı yerden devam vaadi çoğu senaryoda teknik olarak karşılıksızdır. Ya işlemi mümkün olduğunca erken bir tanımlayıcıya (sipariş numarası, takip kodu) bağlayıp o kodla devam ettirirsiniz, ya da vaadi hiç vermezsiniz.
"Daha az çağrı" hedefi ters teşvik üretir
İletişim numarasını üç tık derine gömün, çağrı sayısı düşer. Sorun düşmez. Bu yüzden destek ihtiyacını azaltmak ile destek kanalını zorlaştırmak aynı grafikte aynı yöne kıpırdar, ve ekip yanlış olanı kutlar.
Daha dürüst iki ölçü var. Birincisi, işleme başlayıp tamamlayamayan kullanıcı oranı; çağrı gelmese bile tıkanmayı gösterir. İkincisi, çağrı sonrası işlemin tamamlanıp tamamlanmadığı; destek gerçekten çözüyor mu, yoksa kullanıcıyı başka bir kuyruğa mı devrediyor. Bu ikisi düzelirken çağrı sayısı düşüyorsa tasarım işe yaramıştır.
Destek yolunu görünür tutmak da bu yüzden zayıflık değil. Yanıt süresi yazacaksanız gerçek süreyi yazın, çünkü "ortalama 2 dakika" diyip yirmi dakika bekleten bir ekran, hiç süre yazmayan ekrandan daha çok güven kaybettirir.