B2B sipariş portalı, işletmelerin bayi veya kurumsal müşterilerinden belirli kurallarla sipariş alabileceği kullanıcı alanıdır. Klasik ürün kataloğundan farklı olarak müşteri hesabı, özel fiyat, stok bilgisi ve onay akışı gibi ihtiyaçlar içerebilir. Ancak her toptancı veya üretici aynı işleyişe sahip değildir. Bazı işletmeler siparişi doğrudan kabul eder, bazıları önce fiyat veya teslim koşulunu değerlendirir. Bu fark açıklanmadan yalnızca sepete ekleme ekranı hazırlanması yanlış beklenti oluşturabilir. Kullanıcının yaptığı işlemin işletmede hangi sonucu doğurduğu açık olmalıdır.

İçindekiler

B2B sipariş portalı rehberi dokuz karar üzerinden bayi hesaplarını, fiyat görünürlüğünü, sipariş durumlarını ve iç sistem bağlantısını ele alır. Her projede bütün özelliklerin gerektiği varsayılmaz. Gerçek kullanım, mevcut veri ve ticari işleyiş incelenerek ilk sürüm belirlenir. Burada fiyat, satış artışı veya belirli entegrasyon başarısı iddia edilmez. Amaç, kurumsal sipariş sürecinin hangi sorularla anlaşılır hale getirileceğini göstermektir. İyi başlangıç, çok sayıda düğme eklemekten önce doğru hesabın doğru bilgiyle işlem yapmasını sağlamaktır.

B2B sipariş portalı ihtiyacınızı anlatırken bugün siparişin hangi kanaldan geldiğini açıklayın. Telefon, mesaj ve dosya üzerinden gelen taleplerin kim tarafından kayda alındığını gösterin. Hangi bilgiler tekrar soruluyor ve hangi aşamada onay gerekiyor? Özel yazılım geliştirme görüşmesinde bir normal sipariş ve bir istisna hazırlamanız yararlı olabilir. Teknik çözümü kendiniz belirlemek zorunda değilsiniz. İşletmenin günlük kararları ve beklediği sonuç, kapsamın anlaşılması için daha değerli başlangıç bilgisidir.

B2B sipariş portalı ile açık satış sitesi arasındaki fark

B2B sipariş portalı dışındaki açık sitede bütün ziyaretçiler benzer ürün ve fiyat görebilir. Kurumsal alanda ise müşteri anlaşmaları, ürün grupları veya hesap yetkileri farklı olabilir. Bu farkların gerçekten gerekli olup olmadığı belirlenmelidir. Bir müşterinin özel fiyatı başka hesaba görünmemelidir. Ürünlerin bir bölümü sadece belirli gruba açık olabilir. Her işletmede bu yapı zorunlu değildir. Ancak gereken sınırlar başlangıçta yazılmazsa ekranlar genel satış sitesi gibi çalışabilir ve sonradan önemli değişiklik gerekebilir.

B2B sipariş portalı içinde sipariş gönderildiğinde oluşan kayıt da açıkça tanımlanmalıdır. Bu kesin sipariş mi, ön talep mi, yoksa inceleme bekleyen taslak mı? Kullanıcıya verilen mesaj aynı ayrımı göstermelidir. İşletmenin henüz kontrol etmediği stok veya koşul için kesin onay verilmiş gibi görünmemelidir. İlgili ticari koşullar ayrıca değerlendirilir; bu yazı sözleşme hükmü önermez. Burada açıklanan konu, ekran davranışının gerçek iş akışıyla tutarlı olmasıdır. Durum adlarının anlamı kullanıcı açısından anlaşılır olmalıdır.

Bayi sipariş akışı için 9 temel karar

1. Bayi hesabının açılışı

Hesabın işletme tarafından mı açılacağı, başvuru sonrası mı onaylanacağı belirlenmelidir. Şirket kaydıyla kullanıcı kişisi birbirinden ayrılabilir. Bir bayide birden fazla çalışan bulunabilir ve hepsi aynı yetkiye ihtiyaç duymayabilir. Yeni kişinin doğru şirketle eşleştirilmesi önemlidir. Elektronik posta adresinin bilinmesi tek başına bütün şirket adına işlem hakkı vermeyebilir. Doğrulama ve onay yöntemi işin riskine göre tasarlanır. Hesap açılışı kadar görev değişikliği ve erişim kapanışı da düşünülmelidir.

