Bayiler için B2B Sipariş Portalı: Kapsam Rehberi

B2B sipariş portalı, onaylı müşterilerinizin kendi kataloglarını ve fiyatlarını görmesini, sipariş vermesini ve tekrarlamasını, belgelerini takip etmesini sağlar; hepsi ERP ile senkronizedir. Kapsamı kademeler bölün: önce hesaplar, fiyatlar ve siparişler; sonra ödemeler ve onaylar — eksiksiz açılmaya çalışan bir portal genellikle geç ve yarım kullanımlı açılır.

B2B sipariş portalı nedir?

B2B sipariş portalı, onaylı bayilerinizin ve ticari müşterilerinizin giriş yapıp işleri kendilerinin yürüttüğü markalı bir web kanalıdır: hesaplarına görünen katalogu gezer, kendileriyle anlaşılan fiyatları görür, sipariş kurar ya da öncekini tekrarlar ve hesaplarına ait belgeleri — teklifler, siparişler, faturalar, iade faturaları, sevkiyatları — bulur. ERP kaynak sistem olarak kalır; portal ona açılan bir penceredir ve her hesabın neyi görebileceği ve yapabileceğine dair kurallarla çalışır. Müşteri gruplarınızı, fiyat listelerinizi ve ERP’nizi gönderin; teklif isteyin, hesaplar, fiyatlar ve siparişlerle başlayan fazlı portalın kapsamını çıkaralım.

Portalı, çoğu zaman karıştırılan üç komşusundan ayırmak gerekir:

• Web mağazası. Perakende fiyat, açık üyelik, kart ile ödeme. Bayi portalı tam tersidir: erişim hesap bazında verilir, fiyatlar sözleşmelidir ve ödeme bir ödeme adımından çok var olan koşullara göre yürür.


• Pazarlama sitesindeki müşteri alanı. İndirme ve destek talepleri için kullanışlıdır; ama katalog, fiyat ve sipariş mantığı olmadan satış masasına gelen tek bir telefonu bile ortadan kaldırmaz.


• E-postayla gönderilen PDF fiyat listesi. Bayilerin portal öncesi yaşadığı durum: gönderildiği gün doğru, ertesi hafta yanlış ve hesap bazında aranamaz.

Özellik tablosu: şart, tercih, sonraya

Tedarikçi sayfaları her şeyi birden listeler. Kademelere bölmek ilk sürümü sevk edilebilir tutar. Tablo, tekrar eden özellikleri ilk sürümün ihtiyacı, ikincisinin eklediği ve gerçek kullanım verisiyle ertelenebilir olarak sıralar:

Tablo A: özellik | amaç | kademe (1/2/3) | ERP bağımlılığı

1. kademe davranışı değiştiren sürümdür: bir bayi giriş yapıp kendi fiyatlarını görür, geçen ayın siparişini tekrarlar ve bu ERP'ye girerse telefon ve tablo kanalı kendi kendine kapanmaya başlar. 2. ve 3. kademeler para ve yönetişim katmanlarını ekler; yazılımın tutabilmesi için önce kuruluşun kredi, finans ve onay kararlarının verilmiş olması gerekir.

ERP ve CRM entegrasyonu

Entegrasyon, portalın işin aynası mı yoksa girişi olan bir broşür mü olduğunu belirler. Herhangi bir mimari seçilmeden önce yazılı cevap isteyen dört soru:

1. Senkron yönü. Ana veriler — hesaplar, ürünler, fiyatlar, koşullar — ERP'den portala akar. Siparişler, teklif talepleri ve ödemeler geriye akar. Bunun dışında her şeyin açık bir sahibi olmalıdır: fiyatı kim değiştirebilir ve o değişiklik nerede yaşar?


2. Senkron sıklığı. Gece toplu, gün içinde periyodik tazeleme ya da gerçek zamanlıya yakın. Dürüst kural: fiyatlar ve kredi konumları ürün görsellerinden daha sık senkronu hak eder; karma bir strateji normaldir — kritik veri daha sık, katalog içeriği daha seyrek.


