B2B E-Ticaret Sitesi Kurma Rehberi

Telefon, WhatsApp, e-posta ve Excel ile alınan bayi siparişleri düşük hacimde yönetilebilir görünür. Sipariş sayısı, ürün çeşidi ve müşteri koşulları büyüdüğünde ise hangi fiyatın verildiği, limitin ne kadar kaldığı, teklifin hangi sürümünün kabul edildiği ve stok sözünün kime ait olduğu belirsizleşir. Aynı sipariş farklı kanallardan iki kez girilebilir; finans, satış ve depo ekipleri farklı rakamlarla çalışabilir.

B2B e-ticaret sitesi kurma projesi bu nedenle yalnızca 7/24 açık bir sipariş ekranı değildir. Başarılı bir kurgu; şirket ve kullanıcı yetkilerini, müşteriye özel kataloğu, fiyat ve iskonto önceliğini, cari riski, teklif ile sipariş onayını, stok ve sevkiyatı, e-belgeleri ve entegrasyonları aynı veri akışında yönetir. B2C mağazaya giriş sonrası fiyat gösterme özelliği eklemek, bu operasyon omurgasının yerini tutmaz.

Bu rehber; hangi işletmenin portala ihtiyaç duyduğunu, fiyat motorunun nasıl tanımlanacağını, eşzamanlı siparişlerde cari limitin nasıl korunacağını, RFQ ve PO akışlarının nasıl tasarlanacağını, hangi verinin hangi sistemde ana kaynak olacağını ve hazır paket ile özel proje arasında nasıl karar verileceğini açıklar. Hukuki, mali ve vergisel uygulamalar işlem, taraf ve güncel mevzuata göre uzman kontrolü gerektirir.

B2B E-Ticaret Sitesi Nedir?

B2B, “business to business” ifadesinin kısaltmasıdır ve işletmeden işletmeye ticareti anlatır. B2B e-ticaret sitesi; bir şirketin bayilerine, distribütörlerine veya kurumsal müşterilerine hesap, katalog, fiyat, ödeme, teklif ve sipariş koşullarıyla dijital satış yaptığı portaldır. Bayi portalı ve toptan satış sitesi bu modelin farklı kullanım adlarıdır.

Gerçek bir B2B yapıda alıcı tek kişi değildir. Şirket hesabı altında şubeler, teslimat noktaları, satın almacılar, onaylayıcılar ve finans kullanıcıları bulunabilir. Her kullanıcı yalnız yetkili olduğu şirketin ürünlerini, fiyatlarını, tekliflerini, faturalarını ve cari durumunu görür. Self-servis sipariş kolaylığı kadar yetki ve ticari kural tutarlılığı da önemlidir.

B2B E-Ticaret ile B2C E-Ticaret Arasındaki Fark Nedir?

B2C, işletmeden son tüketiciye standartlaştırılmış satış akışıdır; B2B ise şirket hesabına bağlı, sözleşmeli ve çoğu zaman onaylı satın alma sürecidir. B2B'yi yalnız daha yüksek adetli B2C olarak görmek yanlıştır. Alıcı hiyerarşisi, müşteri bazlı fiyat, vade, cari risk, teklif, PO ve entegrasyon gereksinimleri iş modelini kökten değiştirir.

Aşağıdaki tablo iki model arasındaki operasyon farkını özetler.

Başlık	B2C	B2B
Alıcı tipi	Gerçek kişi tüketici	Şirket, bayi veya kurum
Hesap yapısı	Genellikle tek kullanıcı	Şirket, şube ve çok kullanıcı
Fiyat	Herkese açık standart fiyat	Grup, cari, sözleşme veya teklif fiyatı
İskonto	Kampanya ve kupon ağırlıklı	Sözleşmeli, sıralı ve hacim bazlı
Sipariş miktarı	Az adet	MOQ, koli, palet ve sipariş katı
Ödeme	Anında kart/havale	Vade, açık hesap, kapora, kısmi ödeme
Cari limit	Genellikle yok	Risk politikasının parçası

B2B tasarımında “sepet çalışıyor mu?” sorusu yetmez; doğru kullanıcıya doğru fiyatın, doğru limit ve belge koşuluyla sunulup sunulmadığı test edilmelidir.

Hangi İşletmeler B2B E-Ticaret Sitesine İhtiyaç Duyar?

Üretici, ithalatçı, toptancı, distribütör, bayi ağı yöneten marka ve kurumsal müşterilere tekrarlayan satış yapan işletmeler B2B portalından yararlanabilir. İhtiyaç, yalnız bayi sayısıyla ölçülmez. Fiyat, vade, katalog, onay ve entegrasyon karmaşıklığı arttıkça dijital sipariş kanalının önceliği de artar. Tekrarlayan süreç yükü de belirleyicidir.

Temsili karar tablosu, mevcut çalışma biçimini proje önceliğine çevirir.

Mevcut durum	İşaret	Portal önceliği	İlk çözülmesi gereken konu
Telefon ve mesajla sipariş	Yanlış ürün ve tekrar giriş	Yüksek	Ürün koduyla hızlı sipariş
Az bayi, tek fiyat	Düşük operasyon yükü	Düşük/orta	Basit self-servis katalog
Çok müşteri grubu	Fiyat uyuşmazlığı	Yüksek	Fiyat öncelik politikası
Sık tekrarlanan sipariş	Manuel liste kopyalama	Yüksek	Şablon ve tekrar sipariş
Vadeli satış	Limit ve tahsilat riski	Yüksek	Cari risk ve onay
ERP ana kaynak	Çift veri girişi	Yüksek	Veri sahipliği ve entegrasyon

Tek seferlik, az ürünlü ve her alıcıya aynı peşin koşulla satış yapan işletmede kapsamlı portal gereğinden ağır olabilir. Önce süreç yükünü ve yatırımın çözeceği ölçülebilir sorunu tanımlamak gerekir.

B2B İş Modeli Nasıl Seçilir?

B2B iş modeli; satıcının tedarik zincirindeki konumu, alıcının kimliği ve siparişin kim tarafından onaylandığına göre seçilir. Üreticiden bayiye, toptancıdan perakendeciye, distribütörden alt bayiye, kurumsal satın alma, franchise/şube, B2B2C ve hibrit B2B+B2C modellerinin fiyat ve yetki ihtiyaçları aynı değildir.

Model seçimini alıcı ve akışla birlikte değerlendirmek daha güvenlidir.

Model	Alıcı	Fiyat yapısı	Sipariş akışı	Temel ihtiyaç
Üreticiden bayiye	Yetkili satış noktası	Bayi grubu ve sözleşme	Sipariş, limit, sevk	Bölge ve kanal kuralı
Toptancıdan perakendeciye	Mağaza	Hacim ve koli fiyatı	Hızlı toplu sipariş	MOQ ve stok görünümü
Distribütörden alt bayiye	Alt bayi	Kademeli iskonto	Onay ve rota sevki	Hiyerarşi ve plasiyer
Kurumsal satın alma	Şirket/kurum	Sözleşme/teklif	RFQ, PO ve onay	Bütçe, rol ve belge
Franchise/şube	Bağlı işletme	Merkez politikası	Şube talebi ve merkez onayı	Katalog standardı
B2B2C	İş ortağı üzerinden son alıcı	Kanal ve komisyon kuralı	Ortak sipariş/teslim	Sorumluluk ayrımı
Hibrit B2B+B2C	Şirket ve tüketici	Ayrı fiyat/koşul	Aynı vitrin, farklı checkout	Veri ve deneyim izolasyonu

Aynı sitede B2B ve B2C satış yapılabilir; ancak fiyat, vergi sunumu, ödeme, sözleşme, iade ve erişim politikaları alıcı tipine göre açıkça ayrılmalıdır.

B2B Projesine Başlamadan Önce Hangi Süreçler Haritalanmalıdır?

İlk iş ekran tasarlamak değil, mevcut siparişten tahsilata akışı görünür kılmaktır. Kim fiyat belirliyor, kim limit açıyor, hangi sistem stok kaynağı, siparişi kim onaylıyor ve hangi belge ne zaman oluşuyor soruları yazılı yanıtlanmadan geliştirilen portal mevcut karmaşayı dijitale taşır. İstisnalar özellikle görünür kılınmalıdır.

Keşif çalışmasında en az şu sorular cevaplanmalıdır:

1. Sipariş bugün hangi kanallardan geliyor?
2. Aynı siparişin iki kez girilmesi nasıl önleniyor?
3. Müşteri segmentini kim ve hangi veriye göre belirliyor?
4. Ürün görünürlüğünü hangi ekip yönetiyor?
5. Liste, grup, cari ve sözleşme fiyatlarını hangi sistem tutuyor?
6. Fiyat kuralları çakıştığında hangi yazılı politika uygulanıyor?
7. İskonto yetkileri role ve tutara göre nasıl sınırlandırılıyor?
8. Minimum marj hangi maliyet verisiyle kontrol ediliyor?
9. Kur kaynağı ve güncelleme zamanı nedir?
10. KDV dahil/haric gösterim hangi müşteri için nasıl yapılıyor?
11. Cari limit hangi risk kalemlerini içeriyor?
12. Vadesi geçmiş borçta sipariş davranışı nedir?
13. Geçici limit aşımını kim onaylayabilir?
14. Teklifin sürümünü ve geçerliliğini kim yönetir?
15. Satın alma siparişi numarası zorunlu mu?
16. Müşteri içi onay akışı portala mı, harici sisteme mi aittir?
17. Stokta ana kaynak ve satılabilir stok formülü nedir?
18. Kısmi sevkiyat ile backorder hangi koşullarda açıktır?
19. İade/RMA kararını kim verir?
20. Sipariş, irsaliye ve fatura numaraları nasıl ilişkilendirilir?
21. ERP kesildiğinde portal sipariş kabul edecek mi?
22. Entegrasyon hatası için alarm ve yeniden işleme sahibi kimdir?
23. Hangi kişisel ve ticari veriler hangi süreyle saklanır?
24. Pilot başarı ölçütü ve canlıya geçmeme koşulu nedir?

Süreç sahibi ile karar sahibini ayrı yazmak önemlidir. Satış fiyat kuralını önerebilir; finans limiti onaylayabilir; bilgi teknolojileri uygulayabilir. Yetki belirsizliği teknik sorundan önce yönetişim sorunu üretir.

Açık Katalog mu, Kapalı Bayi Portalı mı, Hibrit Model mi?

Açık katalog ürün bilgisini ve bazen fiyatı herkese gösterir; kapalı portal ürün, fiyat ve hesap verisini yalnız doğrulanmış kullanıcılara açar; hibrit model ise halka açık içerikle giriş sonrası ticari koşulları ayırır. Seçim, SEO hedefi, fiyat gizliliği, başvuru süreci ve müşteri deneyimi birlikte değerlendirilerek yapılmalıdır.

