Harekete Geçiren İade Panoları Nasıl Kurulur

On mağazanın arka ofisini açın, on farklı iade panosu bulursunuz. Dokuzu ölü ağırlıktır: üçüncü haftadan sonra kimsenin açmadığı bir kutucuk ızgarası, bağlamı olmayan bir iade oranı yüzdesi, kimsenin davranışını değiştirmeyen bir sebep dağılımı pastası. Operasyon ekibi pano var olmadan önce verdiği aynı manuel kararları vermeye devam eder ve analitik yatırımı sessizce, yenileme zamanı kimsenin savunamadığı bir bütçe kalemine dönüşür. Sorun nadiren veridir. Çoğu iade panosunun raporlamak için değil, karar tetiklemek için tasarlanmamış olmasıdır.

Bu, ticaretin başka hiçbir yerinde olmadığı kadar iadelerde önemlidir. Giyim ve ayakkabıda iade oranları rutin olarak %20-30 bandında seyreder ve çözülmemiş her iade aynı anda nakit, envanter ve müşteri güvenini işgal eder. Bir gün geç bilgi sunan ya da bir tedarikçi aramasını tetiklemesi gereken tek sayıyı gömen bir pano nötr değildir -- aktif olarak para kaybettirir. Metrik katmanını iade metrikleri rehberimizde, kârlılık merceğini de kâr kaçağı yazımızda ele almıştık. Bu yazı metriklerin üzerindeki katmanla ilgili: panonun kendisini, insanların pazartesi sabahı ne yaptığını değiştirecek şekilde nasıl tasarlarsınız.

Vitrin panoları neden başarısız olur

Bu başarısızlık deseni, mağaza Shopify, Ticimax ya da ikas üzerinde çalışsın fark etmeksizin platformlar arasında tutarlıdır. Biri "iadelere görünürlük" ister, bir BI aracı bağlanır ve ortaya çıkan pano işletmenin vermesi gereken kararları değil, veritabanı şemasını yansıtır. Durum bazında sayılar, gün bazında toplamlar, paydası olmayan sebep kodları elde edersiniz. Yoğun görünür. Hiçbir şeyi harekete geçirmez.

• Çok fazla metrik, hiyerarşi yok -- her şey aynı ekranda aynı boyuttayken hiçbir şey önceliklendirilmemiş olur ve göz nereye bakacağını bilemez.
• Referans veya eşik yok -- geçen ayın rakamı, kategori ortalaması ya da hedef yanında yer almadan %24'lük bir iade oranı hiçbir şey ifade etmez.
• Statik anlık görüntüler -- yalnızca geçmişi gösteren bir pano kimseye sonraki adımı söyleyemez; sadece olanı doğrulayabilir.
• Yanlış kitle, tek görünüm -- bir depo sorumlusu ile bir CFO aynı verinin farklı kesitlerine ihtiyaç duyar, yeniden boyutlandırılmış aynı grafiğe değil.
• Sayının sahibi yok -- bir metriği ilerletmekten tek bir rol sorumlu değilse, o metrik kayar ve kimse fark etmez.

Bir pano rapor değildir. Rapor geçmişi anlatır. Bir pano, bugün birine, zaten yapacağı şeyden farklı ne yapması gerektiğini söylemelidir.

Veri elverişliliği değil, kararlar etrafında tasarlayın

Alışılagelmiş sürecin tersinden başlayın. "Elimizde ne veri var" diye sormak yerine, iade fonksiyonunun fiilen verdiği tekrarlayan kararları listeleyin, ardından her biri için gereken asgari veriye geriye doğru gidin. B2C moda olsun çoklu marka pazar yeri olsun, orta ölçekli çoğu operasyon beş karar türü etrafında kümelenir.

Her satır kendi grafiğini, kendi kitlesini ve kendi yenileme sıklığını ima eder. Beşini birden hizmet etmeye çalışan tek bir "iadelere genel bakış" ekranı hiçbirine tam hizmet edemez. Bu, iade portalı analitiği yazımızda kullandığımız ilkenin aynısı: yalnızca verinin üretildiği anları değil, bir insanın ya da sistemin karar verdiği anları enstrümante edin.

Her çalışan panonun ihtiyaç duyduğu üç katman

Kararlar haritalandıktan sonra arayüzün kendisini tek düz bir ızgara yerine üç katman halinde yapılandırın.

1. Uyarı katmanı

Bu ekranın en üstüdür, ya da daha iyisi, panonun tamamen dışında bir bildirimdir -- Slack, e-posta veya bir operasyon kuyruğu. Yalnızca tanımlı bir eşiği geçmiş metrikleri gösterir: 30 günlük ortalamasının iki standart sapma üzerine çıkmış kusur-iade oranına sahip bir SKU, iade-tutarı eşiğini az önce geçmiş bir müşteri, iade başına maliyeti sıçramış bir kargo hattı. Burada keşifsel hiçbir şey yoktur. Hiçbir eşik geçilmediyse bu katman boştur ve bu doğru davranıştır.

2. Teşhis katmanı

