B2B Sipariş Takip Portalı Nasıl Planlanır? ERP Durumu, Sevkiyat ve Belge Görünürlüğü

B2B sipariş takip portalı, yalnızca “siparişiniz hazırlanıyor” etiketi gösteren bir ekran değildir. Doğru planlandığında ERP, depo, taşıyıcı ve belge kaynaklarından gelen olayları müşterinin anlayabileceği durumlara dönüştürür; hangi kalemin ne aşamada olduğunu, hangi belgenin oluştuğunu, gecikmenin nedenini ve sıradaki beklenen adımı kanıtıyla birlikte gösterir.

Bu rehber bayi kanalı, toptan satış, satış operasyonu, müşteri hizmetleri ve bilgi teknolojileri yöneticileri için hazırlanmıştır. “Kumsal sipariş görünürlük sözleşmesi” bu makale için geliştirilen özgün kapsam aracıdır. Belirli bir teslim süresi, daha az çağrı, daha yüksek memnuniyet veya ERP uyumu garanti edilmez; gerçek davranış sipariş, stok, üretim, sevkiyat, fatura ve yetki kurallarıyla test edilmelidir.

Sipariş takibi tek bir durum alanından daha fazlasıdır

Kurumsal bir sipariş aynı anda satış, finans, depo ve lojistik süreçlerinden geçebilir. Üstelik sipariş başlığı ile satırlar aynı durumda olmayabilir: bir satır sevk edilmiş, biri üretimde, diğeri kredi kontrolünde bekliyor olabilir. Bu nedenle portal, ERP’deki tek bir kodu müşteriye aynen yansıtmamalıdır.

Microsoft’un sipariş geçmişi modülü; sipariş numarası, onay numarası, tarih, kanal, durum ve toplam gibi alanlarla arama ve filtreleme yapılmasını, ardından satır, sevkiyat ve ödeme ayrıntılarına geçilmesini örnekler. Bu, liste görünümü ile ayrıntı görünümünün ayrı kullanıcı görevleri olduğunu gösterir. Microsoft sipariş geçmişi dokümantasyonu bu ayrımı ürün davranışı üzerinden açıklar.

Kumsal sipariş görünürlük sözleşmesi

Bir durum müşteriye gösterilmeden önce altı soruya cevap vermelidir:

1. Kaynak olay: Durumu hangi sistem, kullanıcı veya fiziksel işlem oluşturdu?
2. Müşteriye açık durum: Teknik kod alıcı için hangi anlaşılır anlama çevrildi?
3. Belge kanıtı: Sipariş onayı, irsaliye, fatura, paket veya taşıma kaydı var mı?
4. İstisna nedeni: Bekleme veya gecikme varsa müşteriye açıklanabilecek neden nedir?
5. Sorumlu taraf: Sıradaki hareket müşteri, satıcı, depo, taşıyıcı veya finans ekibinden hangisini bekliyor?
6. Sonraki beklenen adım: Bir sonraki olay nedir ve tarih kesin, tahmini ya da henüz bilinmiyor mu?

Bu altı alan aynı görünmek zorunda değildir; ancak durum sözlüğünde birlikte tanımlanmalıdır. Böylece “ERP kodu geldi, ekrana bastık” yaklaşımı yerine açıklanabilir ve test edilebilir bir müşteri deneyimi oluşur.

Önce iç durumları, sonra müşteri dilini tanımlayın

ERP veya WMS; siparişi “açık”, “serbest bırakıldı”, “toplama başladı”, “kısmi sevk”, “faturalandı” gibi ayrıntılı kodlarla tutabilir. Müşteri bu ayrıntıların tümünü bilmek istemeyebilir; fakat kararını değiştirecek ayrımı görmelidir. Örneğin “hazırlanıyor” etiketi, stok bekleyen sipariş ile paketlenen siparişi aynılaştırıyorsa yararlı değildir.

Durum sözlüğü için her kaynak kodu şu alanlarla eşleyin: müşteri etiketi, kısa açıklama, satır/başlık seviyesi, başlangıç olayı, bitiş olayı, gösterilebilecek belge, istisna nedeni, tarih türü ve görünürlük yetkisi. Haritayı yalnızca mutlu akışla sınırlamayın; blokaj, iptal talebi, kısmi karşılama ve yeniden planlama durumlarını da ekleyin.

