Çok Mağazalı E-Ticaret Yazılımı Seçim Rehberi

Birden fazla markayı, domain’i veya fiyat politikasını aynı ekiple yönetmek isteyen işletmeler sıklıkla tek bir altyapı arar. Çok mağazalı e-ticaret yazılımı, bu ihtiyacı tek admin panelinden birden fazla vitrin açarak karşılar; her mağaza kendi temasına, stok kuralına ve ödeme/kargo ayarına sahip olabilir. Bu rehber, çok mağaza mimarisini çok dilli kurulumdan ve çok satıcılı pazaryerinden net biçimde ayırır; KOBİ, e-ticaret ve kurumsal ekiplerin ne zaman çok mağazaya geçmesi, ne zaman ayrı kurulum yapması gerektiğini adım adım netleştirir.

Çok mağazalı e-ticaret yazılımı nedir?

Çok mağazalı e-ticaret yazılımı, aynı işletmenin birden fazla marka veya domain vitrinini ortak bir çekirdek üzerinde yönetmesini sağlar. Ürün kataloğu, stok motoru, sipariş akışı ve kullanıcı paneli paylaşılır; vitrin tarafında ise fiyat, kampanya, tema, dil tercihi ve kargo politikası mağaza bazında ayrılabilir.

Pratikte bu mimari şu senaryolarda öne çıkar:

Aynı ürün grubunu farklı marka kimlikleriyle satmak (örneğin premium ve ekonomik vitrin)
Farklı domain’lerde bölgesel veya segment odaklı mağazalar açmak
Bayi/kurumsal ve son kullanıcı vitrinlerini tek operasyon ekibiyle yürütmek
Aynı stok havuzunu paylaşan ama farklı fiyat ve kampanya kurgusu isteyen kanallar kurmak

Kritik nokta şudur: buradaki “mağaza”, üçüncü taraf satıcıların kendi dükkânını açtığı pazaryeri modeli değildir. Mağazalar sizin markalarınıza aittir; sizin ekibiniz yönetir, sizin stok ve faturalama politikanız geçerlidir.

Çok mağaza, çok dil ve çok satıcılı pazaryeri farkı

Seçim sürecinde en sık karıştırılan üç kavramı baştan ayırmak, yanlış ürün satın almayı engeller.

Çok mağaza (multi-store)

Aynı işletmenin birden fazla vitrinini tek admin’den yönetmesidir. Her vitrin ayrı domain, tema, fiyat listesi ve stok politikası taşıyabilir. Alıcı tarafında mağazalar bağımsız site gibi görünür; arka planda operasyon birleşiktir.

Çok dil / çok para birimi

Aynı vitrinin farklı dillerde ve para birimlerinde sunulmasıdır. Ürün, kategori ve ödeme akışı bir mağazanın içinde yerelleşir. Bu, “çok mağaza” demek değildir; dil paneli, çeviri iş akışı ve vergi/para birimi kuralları ayrı değerlendirilir. Uluslararası görünürlük planlıyorsanız e-ihracat için uluslararası SEO gereksinimlerini de mağaza mimarisiyle birlikte düşünmek gerekir.

Çok satıcılı pazaryeri

Farklı satıcıların kendi mağazalarını açtığı, komisyon ve satıcı paneli olan modeldir. Sipariş, stok ve ödeme sorumluluğu satıcıya dağılır; platform ise aracıdır. Sizin markalarınızı yönetmek istediğiniz senaryoda pazaryeri yazılımı genelde gereksiz karmaşıklık üretir.

Özellik	Çok mağaza	Çok dil	Pazaryeri
Sahiplik	Aynı işletme	Aynı mağaza	Çok satıcı
Ayrı domain/vitrin	Evet (tipik)	Genelde hayır	Evet (satıcı bazlı)
Ayrı fiyat/stok politikası	Mağaza bazlı	Sınırlı / dil bazlı	Satıcı bazlı
Admin odağı	Merkezi marka operasyonu	Yerelleştirme	Komisyon ve satıcı yönetimi
Tipik ihtiyaç	Çok marka / çok domain	Çok ülke dil desteği	Platform iş modeli

