Çoklu mağaza denince çoğu kişi aklına şunu getirir: her marka için ayrı bir hosting, ayrı bir veritabanı, ayrı bir yönetim ekranı ve tabii ayrı bir stok listesi. İkinci siteni açtığın gün bunun makul göründüğünü biliyorum. Üçüncü siteyi açtığın gün ise gerçek ortaya çıkıyor: aynı kodu üç kez güncelliyorsun, aynı e-pin kodunu yanlışlıkla iki farklı müşteriye satıyorsun, ve hangi markanın gerçekten kâr ettiğini sorduğunda elinde net bir cevap olmuyor. Bu bir büyüme değil, çoğaltılmış bir kaos.
Ciddi hacimle çalışan bayilerin yaptığı şey ise tam tersi. Onlar mağaza sayısını artırırken yönetim yüzeyini artırmıyor. Tek bir e-pin satış scripti çekirdeği üstünde, alan adına göre ayrışan ama stoğu, muhasebesi ve tedarikçi bağlantısı ortak olan bir yapı kuruyorlar. Bu yazıda o mimariyi parça parça açıyorum: stok havuzu nasıl paylaşılır, fiyat neye göre mağazadan mağazaya değişir, hangi veri izole kalmak zorundadır ve tek panele geçerken hangi üç hatayı yaparsan geri dönüşü pahalı olur.
Neden üç ayrı kurulum aslında üç ayrı işletme demek?
Teknik olarak üç kurulum kopyala-yapıştır gibi görünür. Ama işletme tarafında her kurulum kendi takvimini, kendi hata geçmişini ve kendi sürüm numarasını üretir. Bir ödeme sağlayıcısı API'sini güncellediğinde üç yerde ayrı test yaparsın. Bir güvenlik yaması çıktığında üçüncüsünü unutursun ve tam da unuttuğun yerden sızarsın. Daha kötüsü, raporlama parçalanır: toplam ciroyu görmek için üç ayrı ekrandan Excel'e veri taşımak zorunda kalırsın ve bu tabloyu haftada bir defadan fazla yapmazsın. Yapmadığın ölçüm, yönetemediğin işletme demektir.
Tek panel yaklaşımında ise mağaza bir kayıttır, bir kurulum değil. Alan adı, logo, tema rengi, para birimi, kâr marjı ve hangi kategorilerin görüneceği tek bir mağaza satırında tutulur. Aynı dijital ürün satış scripti çekirdeği her istekte gelen alan adına bakar, o mağazanın ayarlarını yükler ve vitrini ona göre kurar. Sen bir hata düzelttiğinde üç mağaza birden düzelir. Bir kampanya kurduğunda hangi mağazalarda geçerli olacağını kutucukla seçersin.
Ortak stok havuzu mu, mağaza bazlı stok mu? İkisi de doğru olabilir
En kritik karar burada veriliyor. Ortak havuzda bir e-pin kodu tek bir yerde durur ve hangi mağazadan satılırsa oradan düşer. Avantajı çok net: 200 adet kod aldığında bunu üçe bölmek zorunda kalmazsın, hangi mağaza satarsa oradan gider, ölü stok neredeyse sıfırlanır. Riski de aynı ölçüde net: kilit mekanizması zayıfsa, iki mağazadan aynı anda gelen sipariş aynı kodu alabilir. Bu yüzden ciddi bir e-pin yazılımı kod teslimini veritabanı seviyesinde satır kilidiyle ve tek yönlü durum geçişiyle yapar; kod "satıldı" olduktan sonra hiçbir sorgu onu tekrar aday listesine alamaz.
Mağaza bazlı stok ise farklı markalar için farklı tedarikçiden alım yaptığında mantıklıdır. Bayilik anlaşman gereği belirli bir kontenjanı yalnızca bir markada satman gerekiyorsa, o partiyi o mağazaya etiketlersin. İyi bir kurulum ikisini birden destekler: varsayılan havuz ortaktır, istisnalar etiketlenir. Aşağıdaki tablo, üç modelin pratikte nasıl davrandığını karşılaştırıyor.
| Kriter | Ayrı kurulumlar | Tek panel + ortak havuz | Tek panel + mağaza stoğu |
|---|---|---|---|
| Bakım yükü | Mağaza sayısıyla çarpılır | Sabit | Sabit |
| Ölü stok riski | Yüksek | Çok düşük | Orta |
| Çift satış riski | Yok (izole) | Kilit doğruysa yok | Yok |
| Tedarikçi anlaşması esnekliği | Yüksek | Düşük | Yüksek |
| Konsolide ciro raporu | Manuel | Anlık | Anlık |
| Yeni mağaza açma süresi | Saatler | Dakikalar | Dakikalar |
Fiyat ve marj her mağazada aynı olmak zorunda mı?
Kesinlikle değil ve zaten olmamalı. Aynı kodu bir mağazada perakende müşteriye, diğerinde toptan bayiye satıyorsan farklı fiyat kurgusu şart. Doğru kurulumda ürünün bir maliyet alanı vardır ve mağaza bazında marj katsayısı veya sabit fark tanımlanır. Böylece tedarikçi zam yaptığında tek bir maliyet alanını güncellersin, üç mağazanın satış fiyatı da kendi kuralına göre yeniden hesaplanır. Bunu elle yönetenler, zam gününde en az bir mağazada zararına satış yapar.
Aynı mantık kur farkı için de geçerlidir. Dövizle alım yapıyorsan maliyeti dövizle tut, satış fiyatını güncel kurla hesapla ve mağazaya özel bir kur tamponu tanımla. Bu, tek panelin en somut kazancıdır: fiyat politikası tek yerde, uygulaması çok yerdedir.
Çoklu mağaza kuran bayilerde zaman kaybının dağılımı
- Stok ve kod yönetimi 45%
- Fiyat ve kur güncelleme 25%
- Raporlama ve mutabakat 20%
- Tema ve içerik bakımı 10%
Hangi veri ortak kalmalı, hangisi kesinlikle izole olmalı?
Burada acemi hatası şudur: her şeyi ortaklaştırmak. Stok, ürün kataloğu, tedarikçi bağlantıları ve maliyet verisi ortak kalabilir; hatta kalmalı. Ancak müşteri hesapları, cüzdan bakiyeleri, sipariş geçmişi ve iletişim izinleri mağaza sınırında durmalıdır. Bir müşteri A markasından üye oldu diye B markasında da hesabı varmış gibi davranmak, hem kullanıcı güvenini zedeler hem de veri işleme açısından savunması zor bir alan yaratır.
Pratik kural şu: işletmenin verisi ortak, müşterinin verisi mağazaya ait. Panelde tek ekrandan tüm mağazaların siparişlerini görmen, müşterinin iki markanın birbiriyle ilişkili olduğunu görmesi anlamına gelmez. Pinova gibi çoklu mağaza için tasarlanmış bir dijital ürün satış yazılımı bu ayrımı mimari seviyede kurar; sonradan eklenen bir yamayla değil.
İkinci mağazanı açmadan önce birinci mağazada bir kod tesliminin uçtan uca kaç saniye sürdüğünü not al. Tek panele geçtikten sonra aynı ölçümü tekrarla. Süre uzadıysa kilit veya sorgu tarafında bir sorun var demektir; hacim artmadan fark edersen ucuz atlatırsın.
Tek panele geçerken hangi sırayla ilerlemelisin?
Sırayı yanlış kurmak, projenin en pahalı hatasıdır. Önce ürün kataloğunu ve maliyet verisini temizle; çünkü kirli katalogla yapılan birleştirme kirliliği üçe katlar. Sonra stok havuzunu taşı ve en az bir hafta tek mağazayla çalıştır. Ardından ikinci mağazayı yalnızca vitrin olarak ayağa kaldır, siparişleri düşük hacimde test et. Ödeme ve otomatik teslimatı en son bağla. Bu sıralama sana her aşamada geri dönebileceğin bir nokta bırakır.
Aşağıdaki kontrol listesini geçiş gününde açıp yanına işaret koy. Maddelerin hepsi "tamam" olmadan ikinci mağazaya trafik gönderme.
| Kontrol | Neden önemli | Durum |
|---|---|---|
| Alan adı → mağaza eşleşmesi doğrulandı | Yanlış eşleşme yanlış fiyatla satış demek | ☐ |
| Kod teslim kilidi eşzamanlı test edildi | Çift satışın tek panzehiri | ☐ |
| Mağaza bazlı marj kuralları tanımlı | Zam gününde zararına satışı önler | ☐ |
| Müşteri verisi mağaza sınırında izole | Güven ve veri uyumu | ☐ |
| Her mağaza için ayrı fatura/ünvan bilgisi | Muhasebe mutabakatı | ☐ |
| Konsolide ve mağaza bazlı rapor ayrı ayrı çalışıyor | Hangi markanın kâr ettiğini görmek | ☐ |
| Stok kritik seviye uyarısı havuz üstünden kurulu | Ortak havuzda tükenme daha hızlı olur | ☐ |
Bu yapı gerçekten ölçekleniyor mu, yoksa sadece kulağa mı hoş geliyor?
Ölçeklenme sorusu aslında iki şeye indirgenir: yeni mağaza açmanın maliyeti ve toplam hacim arttığında teslimatın davranışı. Birincisinde tek panel tartışmasız kazanır; yeni bir marka denemek istediğinde risk neredeyse sıfıra iner, tutmazsa kapatırsın. İkincisinde belirleyici olan kodun kendisidir: sipariş kuyruğu, teslim kilidi ve tedarikçi entegrasyonu düzgün yazıldıysa mağaza sayısı yükü doğrusal artırmaz, çünkü asıl yük sipariş adedinden gelir, mağaza adedinden değil.
Yani doğru soru "kaç mağaza açabilirim" değil, "altyapım günde kaç teslimatı hatasız yapabiliyor" olmalı. Bunu netleştirdiğinde çoklu mağaza bir yük değil, aynı altyapıdan daha fazla gelir çıkarma yöntemine dönüşür. Özellikleri karşılaştırmak istersen özellikler bölümüne, lisans seçeneklerini görmek istersen fiyatlandırmaya göz at.
Tek panelden üç markayı yönetmeye hazır mısın?
Pinova, çoklu mağaza mantığını sonradan eklenen bir modül olarak değil, çekirdek mimari olarak kurar. Stok havuzu ortak, müşteri verisi izole, raporlar hem konsolide hem mağaza bazlı.
Aynı script ile kaç mağaza açabilirim?
Teknik bir üst sınır yoktur; sınırı sunucu kapasiten ve lisans şartların belirler. Pratikte yükü belirleyen mağaza sayısı değil, günlük sipariş ve teslimat adedidir. Beş vitrinle günde 100 sipariş, tek vitrinle günde 100 siparişten daha ağır değildir.
Ortak stok havuzunda aynı kod iki kez satılır mı?
Teslim akışı veritabanı seviyesinde satır kilidiyle yazıldıysa satılmaz. Kod bir siparişe atandığı anda durumu değişir ve tekrar aday havuzuna dönemez. Kurulum sonrası eşzamanlı sipariş testi yaparak bunu mutlaka doğrula.
Her mağazada farklı ödeme yöntemi kullanabilir miyim?
Evet. Ödeme sağlayıcı ayarları mağaza kaydına bağlanabildiği için bir markada havale ve kredi kartı, diğerinde yalnızca bakiye ile satış açık olabilir. Muhasebe ayrışması için her mağazaya kendi ünvan ve fatura bilgisini tanımlamak da mümkündür.
Mevcut ayrı kurulumlarımı birleştirmek veri kaybına yol açar mı?
Doğru sırayla yapıldığında hayır. Önce katalog ve maliyet verisi temizlenir, sonra stok taşınır, en son müşteri ve sipariş geçmişi mağaza etiketiyle aktarılır. Her adımda yedek alındığı ve tek mağazayla bir süre çalışıldığı sürece geri dönüş noktan hep elinde kalır.
Çoklu mağaza, doğru kurulduğunda markanı çoğaltmak değil, tek bir operasyonu birden fazla vitrine açmak demektir. Bu yapının panelde nasıl göründüğünü, mağaza kaydının hangi alanları taşıdığını ve stok havuzunun ekranda nasıl davrandığını kendi gözünle görmek istersen canlı demo üzerinden gez, sonra lisans adımına geç.