Backorder yönetimi: stokta yokken gelen siparişi kaybetmemek

Cuma günü saat 16.40. Satış temsilcisi telefonu kapattığında söz verilmişti bile: 40 adet, pazartesi kargoda. Depo sorumlusu ekranı açıp baktığında eldeki miktar 46 görünüyordu ama bunun 34 adedi hafta içinde onaylanmış başka siparişler için rezerve edilmişti. Gerçekten satılabilir olan 12 adetti. Geriye kalan 28 adet için ne tedarikçiye verilmiş bir sipariş vardı ne de savunulabilir bir tarih. Bu 28 adet o akşam kimsenin ekranında görünmedi; iki hafta sonra müşteri arayıp iptal ettiğinde de sözün nereden çıktığını kimse geriye doğru izleyemedi.

Backorder yönetimi tam olarak bu boşluğa dair bir disiplin. Aşağıda önce karşılanamayan talebin kayda geçmesiyle geçmemesi arasındaki farkı, sonra bir siparişin hangi anda backorder'a düştüğünü ele alıyoruz. Ardından hangi talebi kabul edip hangisini reddetmek gerektiğine dair bir karar tablosu, müşteriye tarih verirken uyulması gereken kurallar, kaydın taşıması gereken alanlar, mal geldiğinde tahsis sırası, pazaryeri tarafının özel durumu, nakit akışına etkisi, izlenecek göstergeler ve backorder sayısını kalıcı olarak düşürmenin yolları geliyor. En sonda sıkça sorulan sorular var.

Stokta yokken alınan sipariş aslında neyi değiştirir?

"Şu an stoğumuz yok" cümlesi bir satış konuşmasını bitirir. Backorder ise aynı durumu açık bir taahhüde çevirir: talep reddedilmez, kayda geçer ve mal geldiğinde otomatik olarak karşılanır. Aradaki fark müşteri deneyiminden önce veri tarafında hissedilir. Reddedilen talep hiçbir yere yazılmaz; iki ay sonra "bu üründen neden bu kadar az satıyoruz" diye sorulduğunda elde yalnızca satış rakamları kalır, kaybedilen talebin izi kalmaz.

Kayıt altına alınan talep ise bir sinyal üretir. Aynı SKU için üst üste düşen backorder satırları, o ürünün sipariş noktasının düşük kurulduğunu ya da tedarik süresinin varsayılandan uzun olduğunu söyler. Bu yüzden backorder yalnızca bir müşteri ilişkisi nezaketi değil, satın alma için de veri kaynağıdır.

Talebin nereden geldiği de önemlidir: mağaza sepetinden düşen bir siparişle telefonda alınan bir sipariş aynı ürünü isteyebilir ama iptal riskleri farklıdır. Kanalların tek yerde birleşmesi bu ayrımı yapabilmenin ön koşulu; sipariş verisini müşteri kaydıyla birleştirmek backorder taahhüdünü kime, hangi geçmişe bakarak verdiğinizi değiştirir.

Sipariş hangi anda backorder'a düşer?

Hataların çoğu tek bir kavram karışıklığından çıkar: eldeki stok ile kullanılabilir stok aynı sayı değildir. Elde 46 adet olabilir ama bunun bir kısmı onaylanmış siparişler için ayrılmıştır. Rocketly'de bu ayrım Stok Hareketleri tarafında tutulur: giriş, çıkış, transfer ve rezervasyon ayrı hareket tipleridir ve hiçbiri sonradan silinmez, düzeltme gerektiğinde yeni bir hareket eklenir. Stok Sağlığı Panosu ise kullanılabilir stok ile rezerve miktarı yan yana gösterir; böylece "sistemde var görünüyordu" tartışması kapanır.

