Çok Kanallı Pazaryeri İadelerini Tek Sistemde Yönetmek

Bir mağazayı Shopify ya da Ticimax üzerinden yeterince uzun süre yönetince pazaryerleri kendiliğinden listeye eklenir: Trendyol, Hepsiburada, Amazon, bazen de kimsenin planlamadığı bölgesel bir oyuncu. Her biri kendi iade süresini, kargo ücretini kimin karşılayacağına dair kendi kuralını ve kendi iade takvimini beraberinde getirir. Bunların hiçbiri sizin tercihinize bağlı değildir; pazaryerleri kendi satıcı politikalarını dayatır, sizinkini değil. Sonuçta ortaya çıkan tablo, tek bir markayı taşıyan tek bir işletmeden çok, müşteriye her seferinde biraz farklı bir söz veren ve muhasebeyi birbirinden biraz farklı şekilde güncelleyen dört ayrı işletmeye benziyor.

Parçalanmışlığın asıl acıttığı yer

Asıl sorun politika farklarının kendisi değil — bir iade ekibi dört farklı teslim süresini ezberleyebilir. Pahalıya patlayan kısım, kanalların birleştiği noktalarda yaşananlar. Bir müşteri pazaryerinden aldığı bir montu iade eder, pazaryeri kendi iadesini işler, üç gün sonra depoda bir çalışan ürünü stoğa geri okutur ve pazaryerinin zaten ödemeyi tamamladığından habersiz olan kendi mağaza sisteminiz, aynı sipariş için ikinci bir iade daha başlatır. Bunu ayda birkaç düzine üründe çarptığınızda, finans ekibi kaynağını bir türlü bulamadığı bir sızıntıyı kapatmaya çalışıp durur. Aynı kırılma noktası tam tersi bir hataya da yol açar: bir iade hiçbir yere kaydedilmez, ürün bir kutuda bekler ve onu yeniden satabilecek kanal, o stoğu asla geri almaz.

Tek taksonomi, tek sistem kaydı

Bunu düzeltmek için Trendyol'u ya da Amazon'u kendi iade formunuzu kullanmaya zorlamanız gerekmiyor. Kanala özgü yüzeyin altında iki şeyin sağlanması yeterli. Birincisi, tek bir iade nedeni taksonomisi: siparişin nereden geldiğine bakılmaksızın uygulanan aynı sonlu kategori seti (yanlış beden, taşımada hasar, açıklamaya uymama, fikir değişikliği ve benzerleri) sayesinde bir iade analisti, dört farklı ve birbiriyle uyuşmayan tabloyu okumak yerine kanallar arasındaki neden dağılımını doğrudan karşılaştırabilir. İkincisi, RMA durumu için tek bir sistem kaydı: bir siparişin pazaryerinden mi geldiğini, o pazaryerinin iadeyi zaten ödeyip ödemediğini ve ürünün fiziksel olarak geri dönüp dönmediğini bilen tek bir merkez.

• Her kanalın kendi kategori adlarını tek bir ortak sete eşleyen paylaşımlı bir neden taksonomisi; böylece Ticimax ve her pazaryerinden gelen iade kodları, dört ayrı uyumsuz liste yerine aynı kovaya düşer.
• Siparişi hangi platform sattıysa satsın, orijinal siparişe bağlanan tek bir RMA defteri; böylece bir pazaryerinin çoktan ödediği bir iade, kendi sisteminizde bir başkası ikinci kez işlem yapmaya kalkışmadan önce görünür hale gelir.
• Hem iadeyi hem de doğru kanal stok havuzunu işaretleyen envanter olayları; böylece pazaryeri siparişinden dönen bir ürün, genel bir depo kutusu yerine o kanalın satılabilir envanterine girer.
• Kaynağı ne olursa olsun aynı analitik ve fit-graph döngüsünü besleyen iade nedeni verisi; böylece bir pazaryerinde görülen beden sorunu, kendi mağazanızda alıcılara söylediklerinizde de kendini gösterir.

Politika değil, kanala duyarlı yönlendirme