Fiyatı gizlemek tek başına B2B stratejisi değildir; aşağıdaki farklar kararın kapsamını gösterir.

Kriter	Açık katalog	Kapalı portal	Hibrit model
Ürün görünürlüğü	Herkese açık	Girişe bağlı	Temel bilgi açık, özel ürün kapalı
Fiyat görünürlüğü	Açık	Müşteriye özel	Liste/“teklif iste” açık, özel fiyat kapalı
SEO	Güçlü indekslenebilir katman	Sınırlı	Public içerikle dengeli
Gizlilik	Düşük	Yüksek kontrol gerektirir	Alan bazlı politika gerekir
Başvuru	İsteğe bağlı	Zorunlu doğrulama	Ticari alanlar için zorunlu
Deneyim	Hızlı keşif	Giriş sürtünmesi	Keşif ve kişiselleştirme dengesi
Operasyon	Basit	Yetki ve hesap karmaşık	İki katmanın tutarlılığı kritik

Teknik ürünlerde halka açık özellik ve dokümanlar talep yaratabilir; müşteriye özel net fiyat, cari, teklif ve belge verileri ise oturum ve yetki kontrolü arkasında tutulmalıdır.

Bayi Başvurusu ve Hesap Aktivasyonu Nasıl Tasarlanır?

Bayi başvurusu yalnız kullanıcı adı oluşturma formu değildir. Şirket unvanı, vergi bilgisi, yetkili kişi, iletişim doğrulaması, bölge ve satış kanalı, sözleşme durumu, ödeme koşulu ve gerekiyorsa risk değerlendirmesi kontrol edilmelidir. Aktivasyon, otomatik skorun tek başına verdiği karar yerine yetkili insan onayıyla tamamlanmalıdır.

1. Başvuru sahibinden yalnız gerekli şirket ve yetkili bilgilerini alın.
2. E-posta ve telefon doğrulamasıyla sahte hesap riskini azaltın.
3. Unvan, vergi ve yetki belgelerini sorumlu ekipte inceleyin.
4. Bayi grubu, bölge, katalog ve ödeme koşulu atayın.
5. Eksik belgeyi açık mesajla isteyin; ret gerekçesini kaydedin.
6. Aktivasyon sonrasında ilk giriş, MFA ve şifre adımlarını yönetin.
7. Yeniden başvuru ve çalışan değişikliği sürecini tanımlayın.

Bot koruması, hız sınırı ve yinelenen şirket kaydı kontrolü başvuru kalitesini artırır. Ticari elektronik ileti izni, portal hizmeti için gerekli bildirimlerden ayrı amaç ve hukuki çerçevede değerlendirilmelidir.

Şirket, Şube ve Kullanıcı Hesapları Nasıl Modellenir?

Hesap modeli ana şirketi, bağlı şubeleri veya lokasyonları, fatura ve teslimat adreslerini, vergi bilgisini, maliyet merkezlerini ve gerçek kişi kullanıcıları ayrı varlıklar olarak tutmalıdır. Bir kullanıcının birden çok lokasyona erişmesi mümkün olabilir; ancak yetki her istek ve her belge üzerinde sunucu tarafında denetlenmelidir.

Çalışan ayrıldığında erişim derhal kapatılmalı, açık oturumlar sonlandırılmalı ve sahip olduğu bekleyen görevler vekile aktarılmalıdır. Kullanıcı silmek yerine işlem geçmişi korunarak hesabı pasifleştirmek denetim izini korur.

B2B Kullanıcı Rolleri ve Yetkileri Nasıl Belirlenir?

Rol tabanlı erişim kontrolü, yani RBAC, kullanıcıya tek tek rastgele izin vermek yerine görevine uygun yetki kümesi atar. En az ayrıcalık ilkesi her kullanıcının yalnız işi için gerekli işlemi yapmasını; görevlerin ayrılığı ise fiyat verme, limit açma ve onaylama gibi riskli yetkilerin tek kişide toplanmamasını sağlar.

Temsili rol-yetki matrisi her işletmenin iç kontrol politikasına göre uyarlanmalıdır.

Rol	Fiyat	Sipariş	Teklif	Onay	Cari/fatura	Kullanıcı/adres
Şirket yöneticisi	Görür	Verir	İster	Politikaya göre	Görür	Yönetir
Satın almacı	Görür	Taslak/verir	İster	Yok	Sınırlı	Yetkili adres
Onaylayıcı	Görür	Görür	Görür	Yetki eşiğinde	Sınırlı	Yok
Finans kullanıcısı	Gerekirse	Blokaj görür	Görür	Limit istisnası	Görür/indirir	Yok
Salt okunur	Politikaya göre	Yok	Görür	Yok	Görür	Yok
Plasiyer	Atanmış hesap	Müşteri adına	Hazırlar	Sınırlı	Sınırlı	Yok
Satıcı operasyonu	Yetkili kapsam	İşler	Revize eder	Operasyon adımı	Belge durumu	Yok

“Yönetici” rolünü herkese vermek kolay görünür fakat şirketler arası veri sızıntısı ve yetkisiz limit aşımı riskini büyütür. Yetki değişiklikleri onaylı, zaman damgalı ve geri izlenebilir olmalıdır.

Müşteriye Özel Ürün Kataloğu Nasıl Oluşturulur?

Müşteri bazlı katalog, belirli şirket veya müşteri grubunun görebileceği ürün, marka, kategori, teknik belge ve satış koşulu kümesidir. Ürün dahil/haric kuralları; bölge, kanal, sözleşme, mevzuat, yetkili servis durumu veya ticari anlaşmaya göre tanımlanabilir. Katalog sürümü ve geçerlilik tarihi kayıt altında tutulmalıdır.

• Genel katalogdan başlayan açık bir varsayılan politika seçin.
• Ürün, kategori ve marka istisnalarını aynı öncelik modelinde tanımlayın.
• Regüle veya sözleşmeli ürünlerde belge ve rol kontrolü uygulayın.
• Teknik PDF ve sertifikaların da katalog erişimine uyduğunu test edin.
• Katalog değişikliğini taslak, onay ve yayın sürümleriyle yönetin.

Yanlış katalog ataması, yalnız ürün bulunabilirliği hatası değildir; özel ürün, fiyat veya dokümanın yetkisiz müşteriye açılması ticari veri ihlaline dönüşebilir. Testler hem arayüzü hem doğrudan API erişimini kapsamalıdır.

Bayiye Özel Fiyatlandırma Nasıl Çalışır?

Bayiye özel fiyatlandırma; liste fiyatı üzerine tek oran indirim yazmak yerine müşteri grubu, cari hesap, sözleşme, ürün-müşteri matrisi, hacim, teklif, para birimi ve geçerlilik tarihi kurallarını değerlendirir. Fiyat motoru, belirli bir kullanıcı ve miktar için hangi kuralın neden uygulandığını açıklayabilmelidir.

Fiyat kaynağı ERP ise portalın bağımsız kopyası değil, tanımlı senkron ve hata politikası olmalıdır. Her satırda kaynak fiyat, uygulanan kural, iskonto, vergi sunumu, kur zamanı ve nihai fiyat denetim kaydına bağlanmalıdır. Genel fiyat, maliyet ve kâr marjı çerçevesi ayrı değerlendirilirken bu projede müşteri bazlı öncelik derinleştirilir.

Fiyat Kurallarının Öncelik Sırası Nasıl Belirlenir?

Fiyat önceliği, aynı ürün için birden fazla kural geçerli olduğunda hangi fiyatın seçileceğini ve hangi indirimlerin üst üste uygulanacağını belirleyen yazılı politikadır. Evrensel tek sıra yoktur. İşletme; sözleşme, cari özel fiyat, grup fiyatı, hacim, kampanya, kupon, teklif ve temsilci indirimini açık bir karar tablosuyla yönetmelidir.

Aşağıdaki örnek sıra yalnız politika tasarlama yöntemini gösterir; her şirket kendi ticari sözleşmeleriyle onaylamalıdır.

Kural türü	Temsili örnek	Öncelik kararı	Çakışma riski	Kontrol
Teklif fiyatı	Sürüm 3, 15 Temmuz'a kadar	Yalnız geçerli ve kabul edilebilir teklifte	Kur ve stok değişimi	Kabul anında yeniden doğrula
Sözleşme fiyatı	Belirli SKU için sabit	Kampanya hariç veya dahil politikası yazılı	İndirim yığılması	Sözleşme bayrağı
Cari özel fiyat	Şirkete özel net fiyat	Grup fiyatından önce olabilir	Hacim indirimiyle çift düşüş	Birleşebilirlik alanı
Müşteri grubu	Yetkili bayi fiyat listesi	Varsayılan B2B tabanı	Yanlış grup ataması	Atama onayı
Hacim fiyatı	100+ adette kademe	Seçilen taban fiyatla ilişkisi tanımlı	Varyantların yanlış toplanması	Miktar kapsamı
Kampanya/kupon	Dönemsel sepet indirimi	Sözleşmeli üründe engellenebilir	Marj tabanı aşımı	Hariç ürün ve tavan
Temsilci override	Ek yüzde 2	Rol ve marj eşiğinde	Yetkisiz fiyat düşüşü	Onay ve gerekçe

Sözleşme fiyatı ile kampanya, cari özel fiyat ile hacim indirimi, grup fiyatı ile kupon ve teklif fiyatı ile kur değişimi için ayrı karar yazılmalıdır. Fiyat motorunun “en düşük fiyatı seç” yaklaşımı sözleşme ve marj politikasını ihlal edebilir.

İskonto Türleri Nelerdir?

B2B iskonto yönetimi tek oran, müşteri grubu, ürün/marka/kategori, hacim, dönemsel kampanya, sepet, ödeme yöntemi, erken ödeme ve teklif bazlı indirimleri kapsar. Sıralı iskonto birden fazla oranın kalan tutara ardışık uygulanmasıdır; kademeli fiyat ise miktar basamağına göre farklı birim fiyat seçilmesidir.

• Tek oran: Seçilen matraha bir defa uygulanır.
• Sıralı iskonto: Her oran bir önceki indirimli tutara uygulanır.
• Grup iskontosu: Standart, yetkili veya zincir müşteri segmentine bağlıdır.
• Ürün iskontosu: SKU, marka ya da kategori kapsamıyla sınırlıdır.
• Hacim iskontosu: Miktar eşiği veya toplam dönem hacmiyle tetiklenir.
• Ödeme iskontosu: Peşin veya erken ödeme koşuluna bağlıdır.
• Teklif indirimi: Belirli teklif sürümü ve geçerlilik tarihiyle sınırlıdır.