Uyarı katmanı bir şeylerin yanlış gittiğini söylediğinde ve insanlar nedenini anlamak istediğinde açtıkları katman budur. Alt kırılıma izin verir: kategoriden SKU'ya varyanta, kargo şirketinden hatta sevkiyata, müşteri segmentinden bireysel hesaba. Bu katman yoğun olabilir, çünkü onu kullanan kişinin zaten aklında belirli bir soru vardır.

3. Trend katmanı

Geleneksel rapora en çok benzeyen tek katman budur ve kullanım açısından en küçük olmalıdır. Liderlik değerlendirmeleri ve çeyreklik planlama için vardır: on iki aylık iade oranı, kanal bazında zaman içinde iade başına maliyet, çeyrekten çeyreğe kayan sebep-kodu dağılımı. Uyarı katmanıyla yer için yarışmak yerine tek bir tıklamanın arkasında durmalıdır.

1. 1Her tekrarlayan iade kararını ve mevcut sahibini listeleyin.
2. 2Her karar için onu tetiklemesi gereken tek metriği ve eşiği tanımlayın.
3. 3Eşik ihlallerini yalnızca bir pano kutucuğuna değil, sahibin fiilen kontrol ettiği bir uyarı kanalına yönlendirin.
4. 4Yalnızca zaten bir uyarısı olan metrikler için alt kırılım yolları kurun -- kimsenin harekete geçmediği şeyler için teşhis inşa etmeyin.
5. 5Eşikleri üç ayda bir gözden geçirin; lansmanda belirlenen statik bir eşik iki sezon içinde yanlış hale gelir.

Kitleye göre segmentleyin, yalnızca veri kaynağına göre değil

En büyük benimseme katili, her paydaşı aynı görünüme zorlamaktır. Bir depo sorumlusunun kargo hattı bazında iade başına maliyete ihtiyacı yoktur; bugünkü personel sayısına karşı bugünkü gelen hacme ihtiyacı vardır. Bir CFO'nun SKU bazında kusur alt kırılımlarına ihtiyacı yoktur; iade yükümlülüğü trendine ve bunun marja etkisine ihtiyacı vardır. Ayrı panolar tutmak yerine, aynı temel veri modeli üzerine role dayalı görünümler kurun -- kaynak rakamlardaki tutarlılık, düzendeki tutarlılıktan daha önemlidir.

Bu segmentasyon, açılan panoları unutulan panolardan ayıran tam olarak şeydir. Analitik benimseme üzerine araştırmalar, belirli kararlar etrafında kurulan ve doğru role yönlendirilen araçların, herkesin kendi kendine hizmet edeceğini varsayan genel amaçlı raporlama katmanlarına kıyasla çok daha yüksek kullanım sürdürdüğünü tutarlı biçimde bulguluyor; McKinsey analitik pratiği de perakende operasyonlarında aynı deseni daha geniş ölçekte belgeledi -- karara bağlı araçlar kullanılır, genel panolar terk edilir.

ResReturn'ün farklı yaptığı şey

ResReturn'ün pano katmanı, ham olay günlükleri üzerine sonradan eklenmek yerine doğrudan yukarıdaki karar modeli üzerine kurulmuştur. SKU bazında kusur sıçramaları, müşteri iade-istismarı skorlaması ve kargo maliyeti anomalileri için uyarılar otomatik tetiklenir ve bir BI ekibinin sorgu hazırlamasına gerek kalmadan Shopify, Ticimax ve ikas mağazaları genelinde doğru sahibe yönlendirilir. Temel iade olay verisi platformlar arasında birleştirildiği için, aynı müşteri risk skoru ya da SKU kusur trendi, sipariş bir Shopify mağazasından mı yoksa bir Ticimax pazar yeri listesinden mi geldiğine bakılmaksızın görünür olur; bu, hibrit yığın çalıştıran mağazalar için önemlidir. Amaç bir kutucuk ızgarası daha eklemek değil -- daha az ama daha keskin kararlara bağlı, gerçekten o sayıdan sorumlu kişiler tarafından kontrol edilen daha az ekrandır.

Kaçınılması gereken yaygın hatalar

• Her metriğin sahibi konusunda anlaşmadan önce panoyu inşa etmek -- sahiplik boşlukları, uyarıların görmezden gelinmesinin nedenidir.
• Karar sıklığına bakmaksızın her şeyi saatlik yenilemek -- mühendislik çabasını tüketir ve kullanıcıları geçici sıçramaları görmezden gelmeye alıştırır.
• Mutlak sayıları ve oranları hangisinin hangisi olduğunu etiketlemeden aynı grafikte karıştırmak.
• Panonun, muhasebe sistemiyle mutabakat yapılmadan finans için gerçeğin kaydı haline gelmesine izin vermek.
• Hiçbir metriği emekliye ayırmamak -- eski kutucuklar birikir ve hâlâ önemli olanlardan dikkati dağıtır.

İade oranları ve ters lojistik maliyetleri sektör genelinde yeterince mercek altında -- NRF iadeleri perakendenin en büyük kontrol edilebilir maliyet merkezlerinden biri olarak işaretledi -- ki panoyu bir yan proje olarak ele almak artık savunulabilir değil. Çalışan bir iade panosu keyfi bir raporlama katmanı değildir; tüm ters lojistik operasyonunun gün be gün yönetildiği arayüzdür.