B2B sipariş portalı hesaplarında hangi bilgilerin asıl kaynaktan geleceği açıklanmalıdır. Bayi adı, teslim adresi veya hesap kodu mevcut programda tutuluyor olabilir. Dış kullanıcının değiştirebileceği alanlar seçilir. Her bilgiyi düzenletmek veya hiçbir şeyi değiştirilemez yapmak uygun olmayabilir. Adres değişikliği için ayrı onay gerekebilir. Kullanıcı birden fazla teslim noktasına sahipse seçim yöntemi anlaşılır olmalıdır. Bilginin yanlış kaynağa kaydedilmesi sonraki siparişlerde tekrar sorun yaratabilir. Bu yüzden hesap yönetimi tek form olarak görülmemelidir.

Hesap kapatıldığında açık siparişlerin ne olacağı da kararlaştırılır. Kullanıcı yeni işlem yapamayabilir ama geçmiş belgeye erişim gerekebilir. Bu koşullar işletmenin işleyişine göre değerlendirilir. Güncel yetkiler ile geçmiş işlem sahipliği farklı konulardır. Bir çalışanın hesabını kapatmak onun oluşturduğu bütün kayıtların kaybolması anlamına gelmemelidir. İş açısından beklenen davranış örnekle açıklanır. Teknik ekip bunun güvenli ve tutarlı uygulama seçeneklerini değerlendirir. Başlangıç kapsamı bu senaryoların hangilerini içerdiğini göstermelidir.

2. Ürün kataloğunun kapsamı

Hangi müşterinin hangi ürünleri göreceği belirlenmelidir. Ürün grubu, marka veya anlaşma bazında sınırlama gerekebilir. Katalogda ürün adı, kod, birim ve gerekli açıklamalar bulunabilir. Her teknik alanı dış kullanıcıya açmak şart değildir. Sipariş için gereken bilgiler önceliklidir. Aynı ürün farklı ambalaj veya birimle satılıyorsa bu ayrım anlaşılmalıdır. Yanlış birim seçimi stok ve teslim sürecini etkileyebilir. Ürün görselinin bulunması yararlı olabilir; fakat doğru kod ve birim bilgisinin yerine geçmez.

B2B sipariş portalı aramasında bayi kendi kullandığı ürün adını veya kodunu arayabilir. İşletmenin iç kodunu herkesin bilmesi beklenmemelidir. Alternatif ad veya müşteri kodu ihtiyacı araştırılabilir. Arama sonuçları müşterinin görmeye yetkili olduğu katalogla sınırlı olmalıdır. Listeden gizlenen ürünün başka bağlantıyla açılması kontrol edilmelidir. Ürün artık satılmıyorsa geçmiş siparişte nasıl görüneceği düşünülür. Güncel katalogdan kaldırmak geçmiş hareketin anlamını kaybetmesi demek olmamalıdır.

Katalog güncellemesini kimin yapacağı ve hangi kaynaktan alacağı belli olsun. Aynı ürün iki yerde değiştiriliyorsa hangisi geçerli kabul edilecek? Açıklama, fiyat ve stok farklı kaynaklardan gelebilir. Kullanıcıya sunulan bilgilerin ne zaman güncellendiği önemli olabilir. Kaynak hizmetin bağlantı olanakları resmi belgeleriyle incelenir. Her eski programın bütün alanları dışarı verebildiği varsayılmaz. İlk sürümde gerekli alanların sınırlandırılması bağlantı kapsamını daha anlaşılır hale getirebilir. Gereksiz veri aktarımı amaç olmamalıdır.

3. Özel fiyat kuralları

Fiyat müşteri, grup, miktar veya başka ticari koşula göre değişebilir. Gerçek kurallar işletme tarafından açıklanmalıdır. Aynı ürün için birden fazla geçerli liste varsa önceliği belirlenir. Kullanıcı ekranda hangi fiyatın gösterildiğini anlayabilmelidir. Vergi, teslim veya başka koşulların gösterimi işin kapsamına göre değerlendirilir. Bu yazı mali veya hukuki uygulama önermez. Amaç fiyat bilgisinin yanlış hesaba ya da yanlış koşula bağlanmasını önleyecek soruların konuşulmasıdır.