Kısaca: “Aynı ürünü iki marka sitesinde farklı fiyattan satacağım” derseniz çok mağaza; “Aynı sitede İngilizce ve Arapça sunacağım” derseniz çok dil; “Başkalarının dükkân açmasını istiyorum” derseniz pazaryeri doğru yoldur.

Ortak depo mu ayrı stok mu: senaryo matrisi

Çok mağazalı mimarinin kalbi stok kurgusudur. Yazılım seçerken “stok paylaşılıyor mu, mağaza bazında ayrılabiliyor mu?” sorusunu demo sırasında mutlaka test edin.

Senaryo 1: Ortak depo, paylaşılan stok

Tek depodan beslenen markalar için uygundur. Bir mağazada satılan adet diğer mağazanın müsaitliğini de düşürür. Avantajı sade operasyondur; riski ise bir kanaldaki agresif kampanyanın diğer vitrini stoksuz bırakmasıdır. Bu modelde sipariş önceliği, rezervasyon süresi ve minimum stok uyarıları net tanımlanmalıdır.

Senaryo 2: Ortak katalog, mağaza bazlı stok kotası

Ürün kartı ortaktır; her mağazaya stok kotası veya ayrı depo bağlanır. Örneğin toplam 200 adetten A markasına 120, B markasına 80 atanır. Marka bazlı kampanya güvenliği artar; sayım ve transfer süreçleri biraz daha disiplin ister.

Senaryo 3: Tamamen ayrı stok ve fiyat politikası

Aynı SKU kodu görsel olarak benzer olsa bile mağazalar bağımsız stok ve fiyat taşır. Özellikle farklı tedarik zinciri, farklı iade kuralı veya farklı hedef kitle varsa tercih edilir. Veri tutarlılığı için ürün bilgisi merkezi (veya sıkı senkron) gerekir; aksi halde varyant ve açıklama sapmaları büyür.

Senaryo 4: Hibrit (bazı ürünler ortak, bazıları mağazaya özel)

Kurumsal ve KOBİ ekiplerinin en sık ihtiyaç duyduğu modeldir. Ana katalog paylaşılır; özel koleksiyonlar veya private label ürünler yalnızca ilgili vitrinde görünür. Yazılımın “ürünü mağazaya bağla / gizle / fiyat override et” yeteneği burada kritiktir.

Seçim ipucu: Sadece “çok mağaza destekli” demek yetmez. Demo’da aynı SKU için iki mağazada farklı fiyat girin, bir mağazadan sipariş verin ve diğer mağazanın stok ekranının nasıl davrandığını izleyin. Bu tek test, broşür metninden daha çok şey söyler.

Domain, SSL, ödeme ve kargo ayrımı

Çok mağazalı e-ticaret yazılımının operasyonel değeri, vitrinlerin dışarıdan gerçekten bağımsız hissettirmesinden gelir. Bunun için teknik ve ticari ayrım net olmalıdır.

Domain ve SSL

Her mağaza kendi domain veya alt domain’iyle yayınlanabilmeli
SSL sertifikaları mağaza bazında sorunsuz bağlanmalı
Canonical, sitemap ve robots kuralları mağaza bazında yönetilebilmeli (SEO karışıklığını önlemek için)
Tema, logo, renk ve e-posta şablonları mağazaya özel olmalı

Ödeme ayrımı

Bazı işletmeler tüm mağazalarda aynı sanal POS’u kullanır; bazıları marka veya şirket tüzel kişiliği farkı nedeniyle ayrı üye işyeri ister. Yazılımda mağaza bazlı ödeme yöntemi aç/kapa, taksit profili ve banka hesabı eşlemesi arayın. Fatura unvanı ve e-arşiv/e-fatura akışının hangi tüzel kişiye bağlandığını da peşinen netleştirin.

Kargo ve teslimat politikası

Aynı depodan çıkan ürünler bile mağazaya göre farklı kargo firması, ücretsiz kargo eşiği veya teslimat süresi vaadi taşıyabilir. Mağaza bazlı kargo kuralı yoksa “premium marka” vitrini ile “outlet” vitrini aynı vaadi paylaşmak zorunda kalır; bu da marka algısını bozar.