Backorder eşiği bu kullanılabilir miktara göre belirlenir. Talep kullanılabilir miktarı aştığında iki seçenek doğar: siparişi bütünüyle backorder'a almak ya da kısmi karşılamak. Kısmi karşılama, elde olan 12 adedi hemen sevk edip 28 adet için açık satır bırakmak demektir. Kargo maliyetini bölerek artırır ama müşteri ürünü set halinde kullanmıyorsa çoğu zaman daha iyi bir takastır.

Karşılanamayan talebin sessizce kaybolması en pahalı senaryodur. Web tarafında bunun karşılığı, beden ya da varyant stokta görünmediği için tamamlanmayan sepetlerdir; yarım kalan siparişleri geri kazanma mantığı ile backorder mantığı aynı sorunun iki ucudur: biri talebi geri çağırır, diğeri talebin gitmesini engeller.

Hangi siparişi backorder'a almalı, hangisini almamalı?

Her karşılanamayan talep açık bir taahhüdü hak etmez. Tedarik süresi belirsizse, ürün mevsimlikse ya da müşteri alternatif bir markaya bir öğleden sonra içinde geçebiliyorsa verilen söz ilişkiyi korumaz, aksine bozar. Kararı kişisel sezgiye bırakmak yerine gözlenebilir birkaç ölçüte bağlamak işi kolaylaştırır.

Ölçüt	Backorder açmak makul	Backorder riskli
Tedarik süresi	Tedarikçiden savunulabilir, onaylı bir teslim tarihi var	İthalat, gümrük ya da üretim kuyruğu belirsiz
Ürünün yerine geçebilirliği	Özel ölçülü, markaya bağlı ya da projeye özgü ürün	Piyasada beş benzeri bulunan standart ürün
Müşteri geçmişi	Düzenli alan, satın alma geçmişi olan hesap	İlk kez alışveriş yapan, iletişim bilgisi doğrulanmamış
Tahsilat biçimi	Kapora alınmış ya da sözleşme var	Peşin tahsil edilmiş, iptal doğrudan nakde vuruyor
İhtiyaç tarihi	Müşteri tarih söylüyor ve tarih tahmininizin sonrasında	Ürün, verebileceğiniz tarihten önce gerekiyor

Tabloyu bir kural kitabı olarak değil, eşik listesi olarak okuyun. Sağ sütundaki durumlardan ikisi aynı anda geçerliyse, net bir ret ve alternatif ürün önerisi çoğu zaman daha dürüsttür; müşteri de iki hafta bekleyip hayal kırıklığına uğramaktansa bugün başka bir çözüme yönelmeyi tercih eder.

Müşteriye tarih verirken neyi söz veriyorsunuz?

Backorder'ın en kırılgan yanı tarihtir. Müşteriye verdiğiniz tarih, tedarikçinin size söylediği tarih değildir; ikisinin arasında mal kabul, kalite kontrolü, depoya yerleştirme ve sevk hazırlığı vardır. Bu adımlar bir ya da iki gün tutar; müşteriye söylenen tarih bu günleri içermezse her siparişte bir gün geciken taraf siz olursunuz.

İkinci kural: tek gün değil aralık verin. "18 Mart" yerine "17-20 Mart arası sevk" demek hem gerçeğe daha yakındır hem de tedarik zincirindeki küçük kaymaları bir krize dönüştürmez. Üçüncü kural: tarih değiştiğinde müşteriyi sizin aramanız gerekir. Müşterinin sorup öğrendiği her gecikme, sizin haber verdiğiniz aynı gecikmeden daha büyük görünür.

Bu haber verme işi tek kanaldan yürümez. Kimi müşteri e-postayı açmaz, kimi telefonu kaldırmaz. müşterinin gerçekten kullandığı kanalda konuşmak backorder bildiriminde başka her yerden daha çok önem taşır, çünkü kaçırılan tek bir bilgilendirme iptalin en yaygın sebebidir.

Mesajlaşma tarafında da aynı ilke geçerli: bilgilendirme, ancak sipariş kaydının yanında görünüyorsa iş görür. mesajlaşma üzerinden yürüyen satış akışını sipariş kaydına bağlamadığınızda, müşteriye ne söylendiği tek bir kişinin telefonunda kalır ve o kişi izinliyken kimse cevap veremez.

