Ortakların gerçekten kullandığı ortak portalları

Bir bayi temsilcisi teklif hazırlayacağı zaman hangi ekranı açar? Sorunun cevabı, çoğu zaman şirketinizin özenle inşa ettiği portal değildir. Cevap; kişisel bir Excel dosyası, bir WhatsApp grubu ya da geçen yıl saha müdüründen kalan bir PDF fiyat listesidir. Portal orada durur, güncel ve doğrudur — ve kullanılmaz.

Ortak portalları, ortaklar için tasarlanmadığı için kullanılmaz; şirket içi raporlama ve kontrol ihtiyacı için tasarlanır. Kullanılabilir bir portal, ortağın günlük iş akışına en az beş dakikalık bir görevi (fiyat kontrolü, stok sorgusu, komisyon takibi) en fazla iki dakikaya indiren araçtır; bunun altındaki her tasarım, portalı "zorunlu ama terk edilen" bir sisteme dönüştürür. Bu, B2B2C dünyasında soyut bir verimlilik meselesi değildir — portalı kullanmayan ortak, son müşteriye eski fiyatı, yanlış stok bilgisini ya da tutarsız bir kampanyayı aktarır. Ortak deneyimindeki her sürtünme, zincirin sonunda müşteri deneyimine dönüşür.

Ortaklar portalınızı neden kullanmıyor?

Çünkü portal, ortağın işini kolaylaştırmak için değil, sizin görünürlük ihtiyacınızı karşılamak için tasarlanmıştır. Davranış ekonomisinde buna sürtünme denir — bir eylemi tamamlamak için gereken bilişsel ve fiziksel çaba. Richard Thaler, 2018 yılında Science dergisinde yayımlanan "Nudge, Not Sludge" başlıklı makalesinde, gereksiz sürtünmeye özel bir isim verir: sludge (çamur). Sludge, bir kullanıcıyı istediği sonuca ulaşmaktan caydıran, kasıtlı ya da kasıtsız her tasarım engelidir — fazla onay adımı, gereksiz form alanı, mantıksız menü hiyerarşisi.

Çoğu ortak portalı sludge ile doludur: giriş için üç farklı şifre kuralı, fiyat almak için beş tıklama, komisyon durumunu görmek için müşteri hizmetlerini arama zorunluluğu. Ortak, WhatsApp'ta aynı bilgiye on saniyede ulaşabiliyorsa, portal rasyonel bir tercih değil, bir ceza olarak algılanır. Bu noktada devreye etki heuristiği (affect heuristic) girer: ortak, portalla ilk kötü deneyiminden sonra sistemin tamamına dair olumsuz bir duygusal etiket yapıştırır ve bir daha denemez.

Ortak portalındaki sürtünme son müşteriyi nasıl etkiler?

B2B2C ilişkilerinde şirketiniz ile son müşteri arasında bir aracı vardır — bayi, distribütör, acente, broker. Bu aracının kullandığı araç ne kadar zayıfsa, müşteriye ilettiği bilgi de o kadar hataya açıktır. Bir sigorta brokerinin poliçe fiyatlandırmasını portaldan değil, üç ay önceki bir e-postadan alması; bir telekom bayisinin kampanya koşullarını yanlış hatırlaması — bunların hepsi aynı köke iner: portal, ortağın gerçek iş akışının bir parçası değildir, ona eklenmiş bir yük olarak kalır.

Bu yüzden ortak deneyimini, dolaylı olarak yönetilen bir müşteri deneyimi kanalı olarak görmek gerekir. Müşteri deneyimi stratejinizin ne kadar iyi tasarlandığı önemsizleşir, eğer bu stratejiyi son müşteriye aktaran ortak, doğru araçtan yoksunsa. Nielsen Norman Group'un kurumsal yazılım kullanılabilirliği üzerine yayımladığı Enterprise UX analizinde vurgulanan temel bulgu şudur: kurumsal kullanıcılar, tüketici uygulamalarında gördükleri kullanılabilirlik standardını iş araçlarında da bekler ve bu standarda ulaşmayan araçları resmî olmayan alternatiflerle (e-posta, sohbet uygulamaları, kağıt üzerinde not) telafi eder. Ortak ağınızda da tam olarak bu olur.

