Toptancılar için ürün kataloğu sitesi ile e-ticaret sitesi arasındaki seçim, “sepete ekle butonu olsun mu?” sorusundan daha büyüktür. Fiyatlar müşteriye göre değişiyor, minimum sipariş adedi bulunuyor, vade/iskonto satış temsilcisi tarafından onaylanıyor veya sevkiyat maliyeti siparişe göre hesaplanıyorsa klasik perakende e-ticaret yerine katalog + teklif, bayi portalı veya hibrit model daha doğru olabilir. Ürün, fiyat, stok ve teslimat kuralları standartsa ve müşteri siparişi satış temsilcisine ihtiyaç duymadan tamamlayabiliyorsa doğrudan e-ticaret anlamlıdır.
Toptancılar için 5 temel web satış modeli
Aynı toptancı bütün müşterilerine aynı dijital deneyimi sunmak zorunda değildir. Bir işletme genel ürün kataloğunu herkese açık gösterebilir, kurumsal müşteriden teklif isteyebilir ve onaylı bayilere giriş yaptıktan sonra özel fiyatla sipariş verebilir. En doğru model, satış ekibinin bugün hangi kararları manuel verdiğine bakılarak seçilmelidir.
| Model | Müşteri ne yapar? | Fiyat | Sipariş nasıl oluşur? |
|---|---|---|---|
| Katalog sitesi | Ürünleri ve teknik bilgileri inceler | Gizli veya referans fiyat | Telefon / form / e-posta |
| Katalog + teklif | Ürün seçip miktar ve ihtiyacı gönderir | Teklif sonrası | Satış ekibi onaylı teklif oluşturur |
| Bayi portalı | Giriş yapar, kendine özel ürün/fiyat görür | Müşteriye özel | Sipariş portalda oluşur, gerekirse onaya gider |
| Doğrudan e-ticaret | Sepet, ödeme ve teslimatı tamamlar | Standart / açık | Sipariş anında sistemde oluşur |
| Hibrit | Genel ürünler açık, özel ürünler teklif/bayi akışında | Ürüne/müşteriye göre | Sepet + teklif + portal birlikte |
Yalnız ürün kataloğu ne zaman yeterlidir?
Ürünün seçimi teknik danışmanlık gerektiriyorsa, fiyat sürekli proje/adet/kur bazında değişiyorsa veya müşteri satın almadan önce satış temsilcisiyle görüşmek zorundaysa katalog sitesi iyi bir başlangıç olabilir. Ama katalog sitesi PDF yükleyip iletişim numarası bırakmak değildir. Ürünler aranabilir, filtrelenebilir, teknik dokümanları düzenli ve mobilde okunabilir olmalı; her ürün sayfasında net bir sonraki adım bulunmalıdır.
- Ürün kategorileri ve filtreler müşterinin kullandığı terimlerle düzenlenmeli.
- Teknik ölçü, materyal, paket içeriği, uyumluluk ve varsa doküman ürün kartında görünmeli.
- Stok bilgisi gösterilmiyorsa “stokta var” gibi doğrulanmamış ifade kullanılmamalı.
- Her ürün için “teklif iste”, “satış danışmanına sor” veya “bayi girişi” gibi tek birincil sonraki adım belirlenmeli.
- Katalog verisi ERP/PIM’den geliyorsa hangi sistemin ürün adını, görseli ve teknik özelliği yönettiği net olmalı.
Katalog + teklif modeli ne zaman daha uygundur?
Toptan satışta siparişin fiyatı, miktar, teslim bölgesi, palet/koli düzeni, ödeme şekli veya müşteri statüsüne göre değişiyorsa “teklif iste” akışı perakende sepetinden daha doğru olabilir. Kullanıcı ürünleri tek tek seçip teklif sepetine ekleyebilir; ardından şirket, miktar, teslim yeri ve notlarıyla talebi gönderir. Bu işlem henüz kesin sipariş değildir.
| Alan | Neden gerekir? | Not |
|---|---|---|
| Şirket adı | Ticari müşteri eşlemesi | Serbest metin + CRM eşlemesi |
| Yetkili kişi | Geri dönüş | Kişisel veri minimizasyonu korunmalı |
| Telefon / e-posta | İletişim | En az bir doğrulanabilir kanal |
| Ürün / SKU | Talep edilen ürün | Sayfadan otomatik taşınabilir |
| Miktar / birim | Fiyat ve sevkiyat hesabı | Adet, koli, palet gibi birim açık olmalı |
| Teslim bölgesi | Nakliye ve termin | İl/ülke yeterli olabilir |
| Not / dosya | Özel teknik ihtiyaç | Dosya güvenliği ayrıca yönetilmeli |
Bayi portalı hangi durumda katalogdan daha ileri, e-ticaretten daha doğru çözümdür?
Aynı ürünü farklı bayilere farklı iskonto, ödeme koşulu, kredi limiti veya ürün erişimiyle satıyorsanız kamuya açık e-ticaret fiyatı operasyonu bozabilir. Bayi portalında her hesap yalnız yetkili olduğu ürünleri, fiyatlarını, sipariş geçmişini, varsa cari durumunu ve teslimat seçeneklerini görür. Bu yapı standart e-ticaret temasından çok B2B iş yazılımı mantığı gerektirir.
| Kural | Örnek | Sistem davranışı |
|---|---|---|
| Müşteri fiyatı | Bayi A %12, Bayi B %18 iskonto | Fiyat sunucuda müşteri hesabına göre hesaplanır |
| Minimum sipariş | En az 1 koli | Sepette alt sınır kontrolü |
| Kredi limiti | Açık bakiye sınırı | Sipariş onaya düşebilir |
| Ürün yetkisi | Bölgeye/segmente özel ürün | Yetkisiz ürün gizlenir veya siparişe kapanır |
| Vade | 30/60 gün | Ödeme koşulu hesap bazında |
| Sipariş onayı | Satış yöneticisi onayı | Sipariş 'alındı' ve 'onaylandı' ayrı durumlar |
Tam e-ticaret ne zaman mantıklıdır?
Ürünler standart, fiyatlar herkese açık veya kurallı, stok çevrimiçi doğrulanabilir, kargo/teslimat sistemi otomatik hesaplanabilir ve müşteri kartla ya da tanımlı ödeme yöntemiyle siparişi kendi başına tamamlayabiliyorsa tam e-ticaret kullanılabilir. Burada siparişin hangi anda bağlayıcı ticari işleme dönüştüğü, stok rezervasyonu, ödeme başarısızlığı, iptal ve iade gibi süreçler baştan tanımlanmalıdır.
Google Search Central'ın güncel dokümantasyonunda merchant listing deneyimlerinin, müşterinin ürünü doğrudan satın alabildiği sayfalara yönelik olduğu belirtiliyor. Buna karşılık yalnız ürün bilgisi sunan sayfalar farklı `Product` snippet yaklaşımıyla değerlendirilebilir. Bu ayrım, katalog ve gerçek satış sayfalarının teknik olarak da aynı şey olmadığını gösterir.
Toptancılar için hibrit model nasıl kurulur?
Birçok B2B işletmede en gerçekçi çözüm hibrittir. Örneğin standart ambalaj malzemeleri sepete eklenip anında alınabilir; özel baskılı kutular için teklif istenir; onaylı bayiler ise giriş yaptıktan sonra kendi iskonto ve vade koşullarıyla sipariş verir. Tek site içinde bu üç yol bulunabilir, fakat ürün bazında hangi satın alma aksiyonunun geçerli olduğu karışmamalıdır.
| Ürün | Önerilen işlem | Neden |
|---|---|---|
| Standart stoklu ürün | Sepete ekle | Fiyat/stok/teslimat öngörülebilir |
| Yüksek adetli standart ürün | Sepet veya teklif eşiği | Hacim indirimi / nakliye değişebilir |
| Özel üretim | Teklif iste | Teknik bilgi ve maliyet teyidi gerekir |
| Bayiiye özel ürün | Bayi girişi | Fiyat/ürün yetkisi hesap bazında |
| Fiyatı günlük değişen ürün | Teklif / güncel fiyat teyidi | Yanlış sabit fiyat riskini azaltır |
Kurgusal örnek: Akhisar’da endüstriyel sarf malzemesi toptancısı
Akhisar’da fabrikalara koli bandı, streç film, iş güvenliği sarfı ve özel baskılı ambalaj satan kurgusal “Ege Endüstriyel Tedarik” işletmesini düşünelim. Bu şirket ve tüm rakamlar öğretici örnektir; Akhisar Dijital'in gerçek müşterisi veya performans verisi değildir.
İşletme standart streç film ve koli bandında sabit liste fiyatı ve düzenli stok tuttuğu için bu ürünleri e-ticarete açar. Özel baskılı ambalajda ölçü, baskı, klişe ve minimum üretim miktarı değiştiği için teklif akışı kullanır. Büyük bayiler ise giriş yaptıktan sonra kendilerine özel fiyat ve vade ile sipariş verir. Ana ürün kataloğu herkese açıktır; fiyat ve işlem modeli SKU bazında belirlenir.
Hangi modeli seçmeniz gerektiğini 10 soruda belirleyin
| Soru | Evet ise eğilim | Hayır ise eğilim |
|---|---|---|
| Fiyat tüm müşterilerde aynı mı? | E-ticaret | Teklif / bayi portalı |
| Stok gerçek zamanlı güvenilir mi? | E-ticaret | Katalog / kontrollü sipariş |
| Kargo otomatik hesaplanabiliyor mu? | E-ticaret | Teklif / nakliye teyidi |
| Ürün standart mı? | E-ticaret | Teklif |
| Minimum sipariş kuralı basit mi? | E-ticaret/portal | Teklif/portal |
| Müşteriye özel iskonto var mı? | Bayi portalı | Açık fiyat mümkün |
| Vade/cari hesap var mı? | Bayi portalı | Kart/standart ödeme |
| Satış temsilcisi onayı şart mı? | Teklif/portal | E-ticaret |
| Tüketiciye de satış var mı? | E-ticaret yükümlülükleri ayrıca değerlendirilir | B2B akışı ağırlıklı |
| Ürün sayısı yüksek ve teknik mi? | Güçlü katalog/PIM | Basit ürün mimarisi yeterli olabilir |
Toptancı web sitesinde fiyat açık mı olmalı?
Fiyatı gizlemek her zaman B2B demek değildir; fiyatı açık göstermek de her zaman perakende değildir. Karar, fiyatın gerçekten herkes için geçerli olup olmadığına bağlıdır. Liste fiyatı yalnız referans niteliğindeyse bunu açıkça belirtin. Giriş yapan müşteriye özel fiyat gösteriyorsanız istemci tarafında gizleyip HTML içinde herkesçe erişilebilir halde bırakmayın; yetki sunucuda uygulanmalıdır.
- Herkese aynı fiyat: açık fiyat + sepet mantığı daha uygundur.
- Müşteri segmentine göre fiyat: login + hesap bazlı fiyatlama.
- Adet basamaklarına göre fiyat: miktar aralıklarını açık ve tutarlı gösterin.
- Günlük/kur bazlı fiyat: kesin fiyat yerine güncel teklif akışı daha güvenli olabilir.
- Özel üretim: “fiyat sorunuz” yerine gerekli teknik alanları olan teklif formu kullanın.
Minimum sipariş miktarı ve koli/palet kuralları nasıl yönetilmeli?
Toptan satışta müşterinin 1 adet seçip ödeme ekranında “minimum 24 adet” hatası görmesi kötü deneyimdir. Ürün kartında satış birimini baştan gösterin: adet, paket, koli, palet veya kilogram. Miktar seçici yalnız izinli basamakları sunmalı; paket içi adet değişiyorsa sipariş özeti toplam fiziksel miktarı da göstermelidir.
| Ürün | Satış birimi | Minimum | Sepette gösterim |
|---|---|---|---|
| Koli bandı | Koli | 1 koli = 36 adet | 1 koli / 36 adet |
| Streç film | Koli | 1 koli = 6 rulo | 2 koli / 12 rulo |
| İş eldiveni | Paket | 10 çift | 3 paket / 30 çift |
| Özel baskılı kutu | Adet | Teklifte belirlenir | Sepet yerine teklif miktarı |
Stok ile termin bilgisini birbirinden ayırın
Depoda fiziksel stok bulunması, müşteriye bugün sevk edilebileceği anlamına gelmeyebilir. Ayrılmış stok, kalite bekleyen ürün, toplama süresi veya taşıma planı farklı olabilir. Katalog sitesinde stok göstermiyorsanız kesin 'hemen teslim' iddiası kullanmayın. E-ticarette ise satılabilir stok kaynağı belirlenmeli ve ödeme/sipariş sırasında stok rezervasyonu politikası tanımlanmalıdır.
Kartla ödeme, havale ve vadeli hesap aynı sitede nasıl yönetilir?
Perakende e-ticaretin aksine toptancıda ödeme koşulu müşteri hesabına göre değişebilir. Yeni müşteri kartla veya havaleyle çalışırken onaylı bayi 30 gün vadeli sipariş verebilir. Kullanıcıya sunulan seçenekler hesap yetkisine göre gelmeli; vade seçeneğini yalnız arayüzde saklamak yerine sunucu tarafında kontrol edin. Kredi limiti veya gecikmiş bakiye siparişi etkiliyorsa sipariş 'reddedildi', 'incelemede' ve 'onaylandı' durumları ayrılmalıdır.
Kargo yerine nakliye teklifi gereken durumlar
Paletli, hacimli veya ağır ürünlerde standart kargo hesaplayıcısı gerçek maliyeti karşılamayabilir. İlçe, tonaj, palet sayısı, araç tipi ve teslim koşulları fiyatı etkiliyorsa sipariş toplamına yanlış nakliye ücreti eklemek yerine 'nakliye teyidi gerekli' akışı kullanılabilir. Hibrit modelde ürün bedeli sabit olsa bile sevkiyat kısmı satış ekibinin onayına bırakılabilir.
Katalog ve e-ticaretin ortak temeli: temiz ürün verisi
Hangi modeli seçerseniz seçin ürün verisi dağınıksa site sürdürülemez. SKU, ürün adı, kategori, marka, ölçü, teknik özellik, satış birimi, paket içeriği, görseller ve dokümanların tek doğrulanmış kaynağı olmalıdır. Aynı ürün ERP’de başka, Excel’de başka, web sitesinde başka isimle tutuluyorsa sipariş/teklif entegrasyonu hataya açıktır.
| Alan | Katalogda | E-ticarette ek ihtiyaç |
|---|---|---|
| SKU | Zorunluya yakın | Sipariş satırı için kritik |
| Ürün adı | Evet | Evet |
| Kategori | Evet | Filtre/arama için |
| Teknik özellik | Evet | Varyant seçimi için |
| Satış birimi | Gösterilmeli | Sepet hesabında kullanılmalı |
| Paket içeriği | Gösterilmeli | Miktar hesabına bağlanmalı |
| Fiyat | Opsiyonel | Satılabilir teklif için gerekli |
| Stok | Opsiyonel | Satılabilir stok kaynağı gerekir |
| Kargo ölçüsü/ağırlığı | Opsiyonel | Teslimat hesabında gerekli |
Katalog ve e-ticaret sayfalarında Product verisi aynı mı olmalı?
Google ürün yapılandırılmış veri dokümantasyonu, satın alınabilir merchant listing sayfaları ile diğer ürün içeriklerini ayrı değerlendiriyor. Müşterinin gerçekten satın alabildiği ürün sayfalarında fiyat, para birimi ve uygunluk gibi `Offer` verileri güncel olmalıdır. Yalnız katalog/teklif sayfasında gerçekte sunulmayan sabit fiyat veya stok bilgisiyle merchant listing işaretlemesi üretmeyin.
Varyantlı ürünlerde Google `ProductGroup` / `Product` yapısını destekliyor; ancak teknik işaretleme, sitedeki gerçek ürün ve satın alma modelinin yerine geçmez. Aynı ürünün renk, ebat veya paket seçenekleri varsa URL ve ürün veri mimarisi buna göre tasarlanmalıdır.
Katalogdan e-ticarete geçerken mevzuat açısından ne değişir?
Sitede yalnız ürün bilgisi gösterip satış temsilcisine yönlendirmek ile, internet üzerinden sipariş veya sözleşme oluşturmak aynı operasyon değildir. Ticaret Bakanlığı'nın ETBİS sayfası, kendine ait elektronik ticaret ortamında faaliyet gösteren hizmet sağlayıcıların kayıt yükümlülüğünü açıklıyor. Ayrıca 17 Ağustos 2026 tarihli tüketici bilgilendirmesinde internet ve mobil uygulama üzerinden tüketiciyle kurulan uzaktan satışların Mesafeli Sözleşmeler Yönetmeliği kapsamında olabileceği belirtiliyor.
Toptancı yalnız tacirlere satış yapsa bile e-ticaret, vergi, ticari ileti, sözleşme, KVKK ve sektör özelindeki yükümlülükleri kendi iş modeline göre değerlendirmelidir. Bu rehber hukuki görüş değildir. Özellikle B2B + B2C birlikte çalışacaksa tüketici akışı ile bayi akışını aynı metin ve koşullarla yönetmeyin.
CRM, ERP ve muhasebe entegrasyonu hangi modelde ne kadar gerekir?
Katalog sitesinde CRM entegrasyonu teklif taleplerini takip etmek için yeterli olabilir. E-ticarette ise ürün, stok, fiyat, sipariş, fatura ve kargo verilerinin hangi sistemden beslendiği daha kritik hale gelir. Bayi portalında müşteri fiyatı, cari hesap ve kredi limiti nedeniyle ERP entegrasyonu genellikle merkeze yaklaşır.
| Sistem | Katalog | Teklif | Bayi portalı | E-ticaret |
|---|---|---|---|---|
| CRM | Opsiyonel | Güçlü öneri | Gerekebilir | Sipariş sonrası satış sürecine göre |
| ERP / stok | Opsiyonel | Termin teyidi için | Genellikle önemli | Gerçek stok için önemli |
| Muhasebe | Düşük | Teklif sonrası | Cari/fatura için önemli | Sipariş/fatura için önemli |
| Ödeme | Yok | Genellikle yok | Hesaba göre | Temel bileşen |
| Kargo/nakliye | Bilgilendirme | Teklifte | Kurala göre | Siparişte otomasyon |
Hangi modelin daha iyi çalıştığını nasıl ölçersiniz?
Katalog sitesi için yalnız sayfa görüntülenmesini, e-ticaret için yalnız ciroyu izlemek eksiktir. Modelin görevine göre metrik seçin. Katalogda ürün görüntüleme → teklif talebi; teklif modelinde nitelikli talep → teklif → sipariş; bayi portalında aktif bayi → tekrar sipariş; e-ticarette ürün → sepet → ödeme → net gelir zinciri izlenmelidir.
| Model | Birincil sinyal | Ticari sonuç |
|---|---|---|
| Katalog | Ürün detay görüntüleme + iletişim | Nitelikli satış görüşmesi |
| Teklif | Tam ürün/miktar içeren talep | Gönderilen teklif ve kazanılan iş |
| Bayi portalı | Aktif giriş yapan bayi | Tekrar sipariş, işlem süresi |
| E-ticaret | Sepet/checkout | Ödenmiş sipariş, net gelir |
| Hibrit | Ürün bazlı doğru CTA kullanımı | Kanala göre teklif veya sipariş |
30 günde katalog mu e-ticaret mi kararını nasıl netleştirebilirsiniz?
- 1–3. gün: Son 50 siparişi inceleyip kaçında özel fiyat, vade, minimum adet, nakliye teyidi veya satış temsilcisi müdahalesi gerektiğini çıkarın.
- 4–6. gün: Ürünleri standart satın alınabilir, teklif gerektiren ve yalnız bayiye açık olarak üç gruba ayırın.
- 7–9. gün: Müşteri segmentlerini; son kullanıcı, küçük işletme, bayi ve kurumsal hesap olarak ayırın.
- 10–12. gün: Ürün veri kalitesini; SKU, satış birimi, paket, fiyat ve stok açısından denetleyin.
- 13–15. gün: Katalog, teklif, bayi portalı ve e-ticaret için gereken ekran/entegrasyon listesini çıkarın.
- 16–18. gün: ETBİS, sözleşme, tüketici, KVKK ve ticari ileti gereksinimlerini işletmenin gerçek modeli için yetkin danışmanla doğrulayın.
- 19–21. gün: En sık satılan 20 ürünle prototip ürün sayfası ve doğru CTA akışını test edin.
- 22–24. gün: Teklif/checkout verisinin CRM/ERP’ye nasıl aktarılacağını test senaryolarıyla netleştirin.
- 25–27. gün: Mobilde ürün bulma, miktar seçme, fiyat görme ve işlem tamamlama kullanıcı testi yapın.
- 28–30. gün: Tek bir model zorlamak yerine gerekiyorsa hibrit yapıyı seçip pilot ürün grubuyla yayına alın.
Yayına almadan önce son kontrol
| Kontrol | Beklenen durum |
|---|---|
| Satış modeli | Her ürün grubu için katalog/teklif/portal/e-ticaret kararı net |
| Fiyat | Gerçek ticari kuralla eşleşiyor |
| Miktar | Satış birimi ve minimum sipariş açık |
| Stok | Gösteriliyorsa güvenilir kaynaktan |
| Nakliye | Standart değilse yanlış otomatik fiyat yok |
| Bayi yetkisi | Fiyat ve ürün erişimi sunucuda kontrol ediliyor |
| Teklif | Kesin siparişten durum olarak ayrı |
| Entegrasyon | CRM/ERP veri sahipliği tanımlı |
| Product schema | Sayfadaki gerçek satın alma modelini yansıtıyor |
| Mevzuat | Gerçek satış modeline göre güncel kontrol yapılmış |
| Ölçüm | Teklif ve sipariş sonuçları ayrı izleniyor |
Sık sorulan sorular
Toptancı için sadece ürün kataloğu sitesi yeterli olabilir mi?
Evet. Fiyat, vade, nakliye veya ürün seçimi satış temsilcisi onayı gerektiriyorsa katalog + teklif modeli daha uygun olabilir. Katalog yine aranabilir ürünler, teknik bilgiler ve net teklif akışı sunmalıdır.
Bayi portalı ile e-ticaret sitesi aynı şey mi?
Hayır. Bayi portalında fiyat, ürün erişimi, vade, cari hesap ve onay kuralları müşteri hesabına göre değişebilir. Standart e-ticarette ise satın alma koşulları çoğunlukla daha genel ve otomatik uygulanır.
Toptan fiyatları web sitesinde herkese açık göstermek gerekir mi?
Hayır. Fiyat gerçekten herkese aynıysa açık göstermek mantıklı olabilir. Müşteriye özel iskonto veya günlük değişen fiyat varsa login veya teklif akışı daha doğru olabilir.
Katalog sitesi ETBİS’e kayıt olmak zorunda mı?
Bu, sitenin gerçek işlem modeline bağlıdır. Ticaret Bakanlığı kendine ait elektronik ticaret ortamında faaliyet gösteren hizmet sağlayıcıların ETBİS kayıt yükümlülüğünü açıklar. Yalnız bilgi/iletişim ile internetten sözleşme veya sipariş oluşturma arasındaki hukuki ayrım işletmenin gerçek akışına göre değerlendirilmelidir.
B2B toptancı aynı sitede hem teklif hem e-ticaret kullanabilir mi?
Evet. Standart stoklu ürünler sepete açılırken özel üretim veya yüksek hacimli ürünler teklif akışına yönlendirilebilir; onaylı bayiler ayrıca login sonrası özel fiyat görebilir.
Google Product structured data katalog sitesinde kullanılabilir mi?
Ürün bilgisi için Product işaretlemesi kullanılabilir; ancak satın alınabilir merchant listing işaretlemesi gerçek fiyat, stok ve Offer verisiyle eşleşmelidir. Katalogda olmayan satış koşullarını structured data içinde uydurmayın.
Projenizi Anlatın 