Sipariş yönetimi (order management) nedir, nasıl kurulur?

Perşembe öğleden sonra, depoda iki kişi aynı ürünün peşinde. Biri WhatsApp'tan gelen bir siparişi hazırlıyor, diğeri pazaryerinden düşen bir siparişi topluyor. Raftaki adet ikisine birden yetmiyor; aynı saatlerde müşteri temsilcisi telefonda üçüncü bir alıcıya "stokta var, yarın çıkar" diyor. Kimse kural çiğnemedi, kimse tembellik etmedi. Eksik olan tek şey, o üç sözü aynı anda görebilecek tek bir sipariş kaydıydı.

Sipariş yönetimi tam olarak bu boşluğu kapatan disiplindir: siparişin doğduğu andan teslim edilip kapandığı ana kadar tek bir kayıt üzerinden yürütülmesi. Aşağıda sipariş kaydının neden teklif ve faturadan ayrı durduğunu, yaşam döngüsünün duraklarını, kısmi sevkiyat ile bekleyen bakiyenin nasıl yönetildiğini, çok kanaldan gelen siparişlerin tek havuzda nasıl birleştiğini ve tüm bunları hangi sırayla kuracağınızı anlatıyorum.

1Sipariş alındı2Onay ve kontrol3Stok rezervasyonu4Hazırlık5Sevkiyat6Teslim ve kapanış

Sipariş yönetimi nedir ve neden ayrı bir kayıttır?

Sipariş yönetimi, bir alıcının "tamam, alıyorum" dediği andan itibaren o taahhüdün takip edildiği, stokla eşleştirildiği, hazırlandığı, sevk edildiği ve kapatıldığı süreçtir. Kayıt olarak bir siparişin içinde şunlar bulunur: kim aldı, hangi kanaldan geldi, hangi ürünler ve adetler, hangi fiyat koşuluyla, nereye teslim edilecek, ne zaman sözü verildi, şu anda hangi aşamada ve hangi kısmı çıktı.

Birçok ekip bu kaydı ayrı tutmaz; teklifi sipariş yerine, faturayı da sipariş yerine kullanır. İkisi de sorun çıkarır. Teklif bir öneridir: değişebilir, reddedilebilir, süresi dolabilir. Fatura ise bir muhasebe belgesidir: kesildikten sonra kolay kolay değişmez ve çoğu zaman iş fiilen bittikten sonra oluşur. Oysa sipariş, ikisinin arasındaki canlı bölgede yaşar. Teklif kabul edildikten sonra hâlâ kısmi sevk edilebilir, bir kalemi iptal edilebilir, teslim tarihi kayabilir. Bu hareketliliği ne teklif ne fatura taşıyabilir.

Pratik ayrım şu: teklif "ne teklif ettik" sorusunun, fatura "ne faturaladık" sorusunun cevabıdır. Sipariş ise "şu an müşteriye ne borçluyuz" sorusunun cevabıdır. Bu üç soru aynı anda farklı cevaplar verebilir ve bu normaldir. Teklifin tahsilata kadar uzanan bütün yolculuğunu tekliften tahsilata (quote-to-cash) süreci yazısında uçtan uca ele alıyoruz; burada odak, o zincirin ortasındaki sipariş halkası.

Sipariş yaşam döngüsü: alındıdan kapanışa

Sağlıklı bir sipariş süreci, herkesin aynı isimlerle andığı net duraklardan oluşur. Durak sayısını abartmayın; yedi durak çoğu işletme için fazlasıyla yeterlidir. Önemli olan durak sayısı değil, her durağın çıkış şartının yazılı olmasıdır: bir sipariş hangi koşul sağlanınca bir sonraki aşamaya geçer? Bu şart yazılı değilse, aşama adları herkesin kafasında farklı anlama gelir ve rapor da o oranda yanıltıcı olur.

Alındı ve onay

"Alındı" durumu, talebin sisteme girdiği ama henüz doğrulanmadığı andır. Onay adımı ise üç şeyi kontrol eder: ürün ve adet doğru mu, fiyat ve ödeme koşulu geçerli mi, teslim adresi ve tarih uygulanabilir mi. B2B'de buna bir de cari risk kontrolü eklenir — açık bakiyesi limiti aşan bir müşteriye yeni sipariş açmak, sonra tahsilat masasının işini zorlaştırır. Onay adımını atlayan ekipler, hatayı depoda ya da kargoda keşfeder; orada düzeltmek çok daha pahalıdır.