Kampanyaların hangi kuralla birleşebileceği ayrıca tanımlanmalıdır. Genel kampanya tasarımında iskonto yığılması ve kârlılık kontrolleri tamamlayıcı bir çerçeve sunar.

Sıralı İskonto Nasıl Hesaplanır?

Sıralı iskonto oranları toplanmaz; her indirim kalan tutar üzerinden hesaplanır. Temsili olarak 1.000 TL fiyat önce yüzde 10 indirimle 900 TL'ye, ardından yüzde 5 indirimle 855 TL'ye iner. Toplam indirim 145 TL, efektif oran yüzde 14,5'tir; yüzde 15 değildir.

Hesap adımlarını tabloyla izlemek, ERP ve portal farkını yakalamayı kolaylaştırır.

İskonto sırası, vergi matrahı, KDV dahil/haric sunum ve satır/toplam yuvarlaması mali müşavirle doğrulanmalıdır. Portal ile ERP aynı hassasiyet, yuvarlama yönü ve sıra kuralını kullanmazsa sipariş ile fatura arasında kuruş veya daha büyük fark oluşabilir.

İskonto Uygulanırken Kâr Marjı Nasıl Korunur?

Marj koruması, her indirimden sonra güncel maliyet ile satış fiyatını karşılaştıran bir taban kuralı gerektirir. Minimum marj, rol bazlı indirim tavanı, kampanya birleşme yasağı, kur ve maliyet güncelliği, temsilci override sınırı ve istisna onayı birlikte çalışmalıdır. Yalnız “maksimum yüzde indirim” yeterli değildir.

• Maliyetin hangi sistemden ve hangi tarihte geldiğini gösterin.
• Ürün, kategori ve müşteri segmentine göre marj tabanı tanımlayın.
• Temsilci yetkisini oran ve toplam tutarla sınırlandırın.
• Taban altı fiyatı engelleyin veya gerekçeli onaya gönderin.
• İndirim yığılmasını fiyat simülasyonuyla yayından önce test edin.
• Override oranını ve brüt marjı düzenli raporlayın.

Marj kontrolü yalnız sipariş anında değil teklif revizyonunda, kur değişiminde ve tekrar siparişte yeniden çalışmalıdır. Yetkili onayı, maliyet verisinin eski olmasını otomatik olarak güvenli hale getirmez.

Hacim Fiyatlandırması, Minimum Sipariş ve Sipariş Katı Nedir?

Hacim fiyatlandırması miktar arttıkça birim fiyat basamağı seçer. Minimum sipariş miktarı, yani MOQ, alınabilecek en düşük adedi; sipariş katı ise miktarın hangi artışlarla girilebileceğini belirler. Minimum sepet tutarı, maksimum miktar, koli/palet kuralı ve ölçü birimi dönüşümü farklı kontrollerdir. Her biri ayrı bir iş kuralıdır.

Kuralların farkını aynı ürün üzerinde görmek yanlış uygulamayı önler.

Kurallar ürün varyantı, müşteri ve depo bazında değişebilir. Ürün sayfası, hızlı sipariş, CSV içe aktarma ve API aynı kural servisini kullanmalı; kullanıcıya geçerli miktarı ve düzeltme önerisini açıkça göstermelidir.

Döviz, Kur, KDV ve Yuvarlama Kuralları Nasıl Yönetilir?

Dövizli B2B fiyatında fiyat para birimi, kur kaynağı, güncelleme zamanı, alış/satış kuru seçimi, kur sabitleme süresi, teklif geçerliliği ve yuvarlama hassasiyeti birlikte tanımlanmalıdır. KDV dahil/haric gösterim ve sipariş-fatura tutarlılığı işlem türüne göre güncel hukuk ve mali müşavir kontrolü gerektirir.

• Kur kaynağını ve başarısız güncellemede kullanılacak son geçerli değeri yazın.
• Sepete ekleme, teklif verme ve kabul anındaki kur davranışını ayırın.
• Kur sabitleniyorsa başlangıç, bitiş ve istisna koşulunu gösterin.
• Satır, vergi ve toplam yuvarlamasını ERP ile aynılaştırın.
• Fiyatın KDV dahil mi hariç mi olduğunu kullanıcıya açıkça belirtin.

Kur servisi kesildiğinde sessizce sıfır, eski veya varsayımsal kurla sipariş oluşturulmamalıdır. Portal ya son doğrulanmış kuru zamanı ile gösterir ya da ilgili işlemi güvenli biçimde bekletir.

Cari Hesap ve Cari Limit Nedir?

Cari hesap, satıcı ile müşteri arasındaki borç, alacak, fatura, tahsilat ve benzeri ticari hareketlerin izlendiği hesaptır. Cari limit veya alış limiti, işletmenin müşteriye tanıdığı ticari risk politikasıdır; banka kredisi değildir. Kredi limiti, risk limiti, vade, teminat ve kullanılabilir limit kavramları yazılı biçimde ayrılmalıdır.

• Kredi/alış limiti: İşletmenin müşteriye tanıdığı üst satış riski çerçevesi.
• Risk limiti: İşletmenin risk hesabında izin verdiği tavan.
• Kullanılabilir limit: Tanımlı limitten politika kapsamındaki risk ve rezervasyonların düşülmesiyle kalan tutar.
• Vade: Borcun hangi tarihte veya koşulda ödeneceği.
• Teminat: İşletme politikasında riski azaltıcı kabul edilen güvence; otomatik olarak nakit değildir.

Satış ekibi ticari ilişkiyi, finans ekibi risk ve tahsilatı, bilgi teknolojileri ise kuralın güvenilir uygulanmasını yönetir. Limit formülü ERP/muhasebe verisi ve şirket politikasıyla onaylanmadan portala kodlanmamalıdır.

Kullanılabilir Cari Limit Nasıl Hesaplanır?

Kullanılabilir limit için evrensel muhasebe formülü yoktur. Temsili yaklaşım; tanımlı limitten açık faturalar, vadesi geçmiş borç, sevk edilmiş fakat faturalanmamış tutar, onaylı açık sipariş ve geçici rezervasyonları düşmek; kesinleşmiş tahsilat, kabul edilmiş teminat veya alacak notunu şirket politikasına göre eklemektir.

Hayalî endüstriyel sarf işletmesi Atlas Endüstriyel için aşağıdaki örnek yalnız işleyişi öğretir.

Bekleyen teklifin limiti tüketip tüketmeyeceği ayrıca kararlaştırılmalıdır; çoğu yapıda teklif sipariş değildir, fakat yüksek değerli ve stok/limit ayıran özel tekliflerde rezervasyon politikası bulunabilir. Tahsilat ve iade, yalnız doğrulandıktan sonra limite yansıtılmalıdır.

Eş Zamanlı Siparişlerde Limit Aşımı Nasıl Önlenir?

İki kullanıcı aynı şirket hesabından aynı anda sipariş verdiğinde, ikisi de eski kullanılabilir limiti görürse toplam risk tavanı aşılabilir. Çözüm; checkout sırasında limit kontrolü ile rezervasyonu tek bölünmez işlem olarak yapmak, yani atomik davranmak; rezervasyona süre koymak ve başarısız işlemde güvenle çözmektir.

1. Kullanıcı siparişi göndermeden önce güncel risk bileşenlerini alın.
2. Sipariş tutarı kadar limiti tek işlem içinde kontrol edip rezerve edin.
3. Başka sipariş aynı anda gelirse güncellenmiş kalan limit üzerinden değerlendirin.
4. Ödeme, onay veya ERP aktarımı başarısız olursa tanımlı koşulda rezervasyonu çözün.
5. Rezervasyon süresi dolduğunda yarış koşuluna karşı tek kez serbest bırakın.
6. Her hareketi sipariş, kullanıcı, zaman ve gerekçeyle denetim kaydına yazın.

ERP gecikmesi varsa portalın kendi rezervasyon defteri ile ERP risk görünümü uzlaştırılmalıdır. Aynı sipariş isteğinin ağ hatası nedeniyle tekrar gönderilmesi ikinci rezervasyon üretmemeli; benzersiz işlem anahtarıyla aynı sonucu döndürmelidir.

Vadesi Geçmiş Borç ve Limit Aşımında Ne Yapılmalıdır?

Vadesi geçmiş borç veya limit aşımı tek bir davranışa mahkûm değildir. İşletme tam blokaj, finans onayı, peşin/kart ödeme, kısmi teminat veya süreli istisna seçeneklerinden birini risk segmentine göre seçebilir. Karar kullanıcıya açık mesajla gösterilmeli; onaylayan kişi, gerekçe ve süre kaydedilmelidir.

Aşağıdaki karar tablosu temsili bir politika taslağıdır.

Otomatik risk önerisi kullanılabilir, fakat ticari sonucu doğrudan ve açıklamasız vermemelidir. Özellikle limit artışı veya müşteri aleyhine blokaj kararında yetkili insan incelemesi ve itiraz kanalı bulunmalıdır.

B2B Ödeme ve Tahsilat Koşulları Nasıl Tasarlanır?

B2B ödeme tasarımı; açık hesap, havale/EFT, kart, kapora, kısmi ödeme, vadeli ödeme ve sipariş öncesi/sonrası tahsilatı şirket hesabı bazında yönetir. Her yöntem her müşteriye açılmamalı; vade, komisyon, başarısız ödeme, sipariş durumu ve cari hareketin ne zaman oluşacağı yazılı kurala bağlanmalıdır.

• Açık hesapta limit, vade ve gecikme politikası checkout öncesinde kontrol edilir.
• Havalede siparişin stok ayırıp ayırmadığı ve bekleme süresi belirlenir.
• Kart tahsilatında ödeme kuruluşu sonucu, sipariş kaydıyla tekilleştirilir.
• Kapora ve kısmi ödeme toplam borç, kalan vade ve iade akışıyla ilişkilendirilir.
• Tahsilat mutabakatı banka, ödeme kuruluşu ve muhasebe kayıtlarıyla yapılır.

Kartla tahsilat için güvenli ödeme akışı ve işyeri hazırlığı ayrıca değerlendirilmelidir; sanal POS başvurusu öncesi site kontrolleri bu adımı tamamlar. Ödeme sonucu belirsizken kullanıcıya ikinci kez ödeme yaptırmak yerine durum sorgulaması yapılmalıdır.

Teklif Talebi (RFQ) ve Teklifli Sipariş Nedir?