B2B sipariş portalı fiyatında ürün listesiyle sipariş anı arasında değişiklik olabilir. Sepette eski değer bulunuyorsa gönderim sırasında ne olacağı açıklanmalıdır. Kullanıcıya değişiklik gösterilmeden başka toplamla kayıt açılması yanlış beklenti yaratabilir. Aynı şekilde eski siparişlerin geçmiş fiyatları güncel listeye göre sessizce değişmemelidir. İşletmenin ihtiyaç duyduğu davranış netleştirilir. Teknik tasarım, hangi bilginin olay anında saklanacağına göre yapılır. Fiyatın doğru görünmesi kadar doğru işleme bağlanması da önemlidir.

Özel fiyatın görünürlüğü yetki meselesidir. Bir müşterinin fiyatını yalnızca menüden gizlemek yeterli olmayabilir. Arama, dosya indirme veya bağlantı yanıtları da uygun sınırı korumalıdır. Testlerde farklı hesaplarla örnek işlemler yapılabilir. Hesaplar arasında geçiş varsa eski fiyatların yanlış bağlamda kalmaması düşünülür. Gereken güvenlik kontrolü teknik ekipçe uygulanır. İşletme, hangi kullanıcıların hangi fiyatları görmesi gerektiğini açıklar. Varsayımla herkese aynı yetki vermek başlangıçta kolay görünse de doğru olmayabilir.

4. Stok bilgisinin anlamı

Kullanıcıya gösterilen stok gerçek miktar, yaklaşık kullanılabilirlik veya sipariş verilebilir durumu olabilir. Hangi bilginin gerekli olduğu belirlenmelidir. Rezervasyon, yoldaki ürün veya farklı depo miktarı hesabı etkileyebilir. Stok var ifadesi belirli tarihte teslim garantisi gibi yorumlanmamalıdır. Ekranın dili gerçek veriye uygun olmalıdır. Güncelleme belirli aralıklarla yapılıyorsa son zaman gösterilebilir. Bağlantı hatasıyla sıfır stok aynı şekilde sunulmamalıdır. Kullanıcının karar vereceği bilgiye hangi düzeyde güveneceği anlaşılır olmalıdır.

B2B sipariş portalı için sipariş gönderilirken yeniden stok kontrolü gerekebilir. Listeyi açtıktan sonra başka işlem nedeniyle miktar değişmiş olabilir. Hangi durumda kullanıcı bilgilendirilecek veya işletme onayı beklenecek? Kısmi sipariş kabulü, alternatif ürün veya bekleyen talep farklı seçeneklerdir. Her işletmede hepsini eklemek gerekmez. Günlük süreç hangi davranışa ihtiyaç duyuyorsa ona göre kapsam belirlenir. Sadece normal stoklu örnekle tasarım yapmak istisnaları dışarıda bırakabilir. İşletmenin gerçek örnekleriyle deneme yapılmalıdır.

5. Sipariş oluşturma davranışı

Kullanıcının ürün ve miktar seçmesi, adresi belirlemesi ve kaydı göndermesi temel akış olabilir. Ancak işletmenin zorunlu referans veya not alanları bulunabilir. Bunların nedeni açıklanmalıdır. Çok fazla zorunlu alan kullanıcıyı zorlayabilir; eksik bilgi ise iç ekibin tekrar iletişim kurmasına neden olabilir. Önceden girilmiş siparişin kopyalanması düşünülüyorsa güncel ürün ve fiyatlar yeniden değerlendirilmelidir. Eski kaydı aynen çoğaltmak her durumda doğru sonuç vermez. Kullanıcıya hangi bilginin değiştiği gösterilebilir.

B2B sipariş portalı düğmesine tekrar basılması aynı siparişin iki kez oluşmasına yol açmamalıdır. Teknik yöntem kullanılan yapıya bağlıdır. İş açısından beklenen sonuç, kullanıcının işlemin alınıp alınmadığını anlayabilmesidir. Bağlantı kesildiğinde durum belirsiz kalabilir. Kullanıcı kayıt geçmişinden sonucu kontrol edebilir veya uygun yeniden deneme yöntemi görebilir. Bu senaryo başlangıçta düşünülmelidir. Sadece hızlı bağlantıda başarılı gönderimi test etmek günlük kullanımın bütün koşullarını kapsamaz. Hata mesajları anlaşılır ve gerekli bilgiyle sınırlı olmalıdır.

