Tek Panelden Beş Mağaza Çeviren Satıcıların Sessiz Düzeni: Epin Satış Scripti ile Çok Mağaza Kurgusunun İçini Sana Açıyorum

Bu sektörde bir süre kalırsan aynı hikâyeyi defalarca duyarsın: tek bir site iyi çalışmaya başlar, sonra ikinci bir marka açma isteği doğar. Belki farklı bir kitleye hitap etmek istersin, belki bir arkadaşınla ortak bir vitrin kuracaksın, belki de bayilerin kendi adlarıyla satış yapmak istiyor. Çoğu kişinin buradaki ilk refleksi nettir: "Aynı kurulumu bir kez daha yaparım, iki panel yönetirim." Kulağa mantıklı gelir, çünkü kısa vadede gerçekten çalışır.

Ama ikinci ayın sonunda tablo değişir. Aynı kod havuzunu iki yerde takip etmeye başlarsın, bir mağazada satılan kodun diğerinde de stokta göründüğünü fark edersin, iki ayrı muhasebe raporunu elle toplarsın ve bir ürünün fiyatını güncellemek için iki panele girersin. Asıl mesele şudur: çok mağaza bir kopyalama işi değil, bir katmanlama işidir. Doğru kurulmuş bir epin satış scripti tek bir çekirdek üzerine birden fazla vitrin bindirir; stok, fiyat, yetki ve muhasebe birbirinden bağımsız olarak ayarlanabilir. Bu yazıda o katmanların her birini ayrı ayrı açıyorum.

Çoğu kişi çok mağazayı "aynı scripti beş kez kurmak" sanır — neden yanlış?

Beş ayrı kurulum demek beş ayrı veritabanı, beş ayrı güncelleme, beş ayrı yedek ve beş ayrı ödeme entegrasyonu demektir. Yönetim maliyeti mağaza sayısıyla doğru orantılı büyür; yani ölçeklenmez. Daha kötüsü, veriler arasında hiçbir bağ yoktur. Bir müşterinin ikinci mağazada da alışveriş yaptığını göremezsin, toplam stok durumunu tek ekranda bilemezsin.

Doğru mimari, tek veritabanı üzerinde mağaza kimliği (store_id) taşıyan bir yapıdır. Ürün, sipariş, müşteri, fiyat ve içerik kayıtlarının her biri hangi mağazaya ait olduğunu bilir. Ortak olması gereken şeyler — kod havuzu, tedarikçi entegrasyonları, temel ürün tanımları — tek yerde durur; mağazaya özel olması gerekenler ise vitrin bazında ayrışır. Böylece altıncı mağazayı açmanın maliyeti, ikincisini açmanın maliyetiyle neredeyse aynı olur.

Ortak stok havuzu mu, izole stok mu?

Bu, çok mağaza kurgusunun en kritik kararıdır ve tek bir doğru cevabı yoktur. Ortak havuzda tüm mağazalar aynı kod deposundan beslenir. Avantajı sermaye verimliliğidir: 500 kodu beş mağaza arasında bölmek zorunda kalmazsın, talep nereden gelirse oradan satılır. Dezavantajı ise bir mağazanın diğerinin stoğunu tüketebilmesidir; özellikle bir vitrin agresif kampanya yaparsa diğerleri stoksuz kalır.

İzole stokta her mağazanın kendi kotası vardır. Ortaklı veya bayili yapılar için bu daha adil, muhasebesi daha net bir modeldir. En olgun çözüm ise melez modeldir: ortak havuz artı mağaza bazlı ayrılmış rezerv. Yani her vitrine minimum garanti kotası tanımlarsın, üzerini ortak havuzdan çeker. Pinova tarafında ürün bazında bu davranışı seçebilmek, aynı sistemde hem kendi markalarını hem bayilerini barındırmanı sağlar.

Fiyatlandırma katmanı: aynı ürün, farklı vitrin, farklı marj nasıl olur?

Çok mağazanın asıl ticari gerekçesi burada saklıdır. Aynı e-pini iki farklı kitleye iki farklı fiyattan satabiliyorsan, aynı stoktan iki farklı marj elde edersin. Bunun için fiyatın ürüne değil, ürün ile mağaza kesişimine tanımlanması gerekir. Üç seviyeli bir yapı işini görür: temel maliyet fiyatı, mağaza bazlı kural (yüzde veya sabit ek), müşteri grubu bazlı indirim.