Bir portalın gerçek rakibi başka bir yazılım değildir; ortağın zaten alışkın olduğu WhatsApp grubu, Excel dosyası ya da telefon görüşmesidir.

Kayıtlı kullanım ile gerçek kullanım arasındaki fark nedir?

Çoğu şirket portal başarısını "aylık aktif kullanıcı" veya "giriş sayısı" ile ölçer — bu, davranışı değil, varlığı ölçen bir vanity metriktir. Ortak giriş yapabilir, ana sayfaya bakabilir, hiçbir görev tamamlamadan çıkabilir. Gerçek kullanım, görev tamamlama oranıdır: kaç fiyat teklifi portaldan üretildi, kaç komisyon sorgusu çağrı merkezine düşmeden çözüldü, kaç sipariş portal üzerinden girildi ve hiçbir manuel düzeltme gerekmedi.

Bu ayrım önemlidir çünkü şirketler genellikle yanlış göstergeyi optimize eder. Giriş sayısını artırmak için portalı zorunlu hale getirebilirsiniz (örneğin komisyon ödemesini portal onayına bağlayarak) — ama bu, kullanımı değil, itaati artırır. Ortak yine de işini WhatsApp'ta yapar, sadece rapor için portala girer. Gerçek benimseme, ortağın seçme şansı olduğunda bile portalı tercih etmesidir.

Portal kullanımını değerlendirirken bakılması gereken sinyaller

• Görev tamamlama oranı — başlanan bir işlemin (teklif, sipariş, talep) portal içinde sonuçlanma yüzdesi, sadece giriş sayısı değil.
• Destek kanalına düşme oranı — portalın çözebileceği bir soru için çağrı merkezine ya da hesap yöneticisine kaç kez başvuruluyor.
• Gönüllü kullanım — zorunlu olmayan işlemlerde (örneğin eğitim materyaline erişim, pazarlama varlıklarını indirme) ortağın kendi isteğiyle portala dönme sıklığı.
• Ortak segmentleri arası fark — büyük ve deneyimli ortaklar mı, yoksa küçük ve yeni ortaklar mı portalı daha az kullanıyor; bu, eğitim eksikliği ile tasarım eksikliğini birbirinden ayırmanıza yardımcı olur.
• Terk noktası — hangi ekranda ortaklar işlemi bırakıp telefonu açıyor; bu, sürtünmenin tam olarak nerede yoğunlaştığını gösterir.

Ortaklar portal tasarımında hangi davranışsal tuzaklara düşer?

Portal tasarımcıları genellikle ortağı, şirketin çıkarına uygun rasyonel bir aktör gibi ele alır. Gerçekte ortak, kendi zamanının değerini hesaplayan, kısa vadeli getiriyi önceleyen ve alışkanlıklarına bağlı bir karar verici gibi davranır. Burada devreye giren iki davranışsal ilke özellikle belirleyicidir.

Birincisi hedef-gradyan etkisi (goal-gradient effect): bir kişi, hedefine ne kadar yaklaşırsa o kadar hızlanır ve motivasyonu artar. Ran Kivetz, Oleg Urminsky ve Yuhuang Zheng'in 2006 yılında Journal of Marketing Research'te yayımlanan "The Goal-Gradient Hypothesis Resonates with Retailers" başlıklı çalışması, sadakat kartlarında ilerleme çubuğunun tamamlanma oranını doğrudan etkilediğini göstermiştir. Aynı mantık portal onboarding'ine uygulanabilir: bir ortağa "profilinizin %80'i tamamlandı" gösterdiğinizde, kalan %20'yi tamamlama olasılığı, boş bir kontrol listesi göstermekten çok daha yüksektir.

İkincisi seçim aşırılığı (choice overload): portal ana sayfasında yirmi farklı menü, ortağı harekete geçirmek yerine donduran bir bilişsel yük yaratır. Kullanılabilir portallar, ortağın rolüne ve o anki ihtiyacına göre daralmış, üç ya da dört net eylemle karşısına çıkar — "teklif oluştur", "stok sorgula", "komisyonumu gör". Her şeyi göstermeye çalışan portal, hiçbir şeyi öncelikli hale getiremez.