3. Hata yönetimi. ERP kapalıysa ya da bir kayıt doğrulamadan geçmiyorsa portal ne yapar: kuyruğa alır, reddeder mi, yoksa son bilinen durumu açık bir notla mı gösterir? Sessiz hata, bir bayinin geçen haftanın fiyatıyla sipariş vermesini doğurur; bu sizin uyuşmazlığınız olur, onun değil.


4. Mutabakat. Her portal siparişi tam olarak bir ERP belgesine mi dönüştü — çift kayıt, boşluk ya da yarım kalmış kayıt olmadan? Cevap, ilk aylarda birinin her gün okuduğu operasyonel bir rapordur ve bu da aşağıdaki kabul testlerinden biridir.

Çok dilli ve çok para birimli kataloglar

İhracatçılar her iki soruyla erken karşılaşır ve karar vermek yeniden yapılandırmaktan ucuzdur.

Diller. Katalog ürün adları, kategoriler ve belgeler için çeviri ister; hesap yapısı hesap başına bir dil tercihi ister ki portal aynı alıcıya her girişte seçim sormasın. Pratik iki nokta: çevirilerin sahibini ve güncelleme ritmini belirleyin — yarım çevrilmiş bir katalog, fark eden alıcıya İngilizce bir katalogdan daha kötü görünür — ve belgelerin (teklif, fatura) arayüz dilini mi izleyeceğini yoksa finans sisteminizin gerektirdiği dilde mi kalacağını kararlaştırın. Bu ikinci soru teknik değildir: yanlış dilde bir fatura bir muhasebe sorunudur.

Para birimleri. Tek para biriminde anlaşılan fiyatlar, ziyaretçi nereden gelirse gelsin o para biriminde gösterilmelidir; görüntüleme para birimlerini sözleşmelilerle karıştırmak uyuşmazlıkların başladığı yerdir. Bir hesap birden fazla para biriminde işlem görüyorsa kural portaldaki ayarlarda değil ERP verisinde yaşamalıdır ve portal asla bir dönüşümün uydurulduğu yer olmamalıdır.

Her iki konu kademeli planla etkileşir: üç pazara satışan bir ihracatçı 1. kademeyi bu üç pazarın siparişlerde gerçekten kullandığı dillerle açabilir ve katalog dillerini talep geldikçe ekleyebilir. Ticari sitelerde dil çalışması için genel kural — tek sahip, tek kaynak dosya, tek güncelleme yolu — internet pazarlama sayfasında anlatılır ve portal kataloğuna aynı şekilde uygulanır.

Güvenlik ve roller

Bir portal ticari verinize açılan bir kapıdır; bu yüzden tasarım soruları erişim sorularıdır:

• Erişim verilir, asla açık kayıtla alınmaz. Her hesap ekibiniz tarafından bir ERP hesabına karşı oluşturulur; alternatif — onay adımıyla açık kayıt — gürültü davet eder ve kimin müşteri olduğunu bulanıklaştırır.


• Role dayalı izinler. Satın alan limit dâhilinde sipariş kurar ve gönderir; onaylayan serbest bırakır; izleyici yalnızca belge okur. Role göre limitler ticari koşulların parçasıdır, teknik bir sonradan ek değildir — müşteri kuruluşunuzda kimin onları bağlayabileceğini kodlarlar.


• Hesap izolasyonu. Bu ürün sınıfındaki en ciddi hata kipi bir bayinin başka bir bayinin fiyatlarını ya da belgelerini görmesidir. Hesap bazlı veri görünürlüğü açıkça test edilmeli ve aşağıdaki kabul testlerinden biridir.


• İz kaydı. Siparişi kim verdi, kim onayladı, fiyatı kim ne zaman değiştirdi — birilerini okumaya ikna edilmesi gereken günlük dosyaları değil, veri olarak tutulur. Ticaretteki uyuşmazlıklar hatıradan çok bu iz ile çözülür.


• Kimlik ve tek giriş (SSO). Büyük bayiler için kendi dizinlerine SSO sık bir taleptir; erken değil geç kapsamayın — çoğu hesap, genel müdürlük federasyon isteyene kadar davet ve parola ile sorunsuz çalışır.