6. Onay ve durum geçişleri

Siparişin işletme içinde incelenmesi gerekiyorsa hangi kuralla onaya gireceği belirlenmelidir. Her kayıt aynı yol izlemeyebilir. Bayi yöneticisinin kendi ekibinin taleplerini onaylaması da farklı ihtiyaç olabilir. Bunlar ayrı süreçlerdir. Kimin hangi aşamada hangi alanı değiştirebileceği açıklanmalıdır. Onay verilmeden hazırlığa başlanıp başlanmayacağı iş kararıdır. Kullanıcı durumun anlamını bilmeli, gerekli eylemi görebilmelidir. Durum listesinin çok uzun olması da takip etmeyi zorlaştırabilir. Gerçek ihtiyaç kadar aşama seçilir.

B2B sipariş portalı onayında eski ve yeni kayıt ilişkisi korunmalıdır. Bir talep reddedildiğinde silinmesi mi, açıklamayla geçmişte kalması mı bekleniyor? Sipariş değişirse yeniden onay gerekir mi? Bu sorular kullanıcıların günlük işlemine göre cevaplanır. Teknik ekip iş kuralını tahminle seçmemelidir. Normal, reddedilen ve değişen örnekler üzerinde deneme yapılabilir. İşletme içindeki özel notlarla bayiye verilecek açıklamalar ayrılmalıdır. Her iç değerlendirme dış kullanıcıya uygun olmayabilir. Gösterilecek bilgi ayrıca seçilir.

7. Belgeler ve hesap bilgileri

Siparişe bağlı belgeler veya uygun hesap özeti sunulabilir. Hangi bilginin gerçekten gösterileceği ve hangi kaynaktan geleceği net olmalıdır. İşletmenin resmi kayıtlarıyla ekrandaki operasyon bilgileri aynı kapsamda olmayabilir. Kullanıcıya bilginin neyi temsil ettiği açıklanır. Bu rehber mali veya hukuki belge niteliğine karar vermez. Mevcut sistemin verdiği bilgilerin kullanım koşulları ayrıca değerlendirilir. Güncel belgeyle eski sürümün ayrılması ve doğru müşteriye bağlanması temel ihtiyaçtır.

B2B sipariş portalı belge indirmesinde kayıt yetkileri korunmalıdır. Sadece listede doğru belge görünmesi yeterli değildir; indirme yolu da yetkiyi kontrol etmelidir. Microsoft Power Pages güvenlik rehberi, sayfa görünürlüğüyle veri erişimi kontrollerini ilişkili ama ayrı konular olarak ele alır. Burada belirli ürünü seçmeniz gerektiği söylenmez. Önemli fikir, menüden gizlemenin kaydı korumak için tek başına yeterli olmadığıdır. Gerçek uygulama uygun erişim senaryolarıyla denenmelidir.

8. İç sistem bağlantısı

Siparişler mevcut programa aktarılacaksa alan eşleme, kayıt kimliği ve hata yönetimi düşünülmelidir. Portalda alındı görünen kayıt iç sisteme ulaşmamış olabilir. Hangi durumda kullanıcıya ve işletme ekibine bilgi verileceği açıklanmalıdır. Aynı siparişin yeniden aktarılması tekrar kayıt oluşturmamalıdır. Teknik ayrıntılar mevcut sistemin olanaklarına bağlıdır. Bağlantı belgeleri ve test erişimi incelenmeden her davranışın mümkün olduğu varsayılmaz. Üçüncü taraf kullanım bedelleri de geliştirme çalışmasından ayrı olabilir.

B2B sipariş portalı bağlantısında hangi sistemin asıl kayıt kaynağı olduğu önemlidir. Fiyatı, stoku ve sipariş durumunu farklı yerler yönetiyor olabilir. Her veri için sorumluluk belirlenmelidir. Dış hizmet değiştiğinde bağlantının nasıl izleneceği konuşulur. Sadece ilk gün başarıyla veri gönderilmesi uzun dönem bakım ihtiyacını ortadan kaldırmaz. Hata kayıtları ve inceleme sorumlusu bulunmalıdır. Kullanıcıya teknik günlük dökmek yerine anlaşılır durum sunulur. İşletme ekibi gerektiğinde ayrıntılı inceleme için gerekli kayıt bilgisine ulaşabilir.