Üçüncü bir katman da IKEA etkisidir: bir sistemin tasarımına katkı sağlayan kişi, o sisteme karşı daha yüksek sahiplenme duygusu geliştirir. Portalı ortaklara danışmadan, sadece iç ekiplerin gereksinimlerine göre inşa eden şirketler, bu sahiplenmeyi baştan kaybeder. Bu etkiyi ve ortak eş-yaratımının müşteri deneyimine katkısını daha ayrıntılı işlediğimiz IKEA etkisi ve müşteri deneyiminde birlikte yaratım başlıklı yazımız, bu ilkenin portal tasarımına nasıl taşınabileceğini gösteriyor.

Kullanılan bir portal nasıl tasarlanır?

Kullanılabilirlik, portalın son eklenen özelliği değil, ilk tasarım kararı olmalıdır. Aşağıdaki sıralama, şirket içi gereksinim listesinden değil, ortağın gerçek iş akışından başlar.

1. Ortağın gününü haritalayın, sizin sürecinizi değil. Bir ortağın sabahtan akşama hangi görevleri hangi sırayla yaptığını gözlemleyin; portal özellik listesini bu gözlemden çıkarın, iç departmanların istek listesinden değil. Ortak yolculuğunu ayrı bir CX yolculuğu olarak haritalamak, hangi adımların gerçekten portalda olması gerektiğini netleştirir.
2. Tek bir birincil eylemi önceliklendirin. Her ortak segmenti için portalın çözmesi gereken bir "işi" (job-to-be-done) belirleyin — bir distribütör için stok görünürlüğü, bir sigorta acentesi için hızlı fiyatlandırma — ve ana ekranı bu işe göre tasarlayın.
3. Varsayılanları doğru kurun. Choice architecture'ın en güçlü aracı varsayılan seçenektir; en sık kullanılan filtre, en çok satılan ürün, en yakın teslimat tarihi varsayılan olarak önceden seçili gelmelidir. Ortak, doğru sonuca ulaşmak için çaba harcamamalı.
4. İlerlemeyi görünür kılın. Onboarding, sertifikasyon ya da kampanya katılımı gibi çok adımlı süreçlerde ilerleme çubuğu veya tamamlanma yüzdesi kullanarak hedef-gradyan etkisinden yararlanın.
5. Sludge'ı ayıklayın. Her form alanını, her onay adımını "bu gerçekten gerekli mi, yoksa sadece bizim raporlama kolaylığımız için mi var" sorusuyla test edin. Şüpheli olan her adım kaldırılmalıdır.
6. Ortaklarla birlikte tasarlayın, onlar için değil. Portal geliştirme sürecine gerçek ortakları — özellikle en sadık ve en eleştirel olanları — dahil edin. Bu, hem daha iyi tasarım hem de IKEA etkisi üzerinden daha yüksek sahiplenme yaratır.
7. Kademeli olarak yayına alın ve gerçek davranışı izleyin. Portalı tek seferde tüm ağa açmak yerine, bir bölge veya segmentte pilot uygulayın; görev tamamlama oranını ve terk noktalarını izleyerek genişletin.

Ortak portalının başarısı nasıl ölçülmeli?

Ölçüm çerçevesi, kullanım verisini ortağın sesiyle birleştirmelidir. Sistem loglarınız "ne olduğunu" gösterir; ortakla yapılan görüşmeler "neden" olduğunu açıklar. Bir ortağın belirli bir ekranı terk etmesinin nedeni, o ekranın yavaş yüklenmesi de olabilir, o ekranın gerektirdiği bilgiye o an sahip olmaması da olabilir — bu ikisi çok farklı çözümler gerektirir.