Burada dikkat etmen gereken tuzak, fiyat kurallarının üst üste binmesidir. Mağaza %15 ekliyor, kampanya %10 indirim veriyor, bayi grubu %12 iskonto alıyorsa sonuç maliyetin altına düşebilir. Bu yüzden her fiyat motorunda bir taban koruma eşiği tanımlanmalı: hesaplanan fiyat maliyetin belirlediğin yüzde üstüne inemez. Bu tek ayar, çok mağazalı yapılarda yılda kaç kez zarar satışını engellediğini sonradan fark edeceğin türden bir korumadır.

Yetki ve rol matrisi: kim hangi mağazanın kasasını görebilir?

Tek mağazada yetki meselesi basittir: sen ve belki bir destek personeli. Çok mağazada ise işin özü budur. Bir bayinin kendi siparişlerini görmesi gerekir ama diğer bayinin cirosunu asla görmemelidir. Destek ekibi siparişleri görebilmeli ama maliyet fiyatına erişmemelidir. Muhasebe raporlara erişmeli ama ürün silememelidir.

Bunu sağlıklı kurmanın yolu, yetkileri kişiye değil role, rolü de mağaza kapsamına bağlamaktır. Yani "destek" rolü sabittir; o rolü A ve C mağazasına atarsın. Kişi değiştiğinde rolü değiştirmezsin, sadece atamayı taşırsın. Ayrıca her hassas işlem — fiyat değişikliği, kod havuzuna müdahale, bakiye düzeltmesi — kim yaptı, ne zaman yaptı, eski değer neydi bilgisiyle kayda geçmeli. İşletme büyüdükçe bu kayıtlar bir güvenlik önlemi olmaktan çıkıp anlaşmazlıkları çözen bir hakeme dönüşür.

Muhasebe tek yerde mi toplanmalı, ayrı mı tutulmalı?

Cevap: ikisi de. Operasyonel olarak tek konsolide ekran istersin — bugün beş vitrinden toplam ne sattım, net marjım ne. Ama yasal ve ortaklık açısından her vitrinin kendi defteri ayrı durmalıdır. Pratikte bu, tek veri tabanında mağaza bazlı etiketlenmiş hareketler ve iki farklı rapor görünümü demektir: konsolide ve mağaza bazlı.

Ortaklı yapılarda bir adım daha gerekir: gelir paylaşımı. Her siparişin üzerinde satış mağazası, maliyet, komisyon oranı ve hak eden taraf bilgisi taşınmalı. Böylece ay sonunda "kim kime ne kadar borçlu" sorusu tartışmaya açık olmaz, rapordan okunur. Bu şeffaflık, ortaklıkların teknik nedenlerle bozulmasını engelleyen en somut şeydir. İyi bir dijital ürün satış scripti bu hesabı sipariş anında dondurur; sonradan fiyat değişse bile geçmiş paylaşım bozulmaz.

Bir mağaza çökerse diğerleri ayakta kalır mı?

Ortak çekirdeğin doğal riski budur: tek nokta arızası. Bunu azaltmanın yolu, paylaşılan katmanı mümkün olduğunca ince tutmak ve mağazaya özel şeyleri izole etmektir. Örneğin bir vitrinin ödeme sağlayıcısı arıza verdiğinde sadece o vitrinin ödeme yöntemi devre dışı kalmalı, diğerleri etkilenmemeli. Bir vitrinin özel temasında hata olduğunda diğer vitrinler etkilenmemeli.

Pratik üç önlem: mağaza bazlı bakım modu (tek vitrini kapatıp diğerlerini açık tutabilmek), mağaza bazlı ödeme ve tedarikçi yapılandırması, mağaza bazlı önbellek anahtarları. Bunlar tek başlarına küçük ayrıntılar gibi görünür ama beş vitrinle çalışırken bir sorunun beş katına çıkmasını engelleyen tam olarak bunlardır. Detayları özellikler sayfasında karşılaştırabilirsin.

Çok mağaza yönetimi, dışarıdan bakıldığında bir ölçek hikâyesi gibi görünür; içeriden bakıldığında ise bir disiplin hikâyesidir. Stoğu nasıl bölüştürdüğün, fiyatı hangi katmanda hesapladığın, kimin neyi görebildiği ve ay sonunda hesabın kendiliğinden çıkıp çıkmadığı — büyümenin hızını bu dört karar belirler. Bu kararları destekleyen bir epin yazılım altyapısıyla çalıştığında ikinci, üçüncü ve beşinci vitrin birer proje değil, birer ayar haline gelir. Katmanların gerçek bir panelde nasıl ayrıştığını görmek istersen canlı demo üzerinden mağaza seçimi, fiyat kuralı ve rol kapsamı ekranlarını inceleyerek başlayabilirsin.