RFQ, “request for quotation” yani teklif talebidir. Alıcı; yüksek miktar, özel ürün, proje fiyatı, teslim süresi veya teknik koşul için standart sepet fiyatı yerine satıcıdan teklif ister. Teklifli sipariş, tarafların revizyonlarla netleştirdiği teklifin gerekli kontrollerden sonra siparişe dönüştüğü akıştır. Talep, henüz kesin sipariş değildir.

RFQ sırasında ürün, miktar, teknik şart, teslimat noktası, hedef tarih, ek dosya ve not alınabilir. Satış temsilcisi fiyat ve teslim seçeneği sunar; alıcı revizyon ister veya kabul eder. Teklif kabulü otomatik olarak stok, kur, vergi, fiyat ve teslim sözünü sonsuza kadar sabitlemez; geçerlilik politikası belirler.

B2B Teklif Süreci Hangi Aşamalardan Oluşur?

Teklif süreci, taslaktan siparişe dönüşüme kadar açık durumlarla yönetilmelidir. Her durumda kimin işlem yapabildiği, hangi alanın değiştirilebildiği, hangi bildirimin gönderileceği ve hangi kaydın korunacağı tanımlanır. Serbest metinle “bekliyor” yazmak raporlama ve sorumluluk takibini zorlaştırır. Durumlar geri izlenebilir olmalıdır. İstisnalar da ayrıca belgelenmelidir.

Temsili durum makinesi aşağıdaki gibidir.

Durum geçişleri geriye dönük değiştirilmemeli; düzeltme gerekiyorsa yeni sürüm veya açık bir iptal işlemi oluşturulmalıdır. Bildirim gönderilememesi teklif durumunu sessizce değiştirmemelidir.

Teklif Revizyonu, Geçerlilik Süresi ve Versiyonlama Neden Önemlidir?

Versiyonlama, teklifin her fiyat, ürün, miktar, tarih, teslim koşulu, not ve ek değişikliğini yeni sürüm olarak saklar. Böylece taraflar hangi metni kabul ettiklerini bilir. Eski sürüm silinmez; kim, neyi, ne zaman ve neden değiştirdiği denetim izinde korunur. Kabul kanıtı sürüme bağlanır.

• Her sürüme benzersiz numara ve oluşturma zamanı verin.
• Değişen alanları önceki sürümle karşılaştırılabilir gösterin.
• Ek dosyaları zararlı içerik ve yetki açısından kontrol edin.
• Geçerlilik bitince kabul düğmesini kapatın veya yenileme isteyin.
• Kabul anında stok, fiyat, kur, vergi, limit ve teslim tarihini yeniden doğrulayın.

Teklifin PDF çıktısı ile sistem kaydı aynı sürüme bağlı olmalıdır. E-postadaki eski bağlantının yeni teklifi kabul etmesi, fiyat ve sözleşme uyuşmazlığına yol açabilir.

Teklif, Proforma Fatura, Satın Alma Siparişi ve Kesin Sipariş Arasındaki Fark Nedir?

Teklif satıcının ticari koşul önerisi; proforma fatura çoğu kullanımda işlem öncesi bilgi amaçlı belge; PO, yani purchase order veya satın alma siparişi, alıcının kendi satın alma kaydı; kesin sipariş ise portalda sipariş yaşam döngüsünü başlatan kayıttır. Hukuki bağlayıcılık taraf, metin ve olaya göre uzman incelemesi ister.

Belgeleri aynı şey kabul etmek stok, limit ve fatura hatası üretir.

“Kabul edildi” durumunun ticari ve hukuki sonucu sözleşmeyle uyumlu tasarlanmalıdır. Portal metni, e-posta, PO ve ERP siparişi arasında numara ve sürüm bağı kurulmalıdır.

Sipariş Onay Akışı Nasıl Kurulur?

Sipariş onay akışı; tutar eşiği, ürün grubu, bütçe, maliyet merkezi, teslimat adresi, yeni kullanıcı, limit aşımı veya sözleşme dışı koşula göre siparişi yetkili role yönlendirir. Tek ve çok seviyeli onay, vekâlet, süre aşımı, eskalasyon, ret gerekçesi ve bildirim kuralları birlikte tasarlanmalıdır.

1. Her kural için tetikleyici, onaylayan rol ve sıralamayı tanımlayın.
2. Aynı sipariş birden çok kurala uyarsa birleşme davranışını belirleyin.
3. Onaylayıcının kendi oluşturduğu siparişi onaylamasını sınırlayın.
4. İzin ve ayrılık durumunda süreli vekâlet kullanın.
5. Süre aşımında hatırlatma ve bir üst role eskalasyon uygulayın.
6. Ret gerekçesini zorunlu, değişiklikleri yeni sürüm olarak kaydedin.

Onay sırasında fiyat, stok ve limit değişmişse eski sonuçla devam edilmemelidir. Yeniden doğrulama, siparişi tekrar onaya gönderecek değişiklik eşiğiyle birlikte tanımlanmalıdır.

Hızlı Sipariş ve Tekrar Sipariş Deneyimi Nasıl Olmalıdır?

B2B hızlı sipariş, kullanıcıların ürün sayfalarını tek tek gezmeden SKU, üretici kodu veya barkodla çok satırlı sipariş oluşturmasını sağlar. CSV yükleme, kayıtlı liste, favori, geçmiş siparişi tekrarlama ve sipariş şablonu sık alımı hızlandırır; fakat her satır güncel fiyat, stok ve miktar kuralıyla yeniden doğrulanmalıdır.

• Çok satırlı alanda kod ve miktar yapıştırmayı destekleyin.
• CSV şablonunu sürümleyin ve hatalı satırı numarasıyla gösterin.
• Geçersiz MOQ veya sipariş katı için düzeltme önerin.
• Geçmiş siparişte artık satılmayan ürünü açıkça işaretleyin.
• Mobilde büyük listeyi ürün kodu odaklı ve hızlı tutun.

Tekrar sipariş “eski sepeti aynen satın al” değildir. Müşterinin güncel kataloğu, sözleşmesi, limiti ve teslim adresi yeniden kontrol edilmelidir.

B2B Ürün Verisi ve Site İçi Arama Nasıl Hazırlanmalıdır?

B2B ürün verisi; pazarlama adının yanında SKU, üretici kodu, EAN/GTIN varsa barkod, varyant, ölçü birimi, koli içi adet, teknik özellik, uyumlu ürün, stok ve güvenlik/sertifika dokümanlarını içerir. Arama, tam ürün kodunu, eş anlamlıları ve yazım hatalarını anlayıp yetkili katalogla sınırlı sonuç vermelidir.

Ürün kodu araması özellikle teknik parça ve tekrar siparişte dönüşümden önce doğruluk aracıdır. Veri sözlüğü, zorunlu alan ve kalite sorumlusu belirlemek için ürün hazırlama rehberindeki veri çerçevesi kullanılabilir. Arama sonucu olmayan sorgular düzenli incelenmeli; eş anlamlı ekleme ile yetkisiz ürünü görünür kılma riski birlikte test edilmelidir.

Stok, Depo ve Rezervasyon Kuralları Nasıl Planlanır?

Gerçek stok fiziksel miktar; satılabilir stok, rezervasyon ve güvenlik stoğu düşüldükten sonra satışa sunulan miktardır. B2B portalı depo bazlı görünürlük, müşteriye ayrılmış stok, backorder, ön sipariş, kısmi karşılama ve ERP gecikmesi kurallarını açıkça yönetmelidir. “Stokta var” tek bir sayı değildir.

• Satılabilir stok formülünü depo ve kanal bazında yazın.
• Sepet, teklif, onay ve siparişte rezervasyon anını ayırın.
• Rezervasyona süre ve serbest bırakma koşulu tanımlayın.
• Backorder için beklenen tarih ve müşteri onayı gösterin.
• ERP verisi eskidiyse zaman damgası veya güvenli uyarı sunun.
• Stok yokken teklif verilebilecek ürünleri ayrı politika ile yönetin.

Genel stok planlaması bu makalenin ana konusu değildir; B2B için kritik olan, stok sözünün müşteri, fiyat, teklif ve sevkiyat akışıyla tutarlı tutulmasıdır.

Sevkiyat ve Teslimat B2B Siparişlerde Nasıl Yönetilir?

B2B sevkiyat; standart kargoya ek olarak müşteri anlaşması, depodan teslim, şubeye teslim, rota/araç, koli veya palet, teslimat randevusu, birleştirilmiş ve kısmi sevkiyat seçeneklerini içerir. Teslim noktası yetkisi, navlun kuralı, sevk durumu ve irsaliye bağı siparişten önce görünür olmalıdır. Randevu da kurala bağlanır.

Kısmi sevkiyatta hangi satırın ne kadar gönderildiği, kalan miktarın backorder olup olmadığı ve faturanın nasıl bölüneceği izlenmelidir. Taşıma seçeneği, desi ve sözleşme yaklaşımı için e-ticaret kargo anlaşması kriterleri tamamlayıcıdır; B2B rota ve palet kurgusu ayrıca kapsamlandırılır.

B2B İade ve RMA Süreci Nasıl Kurulur?

RMA, “return merchandise authorization” yani ürün iade yetkilendirme sürecidir. B2B iadede talep nedeni, sözleşme koşulu, seri/lot/batch, teknik inceleme, onay veya ret, depoya kabul, yeniden stok, fiyat farkı ve alacak belgesi birbirine bağlanır. B2C cayma akışıyla otomatik olarak aynı kabul edilmemelidir.

1. Müşteri sipariş satırından iade talebi açar.
2. Yetkili ekip süre, neden, seri ve sözleşme koşulunu inceler.
3. Gerekirse teknik inceleme ve taşıma talimatı verilir.
4. Depo kabulünde miktar ve durum doğrulanır.
5. Yeniden stok, hurda, değişim veya ret kararı kaydedilir.
6. Alacak, fiyat farkı ve e-belge işlemleri muhasebe akışına bağlanır.

Alıcının sıfatı, işlemin amacı, ürün ve özel mevzuat farklı sonuç doğurabilir. “B2B satışta iade veya cayma hakkı yoktur” gibi mutlak ifadeler yerine sözleşme ve uzman hukuk kontrolü esas alınmalıdır.

ERP Entegrasyonu B2B Portalında Hangi Rolü Üstlenir?

ERP, kurumsal kaynak planlama sistemidir ve birçok işletmede ürün, müşteri/cari, fiyat, limit, stok, sipariş, irsaliye, fatura ve tahsilat verilerinin önemli bölümünü yönetir. B2B portalı ERP'nin ekran kopyası olmamalı; hangi veriyi hangi yönde ve hangi sıklıkta kullandığı açıkça tanımlanmalıdır. Bu ayrım çift giriş riskini azaltır.