Bu yüzden yapılandırılmış bir geri bildirim stratejisi, portal analitiğinin tamamlayıcısı olmalıdır: düzenli ortak anketleri, kullanım verisiyle çapraz okunan görüşmeler ve — mümkünse — portalın kendisine gömülü, tek soruluk anlık geri bildirim mekanizmaları. Kuruluşunuzun ortak deneyimi genel olgunluğunu değerlendirmek isterseniz, CX olgunluk değerlendirmesi ortak kanalınızın hangi yapı taşlarında zayıf kaldığını görmenize yardımcı olabilir.

Ölçümün son adımı, bulguları organizasyonel değişikliğe bağlamaktır. Bir portalın yeniden tasarımı, sadece bir arayüz projesi değildir; ortakların alışkanlıklarını, iç ekiplerin süreçlerini ve bazen komisyon veya teşvik yapılarını da etkiler. Bu ölçekte bir dönüşümü yönetmek, değişim yönetimi disiplinini gerektirir — yeni portalı duyurmak yeterli değildir, ortağın eski alışkanlığını bırakmasının maliyetini de yönetmek gerekir.

Farklı ortak ağlarında bu ilkeler nasıl değişir?

Bir bankanın acente ağı ile bir e-ticaret platformunun satıcı ağı aynı davranışsal mantıkla çalışmaz, ama aynı temel ilkeye tabidir: araç, işin gerçek akışına ne kadar yakınsa o kadar kullanılır. Bir telekom operatörünün bayi ağında fiyat ve stok bilgisinin saniyeler içinde değişebildiği düşünülürse, portalın gerçek zamanlı veri sunması hayati hale gelir; aksi halde bayi kendi tahminine güvenir ve müşteriye yanlış bilgi verir. Bir sigorta broker ağında ise asıl darboğaz genellikle hız değil, güvendir — broker, portalın hesapladığı primin doğru olduğuna inanmıyorsa, kendi manuel hesaplamasına döner.

Bölgesel ortak ekosistemlerinde bu dinamiklerin nasıl işlediğini, gerçekte kullanılan portal örnekleri üzerinden ele aldığımız bölgesel ortak portalı analizimizde daha geniş bir çerçevede inceledik. Ortak deneyiminin kanal, sektör ve pazara göre nasıl farklılaştığını görmek, tek bir "en iyi tasarım" reçetesi aramak yerine, kendi ağınızın gerçek sürtünme noktalarını bulmanıza yardımcı olur.

• Bayi ve distribütör ağları için kritik değişken hız ve veri tazeliğidir; eski stok bilgisi güveni anında yok eder.
• Sigorta ve finansal aracı ağları için kritik değişken şeffaflık ve doğrulanabilirliktir; ortak, sistemin hesabına güvenmelidir.
• Perakende satıcı ve pazaryeri ortakları için kritik değişken kendi kendine hizmet edebilme derecesidir; destek ekibine bağımlılık ne kadar azsa memnuniyet o kadar yüksektir.
• Franchise ve bayilik ağları için kritik değişken yerel esnekliktir; merkezi kuralları katı şekilde dayatan portallar, sahadaki gerçekliğe uymadığında terk edilir.

Sonuç: Portal bir kontrol aracı değil, bir ilişki aracıdır

Şirketler ortak portalını genellikle bir "erişim ve kontrol" aracı olarak tasarlar — kimin ne görebileceğini, kimin neyi onaylayabileceğini belirleyen bir katman. Ama ortağın gözünden portal, şirketle olan ilişkinin günlük yüzüdür. O ilişki ne kadar sürtünmesizse, ortak o kadar sadık kalır, o kadar doğru bilgiyi son müşteriye taşır ve şirketle o kadar az sürtüşme yaşar.

Bir sonraki portal yenileme projesine başlamadan önce sorulacak en doğru soru, "hangi özellikleri ekleyelim" değil, "ortağımız bu görevi bugün nasıl yapıyor ve neden bizim aracımızı değil, kendi çözümünü seçiyor" olmalıdır. Bu sorunun cevabı, genellikle bir özellik eksikliğinde değil, bir güven ya da çaba dengesizliğinde bulunur — ve o dengesizlik düzeltildiği gün, kullanım oranları kendiliğinden değişir.