• Veri koruma. Portaldaki müşteri verisi, şirketin müşteri kayıtları için zaten taşıdığı yükümlülüklerin altındadır; Türkiye operasyonları için KVKK, Avrupa müşterileri için GDPR çerçevesidir — bu konu yazılım outsourcing sayfasında bir geliştirme ortağıyla çalış bağlamında ayrıntılı ele alınır.

Yapım mı, platform mu?

Seçim soyut anlamda özel mi paketli mi değil; aslında hangi katmanı satın aldığınızla ilgilidir.

Tablo B: yol | ne kazandırır | ne yüklenir | ne zaman uyar

İhracatçıların çoğu ilk seferde orta yolu seçer ve kaçınılması gereken hata onu ucuz sanmaktır: bir konnektör bakımlı bir üründür ve maliyeti tekrar eder. Bu sorunun karar çerçevesi — yapılandırma, satın alma ya da yapım — özel mi paketli mi ERP sayfasında uzunca ele alınır; bu sayfanın eklediği portal'a özgü test şudur: ne seçerseniz seçin, hesap başına fiyat listesi ve ERP'ye giren sipariş kanıtlanabilir biçimde doğru olmalı ve seçtiğiniz yol bunu en düşük tekrar eden maliyetle kanıtlanabilir kılan yol olmalıdır.

Kademeli devreye alma ve kabul testleri

Bir portal açılışı, "çalışıyor" demenin "demo çalıştı" anlamına geldiği yerde sessizce başarısız olur. Her kademe, gerçek hesaplarla ve gerçek veriyle yapılan yazılı kabul testleri taşımalıdır:

1. Hesap bazlı katalog görünürlüğü. İki farklı bayi olarak giriş yapın; her biri tam olarak kendi ürün setini görür ve diğerinin izi yoktur. Varsayılmaz, bilerek test edilir.


2. Fiyat doğruluğu. Birkaç hesap ve makale örneklemünde portal fiyatı ERP fiyatına eşittir — arkasındaki kurallarla birlikte (fiyat grubu, kademe, anlaşma). Ticari ilişkiyi koruyan test budur; portaldaki yanlış fiyat teklifteki yanlış fiyattan kötüdür, çünkü müşteri onu geçerli anlaşma olarak görmüştür.


3. Sipariş bütünlüğü. Portaldan verilen sipariş tam olarak bir ERP belgesine dönüşür; doğru makaleler, miktarlar, birimler ve fiyatlarla — ve mutabakat raporu bunu gösterir. Hata yolunu da test edin: bir kural tarafından engellenen sipariş sessizce düşmek yerine bunu açıkça söylemelidir.


4. Durum ve belgeler. ERP'de kayıtlı bir fatura ve sevkiyat, anlaşılan senkron penceresi içinde doğru hesabın portal görünümünde doğru durumla görünür.


5. Koşullar ve limitler. Hesap başına kredi ve ödeme koşulları doğru görüntülenir; kurallar bir siparişi engellemeyi ya da işaretlemeyi söylüyorsa engellenir ya da işaretlenir — rahat ortada değil, sınırda test edilir.


6. Günlük alışkanlıklar. Tekrar sipariş, makale numarasıyla hızlı sipariş ve arama — demo katalogla değil, iki gerçek bayi ürün listesiyle. Benimseme bu üç yolda yaşar ve düzgün test etmek yapım maliyetinin bir kısmına mal olur.

Sıkça Sorulan Sorular

Önce ERP'miz mi olmalı?