Gerçek zamanlı sorgu kritik fiyat, limit ve stok için uygun olabilir; periyodik senkron büyük katalog veya rapor verisinde daha verimli olabilir. Kesinti davranışı, tekrar deneme, sıra ve mutabakat baştan planlanmalıdır. Siparişten faturaya genel operasyon çerçevesi için e-ticaret operasyonu akışı incelenebilir; ayrıntılı ERP mimarisi ayrı proje konusudur.

Hangi Veri Hangi Sistemde Ana Kaynak Olmalıdır?

Ana kaynak veya “tek doğruluk kaynağı”, belirli bir veri alanında son sözü hangi sistemin söylediğini tanımlar. Her verinin aynı sistemde olması gerekmez; fakat ürün, müşteri, fiyat, stok, limit, sipariş ve fatura için sahiplik, güncelleme yönü, sıklık, çakışma çözümü ve sorumlu ekip yazılı olmalıdır.

Temsili veri sahipliği matrisi altyapıya göre uyarlanır.

Portalda kullanıcı tarafından değiştirilebilen adres gibi alanlar için bile ERP'ye aktarım, onay ve hata dönüşü belirlenmelidir. Sessiz çift yönlü yazma veri döngüsü ve eski kaydın yeniyi ezmesi riskini artırır.

API ve Webhook Entegrasyonları Nasıl Güvenilir Hale Getirilir?

API, sistemlerin istek-cevapla veri alışverişi yaptığı arayüzdür; webhook ise bir olay olduğunda karşı sisteme gönderilen bildirimdir. Güvenilir entegrasyon; zaman aşımı, kuyruk, kontrollü tekrar deneme, hız sınırı, idempotency, hata kuyruğu, alarm, manuel yeniden işleme ve günlük mutabakatı birlikte kullanır. Her hata görünür ve izlenebilir olmalıdır.

• Kuyruk: Yoğun veya geçici kesintili işlemleri sırada dayanıklı tutar.
• Timeout: Yanıt beklemenin güvenli üst süresini belirler.
• Retry: Geçici hatayı artan aralıklarla tekrarlar; kalıcı hatayı sonsuza dek denemez.
• Idempotency: Aynı isteğin tekrarı ikinci sipariş veya tahsilat üretmez.
• Dead-letter queue: İşlenemeyen mesajı inceleme için ayrı hata kuyruğuna alır.
• Mutabakat: Gün sonunda iki sistemdeki sipariş, tutar ve durum farkını bulur.

Webhook sırası değişebilir veya aynı olay birden çok kez gelebilir. Zaman damgası, olay kimliği ve sürüm kontrolü olmadan “son gelen doğrudur” demek eski durumun yeniyi ezmesine yol açabilir.

e-Fatura, e-Arşiv ve e-İrsaliye B2B Akışına Nasıl Bağlanır?

B2B sipariş, alıcı unvanı ve vergi bilgisi doğrulandıktan sonra uygun satış ve sevkiyat belgesi akışına bağlanır. e-Fatura, e-Arşiv Fatura ve e-İrsaliye seçimi mükellefiyet, işlem ve güncel GİB kurallarına göre yapılır. Portalın görevi belge türünü tahmin etmek değil, doğrulanmış mali sistemle tutarlı veri aktarmaktır.

1. Sipariş ve teslimat verisini belge oluşturma için hazırla.
2. Alıcının unvan, vergi kimliği ve e-belge durumunu doğrula.
3. ERP veya e-belge özel entegratöründe uygun belgeyi oluştur.
4. GİB/entegratör yanıtını siparişe bağla; hatayı görünür kıl.
5. Yeniden gönderimde aynı belgeyi çoğaltma.
6. İptal, itiraz, iade ve sevkiyat ilişkisini ayrı durumlarla yönet.

Güncel zorunluluk ve teknik kurallar için GİB'in güncel 509 Sıra No.lu VUK Genel Tebliği esas alınmalı; mali müşavir ve entegratörle doğrulama yapılmalıdır. Kontör ve hizmet kapsamı paket fiyatından ayrı olabilir; e-Fatura ve e-Arşiv seçeneklerini inceleyin bağlantısındaki güncel koşullar kontrol edilmelidir.

CRM, PIM, WMS ve Muhasebe Entegrasyonları Ne Sağlar?

CRM müşteri ilişkilerini, PIM ürün bilgisini, WMS depo hareketlerini, muhasebe/ERP ise mali ve ticari kayıtları yönetir. B2B portalı her sistemi aynı veri deposu gibi kullanmamalı; ana süreç, hata riski ve ölçülecek entegrasyon metriğini sistem bazında tanımlamalıdır. Entegrasyon amacı sistem bazında ayrılmalıdır.

Aşağıdaki karşılaştırma, entegrasyon sınırlarını netleştirir.

Bir entegrasyonun “var” olması yeterli değildir. Veri yönü, gecikme, hata görünürlüğü, yeniden işleme, güvenlik ve sorumlu ekip kabul kriterine dahil edilmelidir.

Plasiyer ve Satış Temsilcisi B2B Portalına Nasıl Dahil Edilir?

Plasiyer veya satış temsilcisi, yalnız müşteri portala geçtiği için devreden çıkmaz. Temsilci; atandığı müşteri adına sepet veya teklif oluşturabilir, siparişe yardım edebilir ve istisnayı doğru onaya yönlendirebilir. Ancak müşteri kapsamı, fiyat override sınırı, komisyon ve işlem sahipliği açıkça belirlenmelidir. Tüm işlemler temsilci kimliğiyle kaydedilmelidir.

• Temsilci yalnız atanmış şirket ve lokasyonları görmelidir.
• Müşteri adına işlem yapıldığı arayüzde ve denetim kaydında belirtilmelidir.
• Fiyat değişikliği marj tabanı ve temsilci yetkisiyle sınırlandırılmalıdır.
• Komisyon, portal/temsilci kanal çatışması üretmeyecek kurala bağlanmalıdır.
• Müşteri sahipliği değiştiğinde açık teklif ve görevler devredilmelidir.

Portal satış ekibinin rakibi değil, tekrarlayan işlemleri kolaylaştıran aracıdır. Temsilcinin değeri veri girmekten ilişki, ihtiyaç ve istisna yönetimine kayar; performans ölçümü de yalnız manuel sipariş sayısına bağlanmamalıdır.

B2B Portalında Güvenlik Nasıl Sağlanır?

B2B güvenliği yalnız HTTPS veya güçlü parola değildir. RBAC, çok faktörlü kimlik doğrulama (MFA), güvenli oturum, şirket verisi izolasyonu, nesne düzeyinde yetki, API kimlik doğrulama, hız sınırı, şifreleme, gizli anahtar yönetimi, yedek, WAF, test ve olay müdahalesi birlikte uygulanmalıdır. Kontroller düzenli test edilmelidir.

• Her fiyat, teklif, sipariş, fatura ve cari isteğinde şirket/tenant yetkisi sunucuda kontrol edilir.
• IDOR olarak bilinen kimlik değiştirerek başka kayda erişim riski otomatik test edilir.
• MFA finans, şirket yöneticisi ve satıcı operasyon rollerinde önceliklendirilir.
• Oturum süresi, cihaz değişikliği, şüpheli giriş ve yetki değişimi politikası uygulanır.
• API anahtarları kaynak kodda tutulmaz; döndürülür ve en az yetkiyle sınırlandırılır.
• Fiyat/katalog cache anahtarı şirket ve yetki bağlamını güvenli biçimde içerir.
• Denetim kaydı, kullanıcıların değiştiremeyeceği bütünlük kontrolleriyle korunur.
• Tedarikçi erişimi süreli, onaylı ve izlenebilir olur.

OWASP Top 10:2025 erişim kontrolü rehberi, başka kullanıcının kaydına kimlik değiştirerek erişme ve eksik API yetkilendirmesi gibi riskleri öne çıkarır. Güvenlik testi riski azaltır; hiçbir altyapı için mutlak güvenlik garantisi vermez. Marka güveni ve kullanıcıya açık güven unsurları ayrıca e-ticaret sitesinde güven oluşturma çerçevesiyle ele alınabilir.

KVKK ve Ticari Elektronik İleti Kuralları B2B Portalını Nasıl Etkiler?

Şirket unvanı ve tüzel kişiye ait ticari veri ile şirket yetkilisi, çalışanı veya bayi kullanıcısının ad, e-posta, telefon ve işlem logu ayrılmalıdır. Gerçek kişiye ilişkin veriler KVKK kapsamında olabilir. İşleme amacı, hukuki sebep, minimizasyon, saklama, aktarım, güvenlik ve çalışan ayrılışında erişim kapatma süreçleri tasarıma dahil edilmelidir.

Genel gizlilik politikası her veri işleme faaliyeti için yeterli aydınlatma sayılmamalıdır; KVKK aydınlatma yükümlülüğü açıklamaları doğrultusunda amaç ve hukuki sebep ayrı ve açık sunulmalıdır. Yurt dışındaki bulut, destek veya yapay zekâ hizmetine aktarım varsa KVKK'nın güncel yurt dışına aktarım çerçevesi ve uygun güvence yöntemi uzmanla doğrulanmalıdır.

Tacir ve esnafın elektronik iletişim adresine ticari elektronik ileti gönderiminde önceden onay istisnası bulunabilse de ret hakkı devam eder; güncel ayrıntı Ticaret Bakanlığının ticari elektronik ileti açıklamalarından kontrol edilmelidir. Portalın sipariş bildirimi ile pazarlama iletisi aynı amaç kabul edilmemelidir. Şirket ve ETBİS hazırlığı için e-ticaret için gerekli belgeler rehberi bağlama göre tamamlayıcıdır.

B2B Portalında Performans ve Ölçeklenebilirlik Nasıl Planlanır?

Büyük katalog, müşteriye özel fiyat hesaplama, ürün kodu araması, CSV siparişi ve ERP yanıt süresi B2B performansını belirler. Cache, CDN ve kuyruk doğru kullanıldığında yükü azaltır; fakat müşteriye özel fiyatın yanlış cache anahtarıyla başka şirkete gösterilmesi hız sorunundan daha ciddi bir veri ihlalidir.

• Halka açık görsel ve statik içerikleri CDN ile dağıtın.
• Özel fiyat ve cari yanıtını şirket, rol ve kural sürümüyle izole edin.
• Toplu siparişi senkron ekran bekletmek yerine kontrollü kuyruğa alın.
• ERP yavaşlığında zaman aşımı, devre kesici ve kullanıcı mesajı tanımlayın.
• Kampanya ve dönem sonu yoğunluğu için kapasite testi yapın.
• Yanıt süresi kadar hata oranı, kuyruk yaşı ve veri tazeliğini izleyin.