Rezervasyon, hazırlık, sevkiyat, teslim

Onaydan sonra sipariş stok tarafında bir yer kaplamaya başlar: kalemler rezerve edilir. Ardından toplama ve paketleme gelir, sonra sevkiyat, sonra teslim ve nihayet kapanış. Kapanış küçük görünür ama önemlidir: bir sipariş "teslim edildi" ile "kapandı" arasında hâlâ iade penceresinde, hâlâ eksik bakiyeli, hâlâ faturasız olabilir. Kapanışı ayrı bir durak olarak tanımlayan ekipler, ay sonunda "bu iş bitti mi bitmedi mi" tartışması yaşamaz.

Stokla senkron çalışmak: rezervasyon mantığı

Sipariş yönetiminin kalbi, "elde var" ile "satılabilir" arasındaki farkı görmektir. Rafta on adet olabilir ama altısı başka siparişlere sözlenmişse satılabilir adet dörttür. Rezervasyon tam da bunu yapar: onaylanan sipariş, kalemlerini fiziksel stoktan koparmadan bloke eder.

Bu ayrımı kurmayan işletmelerde klasik zincir işler: aynı ürün iki kez satılır, biri gecikir, gecikme telefonla açıklanır, müşteri güvenini kaybeder. Stok tarafının kendi disiplinini stok takibi ve envanter yönetimi yazısında ayrıntılı kuruyoruz; sipariş açısından kritik olan üç kural şudur: rezervasyon onayda başlar, sevkiyatta fiziksel düşüm olur, iptalde rezervasyon aynı gün serbest bırakılır.

Serbest bırakma kısmı sık atlanır. İptal edilen ama rezervasyonu düşmeyen siparişler, kâğıt üstünde stoksuz görünen ama depoda duran mallar yaratır. Kritik ürünlerde eşik değerlerini de bağlayın; nasıl kurulacağını stok ve eşik uyarı otomasyonu yazısında adım adım gösteriyoruz.

Kısmi sevkiyat ve bekleyen bakiye (backorder)

Gerçek hayatta siparişler nadiren tek parça çıkar. Beş kalemin üçü hazırdır, ikisi tedarikte. Burada iki kötü seçenek vardır: her şey gelene kadar beklemek ya da eksik gönderip kaydı "tamamlandı" yapmak. İkisi de müşteriyi ve muhasebeyi yanıltır.

Doğru yapı, siparişi kalem bazında takip etmektir. Her kalemin kendi "sipariş edilen", "sevk edilen" ve "bekleyen" adedi olur. Sipariş ancak bekleyen bakiye sıfırlandığında ya da kalan kısım bilinçli olarak iptal edildiğinde kapanır. Kısmi sevkiyat, kendi irsaliyesini ve gerekiyorsa kendi faturasını üretir; sipariş kaydı ise bunların hepsini bir arada tutan üst çatı olarak kalır.

Bekleyen bakiye ayrıca bir karar noktasıdır. Kalan kalem kısa sürede gelecekse beklemek makuldür; tedarik süresi belirsizse müşteriye seçenek sunmak, sessizce beklemekten her zaman iyidir. Bu yüzden bekleyen bakiyeli siparişleri ayrı bir liste olarak tutun ve haftada bir gözden geçirin. Bu liste aynı zamanda satın alma ekibi için en dürüst talep sinyalidir: müşteri parasını vermeye hazır olduğu hâlde raf boş demektir.

Bir siparişin durumu tek kelimeyle anlatılabiliyorsa, o sipariş muhtemelen henüz gerçek hayatla karşılaşmamıştır.

Ödeme durumu ile sipariş durumu ayrı eksenlerdir

En yaygın tasarım hatası, ödeme ve teslimat durumunu tek bir alanda birleştirmektir. "Ödendi" bir teslim aşaması değildir; "sevk edildi" de bir tahsilat bilgisi değildir. Bu ikisini tek listede toplayınca, peşin çalışan müşteriyle vadeli çalışan müşteriyi aynı ekranda okuyamaz hâle gelirsiniz.