9. Kullanıma geçiş ve destek

İlk sürüm sınırlı bayi grubuyla değerlendirilebilir. Bu zorunlu yöntem değildir; kapsam ve işletme düzenine göre seçilir. Kullanıcılara hesap açılışı, sipariş gönderimi ve durum takibi açıklanmalıdır. İç ekip de gelen kayıtları nasıl işleyeceğini bilmelidir. Sadece dış ekranı hazırlamak yeterli olmayabilir. Hangi talep kime gider, yanlış kayıt nasıl düzeltilir ve erişim sorunu kim tarafından ele alınır? Bu sorumluluklar günlük çalışma düzeninin parçasıdır. Teknik bakım ile iş verisi yönetimi ayrılabilir.

B2B sipariş portalı kullanıma girdikten sonra geri bildirimler toplanır. Kullanım sorusu, hata ve yeni özellik ayrı değerlendirilmelidir. Kullanıcının formu bitirememesiyle yeni rapor istemesi aynı öncelik olmayabilir. İlk sürümde sunulmayan işlevler varmış gibi tanıtılmamalıdır. Sonraki geliştirmeler gerçek ihtiyaçlara göre planlanabilir. Başlangıçta belirli başarı oranı sözü vermek yerine hangi sorunun nasıl değerlendirileceği açıklanır. Kullanıcıların temel işlemi doğru ve anlaşılır biçimde tamamlayabilmesi öncelikli ölçüttür.

Varsayımsal örnek: Dosyayla alınan bayi talebi

B2B sipariş portalı örneği olarak bir toptancının bayilerinden ürün kodu ve miktar içeren tablolar aldığını düşünelim. Bu tamamen varsayımsal örnekte portal hesabı müşteriye uygun katalog ve fiyatları gösteriyor. Bayi miktar seçip sipariş isteği gönderiyor. İşletme stok ve koşulları kontrol ettikten sonra kaydı onaylıyor. Kullanıcı alındı ve onaylandı durumlarının farkını görüyor. Burada gerçek müşteri projesi veya satış artışı iddia edilmez. Örnek, dış kullanıcı adımıyla iç onay sürecinin nasıl ilişkilendirilebileceğini anlatır.

B2B sipariş portalı bu örnekte yanlış ürün kodunu azaltabilecek bir kullanım yolu sunabilir; ancak bunun gerçekleştiği ölçülmeden oran verilmez. Eski dosya yöntemi tamamen kalkacak mı, bazı müşteriler onu kullanmaya devam edecek mi? Aynı sipariş iki kanaldan gelirse nasıl fark edilecek? Bu sorular geçiş planına eklenir. Yeni uygulama eski sürecin yanına konduğunda iş yükü geçici olarak artabilir. Kullanıcı ve işletme sorumlulukları bu nedenle birlikte hazırlanmalıdır. Gerçek sonuç kullanım değerlendirmesiyle anlaşılır.

Teklif istemeden önce dosyaları hazırlamak

B2B sipariş portalı için ürün listesi, bayi grupları, fiyat kuralları ve örnek sipariş hazırlanabilir. Bütün canlı veriyi ilk görüşmede paylaşmak gerekli olmayabilir. Hassas alanlar ayıklanır, ilişkileri gösteren küçük kayıt grubu seçilir. Hangi verinin nerede tutulduğu ve kimin güncellediği açıklanır. Belirsiz konular kesinmiş gibi yazılmamalıdır. Mevcut sistemden alınabilen örnek dosyalar ve resmi bağlantı belgeleri yararlıdır. Sadece API var ifadesine dayanmak yerine hangi işlemlerin gerçekten sunulduğu görülmelidir. Bu bilgi kapsam değerlendirmesini güçlendirir.