Yeni bir ERP gerekmiyor — ama ana verinin güvenilir bir yerde olması gerekiyor: hesaplar, ürünler, fiyat listeleri ve koşullar. Bunlar yalnızca tablolardaysa portal hataları hesap başına otomatikleştirir; bu telefonda kalmaktan kötüdür. Durum buysa dürüst sıra önce veriyi düzene sokmaktır (çoğu zaman kullanılmayan mevcut bir ERP'de), portal sonra; bu kararı ERP tarafından ticaret şirketleri için Odoo sayfasında bulabilirsiniz.

Müşterilerin kendi fiyat listeleri olabilir mi?

Evet — hesap bazlı fiyatlandırma bu ürün sınıfının çekirdeğidir, ekstra değil: fiyat grupları, kademeli fiyat ya da bireysel anlaşmalar, hepsi ERP'de tutulur ve hesap bazında gösterilir. Israr edilmesi gereken kural şu: portal hiçbir şeyi kendisi fiyatlamaz; ERP'de tutulanı gösterir ve bir bayinin gördüğü her fiyat ekibinizin yaptığı bir anlaşmaya kadar izlenebilir.

Siparişler nasıl onaylanır?

Genellikle iki katman. Müşterinizin kuruluşunun içinde onay onlara aittir: satın alan teklif eder, onaylayan serbest bırakır, istenirse limitler dâhilinde — portal 3. kademede bu rolleri taşıyabilir. Kendi kuruluşunuzun içinde sipariş ERP'ye girer ve normal sipariş akışınızı izler; portal satış masanızın kontrollerinin yerini almaz, etraflarındaki yeniden girişi ve telefonu ortadan kaldırır.

Portal birden fazla dilde çalışabilir mi?

Evet, çalışmalı — ama kademe başına kapsamı kararlaştırın. Katalog çevirileri, hesap başına dil tercihi ve çevrilmiş belgeler üç ayrı iştir; 1. kademeyi aktif pazarlarınızın siparişlerde kullandığı dillerle açın, kalanı gerçek taleple ekleyin. Yönetim noktaları — çeviride tek sahip, tek güncelleme yolu — yukarıdaki çok dilli bölümde.

Verinin sahibi kim?

Sizsiniz — hesaplar, fiyatlar, siparişler, belgeler ve geçmiş şirketin kayıtları olarak ERP'de kalır. Bunu portalı inşa edecek şirketle sözleşmede söylemek yerindedir: barındırma erişimi, kaynak kodu ya da yapılandırma ve çıkışta verinin dışa aktarımı, hepsi adıyla. Fikri mülkiyet ve çıkış koşulları outsourcing sayfasında daha geniş geliştirme sözleşmesi bağlamında ele alınır.

Bayiler nasıl devreye alınır?

En çok sipariş veren hesaplarla başlayın, onları kişisel olarak davet edin ve ilk mesajda üç şey verin: giriş bilgileri, ekranda görünen fiyat listeleri ve aranacak bir kişi. Sonra önemli olan benimseme sinyalini izleyin — oturum sayısı değil, tekrar sipariş hacminin portal üzerinden gelen payı. Paralel çalışma (portaldan sipariş, sonra telefonla teyit) haftalarca normaldir; portalın fiyat ve belgelerde kanıtlanabilir biçimde doğru olduğu anda biter; yukarıdaki kabul testleri tam bunun içindir.

Kaynaklar ve standartlar

• Burada tarif edilen tipik özellik kümesi (hesaplar, hesap bazlı fiyat listeleri, tekrar sipariş, faturalar ve iade faturaları, hesap bazlı görünürlük, limitli roller, vadeli koşullar, ödeme geçitleri) genel olarak B2B sipariş portalı için tedarikçi tanımlı yetenek listelerini izler; bu sayfada hiçbir performans sonucu, maliyet ya da takvim iddia edilmez.
• Kurulum desenleri (ERP'nin yerel portalı; Shopify gibi bir ticaret platformunun middleware ya da konnektörlerle ERP'ye senkronu) tekrar eden iki yol olarak tarif edilir; hiçbir platform sağlayıcısıyla ortaklık iddia edilmez.
• Süreç ve yönetişim ifadeleri bu sitenin sayfalarını izler: özel mi paketli mi ERP, tedarikçi RFP listesi, ticaret şirketleri için Odoo ve Türkiye'den yazılım outsourcing (veri koruma yükümlülükleri, fikri mülkiyet ve çıkış koşulları, pilot tasarımı).
• Bu sayfada müşteri örneği, portal bütçesi ya da proje süresi belirtilmez; kapsam, kademeler ve ticari koşullar proje bazında teklifle belirlenir.

İlgili sayfalar

Yazılım geliştirme · Özel mi paketli mi ERP · Tedarikçi RFP listesi · Ticaret şirketleri için Odoo · İnternet pazarlama · Teklif isteyin