Bir backorder kaydı hangi bilgileri taşımalı?

Backorder'ı bir not alanı yerine yapısal bir kayıt olarak tutmak gerekir. Asgari alanlar şunlardır:

• Ürün ve varyant, karşılanamayan miktar, sipariş tarihi
• Müşteriye söylenen sevk aralığı ve bu tarihin dayandığı varsayım
• Bağlı satın alma siparişi ya da beklenen mal kabul kaydı
• Öncelik: müşterinin önemi, ihtiyaç tarihi, kapora durumu
• Kapanma koşulu: hangi tarihten sonra satır kendiliğinden kapanacak
• Müşteriye yapılan son bildirim ve bildirimi yapan kişi

Rocketly'nin Backorder Yönetimi özelliği tam olarak bu kaydı tutar: karşılanamayan talep silinmez, açık satır olarak durur ve mal girişi yapıldığında ilgili satır otomatik kapanır. Böylece "mal geldi mi, geldiyse kime gidecekti" sorusu bir kişinin hafızasına değil kayda sorulur. Tedarikçi tarafında tarih değiştiğinde ise Sipariş Revizyonu devreye girer: gönderilmiş bir satın alma siparişi revize edilebilir ve her revizyon değişiklik dökümüyle saklanır, yani müşteriye verdiğiniz ikinci tarihin nereden geldiği sonradan izlenebilir.

Kaydın ekip içinde görünür olması da en az alanlar kadar önemli. Müşteri "siparişim ne oldu" diye yazdığında cevabı kimin vereceği belli değilse kayıt iş görmez; gelen mesajların tek ekip ekranında toplanması backorder sorularının sahipsiz kalmasını engeller.

Mal geldiğinde tahsis sırasını kim belirler?

Bekleyen üç sipariş var ve gelen mal ikisine yetiyor. Bu anı önceden kurala bağlamazsanız tahsisi, o gün ekranı ilk açan kişi yapar. En savunulabilir varsayılan kural sipariş tarihine göre sıradır: önce gelen önce alır. Adildir, kendini açıklar ve tartışmayı bitirir.

Varsayılandan sapmak için yazılı bir gerekçe olmalı. Meşru sapmalar vardır: ihtiyaç tarihi bu hafta olan müşteriyi, tarihi bir ay sonraki müşterinin önüne almak; kapora alınmış siparişi öne almak; ya da kısmi sevkle bir müşterinin üretim hattının durmasını engellemek. Sapmanın kaydı tutulmazsa aynı davranış birkaç hafta içinde keyfi bir önceliklendirmeye dönüşür.

Son kullanma tarihi olan ürünlerde tahsis, kime sorusu kadar hangi partiden sorusudur da. Lot / Seri Takibi özelliği partiye ve seri numarasına göre izlenebilirlik sağlar ve son kullanma tarihine göre FEFO çıkış yapar; böylece bekleyen müşteriye giden mal, rafta en uzun kalmış parti olur.

Gecikme uzadıkça şikayet yalnızca satış temsilcisine gelmez, herkese açık kanallara da düşer. açık kanallardan gelen soruları işleyen bir akış kurmadan büyük bir backorder kuyruğunu yönetmek, aynı gecikmeyi iki ayrı yerde iki ayrı cümleyle anlatmak anlamına gelir.

Pazaryerinde satarken backorder nasıl yönetilir?

Kendi sitenizde açık bir taahhüt verebilirsiniz; pazaryerinde çoğu zaman veremezsiniz. Platformların hazırlama süresi kuralları, geciken siparişte satıcı puanına yansıyan düşüşler ve otomatik iptal mekanizmaları backorder'ı pratikte çalışmaz hale getirir. Bu yüzden çok kanallı satışta doğru strateji backorder'ı pazaryerine taşımak değil, oraya yazılan miktarı gerçek kullanılabilir stoğa sabitlemektir.