B2B sipariş portalı görüşmesinde sorunlu örnekler de önemlidir. Stok yokken verilen sipariş, fiyatı değişen ürün veya yanlış adrese yönlenen kayıt gibi durumlar gösterilebilir. Bunlar gerçek kişilerin bilgilerini içermek zorunda değildir. Temsili örnekle de iş kuralı açıklanabilir. Her sorunu ilk sürümde çözmek mümkün veya gerekli olmayabilir. Öncelikler belirlenir ve ertelenen işin günlük kullanımda nasıl karşılanacağı konuşulur. Bilinçli sınırlama ile unutulmuş ihtiyaç arasındaki fark karar kaydında görünür olmalıdır.

Tekrarlanan siparişlerde eski ve yeni bilgiyi ayırmak

B2B sipariş portalı kullanıcıları benzer ürünleri düzenli isteyebilir. Bu durumda eski siparişten başlamak yararlı olabilir. Ancak eski kaydın bütün bilgilerinin bugün geçerli olduğu varsayılmamalıdır. Ürün birimi değişmiş, teslim adresi kapanmış veya müşteri fiyatı güncellenmiş olabilir. Kullanıcıya hangi alanların yeniden kontrol edildiği anlaşılır gösterilmelidir. Eski belge geçmiş işlem olarak korunurken yeni sipariş güncel kurallarla değerlendirilir. Bu ayrım hem kullanıcı beklentisi hem kayıtların tutarlılığı açısından önemlidir. Kolaylık sağlayan özellik, kontrol adımlarını görünmez hale getirmemelidir.

B2B sipariş portalı için favori ürün veya kaydedilmiş liste de düşünülebilir. Bunlar kesin sipariş değildir. Listeye eklenen ürün artık satılmıyorsa kullanıcı uygun açıklama görmelidir. Miktar ve birim bilgisi korunacaksa güncel katalogla ilişkisi değerlendirilir. Birden fazla kişinin aynı bayi hesabında çalıştığı durumda listenin kişisel mi şirket ortak mı olduğu belirlenir. Kullanıcıların birbirinin hazırlığını istemeden değiştirmesi günlük işi zorlaştırabilir. Hangi davranışın gerekli olduğu gerçek bayi örnekleriyle konuşulur. Her kullanışlı fikir ilk sürüme otomatik eklenmemelidir.

Bekleyen taleplerin unutulmaması

B2B sipariş portalı içindeki inceleme bekleyen kayıtların işletme ekibinde karşılığı bulunmalıdır. Hangi sorumlu hangi kuyruğu takip edecek? Bir kişi izinliyken kayıt kime yönlendirilecek? Teknik bildirim bulunması talebin gerçekten ele alındığını kanıtlamaz. İşletmenin çalışma düzeni gerekir. Bekleme nedeninin müşteriye ne kadar açıklanacağı da değerlendirilir. İç notla dış açıklama ayrı tutulabilir. Sadece beklemede etiketinin uzun süre kalması kullanıcıyı yeniden telefon etmeye yöneltebilir. Doğru bilgiyle takip, uygulamanın temel hizmet işlevlerinden biridir.

B2B sipariş portalı durumlarında görev bitişi ile sipariş kapanışı aynı olmayabilir. Bir kullanıcı kontrolünü tamamlamış ama teslim henüz yapılmamış olabilir. Hangi olayın dış durumda değişiklik yaratacağı açıklanmalıdır. Her iç adımı müşteriye taşımak gerekmez. Ancak kullanıcıdan beklenen işlem varsa açıkça görünmelidir. Eksik bilgi tamamlanınca kaydın yeniden incelemeye girmesi gerekebilir. Bu yol örnek kayıtlarla denenir. İyi durum tasarımı yalnızca etiket sayısını artırmak değil, kullanıcının bir sonraki adımı anlamasını sağlamaktır.

Sipariş düzeltmesini geçmişi bozmadan yapmak

B2B sipariş portalı üzerinden gönderilmiş kaydın sonradan değiştirilmesi ayrı senaryodur. İşletme henüz incelememişse düzeltme mümkün olabilir; hazırlığa başlanmışsa başka yöntem gerekebilir. Bu ticari ve operasyon kararı ayrıca değerlendirilir. Kullanıcının ekrandaki miktarı değiştirmesi bütün sistemlerde aynı anda güvenle sonuçlanacak diye varsayılmamalıdır. Hangi aşamada hangi alanların değiştirileceği ve yeniden onay gerekip gerekmediği yazılır. Eski değerle yeni değer arasındaki farkın takip edilmesi gerekli olabilir. Teknik tasarım bu iş beklentisine göre yapılır.