Sipariş başlığı ve satır görünürlüğünü ayırın

Tek teslimatlı basit siparişlerde başlık durumu yeterli görünebilir. B2B siparişlerde ise farklı depolar, üretim süreleri, paket katları veya müşteri talepleri nedeniyle satırlar bölünebilir. Portal, genel durumu özetlemeli; ayrıntıda her satırın sipariş edilen, onaylanan, ayrılan, sevk edilen, iptal edilen ve kalan miktarını göstermelidir.

“Sipariş tamamlandı” ifadesi ancak kapanış kuralı tanımlandığında güvenilirdir. Tüm satırlar sevk edilince mi, fatura oluşunca mı, teslimat kanıtı gelince mi kapanır? Bu karar müşteri hizmetleri, finans ve lojistik ekipleriyle ortak verilmelidir.

Durumu değil, olayı kaydedin

Sadece mevcut durumu saklamak geçmişin neden değiştiğini açıklamaz. Bunun yerine sipariş onaylandı, kredi kontrolüne girdi, stok ayrıldı, toplama başladı, paket kapandı, taşıyıcıya teslim edildi ve teslimat doğrulandı gibi olayları zaman damgasıyla kaydedin. Mevcut durum bu olaylardan türetilebilir.

GS1 EPCIS standardı, farklı uygulamaların fiziksel veya dijital nesnelerle ilgili görünürlük olaylarını ortak iş bağlamında yakalayıp paylaşabilmesini amaçlar. EPCIS her portalda zorunlu değildir; ancak “ne, ne zaman, nerede ve neden oldu?” yaklaşımı olay modelleme için yararlı bir referanstır. GS1 EPCIS 2.0 standardı, görünürlük olaylarının tamamlanmış iş adımlarını temsil ettiğini açıklar.

Kısmi sevkiyatları ayrı teslimat birimleri olarak gösterin

Bir sipariş birden fazla sevkiyata bölündüğünde tek takip numarası alanı yetersiz kalır. Her sevkiyat için paket veya taşıma birimi, içerdiği satırlar ve miktarlar, çıkış deposu, taşıyıcı, takip kimliği, planlanan ve gerçekleşen tarihler ile son durum tutulmalıdır.

Müşteri “siparişim nerede?” diye sorduğunda portalın cevabı sipariş başlığından değil ilgili sevkiyattan gelmelidir. Henüz sevk edilmeyen bakiye de kaybolmamalı; ayrı bir kalan miktar ve gerekçeyle gösterilmelidir.

Tarihleri kesinlik derecesiyle birlikte sunun

Sipariş tarihi, talep edilen teslim tarihi, onaylanan tarih, tahmini sevk tarihi ve gerçekleşen teslim tarihi aynı şey değildir. Arayüz bu alanları birbirine karıştırırsa kullanıcı tahmini bir tarihi taahhüt olarak okuyabilir.

Her tarih için kaynağı ve türü belirleyin: müşterinin talebi, ERP planı, üretim planı, taşıyıcı tahmini veya gerçekleşen olay. Tahmin değiştiğinde eski değeri silmek yerine revizyon geçmişini ve güncelleme nedenini operasyon kayıtlarında koruyun. Müşteriye yalnızca iş için gerekli ayrıntıyı gösterin.

Belge merkezini sipariş olaylarıyla ilişkilendirin

Sipariş onayı, proforma, fatura, irsaliye, paket listesi, kalite belgesi veya teslimat kanıtı bağımsız bir dosya arşivinde kaybolmamalıdır. Her belge sipariş, sevkiyat ve gerekiyorsa satır kimliğiyle ilişkilendirilmelidir.

Belge kaydında tür, sürüm, oluşturulma zamanı, geçerlilik, dil, erişim yetkisi ve kaynak sistem bulunmalıdır. “Fatura hazır” durumu gösteriliyorsa indirilen belgenin aynı sipariş ve güncel sürüme ait olduğu doğrulanmalıdır. Finansal veya kişisel bilgiler rol ve müşteri hesabına göre sınırlandırılmalıdır.