Entegrasyon katmanında sipariş, stok ve lojistik akışlarını bağlarken API entegrasyonu planı çıkarmak, mağaza çoğaldıkça ortaya çıkan hata yüzeyini küçültür. Webhook ve test ortamı olan yazılımlar, canlıda stok çakışmasını daha kontrollü yönetmenizi sağlar.

Kullanıcı yetkisi ve mağaza bazlı raporlama

Çok mağaza yönetiminin en görünmeyen riski, yetki dağınıklığıdır. Tek admin hesabıyla herkesin her mağazaya müdahale etmesi; fiyat hatası, yanlış kampanya ve veri sızıntısı üretir.

Yetki modeli nasıl olmalı?

Süper admin: Tüm mağazalar, kullanıcılar, entegrasyonlar
Mağaza yöneticisi: Yalnız atandığı mağazanın ürün, sipariş, içerik ve kampanya alanları
Operasyon / depo: Stok ve sevkiyat; fiyat ve tema yetkisi yok
Pazarlama: Kampanya ve içerik; ödeme/kargo ayarlarına kapalı
Muhasebe / finans: Sipariş ve fatura raporları; katalog düzenleme kapalı

İdeal olarak rol ataması mağaza kapsamıyla birleşir: “Ahmet yalnızca A markasının siparişlerini görsün, B markasının fiyatını değiştiremesin.” Onay gerektiren işlemler (toplu fiyat güncelleme, iade iadesi eşiği, kupon tanımı) için iş akışı otomasyonu ve onay süreçleri düşünmek, çok mağazalı operasyonda hata maliyetini düşürür.

Mağaza bazlı raporlama

Toplam ciroyu görmek yetmez. En az şu kırılımlar panelde veya dışa aktarımda bulunmalıdır:

Mağaza bazlı sipariş adedi, ciro, ortalama sepet
Mağaza bazlı iade / iptal oranı
Ürün ve kategori performansı (hangi mağazada ne satıyor?)
Kampanya etkisi (kupon, ücretsiz kargo, paket)
Stok devir ve kritik stok (mağaza veya depo bazlı)

Kurumsal ekipler için ek beklenti, mağazalar arası karşılaştırma ve ortak ürünün kanallar arası katkısını görmektir. Raporları yalnızca “güzel grafik” olarak değil, stok transferi ve fiyat kararına bağlayacak şekilde okuyun.

Ne zaman çok mağazaya geçilmeli, ne zaman ayrı kurulum gerekir?

Çok mağaza her zaman en iyi yol değildir. Kararı, operasyonel ortaklık derecesi belirler.

Çok mağazaya geçmek mantıklı olduğunda

Markalar aynı ürün havuzunun büyük kısmını paylaşıyor
Aynı depo, aynı operasyon ekibi ve aynı muhasebe entegrasyonu kullanılacak
Fiyat, tema ve kampanya farkı istiyorsunuz ama sipariş süreçleri benzer
Tek panelden yetki ve rapor konsolidasyonu öncelikli
Yeni vitrin açma sıklığınız yüksek; her seferinde sıfırdan kurulum istemiyorsunuz

Ayrı kurulum daha doğru olduğunda

Markalar tamamen farklı ürün, tedarikçi ve iade politikasına sahip
Tüzel kişilik, vergi ve ödeme altyapısı birbirinden kopuk
Bir markanın özel geliştirmesi diğerini yavaşlatma / bozma riski taşıyor
Güvenlik ve veri izolasyonu (müşteri verisi, B2B fiyat listeleri) çok katı
Ekipler bağımsız çalışıyor; ortak admin avantajdan çok çatışma üretiyor

Pratik bir karar kuralı: “Bu iki vitrinin stok, sipariş ve müşteri verisini aynı veritabanında tutmak bana operasyonel hız mı kazandırıyor, yoksa risk mi yüklüyor?” Hız kazandırıyorsa çok mağaza; risk yüklüyorsa ayrı kurulum veya en azından güçlü veri izolasyonlu mimari tercih edin.