Ölçeklenebilirlik “sınırsız” bir özellik değildir; ürün, kullanıcı, fiyat kuralı, eşzamanlı sipariş ve entegrasyon hacmiyle ölçülür. Teklifte kapasite varsayımları ve büyüme eşiği açıkça yazılmalıdır.

B2B Kullanıcı Deneyimi Nasıl Olmalıdır?

B2B kullanıcı deneyimi gösterişli vitrinden önce işi hızlı ve hatasız tamamlatmalıdır. Masaüstü ve mobilde ürün kodu arama, yoğun liste, klavye kullanımı, erişilebilir form, açık hata mesajı, fiyat/iskonto açıklaması, kalan limit, vade, teklif ve sipariş durumları role uygun bir gösterge panelinde sunulmalıdır.

• Satın almacıya hızlı sipariş ve geçmiş listeler öne çıkarılır.
• Onaylayıcıya karar için fiyat, bütçe, teslim ve değişiklik özeti verilir.
• Finans kullanıcısına cari, vade ve bloke gerekçesi gösterilir.
• Mobilde tablo yerine öncelikli alanlar ve satır bazlı eylemler kullanılır.
• Klavye odağı, etiketler, kontrast ve hata ilişkisi erişilebilir tasarlanır.

“Sipariş verilemedi” yerine hangi ürün, miktar, limit veya onay kuralının işlemi durdurduğu ve kullanıcının ne yapabileceği açıklanmalıdır. Ticari sır oluşturan iç risk kuralı ise gereğinden fazla ifşa edilmemelidir.

Kapalı B2B Portalında SEO Nasıl Yapılır?

Giriş gerektiren portal sayfaları arama motorlarınca taranamaz; bu nedenle SEO için halka açık bir içerik katmanı gerekir. Kategori ve çözüm sayfaları, seçilmiş ürün bilgileri, teknik rehberler ve SSS açık olabilir; müşteriye özel fiyat, cari, teklif ve belge verileri indekslenmemelidir. İki katmanın sınırı net olmalıdır.

• Hangi ürün detayının açık, hangisinin hesapla sınırlı olduğunu belirleyin.
• Filtre URL'leri ve benzer içerik için canonical politikasını planlayın.
• Teknik PDF'lerin erişim ve indeksleme kararını ürünle uyumlu yapın.
• Marka, ürün kodu ve çözüm sorguları için açıklayıcı public içerik üretin.
• Özel fiyatı HTML, API yanıtı veya önbellekte halka açık bırakmayın.

Google, indekslenecek sayfanın halka açık, çalışır ve indekslenebilir içerik taşımasını ister; ayrıntı Google Search teknik gereksinimlerinde açıklanır. Açık katman için e-ticaret SEO rehberi, yapay zekâ cevap sistemlerinin içeriği anlaması için de AI aramalarında görünürlük rehberi doğal tamamlayıcılardır.

Yapay Zekâ B2B E-Ticarette Nasıl Kullanılabilir?

Yapay zekâ; semantik ürün arama, ürün eşleştirme, teklif özeti, tekrar sipariş önerisi, talep tahmini, anomali tespiti, müşteri hizmetleri, teknik doküman yanıtı ve içerik hazırlamada yardımcı olabilir. Fiyat, risk, limit veya teklif önerisi ise yetkili insan kontrolü olmadan ticari karara dönüştürülmemelidir.

• Yanıtı yetkili katalog ve güncel ürün verisiyle sınırlandırın.
• Teknik doküman yanıtında kaynak belgeyi ve sürümünü gösterin.
• Anomali uyarısını otomatik suçlama veya blokaj kabul etmeyin.
• Model hatası ve hallüsinasyon için geri bildirim/inceleme kanalı kurun.
• Müşteriye özel fiyat, cari, teklif ve belgeyi genel amaçlı araçlara kontrolsüz aktarmayın.

Veri sınıflandırması, erişim kontrolü, kayıt ve sağlayıcı sözleşmesi AI projesinin parçasıdır. Kullanım örnekleri ve insan gözetimi için yapay zekâ destekli e-ticaret yaklaşımı ayrıca değerlendirilebilir.

Hangi B2B E-Ticaret Metrikleri Takip Edilmelidir?

B2B metrikleri yalnız ciroyu değil dijital adaptasyonu, sipariş hızını, manuel iş yükünü, teklif verimini, fiyat ve limit kontrolünü, entegrasyon sağlığını ve belge kalitesini ölçmelidir. Her KPI için tanım, formül, veri kaynağı, sorumlu ve hedef aralığı yazılmadan gösterge paneli karşılaştırılamaz. Tanımlar dönemler arasında değişmemelidir.

Aşağıdaki KPI tablosu ölçüm kataloğu için başlangıçtır.

Tanım tutarlılığı ve kârlılık bağlamı için e-ticaret raporlama yaklaşımı kullanılabilir. KPI hedefi sektör ve müşteri yaşam döngüsüne göre belirlenmeli; tek bir oran başarı garantisi sayılmamalıdır.

B2B E-Ticaret Sitesi Kurma Maliyeti Hangi Kalemlerden Oluşur?

B2B proje maliyeti yalnız paket veya lisans bedeli değildir. Kurulum, tasarım, veri temizleme, entegrasyon, özel iş kuralı, altyapı, güvenlik, e-belge, ödeme, mesajlaşma, eğitim, destek, bakım ve iç ekip zamanı toplam sahip olma maliyetini oluşturur. Kesin fiyat, kapsam ve hacim belirlenmeden sağlıklı verilemez.

Teklifleri aynı kapsamda karşılaştırmak için maliyet tablosu kullanılmalıdır.

Paket bedeli ile B2B proje toplamı ayrı gösterilmelidir. Kapsamı güncel ürün sayfasından doğrulamak ve SoloCommerce paketlerini karşılaştırmak, özel geliştirme ve üçüncü taraf maliyetlerini görünür kılmak için başlangıç sağlar.

Hazır B2B Paket, Özel Yazılım ve Hibrit Çözüm Nasıl Karşılaştırılır?

Hazır paket standart kabiliyetlerle daha hızlı başlatır; özel yazılım benzersiz süreçler için esneklik sağlar fakat bakım ve teknik borç sorumluluğu büyüktür; hibrit model standart ticaret çekirdeğini koruyup kritik fiyat, limit veya entegrasyon kurallarını özel geliştirir. Karar yalnız ilk fiyata göre verilmemelidir.

Karşılaştırma toplam sahip olma ve değişim yeteneğini birlikte ele alır.

Hazır e-ticaret sitesi yaklaşımı ile özel B2B sınırı ve e-ticaret paketi seçim kriterleri birlikte incelenmelidir. “Özel” kelimesi otomatik olarak daha iyi, “hazır” kelimesi de otomatik olarak yetersiz anlamına gelmez.

B2B E-Ticaret Altyapısı Seçerken Hangi Sorular Sorulmalıdır?

Altyapı değerlendirmesi özellik kutularını saymak yerine iş kurallarının gerçekten nasıl çalıştığını kanıtlamalıdır. Demo; işletmenin gerçek ürün, fiyat, limit, teklif ve entegrasyon senaryolarıyla yapılmalı; cevaplar sözleşme, teknik kapsam, kabul kriteri ve sorumluluk matrisiyle kayıt altına alınmalıdır. Kanıtlanabilir demo sonucu istenmelidir. Ürün sınırları da yazılmalıdır.

Fiyat ve katalog soruları

1. Müşteri, grup, sözleşme ve teklif fiyatı aynı anda nasıl öncelikleniyor?
2. İndirimlerin birleşebilirliği ve sıralı iskonto nasıl hesaplanıyor?
3. Minimum marj ve temsilci fiyat override sınırı var mı?
4. MOQ, maksimum miktar, sipariş katı, koli ve palet destekleniyor mu?
5. Döviz, kur sabitleme, KDV ve yuvarlama ERP ile aynı mı?
6. Müşteriye özel katalog ve belge erişimi API düzeyinde korunuyor mu?

Cari, teklif ve sipariş soruları

1. Kullanılabilir limit hangi risk kalemlerinden hesaplanıyor?
2. Eşzamanlı siparişte limit atomik olarak rezerve ediliyor mu?
3. Vadesi geçmiş borçta blokaj, onay veya peşin ödeme seçilebiliyor mu?
4. RFQ durumları, sürümleri, geçerlilik ve kabul kaydı tutuluyor mu?
5. Teklif kabulünde fiyat, stok, kur ve limit yeniden doğrulanıyor mu?
6. PO numarası, çok seviyeli onay, vekâlet ve eskalasyon var mı?
7. SKU, CSV, favori ve tekrar sipariş hangi kurallarla kontrol ediliyor?

Stok, ERP ve e-belge soruları

1. Gerçek, satılabilir ve rezerve stok nasıl ayrılıyor?
2. Backorder, kısmi sevkiyat ve depo bazlı görünürlük destekleniyor mu?
3. Her veri alanının ana sistemi ve güncelleme yönü tanımlanabiliyor mu?
4. API kesintisinde sipariş kabul, kuyruk ve kullanıcı mesajı nedir?
5. İdempotency, retry, hata kuyruğu ve günlük mutabakat nasıl uygulanıyor?
6. e-Fatura/e-Arşiv/e-İrsaliye kapsamı, kontör ve entegratör maliyeti ayrı mı?
7. İptal, iade ve başarısız belge yeniden gönderimi nasıl izleniyor?

Güvenlik, performans ve veri soruları

1. Şirketler arası veri izolasyonu nasıl test ediliyor?
2. RBAC, MFA, SSO ve oturum politikası hangi kapsamda?
3. API nesne düzeyi yetki ve hız sınırı testleri var mı?
4. Denetim kaydına kim erişebilir ve kayıt bütünlüğü nasıl korunur?
5. Özel fiyat cache'i müşteri ve rol bazında nasıl ayrılıyor?
6. Ürün, kullanıcı ve eşzamanlı sipariş kapasite sınırları nedir?
7. Veri dışa aktarma formatı ve silme/iade prosedürü nedir?

Maliyet, destek ve çıkış soruları

1. Lisans, kullanım, modül, entegrasyon ve üçüncü taraf kalemleri nelerdir?
2. Özel geliştirme bakım ve sürüm yükseltme ücretine nasıl yansır?
3. SLA yanıt ve çözüm süresi hangi olayları kapsar?
4. 7/24 izleme ile 7/24 destek arasındaki fark nedir?
5. Yedek, felaket kurtarma ve geri dönüş test sıklığı nedir?
6. Tedarikçi değişiminde ürün, müşteri, fiyat, teklif, sipariş ve belge geçmişi alınabilir mi?
7. Sözleşme bittiğinde API erişimi, veri saklama ve silme nasıl yürür?