İstisnaları gizlemek yerine eyleme dönüştürün

“Beklemede” tek başına yeterli açıklama değildir. Stok, kredi, teknik onay, adres doğrulama veya müşteri yanıtı bekleyen siparişlerin sonraki adımı farklıdır. Portal, iç operasyon notlarını açığa çıkarmadan müşterinin yapabileceği eylemi belirtmelidir.

• Ödeme veya kredi koşulu bekleniyorsa gerekli belge ya da iletişim yolu;
• Adres eksikse güvenli düzeltme talebi;
• Kısmi stok varsa bekleme veya mevcut kalemleri sevk etme seçeneği;
• Teknik onay gerekiyorsa incelenen sürüm ve sorumlu ekip;
• Taşıyıcı gecikmesi varsa son doğrulanmış olay ve yeni tahmin.

Microsoft’un sipariş blokajı dokümantasyonu, blokajın ayrıntılı durum ve nedenle incelenmesini örnekler. Portal tasarımında amaç iç ekranı kopyalamak değil, blokajı müşteriye uygun açıklama ve eyleme çevirmektir. Sipariş blokajları dokümantasyonu iç durum ile ayrıntılı neden ayrımına örnek sunar.

ERP, WMS ve taşıyıcı arasında alan sahipliğini belirleyin

Portal yeni bir gerçeklik kaynağı olmamalıdır. Sipariş miktarı ve ticari durum ERP’den, fiziksel toplama WMS’den, taşıma olayı taşıyıcıdan, müşteri açıklaması ise kontrollü durum sözlüğünden gelebilir. Her alan için tek yetkili kaynak ve güncelleme yönü belirlenmelidir.

Bu sahiplik kararı için e-ticaret–ERP entegrasyonu rehberindeki alan bazlı yaklaşımı kullanabilirsiniz. Portal, kaynak sistemden gelen olayın kimliğini, sürümünü ve zamanını korumalı; aynı olayı iki kez uygulamamalıdır.

Gecikmeli ve sırasız olayları tasarımın parçası kabul edin

Taşıyıcı olayı ERP güncellemesinden önce gelebilir; ağ kesintisi eski bir depo mesajını geç iletebilir; kullanıcı aynı işlemi yeniden gönderebilir. Bu nedenle zaman sırası yalnızca mesajın geliş anına göre kurulamaz.

Her olay benzersiz kimlik, olay zamanı, sisteme geliş zamanı, kaynak, sipariş/sevkiyat ilişkisi ve sürüm taşımalıdır. Sistem mükerrer olayı reddetmeli, sırasız olayı kurala göre yeniden değerlendirmeli ve çelişkiyi görünür bir inceleme kuyruğuna almalıdır. Müşteriye doğrulanmamış geçici veriyi kesin bilgi gibi göstermeyin.

Bildirim ile portal gerçeğini aynı kaynaktan üretin

E-posta, SMS veya uygulama bildirimi portaldan farklı kuralla oluşturulursa müşteri iki ayrı durum görür. Bildirim; aynı görünür olay sözlüğünü kullanmalı, sipariş veya sevkiyat bağlantısı taşımalı ve hassas bilgiyi mesaj metnine gereksiz yere koymamalıdır.

Her olay bildirim gerektirmez. Sipariş kabulü, müşteri eylemi gerektiren blokaj, sevkiyat çıkışı, teslimat istisnası ve tamamlanma gibi karar değiştirici olayları seçin. Bildirim tercihleri, kanal izinleri ve tekrar sınırları ayrıca yönetilmelidir.

Erişilebilir durum güncellemeleri planlayın

Durumu yalnızca renkle anlatmayın. Etiket, kısa açıklama, tarih ve gerekiyorsa simge birlikte kullanılmalıdır. Yeni veri yüklendiğinde klavye odağını beklenmedik biçimde taşımayın; ancak kullanıcı işlemiyle değişen önemli sonucu yardımcı teknolojilere bildirin.