B2B sipariş portalı iptalinde de benzer ayrım vardır. İptal isteği ile iptal edilmiş kayıt aynı durum değildir. Müşteri isteği gönderebilir, işletme mevcut hazırlık veya teslim durumuna göre değerlendirebilir. Ekran mesajı gerçekte hangi olayın gerçekleştiğini açıklamalıdır. Yanlış kesinlik kullanıcı güvenini etkileyebilir. Kapsam gerektiriyorsa iptal nedeni ve ilgili açıklama tutulur. Her işlemde bütün geçmişi silmek izlenebilirliği azaltabilir. Saklama ve erişim koşulları işletmenin durumu ve yükümlülükleriyle ayrıca ele alınır; bu yazı hukuki hüküm vermez.

Kayıt doğruluğunu küçük örneklerle sınamak

B2B sipariş portalı denemesinde her hesap için birkaç anlamlı kayıt seçin. Normal ürün, fiyat istisnası, kapalı ürün ve stok sorunu gibi durumlar örnek olabilir. Her birinde beklenen davranışı önceden yazın. Böylece sonuç yalnızca sezgiyle değerlendirilmez. İşletme hangi ticari kuralın doğru olduğunu açıklar, teknik ekip uygulamanın o kurala uygunluğunu kontrol eder. Kullanıcıdan teknik teşhis yapması beklenmez. Kısa açıklama ve örnek kayıt numarası incelemeyi başlatabilir. Hassas veriler gereksiz yere test dosyalarına taşınmamalıdır.

B2B sipariş portalı için boş hesap ve yeni bayi senaryosu da düşünülmelidir. Geçmiş siparişi olmayan kullanıcı ne görecek? Ürün listesi yüklenemiyorsa boş katalogla hata ayrılıyor mu? Kullanıcıya tekrar deneme veya iletişim yolu gösterilebilir. Teknik ayrıntıların tamamının dışarı açıklanması gerekmez. Anlaşılır durum bilgisi yeterlidir. Aynı şekilde iç sistem bağlantısı geciktiğinde kaydın kaybolmuş gibi görünmemesi önemlidir. Hangi bilginin doğrulanmış, hangisinin bekleyen işlem olduğu açık tutulmalıdır. Bu kontroller gerçek kullanıma geçişin önemli bölümüdür.

Yerel işletmeler için başlangıç görüşmesi

B2B sipariş portalı planlayan Maltepe, İdealtepe ve Anadolu Yakası işletmeleri, bayi siparişlerinin bugünkü akışını HD Bilgisayar ile değerlendirebilir. İletişim numarası 0532 396 34 71, adres Altayçeşme, Oba Çıkmazı No:3, Maltepe, İstanbul’dur. Görüşme zamanı ve yöntemi ayrıca kararlaştırılır. Bu rehber belirli bir sistemle hazır bağlantı, teslim tarihi veya fiyat taahhüdü değildir. Mevcut programlar, veri ve onay kuralları incelenerek yapılacak çalışma netleştirilir. Yakın konum ihtiyacın değerlendirilmesinin yerine geçmez.

Sipariş akışını denemek için kontrol listesi

B2B sipariş portalı değerlendirmesinde farklı hesap ve ürün koşullarıyla örnek işlemler yapın. Doğru fiyatın doğru müşteriye gösterildiği ve gönderilen kaydın hangi aşamada olduğu anlaşılmalıdır. Kullanıcı tekrar denediğinde kayıt çoğalıyor mu, stok değişince ne oluyor ve indirme yetkileri korunuyor mu? Bu sorular uygulamanın kapsamına göre denenir. Teknik ekip ve işletmenin hangi kontrolü yapacağı belirlenmelidir. Sonuçlar yalnızca ekranın güzel görünmesine göre değil, gerçek sipariş davranışıyla uyumuna göre değerlendirilir.