Sistem kaydını birleştirmek her kanalı tek bir politikaya indirgemek anlamına gelmiyor. Bir pazaryeri siparişi yine de o pazaryerinin kendi iade süresine ve kargo ücreti kuralına uymak zorunda, çünkü orada satış yapmak için imzaladığınız sözleşme bu. Değişen şey, bu mantığın nerede yaşadığı. Üç ayrı ekibin kendi tablosunu ve kendi takdirini kullanmasının yerine, yönlendirme kuralları siparişin geldiği kanalı okur, o kanalın politikasını otomatik olarak uygular ve fiziksel ürünle iade kararını tek bir iş akışından geçirir — böylece altta yatan politika farklı olsa bile müşteri deneyimi tutarlı kalır.

Kanal başına bir iade politikası sorun değil. Kanal başına ayrı bir iade süreci ise kendi envanterinizin izini kaybetmenizin en garanti yoludur.

ResReturn'ün iade API entegrasyonu üzerine yazdıklarımızda da aynı sorun sürekli karşımıza çıkıyor: bir iadenin fiziksel hareketiyle bir geri ödemenin finansal hareketi, ara sıra birbirine denk gelen iki ayrı sistem yerine tek bir olay olarak izlenmeli. Pratikte bu, müşterinin nereden satın aldığına bakılmaksızın kullandığı tek bir self-servis portal, bir pazaryeri iadesiyle bir mağaza kredisinin aynı sipariş üzerinde ikisinin birden tetiklenmesini imkansız kılan tek bir defterden verilen anlık kredi ve bir pazaryeri iadesini bir kimsenin elle yeniden girmesine gerek kalmadan doğrudan satıştan farklı bir fiziksel rotaya yönlendirecek kadar kanal mantığını anlayan yönlendirme kuralları anlamına geliyor.

Kanal arketiplerinde iade yönetimini karşılaştırmak

Aşağıdaki tablo örnekleyici bir çerçevedir, herhangi bir pazaryerinin yayımlanmış şartlarının birebir alıntısı değildir — her platform politikasını düzenli olarak güncelliyor ve bölgesel varyasyonlar uyguluyor. Ama farkların şekli gerçek ve birleşik bir sistemin müşteriye hissettirmeden absorbe etmesi gereken tam olarak bu.

Sütunları yan yana okuduğunuzda, bir operatörü en çok endişelendirmesi gereken sütun mutabakat sütunu, çünkü çeyreklik bir stok sayımı açık verene kadar günlük panolarda pek görünmez. Pazaryerinden dönen bir ürün, o pazaryerinin kendi envanter havuzuna geri girmezse, satın almak için ödediğiniz stoğu iki kez kaybetmiş olursunuz — bir kere depodan çıktığında, bir kere de aslında satabilecek kanala hiç geri kredilenmediğinde. Bu bir politika sorunu değil, tam anlamıyla bir yönlendirme sorunu; bu yüzden iade önleme ve chargeback yazımızda da anlattığımız gibi, fiziksel ürünle stok defterinin ay sonunda elle mutabakat yapılmak yerine olay olay birlikte hareket etmesi gerekiyor.

Bu karmaşayı çözmeye nereden başlamalı

1. 1Sattığınız her kanalı denetleyin ve gerçek iade süresini, kargoyu kimin ödediğini ve ne kadar hızlı sonuçlandığını yazın — çoğu satıcı kendi zihnindeki tablonun ne kadar güncel olmadığını görünce şaşırıyor.
2. 2Tek bir iade nedeni taksonomisi kurun ve her kanalın kendi neden kodlarını buna eşleyin; böylece bir Ticimax siparişindeki yanlış beden iadesiyle bir pazaryerindeki yanlış beden iadesi verinizde aynı şekilde sayılsın.
3. 3RMA durumunu, bir pazaryerinin siparişi zaten ödeyip ödemediğini işaretleyen tek bir sistem kaydında merkezileştirin; böylece kendi ekibiniz aynı sipariş için ikinci bir iade başlatmasın.
4. 4İade edilen her ürünü geldiği kanalla etiketleyin, böylece genel bir depo kutusu yerine doğru satılabilir stok havuzuna geri girsin.
5. 5Birleşik neden verisini beden/uyum modelinize besleyin, böylece bir kanalda görülen bir örüntü her yerdeki önerileri iyileştirsin; satın alma sonrası deneyimle ilgili daha geniş araştırmalar da — örneğin Baymard Institute'ün çalışmaları — aynı yöne işaret ediyor: iade deneyimi, müşterinin tekrar alışveriş yapıp yapmayacağını belirliyor.