Cevap “yapılabilir” ise standart pakette mi, Enterprise/özel projede mi olduğu ve teslim kriteri sorulmalıdır. Güncel kapsamı kurumsal satış sürecine uygun e-ticaret paketi üzerinden karşılaştırırken gelişmiş B2B iş kurallarını ayrıca yazılı teklif kapsamına alın.

B2B E-Ticaret Projesi Hangi Aşamalarla Kurulur?

B2B proje; strateji, süreç keşfi, gereksinim, veri temizleme, mimari, UX prototipi, MVP, geliştirme, test, UAT, pilot, eğitim, kademeli canlıya geçiş ve sürekli iyileştirme aşamalarıyla kurulmalıdır. Her aşamanın somut çıktısı ve çıkış kriteri olmadan takvim ilerlemesi tamamlanma sayılmamalıdır. Aşamalar geriye dönük izlenebilir olmalıdır.

Yol haritası sorumluluk ve go/no-go kararını görünür kılar.

MVP yalnız “az özellik” değildir; fiyat, yetki, limit ve sipariş doğruluğunu güvenli biçimde sağlayan en küçük değerli akıştır. Kritik kontrolü sonraya bırakıp yalnız vitrin açmak doğru MVP değildir.

UAT, Pilot Bayi ve Canlıya Geçiş Nasıl Yönetilir?

UAT, kullanıcı kabul testidir ve iş birimlerinin gerçek senaryolarla sistemin gereksinimi karşılayıp karşılamadığını doğrulamasıdır. Pilot, sınırlı ve temsil edici bayi grubuyla canlı davranışı ölçer. Go/no-go kararı; fiyat, limit, yetki, entegrasyon, belge, performans, eğitim ve geri dönüş kriterlerine dayanmalıdır. Kritik senaryolar yayından önce geçmelidir.

En az aşağıdaki senaryolar işletmenin gerçek verisine uyarlanarak test edilmelidir:

1. Standart bayi doğru katalog ve fiyatı görür.
2. Yetkili bayi farklı grup fiyatını görür.
3. Bir şirket diğer şirketin fiyatına erişemez.
4. Sözleşme fiyatı ile kampanya çakışması doğru çözülür.
5. Yüzde 10 ve yüzde 5 sıralı iskonto 855 sonucunu üretir.
6. Marj tabanı altı fiyat engellenir veya onaya gider.
7. MOQ altındaki satır anlaşılır hata verir.
8. Koli katına uymayan CSV satırı işaretlenir.
9. Döviz kuru yokken güvenli davranış çalışır.
10. Yuvarlama ERP ve portalda aynı sonucu verir.
11. Limit içindeki sipariş başarıyla rezerve edilir.
12. Aynı anda iki sipariş limiti birlikte aşamaz.
13. Başarısız işlem rezervasyonu doğru çözer.
14. Vadesi geçmiş borç politikadaki davranışı tetikler.
15. Finans istisnası süre ve gerekçeyle kaydedilir.
16. RFQ taslak, gönderim ve revizyon durumlarından geçer.
17. Eski teklif sürümü kabul edilemez.
18. Süresi dolan teklif yeniden doğrulama ister.
19. PO numarası zorunlu hesapta boş geçilemez.
20. Çok seviyeli onay doğru role gider.
21. Vekâlet süresi bitince yetki kalkar.
22. Geçmiş sipariş güncel fiyat ve stokla yenilenir.
23. Stok yok, backorder ve kısmi sevk ayrı çalışır.
24. ERP kesintisinde kuyruk ve mesaj politikaya uyar.
25. Aynı API isteği çift sipariş oluşturmaz.
26. e-belge hatası görünür ve yeniden işlenebilir olur.
27. İptal/iade/RMA sipariş ve belgeye bağlanır.
28. Yetkisiz kullanıcı fatura ve cariye erişemez.
29. Mobil hızlı sipariş ve klavye erişilebilirliği çalışır.
30. Yoğun toplu sipariş yükünde kabul eşiği sağlanır.
31. Yedekten dönüş ve rollback prosedürü denenir.

Pilot bayi; farklı segment, sipariş büyüklüğü ve kullanım becerisini temsil etmelidir. Eski telefon/e-posta kanalının ne zaman ve nasıl sınırlandırılacağı, destek masası, sorumlu nöbeti ve geri dönüş kararı yayından önce duyurulmalıdır.

B2B E-Ticarette En Sık Yapılan Hatalar Nelerdir?

En yaygın hata, B2C mağazada fiyatı giriş arkasına alıp gerçek B2B operasyonunun kurulduğunu varsaymaktır. Fiyat önceliği, cari risk, teklif, yetki, veri sahipliği ve entegrasyon hataları yazılı yönetilmediğinde güzel arayüz yanlış siparişi daha hızlı üretir. Her hata için önleyici kontrol atanmalıdır.

• Fiyat önceliğini yazılı tanımlamamak.
• Sıralı iskontoyu oranları toplayarak hesaplamak.
• Marj tabanı ve override yetkisi koymamak.
• Açık siparişi cari riske dahil etmemek.
• Eşzamanlı siparişte limiti iki kez kullandırmak.
• Teklif kabulünde fiyat, stok ve kuru doğrulamamak.
• Her kullanıcıya şirket yöneticisi yetkisi vermek.
• Özel fiyatı yanlış cache ile başka müşteriye göstermek.
• ERP ve ana veri sahipliğini son aşamaya bırakmak.
• API hatasını sessizce yutmak ve çift siparişi önlememek.
• Ürün kodu araması ve mobil hızlı siparişi ihmal etmek.
• Satış ekibini projeye dahil etmemek.
• Bayileri eğitmeden eski kanalı kapatmak.
• Tüm özellikleri ilk sürüme doldurmak.
• Paket fiyatı ile toplam proje maliyetini karıştırmak.
• Hukuk, KVKK ve e-belge doğrulamasını sona bırakmak.
• AI önerisini otomatik ticari karara çevirmek.

Hataları önlemenin en etkili yolu, her kuralı örnek veri, olumsuz senaryo ve sorumlu kişiyle test edilebilir kabul kriterine dönüştürmektir.

SoloCommerce B2B ve Bayi Operasyonlarında Nasıl Konumlanır?

SoloCommerce, B2B projesinde yalnız bayi fiyatı gösteren bir modül olarak değil; markalı site, katalog, fiyat, sepet, sipariş ve operasyon katmanlarının birlikte planlanabileceği e-ticaret altyapısı olarak değerlendirilebilir. Hangi B2B kabiliyetinin standart paket, Enterprise veya özel proje olduğu güncel kapsam ve teklif üzerinden ayrılmalıdır.

14.07.2026 tarihli paket sayfasında storefront/katalog, tema/CMS, sepet/checkout, fiyat motoru, set ürün ve blog/SEO çekirdeği paket karşılaştırmasında dahil olarak listelenmektedir. Professional bölümünde gelişmiş pazaryeri yönetimi, cari ve tahsilat takibi, satış dokümanları ile stok/depo görünürlüğü; Enterprise bölümünde özel entegrasyonlar, SLA, gelişmiş otomasyonlar, yüksek hacimli kurgu, ERP/muhasebe özel bağlantıları ve proje bazlı kurulum belirtilmektedir.

Bu doğrulama, müşteriye özel katalog, karmaşık iskonto önceliği, atomik risk motoru, çok seviyeli PO onayı, RFQ pazarlığı, SSO veya punchout'un standart özellik olduğu anlamına gelmez. Bu ihtiyaçlar için veri sahipliği, iş kuralı, entegrasyon, güvenlik ve kabul senaryolarını içeren kapsam analizi gerekir. e-Fatura/e-Arşiv güncel karşılaştırmada opsiyonel ya da teklif ile gösterildiğinden kontör ve hizmet maliyeti ayrıca değerlendirilmelidir.

Harici servis, alan adı, kapasite, veri taşıma, özel tema, güvenlik testi, e-belge, ödeme komisyonu, mesajlaşma, özel entegrasyon, eğitim ve SLA kalemleri paket bedelinden ayrı olabilir. Belirli satış, marj, SEO sıralaması, güvenlik veya kesintisiz çalışma garantisi verilmemelidir. B2B ve operasyon ihtiyacınıza uygun e-ticaret paketleri sayfasını bu rehberdeki kriterlerle karşılaştırıp doğrulanmayan gelişmiş ihtiyaçlar için yazılı teklif isteyin.

B2B E-Ticaret Sitesi Kurma Kontrol Listesi

Kontrol listesi, gereksinimi “özellik var/yok” düzeyinden uygulanabilir ve test edilebilir kararlara dönüştürür. Aşağıdaki 120 madde her işletmede aynı öncelikte değildir; iş modeli, müşteri segmenti, risk politikası ve entegrasyon mimarisine göre sahip, tarih ve kanıt alanları eklenerek proje planına alınmalıdır.

Strateji ve iş modeli

• Dijital kanalın çözeceği üç ölçülebilir sorunu yazın.
• B2B, B2B2C veya hibrit model kararını onaylayın.
• Portalın satış ekibiyle görev paylaşımını tanımlayın.
• MVP ve sonraki sürüm sınırını belirleyin.
• Proje sahibi ile ticari karar sahibini atayın.
• Başarı KPI'larını ve ölçüm başlangıcını kaydedin.

Bayi ve müşteri segmentasyonu

• Standart, yetkili ve zincir müşteri gruplarını tanımlayın.
• Segment atama verisini ve onaylayan rolü belirleyin.
• Bölge, kanal ve ürün erişim kurallarını yazın.
• Segment değişikliğinin fiyat etkisini test edin.
• Pasif bayi ve yeniden aktivasyon sürecini tanımlayın.
• Aynı şirketin birden çok segmentte olma kuralını çözün.

Şirket, şube ve kullanıcı hesapları

• Ana şirket, şube ve lokasyon hiyerarşisini modelleyin.
• Fatura ve teslimat adreslerini ayrı yönetin.
• Vergi bilgisi değişikliğine onay akışı koyun.
• Bir kullanıcının çoklu lokasyon yetkisini test edin.
• Yinelenen şirket ve kullanıcı kaydını önleyin.
• Çalışan ayrılışında erişim kapatma süresini belirleyin.

Rol ve yetki

• Her rol için izin matrisi oluşturun.
• En az ayrıcalık ilkesini varsayılan yapın.
• Fiyat, limit ve onay görevlerini ayırın.
• Finans ve yönetici rollerinde MFA uygulayın.
• Vekâlet yetkisine başlangıç ve bitiş tarihi verin.
• Yetki değişikliklerini onay ve audit log ile saklayın.