Eksen	Neyi anlatır	Örnek değerler
Sipariş durumu	Malın fiziksel yolculuğu	Alındı, onaylandı, hazırlanıyor, sevk edildi, teslim edildi
Ödeme durumu	Paranın durumu	Beklemede, kısmi tahsil, tahsil edildi, iade edildi
Kapanış	Kaydın yaşam durumu	Açık, kısmi, kapalı, iptal

Üç ekseni ayırdığınızda "teslim edildi ama tahsil edilmedi" gibi en riskli grubu tek filtreyle görürsünüz. Vadeli çalışan B2B ekipleri için bu filtre, nakit akışının erken uyarı sistemidir.

İptal ve iadeyi siparişe bağlayın

İptal, henüz sevk edilmemiş bir taahhüdün geri alınmasıdır; iade ise sevk edilmiş malın geri gelmesidir. İkisi farklı akışlardır ama ortak noktaları vardır: her ikisi de orijinal sipariş kaydına bağlanmalıdır. Serbest yüzen bir iade kaydı, hangi siparişten çıktığı bilinmediği için ne stoku doğru düzeltir ne de kârlılığı doğru gösterir.

İadeyi bir süreç olarak kurmak, aynı zamanda müşteriyi elde tutma fırsatıdır; ürün iadesi ve RMA süreci yazısında bu akışın nasıl kurulacağını anlatıyoruz. Sipariş tarafında yapmanız gereken tek şey, iade kaydının siparişe ve kalemine referans vermesi ve iade onaylandığında stok ile cari hesabın birlikte güncellenmesidir.

Çok kanaldan gelen siparişleri tek havuzda birleştirmek

Sipariş bugün tek kapıdan girmiyor. Pazaryeri panelinden, kendi web sitenizden, WhatsApp'tan, telefondan, sahadaki satış temsilcisinin tabletinden geliyor. Her kanalın kendi ekranında kalması, o üç kişinin depoda çarpışmasının asıl sebebidir.

Birleştirmenin mantığı basit: kanal bir alan olmalı, ayrı bir sistem değil. Sipariş nereden gelirse gelsin aynı kayda dönüşür, aynı durum listesini kullanır, aynı stok havuzundan rezerve eder; sadece "kaynak" alanı farklıdır. Pazaryeri tarafının teknik kurulumunu pazaryeri entegrasyonu yazısında, kendi mağazanızın bağlanmasını ise e-ticaret ve CRM entegrasyonu yazısında ele alıyoruz.

Birleştirmede iki teknik detay hayat kurtarır. Birincisi, her kanaldan gelen siparişin kanal tarafındaki numarasını da kaydınızda saklayın; bir uyuşmazlıkta iki sistemi eşleştirmenin tek yolu budur. İkincisi, aynı siparişin iki kez düşmesini engelleyecek bir tekillik kuralı tanımlayın — kanal adı ile kanal sipariş numarasının birleşimi genelde yeterlidir.

Bayi ve toptancı siparişleri ayrı bir dünyadır: fiyat listesi müşteriye göre değişir, adetler katlıdır, sipariş sıklığı yüksektir. Bu trafiği e-postadan kurtarmak isteyenler için B2B bayi sipariş portalı kurmak yazısı işin kendi kendine servis edilen tarafını anlatıyor.

Sipariş hatalarının kök nedenleri

Yanlış giden siparişleri tek tek incelediğinizde, sebepler şaşırtıcı derecede tekrar eder:

• Çift kayıt: Aynı sipariş hem kanal panelinde hem elle girildiği için iki kez hazırlanır ve stok iki kez düşer.
• Onaysız ilerleme: Adres veya adet doğrulanmadan hazırlığa geçilir, hata ancak kargo geri döndüğünde ortaya çıkar.
• Rezervasyonsuz söz: Satış "stokta var" der ama sistemde hiçbir şey bloke edilmez; ilk çıkan siparişi başkası alır.
• Kapanmayan kayıtlar: Teslim edilen sipariş kapatılmadığı için açık sipariş listesi şişer, gerçek yük görünmez olur.
• Sözlü değişiklik: Müşteri telefonda kalem değiştirir, kayıt güncellenmez; depo eski listeye göre hazırlar.