W3C, danışma niteliğindeki dinamik durum bilgilerinin status rolüyle ve odağı zorla taşımadan iletilebileceğini açıklar. Bu teknik tek başına erişilebilirlik sağlamaz; anlamlı metin, mantıklı odak sırası, klavye kullanımı ve hata açıklamaları da test edilmelidir. W3C status rolü açıklaması canlı durum bildirimleri için temel davranışı tanımlar.

Yetkiyi müşteri hesabı, rol ve sipariş ilişkisiyle sınırlandırın

B2B hesaplarda satın almacı, finans, depo ve yönetici farklı ayrıntıları görebilir. Ayrıca bir grup şirketi veya bayi ağı yalnızca kendisine bağlı siparişlere erişmelidir. URL’deki sipariş numarasını bilmek yetki vermemelidir.

Her sorguda müşteri hesabı, kullanıcı rolü, sipariş sahipliği, belge sınıfı ve gerekiyorsa lokasyon ilişkisi sunucu tarafında doğrulanmalıdır. Dışa aktarımlar, indirilen belgeler ve destek talepleri de aynı yetki modeline uymalıdır.

Kabul testlerini gerçek sipariş örneklerinden daha zor yazın

• Tek siparişte iki depo ve üç ayrı sevkiyat oluşması;
• Bir satır sevk edilirken diğerinin kredi kontrolünde beklemesi;
• Taşıyıcı olayının geç, mükerrer veya yanlış sırada gelmesi;
• Tahmini tarihin iki kez değişmesi ve neden kaydının korunması;
• İptal talebi sırasında paketleme işleminin başlamış olması;
• Yanlış müşteri hesabının sipariş veya belge URL’sini denemesi;
• Fatura sürümü değiştiğinde eski bağlantının davranışı;
• Ekran okuyucu ve klavyeyle filtre, ayrıntı ve durum güncellemesinin kullanılması.

Her senaryoda kaynak olay, portal durumu, müşteriye gösterilen açıklama, bildirim, belge, yetki sonucu ve hata kuyruğu birlikte doğrulanmalıdır.

Başarıyı hangi göstergelerle izlemelisiniz?

Başarıyı yalnızca portal giriş sayısıyla ölçmeyin. Durum verisinin güncellik gecikmesi, eşlenemeyen olay oranı, mükerrer olaylar, yanlış yetki denemeleri, müşterinin durum görüntüledikten sonra açtığı destek talepleri, belge indirme başarısı ve istisna çözüm süresi daha açıklayıcı olabilir. Bu göstergeler hedef değil başlangıç ölçümü olarak ele alınmalı; gerçek veriye göre eşikler insan tarafından belirlenmelidir.

Teklif kapsamına hangi teslimatlar girmeli?

• Sipariş, satır, sevkiyat, paket, belge ve olay veri modeli;
• Kaynak kod–müşteri durumu sözlüğü ve görünürlük kuralları;
• ERP/WMS/taşıyıcı alan sahipliği ve entegrasyon sözleşmeleri;
• Liste, filtre, ayrıntı, zaman çizgisi, belge ve istisna ekranları;
• Rol, müşteri hesabı ve belge yetki matrisi;
• Mükerrer/sırasız olay, yeniden deneme ve inceleme kuyruğu;
• Bildirim politikası, erişilebilirlik ve sınır durumu testleri;
• Pilot müşteri grubu, eğitim, izleme ve teknik devir belgeleri.

Sonuç

B2B sipariş takip portalı, farklı sistemlerden gelen teknik kodları yan yana sıralamak değildir. Kaynak olayları müşterinin karar verebileceği durumlara çeviren; satır, sevkiyat, tarih, belge, istisna ve yetki ilişkisini koruyan bir görünürlük ürünüdür. İlk sürümde sınırlı müşteri grubu, gerçek kısmi sevkiyatlar ve zorlayıcı hata örnekleriyle pilot yapın.

Kendi bayi veya toptan satış kanalınız için sipariş görünürlüğü, ERP/WMS bağlantısı ve müşteri portalı kapsamı çıkarmak istiyorsanız Kumsal Ajans e-ticaret çözümlerini inceleyebilir; görüşme öncesinde durum kodlarını, örnek siparişleri, sevkiyat bölünmelerini, belgeleri ve mevcut destek sorularını hazırlayabilirsiniz.