Katalog ve ürün verisi

• Müşteri bazlı dahil/haric ürün politikasını yazın.
• SKU ve üretici kodunu benzersiz doğrulayın.
• Ölçü birimi ve koli içi adedi standartlaştırın.
• Teknik özellik ve sertifika sahiplerini atayın.
• Katalog sürümü ve geçerlilik tarihini yönetin.
• Yetkisiz teknik doküman erişimini API'de test edin.

Fiyat ve iskonto

• Fiyat türlerinin öncelik sırasını yazılı onaylayın.
• Birleşebilir ve dışlanan iskonto kurallarını işaretleyin.
• Sıralı iskonto matematiğini ERP ile karşılaştırın.
• Minimum marj ve override yetkisini tanımlayın.
• Kur kaynağı, zamanı ve hata davranışını belirleyin.
• KDV ve yuvarlama sonucunu sipariş-faturada test edin.

Cari, limit ve risk

• Limit ile risk limiti kavramlarını ayırın.
• Risk hesabına giren kalemleri tek tek yazın.
• Açık siparişin limite etkisini tanımlayın.
• Atomik limit rezervasyonunu eşzamanlı test edin.
• Başarısız işlemde rezervasyon çözmeyi doğrulayın.
• Geçici limit artışına süre ve gerekçe zorunluluğu koyun.

Teklif ve sipariş onayı

• RFQ durumlarını ve geçiş yetkilerini tanımlayın.
• Teklif sürüm geçmişini değiştirilemez saklayın.
• Geçerlilik bitiminde kabulü engelleyin.
• Kabul anında fiyat, stok ve limiti doğrulayın.
• PO numarası zorunluluğunu müşteri bazında yönetin.
• Onay eskalasyonu ve ret gerekçesini test edin.

Hızlı sipariş ve checkout

• SKU ile çok satırlı girişi destekleyin.
• CSV şablonunu ve sürümünü yayımlayın.
• Hatalı satırı numarası ve nedeniyle gösterin.
• Tekrar siparişte güncel koşulları yeniden hesaplayın.
• Ödeme sonucunu benzersiz işlem anahtarıyla bağlayın.
• Mobil checkout'u gerçek cihazda tamamlayın.

Stok, depo ve sevkiyat

• Satılabilir stok formülünü depo bazında yazın.
• Rezervasyon anı ve süresini belirleyin.
• Güvenlik stoğunu kanallar arasında koruyun.
• Backorder ve ön siparişi ayrı durumlarla yönetin.
• Kısmi ve birleştirilmiş sevkiyatı test edin.
• İrsaliye ile sevk satırlarını ilişkilendirin.

ERP, API ve entegrasyon

• Her veri için ana sistem ve sahibi atayın.
• Güncelleme yönü ve sıklığını belgeleyin.
• Timeout ve retry politikasını sınırlayın.
• İdempotency ile çift siparişi önleyin.
• Hata kuyruğu ve manuel yeniden işlemeyi kurun.
• Günlük sipariş, tutar ve durum mutabakatı yapın.

E-belge ve mali süreç

• Alıcı unvanı ve vergi bilgisini doğrulayın.
• Belge türünü güncel GİB kuralıyla seçin.
• Sipariş-fatura tutar farkı kontrolü ekleyin.
• Belge hatasını görünür ve yeniden işlenebilir yapın.
• İptal, itiraz ve iade akışını tanımlayın.
• Kontör, entegratör ve destek maliyetini ayırın.

KVKK ve hukuk

• Tüzel kişi verisi ile kişisel veriyi ayırın.
• İşleme amacı ve hukuki sebebi belgeleyin.
• Gereksiz başvuru alanlarını kaldırın.
• Saklama ve imha sürelerini süreç bazında yazın.
• Yurt dışı aktarım ve tedarikçileri envanterleyin.
• Sözleşme, iade ve vade koşullarını uzmana doğrulatın.

Güvenlik

• Şirketler arası nesne erişimini olumsuz test edin.
• Oturum, parola ve MFA politikasını uygulayın.
• API sırlarını kasa hizmetinde yönetin.
• Rate limit ve bot koruması ekleyin.
• Yedekten dönüş testini düzenli yapın.
• Olay müdahalesi ve bildirim sahiplerini belirleyin.

Performans ve ölçeklenebilirlik

• Katalog ve fiyat sorgusu hedeflerini belirleyin.
• Cache anahtarına şirket ve yetki bağlamı ekleyin.
• Toplu sipariş yük testini çalıştırın.
• ERP yavaşlığında devre kesici davranışı test edin.
• Kuyruk yaşı ve hata oranına alarm kurun.
• Yoğun dönem kapasite planını onaylayın.

Mobil, UX ve erişilebilirlik

• Rol bazlı gösterge paneli önceliklerini belirleyin.
• Ürün kodu aramasını klavyeyle kullanılabilir yapın.
• Fiyat ve iskonto açıklamasını görünür tutun.
• Limit blokajında uygulanabilir mesaj gösterin.
• Form etiketi, odak ve hata ilişkisini test edin.
• Mobilde 100 satırlı siparişi deneyin.

SEO ve AI görünürlüğü

• Public ve private içerik sınırını belgeleyin.
• Özel fiyat ve cariyi indekslemeden koruyun.
• Kategori ve çözüm sayfalarını taranabilir yapın.
• Canonical ve filtre URL politikasını tanımlayın.
• AI yanıtlarını kaynak ve yetkiyle sınırlandırın.
• Özel ticari veriyi genel modellere aktarmayın.

Raporlama

• Her KPI için tek formül tanımlayın.
• Veri kaynağı ve tazelik zamanını gösterin.
• Dijital sipariş payını segment bazında izleyin.
• Override, blokaj ve marjı birlikte raporlayın.
• Entegrasyon ve belge hatasını sınıflandırın.
• Rapor erişimini rol ve şirkete göre sınırlandırın.

UAT, pilot ve eğitim

• Gerçek fiyat ve limit verisiyle UAT yapın.
• Olumsuz yetki ve kesinti senaryosu çalıştırın.
• Temsil edici pilot bayi grubunu seçin.
• Rol bazlı kısa eğitim materyali hazırlayın.
• Pilot geri bildirimini öncelik ve sahip ile kaydedin.
• Go/no-go kriterlerini yayından önce imzalayın.

Canlı operasyon, destek ve SLA

• İlk gün destek sorumlularını ve kanalı duyurun.
• Eski sipariş kanalının geçiş planını belirleyin.
• Kritik olay ve öncelik tanımlarını yazın.
• SLA yanıt ile çözüm süresini ayırın.
• Rollback karar yetkisini ve adımlarını test edin.
• Aylık KPI ve iyileştirme toplantısını planlayın.

Liste tamamlandığında her madde için “uygulanmadı, devam ediyor, kanıtlandı, kabul edildi” gibi durumlar ve kanıt bağlantısı tutulmalıdır. İşaretlenmiş kutu tek başına teknik veya hukuki uygunluk kanıtı değildir.

Sıkça Sorulan Sorular

B2B e-ticaret sitesi nedir?

B2B, “business to business” ifadesinin kısaltmasıdır ve işletmeden işletmeye ticareti anlatır. B2B e-ticaret sitesi; bir şirketin bayilerine, distribütörlerine veya kurumsal müşterilerine hesap, katalog, fiyat, ödeme, teklif ve sipariş koşullarıyla dijital satış yaptığı portaldır.

B2B ile B2C arasındaki fark nedir?

B2C, işletmeden son tüketiciye standartlaştırılmış satış akışıdır; B2B ise şirket hesabına bağlı, sözleşmeli ve çoğu zaman onaylı satın alma sürecidir. B2B'yi yalnız daha yüksek adetli B2C olarak görmek yanlıştır.

Hangi firmalar B2B bayi sistemine ihtiyaç duyar?

Üretici, ithalatçı, toptancı, distribütör, bayi ağı yöneten marka ve kurumsal müşterilere tekrarlayan satış yapan işletmeler B2B portalından yararlanabilir. İhtiyaç, yalnız bayi sayısıyla ölçülmez.

Bayiye özel fiyat nasıl tanımlanır?

Bayiye özel fiyatlandırma; liste fiyatı üzerine tek oran indirim yazmak yerine müşteri grubu, cari hesap, sözleşme, ürün-müşteri matrisi, hacim, teklif, para birimi ve geçerlilik tarihi kurallarını değerlendirir.

Cari bazlı fiyatlandırma nedir?

Cari hesap, satıcı ile müşteri arasındaki borç, alacak, fatura, tahsilat ve benzeri ticari hareketlerin izlendiği hesaptır. Cari limit veya alış limiti, işletmenin müşteriye tanıdığı ticari risk politikasıdır; banka kredisi değildir.

B2B e-ticaret sitesi kurma maliyeti ne kadardır?

B2B proje maliyeti yalnız paket veya lisans bedeli değildir. Kurulum, tasarım, veri temizleme, entegrasyon, özel iş kuralı, altyapı, güvenlik, e-belge, ödeme, mesajlaşma, eğitim, destek, bakım ve iç ekip zamanı toplam sahip olma maliyetini oluşturur.

Uygulama Kontrol Listesi

B2B e-ticaret sitesi kurmanın başarısı yalnız modern arayüze değil; doğru kullanıcıya doğru katalog ve fiyatın, doğru cari risk ve onayla, güncel stok ve teslim sözüyle, güvenilir belge ve entegrasyon akışında sunulmasına bağlıdır. Her özellik ilk sürüme doldurulmamalı; kritik ticari doğruluğu sağlayan MVP, temsil edici pilotla kanıtlanmalıdır.

Fiyat önceliği, sıralı iskonto, limit rezervasyonu, teklif sürümü, rol ayrılığı ve ana veri sahipliği yazılı değilse teknik ekip tutarlı sonuç üretemez. Güvenlik, mevzuat, veri kalitesi, entegrasyon izleme ve kullanıcı adaptasyonu bir defalık kurulum değil sürekli yönetim işidir. Portal satış veya kârlılık garantisi vermez; doğru ölçüm ve kontrollü iyileştirme için ortak çalışma zemini sağlar.

Solofor e-ticaret paketleri sayfasını inceleyerek ürün, fiyat, sipariş, stok, cari, tahsilat, entegrasyon, e-belge, raporlama ve özel proje ihtiyaçlarınıza uygun SoloCommerce kapsamını karşılaştırabilirsiniz. E-belge sürecini ayrıca planlıyorsanız Solofor e-Fatura çözümleri üzerinden güncel portal ve kontör seçeneklerini inceleyebilirsiniz.