Beşinin de ortak paydası aynı: değişikliğin yazıldığı tek bir yer yok. Kök nedeni çözmek, ekstra kontrol katmanı eklemekten değil, tek kayıt kuralını uygulamaktan geçer.

Ne ölçmeli: üç temel metrik

Sipariş operasyonu üç sayıyla yönetilir. Birincisi zamanında teslim oranı: söz verilen tarihte teslim edilen siparişlerin payı. İkincisi sipariş doğruluğu: eksiksiz, doğru ürünle ve hasarsız ulaşan siparişlerin payı. Üçüncüsü sipariş-sevkiyat süresi: onaydan kargoya çıkışa geçen ortalama saat.

Bu üç metriğin nasıl hesaplandığını da yazılı hâle getirin. "Zamanında" hangi tarihe göre ölçülüyor: müşteriye söz verilen ilk tarihe mi, sonradan revize edilen tarihe mi? İkisi çok farklı sonuç verir ve revize tarihi kullanan ekipler kendilerini olduğundan başarılı görür. Aynı şekilde kısmi sevkiyatlı bir siparişin hangi anda "teslim edildi" sayılacağını da baştan kararlaştırın.

Bu üçlüyü birlikte okumak şart. Süreyi tek başına kısaltmaya çalışan ekipler doğruluğu düşürür; doğruluğu tek başına kovalayanlar süreyi uzatır. Ölçümü kanal, ürün grubu ve depo kırılımında yapın — ortalama, sorunun nerede olduğunu asla söylemez. Süre metriğinde saat cinsinden çalışın; gün cinsinden ölçüm, aynı gün toparlanabilecek gecikmeleri gizler.

Adım adım kurulum

Sıfırdan kuracaksanız sıralama önemlidir; çoğu ekip hata yapıp otomasyondan başlıyor.

1. Durum listesini yazın: Yedi durağı adlandırın ve her durağa geçiş için gereken şartı bir cümleyle tanımlayın.
2. Kayıt şemasını netleştirin: Sipariş başlığı, kalemler, kanal, teslim tarihi, ödeme durumu ve kapanış alanlarını ayırın.
3. Ürün ve stok verisini düzeltin: Varyantlar, barkodlar ve birimler doğru değilse rezervasyon da doğru olmaz.
4. Kanalları tek havuza bağlayın: Önce en yoğun iki kanalı bağlayın, akış oturduktan sonra kalanları ekleyin.
5. Rezervasyon ve düşüm kurallarını uygulayın: Onayda rezerve, sevkiyatta düşüm, iptalde serbest bırakma.
6. Sevkiyat tarafını otomatikleştirin: Kargo firmasıyla bağlantı kurup takip numarasının kayda kendiliğinden düşmesini sağlayın.
7. Bilgilendirmeyi bağlayın: Durum değişimlerini müşteriye otomatik iletin.
8. Raporu kurun ve haftalık okuyun: Üç metriği panoya alın, açık ve bekleyen bakiyeli siparişleri her hafta gözden geçirin.

Altıncı adımda kurye ve kargo bağlantısının detaylarını kargo ve kurye entegrasyonu yazısında, yedinci adımdaki müşteri bilgilendirme akışının kurgusunu ise sipariş durumu otomatik bilgilendirme yazısında bulacaksınız.

Küçük ekipler için gerçekçi bir başlangıç

Bütün bunları aynı ayda kurmanız gerekmiyor. Tek kayıt kuralı, kalem bazlı takip ve ödeme–teslimat ayrımı; bu üçü tek başına hataların büyük kısmını kaldırır. Geri kalanı, hacminiz büyüdükçe sırayla eklenir.

Rocketly'de sipariş kaydı ürün, stok, cari hesap ve fatura ile aynı yerde durduğu için rezervasyon, kısmi sevkiyat ve tahsilat takibi ayrı sistemlere dağılmaz; durum değişimlerini iş akışı otomasyonuna bağlayıp bildirimleri ve görevleri de aynı akışa alabilirsiniz. Sipariş süreçlerinizi tek kayıt üzerinden yürütmeye başlamak için Rocketly hesabınızı açın ve ilk kanalınızı bağlayarak deneyin.