Bunun için kanallara giden sayının tek bir kaynaktan üretilmesi gerekir. Rocketly'de 16 Pazaryeri ve Mağaza Konnektörü bağlantıyı kurar ve siparişler taslak fatura olarak düşer; stok veya ürün yazımı ise ancak eşlemeler tamam ve yetki açıkça verilmiş olduğunda çalışır. Bu kısıt başta can sıkıcı görünür, sonra neyi önlediği anlaşılır: yanlış eşlenmiş bir SKU yüzünden elinizde olmayan stoğu satışa açmazsınız.

Kanal sayısı arttıkça bu tek kaynak meselesi daha da belirginleşir; çok kanallı siparişi tek yerde toplamanın en somut faydası da budur: aynı SKU için üç ayrı satıcı panelinde üç ayrı sayı taşımak zorunda kalmazsınız.

Backorder nakit akışında nereye oturur?

Peşin tahsil edilmiş bir backorder kasadaki para gibi görünür ama değildir. O tutar henüz teslim edilmemiş bir yükümlülüktür ve müşteri vazgeçtiği anda geri ödenir. Bekleyen backorder toplamınızı tahsil edilmiş gelir gibi planlarsanız, bir iptal dalgasında aynı parayı iki kez harcamış olursunuz.

Backorder satın alma tarafında da bir nakit çıkışı tetikler: malı getirmek için tedarikçiye ödeme yaparsınız, müşteriden tahsilat ise sevkiyattan sonra tamamlanır. Aradaki gün sayısı doğrudan nakit akışı planlamanızın içine girer ve backorder kuyruğu büyüdükçe bu boşluk da büyür.

Tersi de bir o kadar gerçek: fazla stok tutarak backorder'ı sıfırlamaya çalışmak. Bu, sorunu nakitle çözmektir ve genellikle pahalıdır. Rafta bekleyen mal, kullanamadığınız sermayedir; işletme sermayesini yöneten her karar bu iki uç arasında bir denge arar. Rocketly'deki ABC Analizi bu dengeyi kurmayı kolaylaştırır: stoğu değere göre sınıflara ayırıp sermayenin nerede kilitli olduğunu görünce, güvenlik stoğunu bütün ürünlerde değil yalnızca hak edenlerde yükseltirsiniz.

Backorder'ı ölçmenin doğru göstergeleri hangileri?

Açık backorder sayısını tek başına izlemek yanıltır; bir kampanya döneminde artması zaten beklenir. Anlamlı bilgi şu dört göstergede saklıdır:

• İlk seferde karşılama oranı: gelen siparişlerin yüzde kaçı hiç beklemeden sevk edildi
• Backorder yaşı: açık satırların ortalama ve en uzun bekleme süresi
• Söz tutma oranı: müşteriye verilen ilk aralıkta sevk edilen siparişlerin oranı
• Bekleme kaynaklı iptal oranı: beklerken vazgeçilen siparişler

Kırılım da toplam kadar önemli. Aynı SKU listenin başında tekrar tekrar çıkıyorsa sorun tedarikte değil planlamadadır; farklı ürünler dönüşümlü çıkıyorsa sorun büyük ihtimalle tedarikçi tarafındadır. Rocketly'deki Tedarikçi Performansı ekranı sipariş ve teslim sayısını, toplam harcamayı ve ortalama teslim süresini yan yana koyar; hangi tedarikçinin verdiği tarihi tuttuğunu tahmin etmek yerine ölçersiniz.

Bu sayıların belirli bir günde kendiliğinden önünüze gelmesi, panoyu açmayı hatırlamaktan daha güvenilirdir; özetin belirlenen günde kendiliğinden gelmesi backorder kuyruğunun bir çeyrek boyunca sessizce büyümesini engelleyen basit bir alışkanlıktır.