• Bayi hesabı ve kişi yetkileri doğru eşleşiyor mu?
• Katalog ve birimler anlaşılır mı?
• Özel fiyat kurallarının önceliği belli mi?
• Stok bilgisinin anlamı ve güncelliği açıklanıyor mu?
• Gönderimin kesin sipariş mi talep mi olduğu net mi?
• Onay, değişiklik ve iptal senaryoları tanımlı mı?
• Belge ve hesap bilgileri doğru kişiye açık mı?
• İç sistemdeki başarısız aktarımlar takip ediliyor mu?
• Kullanıcı ve işletme destek sorumluları belli mi?

Sık sorulan 6 soru

Her bayi farklı fiyat görebilir mi?

Böyle iş kuralı varsa kapsamda değerlendirilebilir. Fiyatın hangi kaynaktan geldiği ve kuralların önceliği açıklanmalıdır. B2B sipariş portalı fiyat görünürlüğü doğru hesaba bağlı olmalıdır. Liste, arama ve indirme gibi yollar aynı sınırı korumalıdır. Geçmiş siparişlerin fiyatlarının nasıl tutulacağı da düşünülür. Mevcut sistem bu veriyi sağlayabiliyor mu sorusu resmi belgeler ve örneklerle ayrıca incelenmelidir.

Sipariş gönderildiğinde otomatik kabul mü edilir?

Bu işletmenin seçtiği akışa bağlıdır. Kayıt önce inceleme bekleyen talep olarak alınabilir veya belirli koşullarda onaylanabilir. B2B sipariş portalı kullanıcıya hangi olayın gerçekleştiğini açıkça göstermelidir. Alındı mesajı onaylandı gibi yorumlanmamalıdır. Stok ve ticari koşulların ne zaman kontrol edildiği belirlenir. Hangi yöntemin uygun olduğu gerçek süreç, mevcut sistem ve sorumluluklarla birlikte değerlendirilir.

Mevcut muhasebe veya stok programına bağlanabilir mi?

Bu, programın sunduğu bağlantı olanaklarına ve erişim koşullarına bağlıdır. Belgeler ve test yöntemi incelenmeden kesin söz verilmemelidir. Hangi veri hangi yönde aktarılacak sorusu açıklanmalıdır. B2B sipariş portalı tarafında kayıt alındığı halde iç sisteme ulaşmaması gibi durumlar düşünülür. Hata takibi, tekrar gönderim ve kayıt kimliği önemlidir. Üçüncü tarafın kendi ücretleri geliştirme bedelinden ayrı olabilir.

Bayi eski siparişini tekrar kullanabilir mi?

İhtiyaç varsa bu işlev değerlendirilebilir. Ancak eski ürün ve fiyatların aynen geçerli olduğu varsayılmamalıdır. Güncel katalog, stok ve fiyat kontrolü gerekebilir. Kullanıcıya hangi bilginin değiştiği anlaşılır gösterilir. B2B sipariş portalı geçmiş kaydı kopyalarken yeni işlem oluşturduğunu açıklamalıdır. Kapanmış ürünler veya değişen birimler için uygun davranış belirlenir. Örnek eski kayıtlarla deneme yapmak yararlı olabilir.

Telefon ekranından sipariş verilebilir mi?

Bu kullanım ihtiyacı tasarım ve deneme kapsamına alınabilir. Uzun katalog, miktar girişi ve adres seçimi küçük ekranda ayrıca değerlendirilir. Sadece sayfanın açılması rahat kullanım kanıtı değildir. B2B sipariş portalı bağlantı kesintisi ve tekrar gönderim durumlarında anlaşılır davranmalıdır. Kullanıcı kayıt alındığını görebilmeli, belirsiz durumda sonucu kontrol edebilmelidir. Kesin teknik yöntem uygulamanın yapısına göre belirlenir.

İlk görüşmede hangi örnekleri hazırlamalıyım?

B2B sipariş portalı için bir normal sipariş, bir fiyat istisnası ve bir stok sorunu hazırlayın. Bayi grupları, ürün birimleri ve mevcut veri kaynaklarını kısaca açıklayın. Hassas bilgileri ayırarak küçük örnek gösterebilirsiniz. Teknik mimariyi kendiniz seçmek zorunda değilsiniz. Siparişin bugün nasıl geldiğini ve içeride kimlerin hangi kararı verdiğini anlatmanız başlangıç için daha yararlı bir zemin oluşturur.