Çok mağazalı yazılım seçim kontrol listesi

Demo ve teklif aşamasında aşağıdaki maddeleri tek tek işaretleyin. “Var” demek yetmez; mağaza A ve mağaza B ile canlı senaryo çalıştırın.

Mağaza oluşturma: domain, tema, dil ve para birimi bağımsız mı?
Ürün bağlama: ortak katalog + mağaza özel ürün + gizleme destekleniyor mu?
Fiyat override: mağaza bazlı liste fiyatı, indirim ve kupon alanı var mı?
Stok modeli: paylaşılan / kotalı / depo bazlı seçenekler test edildi mi?
Ödeme ve kargo: mağaza bazlı yöntem, taksit ve kargo kuralı çalışıyor mu?
Yetki matrisi: kullanıcıyı belirli mağazalara kilitleyebiliyor musunuz?
Raporlama: mağaza kırılımlı ciro, iade ve stok raporları dışa aktarılabiliyor mu?
SEO ayrımı: sitemap, meta, canonical ve mağaza bazlı URL kontrolü mümkün mü?
Entegrasyon: ERP, kargo, e-fatura ve pazarlama araçları mağaza bağlamı taşıyor mu?
Yedekleme ve güncelleme: bir mağazanın özel eklentisi tüm sistemi kilitliyor mu?

HazırSoft tarafında hazır e-ticaret ve script seçeneklerini incelerken de aynı kontrol listesini kullanabilirsiniz; amaç özellik listesini ezberlemek değil, sizin stok–fiyat–yetki gerçekliğinize oturan mimariyi bulmaktır. Katalogdaki hazır yazılımlar arasından ilerlerken “çok mağaza” ifadesinin hangi stok ve domain modelini kapsadığını yazılı olarak netleştirin.

Uygulanabilir geçiş planı

Karar verildikten sonra geçişi tek seferde devasa bir proje gibi değil, kontrollü bir pilot gibi yönetin.

Kapsam netleştirin: Hangi markalar çok mağazaya girecek, hangileri dışarıda kalacak?
Stok matrisini yazın: Ortak, kotalı veya ayrı; depo ve min stok kurallarını belgeleyin.
Pilot mağaza seçin: En düşük riskli vitrinde domain, ödeme, kargo ve sipariş akışını doğrulayın.
Yetkileri kurun: Rolleri mağaza bazında atayın; süper admin sayısını bilinçli sınırlayın.
Veri kurallarını sabitleyin: Ürün adı, görsel, varyant ve fiyat kaynağı kim? Override kimde?
Rapor setini tanımlayın: Haftalık mağaza skoru (ciro, iade, stok kritik, sepet ortalaması).
İkinci mağazayı açın: Pilot stabil olduktan sonra fiyat ve kampanya farkını devreye alın.

Bu plan, “her şeyi bir gecede birleştirelim” yaklaşımından daha yavaş görünür; ancak stok çakışması ve yanlış fiyat yayınını büyük ölçüde azaltır.

Sonuç: Doğru mimari, doğru ayrımla başlar

Çok mağazalı e-ticaret yazılımı, birden fazla marka veya domain’i tek operasyon omurgasında toplamak isteyen işletmeler için güçlü bir modeldir. Başarı, yazılımın “çok mağaza” demesinden değil; stok senaryosunu, domain/ödeme ayrımını, yetki matrisini ve mağaza bazlı raporlamayı sizin iş gerçeğinize uydurmasından gelir. Pazaryeri ile çok dili birbirine karıştırmadan, ortak depo ile ayrı stok arasındaki farkı yazılı hale getirerek seçim yapın.

HazırSoft ile ilerlerken önce mağaza sayınızı, stok politikasını ve tüzel/ödeme ayrımını netleştirin; ardından demo’da gerçek SKU ve gerçek sipariş senaryosuyla test edin. Doğru kurgulandığında çok mağaza mimarisi, ayrı sitelerin dağınıklığını azaltır; yanlış kurgulandığında ise tüm markaları aynı hataya bağlar. Bu yüzden seçim kriterlerinizi özellik listesinden değil, operasyon senaryolarından kurun.