Backorder sayısını kalıcı olarak nasıl düşürürsünüz?

İyi kurulmuş bir backorder süreci bile sonuçta bir semptom yönetimidir. Asıl iş, aynı ürünün tekrar tekrar tükenmesini engellemektir. Bunun üç ayağı var: doğru sipariş noktası, gerçekçi tedarik süresi varsayımı ve erken uyarı.

Sipariş noktası, tedarik süresi boyunca beklenen tüketimin üzerine güvenlik stoğu eklenerek kurulur. Örnek olarak: günde ortalama dört adet satan ve tedarik süresi on gün olan bir üründe mal gelene kadar 40 adet tükenir; talep dalgalanması için eklenen tampon eşiği bunun üstüne çıkarır. Rakamlar her işletmede farklıdır, değişmeyen şey eşiğin sezgiyle değil geçmiş tüketimle kurulmasıdır.

Erken uyarı tarafında Rocketly'nin Risk Altındaki Stoklar kuyruğu işi somutlaştırır: talep hızı, kullanılabilir miktar, tedarik süresi ve güvenlik stoğu varsayımlarıyla öncelikli bir liste üretir; hangi ürünün kaç gün sonra tükeneceği ve hangisinin zaten sipariş noktasının altında olduğu görünür. Satırdan doğrudan taslak satın alma siparişi açabilirsiniz, yani uyarıyı eyleme çevirmek için başka bir ekrana geçmeniz gerekmez. Stok Uyarıları ise kritik stok, tükenme ve fazla stok durumunu on beş dakikada bir tarayıp uygulama içi ve e-posta bildirimi gönderir.

Set halinde satış yapıyorsanız eşiği bileşen düzeyinde hesaplamak gerekir; Kit / Set Ürün özelliği bileşen stoklarına göre anlık üretilebilir adedi hesaplar, böylece "set var görünüyordu ama bir bileşeni bitmiş" durumu satıştan sonra değil önce yakalanır. Bu akışları kendi ürün listenizde denemek isterseniz ücretsiz bir Rocketly hesabı açıp stok ve backorder ekranlarını kendi verinizle gezebilirsiniz.

Sıkça sorulan sorular

Backorder ile ön sipariş aynı şey mi?

Değil. Ön sipariş, henüz piyasaya çıkmamış ya da ilk partisi yolda olan bir ürün için bilerek açılan bir satış kanalıdır; müşteri baştan rafta bir şey olmadığını bilir. Backorder ise satışta olan bir ürünün tükenmesiyle oluşur, yani beklenmedik bir durumdur. Kayıt yapısı benzer olabilir ama müşteri beklentisi ve iletişimin tonu farklıdır.

Backorder'da peşin tahsilat almalı mıyım?

Ürüne bağlı. Özel üretim ya da elden çıkarması zor kalemlerde kapora, iptal riskini paylaşmanın makul bir yoludur. Standart ürünlerde tam peşin tahsilat, en küçük gecikmede bir iade yükü yaratır ve nakit planlamasını bozar. Genel yaklaşım, tahsilat oranıyla iptal maliyetini aynı tabloda değerlendirmektir.

Açık bir backorder satırı ne zaman kapatılmalı?

Kapanma koşulunu satırı açarken yazmak en temizidir: belirlenen tarihten sonra müşteri teyit etmezse satır kendiliğinden kapanır. Süresiz açık bırakılan satırlar aylar sonra hem raporu bozar hem de gelen malı çoktan başka bir çözüme geçmiş bir müşteriye tahsis eder.

Kısmi sevk mi yapmalı, tam sevki mi beklemeli?

Müşteri ürünleri set olarak kullanmıyorsa kısmi sevk genellikle daha iyidir: açık miktar azalır, ilişki korunur. Montaj ya da proje teslimi söz konusuysa parçalı gönderim müşteriye ek iş çıkarır; orada tam sevki bekleyip tek ve net bir tarih vermek daha doğrudur.