Konu Başlıkları
Yükleniyor...

UX ve CX'i Birleştirmek: Yolculuk Haritası Nerede Kırılıyor

Yolculuk Odaklı Tasarım: Haritanın Vaadi, Verinin Söylediği

Yolculuk odaklı tasarım anlatısı hep aynı yerde düğümlenir: departmanlar silo halinde çalışıyor, ortak hedef yok, bütçe ayrı. Doğru ama eksik. Silolar kalksa bile, birbirini takip eden bir yolculuk görebilmek için kimin nereden geçtiğini bilmen gerekiyor, ve çoğu kurumda o bilgi yok. Bu yazı, haritanın çizdiği akışla sistemin kaydettiği akışın neden tutmadığına bakıyor.

Silo hikâyesinin eksik yarısı

Organizasyon şemasını düzeltmek yolculuk sorununu çözmüyor. Web tarafında ziyaretçi bir çerez kimliğiyle, mobilde cihaz kimliğiyle, çağrı merkezinde telefon numarasıyla, faturada vergi numarasıyla tanınıyor. Aynı kişinin bu dördünden geçtiğini söyleyebilmek için ortak bir anahtar gerekiyor. O anahtar yoksa, çizilen yolculuk bir ölçüm değil, bir varsayım.

Peki ya anahtar kısmen varsa? Genelde durum budur: kullanıcıların bir bölümü giriş yapmıştır, gerisi anonimdir. O zaman elindeki yolculuk verisi giriş yapanların yolculuğudur, yani zaten en bağlı müşterilerin. Terk edenler, tam da haritanın açıklamaya çalıştığı kişiler, veride görünmez. Bu, ekiplerin "yolculuk sorunsuz görünüyor" sonucuna varmasının en sık sebeplerinden biri.

Harita mutlu yolu çizer, sistem tüm grafiği taşır

Atölyede çizilen yolculuk haritaları soldan sağa akar: altı temas noktası, aralarında beş ok. Gerçekte bu altı nokta arasında geçiş serbestse, olası yönlü geçiş sayısı 6 × 5 = 30. Haritanın gösterdiği beş adım, mümkün akışların altıda birinden azı. Kalan yirmi beş geçiş yok sayılmıyor, sadece kimse onlara bakmıyor: mobil uygulamadan çağrı merkezine dönen, ödeme adımından ürün sayfasına geri giden, e-postadaki linkten üçüncü kez gelen kullanıcı hep o kalan kısımda.

Bir atölyede çizilmiş yolculuk haritasını, sistemin kendi loglarından çıkarılan akıştan daha az güvenilir bulurum. Harita ekibin yolculuk hakkındaki inancını gösterir; log kullanıcının ne yaptığını. İkisi çakıştığında haritayı kullanmakta sorun yok. Ayrıştığında haklı çıkan taraf neredeyse her zaman log oluyor.

Haritayı tamamen atmak gerekmiyor

Harita hâlâ işe yarıyor, ama başka bir iş için: nerede ölçüm yapılacağını konuşmak. Ekip altı kutu çizip aralarındaki geçişleri tartıştığında, aslında hangi olayların kaydedilmesi gerektiğine karar veriyor. Çıktıyı bir sonuç raporu değil, ölçüm planı olarak görmek bu yüzden daha verimli.

Yolculuk tek bir kişinin mi?

Yolculuk kavramı sessizce tek bir aktör varsayar. Oysa satın alma kararlarının önemli bir kısmı böyle çalışmıyor. Ev aboneliğini biri açar, faturayı başkası öder. Kurumsal alımda araştırmayı yapan, kararı veren ve sözleşmeyi imzalayan üç ayrı kişi olabilir.

Bu durumda yolculuk haritası kimin yolculuğunu çiziyor? Üç kişinin adımlarını tek çizgide birleştirirsen ortaya kimsenin yaşamadığı bir deneyim çıkar. Ayrı ayrı çizersen aralarındaki devir teslim anlarını kaybedersin, ki asıl sürtünme genelde tam orada. Pratikte işe yarayan yöntem, yolculuğu kişiye göre değil, hesaba ya da işleme göre kurmak ve kişileri o işlemin üstünde rol olarak taşımak.

Küçük ekipte nereden başlanır

Kaynağı sınırlı bir ekipte ayrı bir CX fonksiyonu kurmaya çalışmak zaman kaybı. Daha hızlı yol, tek bir yolculuğu seçip uçtan uca ölçülebilir hale getirmek:

  • En çok şikâyet üreten tek bir akışı seç, tamamını değil.
  • O akıştaki her adıma aynı kimlik anahtarını taşıyan bir olay kaydı ekle.
  • Kanal değişen noktaları ayrıca işaretle; kopmaların çoğu orada oluyor.
  • İki hafta veri biriktikten sonra haritayı yeniden çiz, bu kez veriyle.

Bu dört maddenin üçüncüsü genelde atlanıyor ve en pahalıya patlayanı o. Kanal geçişinde bağlam taşınmadığında kullanıcı kendini ikinci kez anlatmak zorunda kalıyor, memnuniyetsizliğin kaynağı olarak da tasarım değil personel görülüyor.

Geriye ne kalıyor

UX ve CX'i birleştirme tartışması organizasyon şemasında değil, veri modelinde çözülüyor. Ortak hedef ve paylaşılan bütçe faydalı, fakat ikisi de aynı müşteriyi iki kanalda eşleştirebilmenin yerine geçmiyor. Yolculuk odaklı çalışmaya geçmek isteyen bir ekibin ilk sorusu "kim sahip olacak" değil, "aynı kişiyi kaç sistemde tanıyabiliyoruz" olmalı. Cevap birden büyükse, geri kalan her şey ondan sonra geliyor.