Hazır e-ticaret paketi mi, özel yazılım mı sorusunun tek doğru cevabı yoktur. Doğru tercih; işletmenin satış modeli, ürün verisi, operasyon ekibi, entegrasyon ihtiyacı ve büyüme planına göre değişir. Başlangıç maliyetine tek başına bakmak yerine lisans, bakım, veri sahipliği, operasyon süresi ve sonradan eklenecek ihtiyaçlar birlikte değerlendirilmelidir.

Hazır paket hangi durumda mantıklıdır?
Standart ürün kataloğu, temel kategori yapısı, tek tip fiyat, sınırlı kampanya kuralı ve yaygın ödeme-kargo ihtiyacı olan B2C mağazalar için hazır paket hızlı başlangıç sağlayabilir. Yönetim panelinin günlük kullanımda kolay olması, gerekli modüllerin gerçekten mevcut olması ve güncelleme sorumluluğunun açıkça tanımlanması gerekir. Ancak “modül var” ifadesi, işletmenizin iş akışına uygun olduğu anlamına gelmez; örnek ürün, sipariş ve iade senaryolarıyla test edilmelidir.

Özel geliştirme ne zaman gerekli hale gelir?
Bayiye özel fiyat, iskonto, vade, cari limit, rol bazlı ürün görünürlüğü, çoklu depo, özel üretim, tekliften siparişe dönüşen akışlar veya ERP ile çift yönlü veri alışverişi varsa standart paket sınırları erken ortaya çıkabilir. Özel geliştirme, her şeyi sıfırdan yazmak demek değildir; işletmenin farklılaştığı iş kurallarını doğru katmanda çözmek demektir.

Ürün verisi ve entegrasyon kararı belirler
Ürünler Excel, XML, ERP veya birden çok tedarikçiden geliyorsa; kategori, varyant, barkod, fiyat ve stok kuralları altyapı seçiminden önce yazılmalıdır. Pazaryerleriyle çalışılıyorsa hangi sistemin ana stok kaynağı olduğu, siparişin nereye düştüğü ve iade sonrası verinin nasıl güncellendiği net olmalıdır. XML entegrasyonu ve pazaryeri entegrasyonu, mağazaya sonradan eklenen kutucuklar değil; satış operasyonunun parçalarıdır.

Toplam sahip olma maliyetini karşılaştırı
Hazır pakette kurulum bedeli dışında aylık/yıllık lisans, işlem komisyonu, zorunlu eklentiler, kullanıcı sınırları ve sürüm yükseltme maliyetleri olabilir. Özel geliştirmede ise analiz, yazılım, test, sunucu, bakım ve yeni fazların kapsamı yazılı hale getirilmelidir. Her iki seçenekte de verinin dışa aktarılabilirliği, kod/altyapı bağımlılığı, güvenlik güncellemeleri ve destek süresi teklif içinde görünmelidir.

Satın alma deneyimi ile operasyon aynı sistemde buluşmalı
Müşteri için hızlı kategori gezintisi, anlaşılır ürün bilgisi, güvenli ödeme ve takip edilebilir iade önemlidir. Operasyon ekibi için ise doğru stok, sipariş durumu, kargo bilgisi ve hata kaydı önem taşır. Bir tarafı kolaylaştırıp diğer tarafı manuel iş yüküne bırakan sistem, büyüdükçe maliyet üretir. E-ticaret kontrol listesi, bu akışların tasarımdan önce nasıl yazılacağını anlatır.

Karar vermeden önce sorulacak beş soru
Satış B2C mi, B2B mi yoksa ikisi birden mi? Ürün ve stok verisinin ana kaynağı nedir? Hangi ödeme, kargo, ERP, muhasebe veya pazaryeri bağlantıları zorunlu? Operasyon ekibi hangi işlemleri elle yapıyor? Önümüzdeki 12 ayda hangi satış kuralı veya kanal eklenebilir? Bu soruların yanıtı netleştikçe doğru altyapı seçimi de görünür hale gelir.

E-ticaret mağazanızı vitrin ve operasyon tarafıyla birlikte planlamak için e-ticaret sitesi hizmetini inceleyin. Ürün yapınızı, satış modelinizi ve entegrasyon ihtiyacınızı paylaşarak altyapı değerlendirmesi isteyebilirsiniz.

Antalya’da e-ticaret sitesi kurmak, yalnızca ürünlerin göründüğü bir mağaza açmak değildir. Satış kanalı, ürün verisi, stok, fiyat, ödeme, kargo ve müşteri iletişimi aynı akışın parçalarıdır. Başlangıçta doğru sorular sorulmazsa; ekip sonradan ürün eşleme, yanlış stok, başarısız ödeme veya manuel sipariş takibiyle zaman kaybeder. Bu nedenle tasarıma geçmeden önce satış operasyonunun nasıl çalıştığı belirlenmelidir.

1. Önce satış modelini netleştiri
İlk karar, mağazanın B2C, B2B veya ikisini birlikte mi yürüteceğidir. B2C tarafta kategori, ürün, kampanya, sepet, teslimat ve iade deneyimi öne çıkar. B2B tarafta bayi girişi, özel fiyat listesi, iskonto, vade, minimum sipariş, cari hesap ve onay adımları gerekebilir. Fiziksel mağaza, depo, tedarikçi veya saha satış ekibi varsa bunların hangisinin ürün, stok ve sipariş konusunda ana kaynak olduğu da yazılı hâle getirilmelidir.

2. Ürün verisini satışa çıkmadan kontrol edi
Her ürün için ürün kodu, barkod, marka, kategori, varyant, KDV, maliyet, satış fiyatı, stok, görsel ve açıklama alanlarının hangi kaynaktan geldiği bellidir. Özellikle aynı ürünün farklı renk, beden veya paket seçenekleri varsa eşleştirme ana ürün seviyesinde değil varyant seviyesinde test edilmelidir. Eksik görsel, boş barkod, yanlış kategori veya sıfır stoklu ürün için sistemin nasıl davranacağı önceden belirlenmelidir.

Tedarikçiden veri alınıyorsa kaynak XML, JSON, CSV veya Excel olabilir. Bu veriyi doğrudan canlı mağazaya aktarmak yerine; örnek ürünlerle eşleme, fiyat ve stok sonuçları doğrulanmalıdır. XML ürün entegrasyonu kapsamı; veri temizleme, kopya kayıt kontrolü, kategori eşleme, görsel denetimi, fiyat kuralı ve hata kaydı olmadan tamamlanmış sayılmaz.

3. Pazaryeri mağazayı desteklemeli, mağaza ile yarışmamalı
Trendyol, Hepsiburada, Akakçe veya ÇiçekSepeti gibi kanallarda satış yapılacaksa ürün, stok, fiyat ve sipariş akışının yönü açık olmalıdır. Bir kanal stok konusunda ana kaynak, diğeri kopya kaynak olduğunda çakışmalar oluşur. Sipariş geldiğinde stok ne zaman düşecek, iade sonrası ne zaman geri eklenecek, fiyat güncellemesi hangi kuralla yayılacak ve başarısız API isteği nasıl tekrar denenecek sorularının cevabı bulunmalıdır.

Doğru pazaryeri entegrasyonu; yalnız ürün göndermez. Varyant, barkod, kategori, stok, fiyat, sipariş, kargo ve uygun olduğunda fatura bilgisinin hangi sistemde işlendiğini görünür kılar. İşletmenin tek seferde yüzlerce ürün veya birden fazla satış kanalı yönetmesi gerekiyorsa, hata kaydı ve manuel müdahale ekranı satış operasyonunun önemli bir parçasıdır.

4. Sanal POS kararını komisyon oranıyla sınırlamayı
Banka sanal POS’u veya ödeme kuruluşu seçerken başarılı ödeme kadar başarısız ödeme, 3D Secure iptali, tekrar deneme, kısmi iade, tam iade, taksit ve ödeme sonrası sipariş durumu düşünülmelidir. Kullanıcı banka ekranından döndüğünde siparişin hangi durumda kalacağı; sağlayıcının sunucu bildirimi gecikirse sistemin nasıl doğrulama yapacağı; iade sonrasında stok, fatura ve müşteri bildirimlerinin hangi sırayla güncelleneceği test edilmelidir.

Sanal POS ve ödeme sistemi entegrasyonu bu yüzden yalnız ödeme formu yerleştirmek değildir. Güvenli dönüş, sipariş eşleştirme, iade ve hata senaryoları canlı anahtarlar kullanılmadan önce test ortamında doğrulanmalıdır.

5. Kargo, iade ve müşteri iletişimi tekliften önce düşünülmeli
Kargo ücreti, ücretsiz kargo eşiği, teslimat bölgesi, desi, kapıda ödeme varsa ek koşullar, iade talebi ve müşteri bilgilendirmesi sepet deneyimini doğrudan etkiler. Sipariş alındı, ödeme bekliyor, hazırlanıyor, kargoda, teslim edildi ve iade edildi gibi durumlar; müşteri, depo ve muhasebe tarafında aynı anlamı taşımalıdır. Aksi hâlde e-ticaret sitesi satış kanalından çok manuel takip ekranına dönüşür.

6. Antalya’daki işletmeler için görünürlük ve güven sinyalleri
Yerel müşteri hedefleniyorsa şirket bilgisi, iletişim kanalları, açık hizmet kapsamı, gerçek proje örnekleri, iade ve teslimat koşulları, mobil hız ve güvenli ödeme açıklaması ulaşılabilir olmalıdır. Arama motoru açısından da kategori ve ürün yapısı, açıklayıcı başlıklar, teknik bilgisi olan ürün sayfaları, doğru görseller ve düzenli iç bağlantılar önem taşır. Ancak bu unsurlar tek başına sıralama garantisi değildir; kullanıcıya yararlı, özgün ve güvenilir bir satış deneyiminin parçalarıdır.

7. Tasarım başlamadan önce operasyon senaryolarını yazı
E-ticaret projesinde en pahalı hatalar, ekran tasarlandıktan sonra ortaya çıkan iş kurallarıdır. Örneğin bir ürün yalnız belirli bayilere satılacaksa, ürün sayfasındaki fiyatın herkese açık olup olmayacağı; birden fazla depoda stok varsa, müşteriye hangi deponun teslimat süresinin gösterileceği; kişiye özel üretimde siparişin doğrudan ödemeye mi yoksa teklif onayına mı gideceği tasarım öncesinde belirlenmelidir. Bu kararlar ürün kartı, sepet, yönetim paneli ve entegrasyonların tamamını etkiler.

Kapsam belgesinde en az şu konular bulunmalıdır: müşteri tipleri, ürün grupları, kategori yapısı, kampanya kuralları, kupon ve hediye çeki ihtiyacı, teslimat seçenekleri, vergi ve fatura süreci, müşteri destek kanalı, çalışan yetkileri ve raporlama ihtiyacı. İşletme mevcut bir site veya mağaza programı kullanıyorsa; ürünlerin, müşterilerin, sipariş geçmişinin, görsellerin ve yönlendirmelerin nasıl taşınacağı da ayrı planlanmalıdır. Taşıma sırasında eski URL yapısının korunması veya doğru yönlendirilmesi, hem kullanıcıların hem arama motorlarının kaybolmaması açısından önemlidir.

8. Yetki, güvenlik ve veri sorumluluğunu bölüştürü
Mağaza yöneticisi, operasyon ekibi, muhasebe, depo ve müşteri hizmetleri aynı ekrana aynı yetkiyle girmemelidir. Kim ürün fiyatı değiştirebilir, kim iade başlatabilir, kim sipariş durumunu güncelleyebilir ve kim rapor indirebilir soruları rol bazında cevaplanmalıdır. Ödeme kartı verisi mağaza sunucusunda tutulmamalı; ödeme sağlayıcısının güvenli akışı kullanılmalıdır. Yönetim paneli için güçlü parola, iki aşamalı doğrulama uygunsa ek doğrulama, düzenli yedek, erişim kaydı ve güncelleme planı değerlendirilmelidir.

E-ticaret sitesinde kişisel veri içeren alanlar da vardır: müşteri adı, teslimat bilgisi, telefon, e-posta ve sipariş geçmişi. Bu verinin hangi amaçla işlendiği, kimlerin erişebildiği, ne kadar süre saklandığı ve müşteri talebi geldiğinde nasıl ele alınacağı işletmenin kendi hukuki ve operasyonel sürecine uygun biçimde netleştirilmelidir. Teknik kurulum ile sözleşme, aydınlatma metni ve veri sorumluluğu aynı şey değildir; ancak birbirleriyle çelişmemelidir.

9. Canlıya geçiş tek gün değil, kontrollü bir süreçtir
İlk gün bütün ürünleri ve bütün satış kanallarını açmak zorunlu değildir. Önce seçilmiş kategori ve ürünlerle sipariş oluşturma, ödeme, kargo, stok düşümü, e-posta bildirimi, iade ve panel raporları kontrol edilebilir. Test hesabıyla yapılan işlemler; müşteri ekranı, ödeme sağlayıcısı, kargo entegrasyonu ve yönetim panelinde aynı sipariş numarası üzerinden karşılaştırılmalıdır. Böylece bir hata oluştuğunda sorun hangi sistemde ve hangi adımda başladı anlaşılır.

Pazaryeri veya XML bağlantısı varsa, ilk senkronizasyonda küçük bir ürün grubu seçmek daha güvenlidir. Ürün başlığı, açıklama, barkod, varyant, görsel, kategori, fiyat ve stok alanları tek tek kontrol edilmeden büyük katalogları otomatik yayına almak gereksiz risk oluşturur. Başarısız istek, kuyrukta bekleyen işlem ve tekrar deneme kayıtlarının operasyon ekibi tarafından okunabilir olması gerekir. Bir entegrasyonun başarılı olduğu, yalnız bağlantının kurulmasıyla değil; istisna senaryolarında nasıl davrandığıyla anlaşılır.

10. Yayından sonra hangi veriler izlenmeli?
E-ticaret başarısı yalnız ciro ile ölçülmez. Hangi kanaldan ziyaretçi geldiği, hangi kategoride ürün bulunduğu hâlde sepete eklenmediği, hangi ödeme adımında terk yaşandığı, iade nedenleri, stokta bulunamayan ürünler ve müşteri hizmetlerine gelen tekrar eden sorular düzenli incelenmelidir. Bu veriler tasarım, içerik, ürün bilgisi ve operasyonun hangi bölümünün iyileştirilmesi gerektiğini gösterir.

Organik görünürlük tarafında ise hizmet ve kategori sayfalarının arama sorguları, tıklama oranı ve mobil deneyimi ayrı takip edilmelidir. E-ticaret mağazasına trafik getiren içerikler doğrudan satış yapmasa bile doğru ürün veya hizmet sayfasına kullanıcı taşıyabilir. Bu nedenle blog yazısı, ürün kategorisi, referans ve hizmet sayfası arasında açıklayıcı bağlantılar kurulmalıdır. Yeni içerik yalnız arama motoru örümceği gelsin diye değil, müşterinin karar sürecindeki gerçek bir soruyu yanıtlamak için yayınlanmalıdır.

11. Hazır altyapı ile özel geliştirme kararını iş kuralına göre veri
Her e-ticaret projesinin sıfırdan özel yazılıma ihtiyacı yoktur. Ürün sayısı sınırlı, tek satış kanalı olan ve standart ödeme-kargo akışıyla çalışan bir işletme için yönetilebilir bir hazır altyapı hızlı başlangıç sağlayabilir. Buna karşılık bayi bazlı fiyat, özel iskonto, farklı depo kuralları, ERP veya muhasebe bağlantısı, birden fazla tedarikçi, özel sipariş onayı, saha satış uygulaması ya da pazaryerine özgü iş kuralları varsa standart eklentiler kısa sürede yetersiz kalabilir.

Kararı verirken yalnız ilk kurulum bedeli değil; veri sahipliği, yıllık bakım, güncelleme, entegrasyon esnekliği, hız, güvenlik, yönetim yetkileri ve gelecek iki yıldaki operasyon ihtiyacı birlikte değerlendirilmelidir. Örneğin bugün tek fiyatla satış yapan bir firma, yarın bayi gruplarına özel fiyat, bölgesel kargo, farklı tahsilat veya toptan sipariş ekranı isteyebilir. Bu nedenle proje başlangıcında değişmeyecek temel kurallar ile sonraki faza bırakılabilecek istekler ayrılmalıdır.

12. Teklif isterken doğru bilgiyi paylaşı
Sağlıklı e-ticaret teklifi için yalnız “bir e-ticaret sitesi istiyorum” demek yeterli değildir. Yaklaşık ürün ve kategori sayısı, satış modeli, mevcut site veya veri kaynağı, hedef pazaryerleri, ödeme-kargo tercihleri, bayi veya bayi dışı müşteri kuralları, gerekli entegrasyonlar, içerik ve görsel hazırlık durumu ile hedef yayın tarihi paylaşılırsa kapsam daha doğru çıkar. Bu bilgiler ilk görüşmede tüm detayları kesinleştirmek için değil, gereksiz modül ve yanlış varsayımları önlemek için kullanılır.

Antalya’da turizm, perakende, üretim, yerel ürün, sağlık, mobilya, yedek parça veya B2B satış yapan işletmelerin ihtiyaçları aynı değildir. Birinin çok dilli katalog ve rezervasyon bağlantısına, diğerinin stok-fiyat otomasyonuna veya bayi siparişine ihtiyacı olabilir. Bu yüzden iyi bir başlangıç; ekran listesiyle değil, müşteri yolculuğu ve operasyon akışıyla yapılır. Sonuçta kurulacak mağaza yalnız ürün sergilememeli; doğru müşteriyi doğru ürüne, doğru ödeme ve teslimat seçeneğiyle taşımalıdır. Proje kapsamı, yayına çıkmadan önce operasyon ekibinin günlük kullanım senaryolarıyla ayrıca dikkatle gözden geçirilmelidir. Bu inceleme önemlidir.

Yayın öncesi kısa kontrol listesi
• Hedef müşteri B2C, B2B veya hibrit olarak tanımlandı mı?
• Ürün, varyant, barkod, kategori, fiyat ve stok için ana veri kaynağı belli mi?
• XML veya tedarikçi verisinde eksik, kopya ve sıfır stok kuralları test edildi mi?
• Pazaryeri ile stok-fiyat-sipariş akışının yönü tanımlandı mı?
• Başarılı ve başarısız ödeme, 3D Secure, iptal ve iade senaryoları denendi mi?
• Kargo, iade, destek ve müşteri bilgilendirmesi açık mı?
• Mobilde ürün bulma, sepet ve ödeme adımları gerçek cihazda kontrol edildi mi?

E-ticaret yatırımı; e-ticaret sitesi altyapısı, ürün verisi, ödeme ve satış kanallarını birlikte ele aldığında sürdürülebilir olur. Antalya’daki işletmeniz için hangi modüllerin gerçekten gerekli olduğunu belirlemek üzere proje analizi talep edebilirsiniz.

Antalya’da e-ticaret sitesi kurma maliyeti, yalnız tasarım ekranlarının sayısıyla belirlenmez. Ürün verisi, satış modeli, ödeme, kargo, pazaryeri, XML kaynağı, yönetim paneli ve operasyon kuralları proje kapsamını doğrudan değiştirir. Bu yüzden sağlıklı soru “e-ticaret sitesi ne kadar?” değil; “işletmem hangi satış ve operasyon akışına ihtiyaç duyuyor?” sorusudur.

Maliyeti belirleyen ilk konu satış modelidir
Hazır ürün satan bir B2C mağaza; kategori, ürün, sepet, ödeme, kargo, müşteri hesabı ve kampanya araçlarına ihtiyaç duyabilir. Bayilere satış yapan B2B işletmede buna özel fiyat, iskonto, vade, cari limit, sipariş onayı, ürün görünürlüğü ve rol bazlı yetkiler eklenir. Aynı altyapıda hem perakende hem bayi satışı yapılacaksa iki müşteri yolculuğunun kuralları baştan ayrılmalıdır. Bu kararlar yönetim panelini ve entegrasyonları da etkiler.

Ürün verisi ve içerik hazırlığı genellikle gözden kaçar
Ürün adı, açıklama, marka, kategori, varyant, barkod, fiyat, stok, görsel ve teknik özelliklerin hangi kaynaktan geleceği net değilse proje gecikir. Binlerce ürünün düzensiz Excel dosyasında olması ile düzenli bir XML ya da API kaynağından gelmesi aynı iş değildir. Tedarikçi verisi kullanılıyorsa kategori eşleme, kâr marjı, stok, hatalı görsel, pasif ürün ve kopya kayıt kuralları gerekir. XML ürün entegrasyonu bu yüzden tek seferlik dosya aktarımı değil, kontrol edilen veri sürecidir.

Pazaryeri bağlantısı kapsamı büyütebilir
Trendyol, Hepsiburada, Akakçe veya ÇiçekSepeti gibi kanallar kullanılıyorsa sadece ürün göndermek yeterli olmaz. Stok ve fiyatın hangi kaynaktan güncelleneceği, siparişin ne zaman mağazaya veya ERP sistemine düşeceği, iptal-iade sonrası verinin nasıl düzeltileceği ve başarısız isteklerin nasıl takip edileceği belirlenmelidir. Pazaryeri entegrasyonu için kanal sayısı, ürün yapısı, API kuralları ve operasyon ekibinin müdahale ihtiyacı teklif kapsamını etkiler.

Ödeme ve kargo sistemi ayrı kalemler değildir
Sanal POS tarafında başarılı ödeme, başarısız ödeme, 3D Secure dönüşü, sipariş eşleştirme, iptal, tam veya kısmi iade ve taksit senaryoları test edilmelidir. Kargo tarafında desi, teslimat bölgesi, ücretsiz kargo eşiği, gönderi durumu ve iade akışı düşünülmelidir. Ödeme sistemleri hizmeti ile e-ticaret altyapısının sipariş durumları birbirini desteklemelidir; aksi halde müşterinin ekranı ile yönetim paneli arasında farklı bilgiler oluşabilir.

Hazır paket mi, özel geliştirme mi?
Tek kanal, standart katalog ve temel satış akışı olan işletmeler için yönetilebilir bir paket hızlı başlangıç sağlayabilir. Ancak özel B2B fiyatlandırma, ERP bağlantısı, çoklu depo, tedarikçi kuralı, bayi onayı, saha satış akışı veya özel raporlama varsa hazır seçeneklerin sınırı erken görülebilir. Karar verilirken ilk kurulum yanında lisans, işlem komisyonu, bakım, güvenlik güncellemesi, veri sahipliği ve büyüme maliyeti birlikte değerlendirilmelidir.

Teklif alırken paylaşılması gereken bilgiler
Yaklaşık ürün-kategori-varyant sayısı, mevcut veri kaynağı, satış modeli, hedef pazaryerleri, ödeme ve kargo tercihi, gerekli entegrasyonlar, içerik-görsel hazırlık durumu ve hedef yayın tarihi paylaşıldığında teklif gerçekçi olur. İşletme her ayrıntıyı ilk gün bilmek zorunda değildir; fakat belirsiz kalan başlıklar varsayım olarak yazılmalı, sonradan kapsam değişikliğine dönüşmemelidir.

E-ticaret maliyetini düşürmenin doğru yolu gerekli modülleri çıkarmak değil, gereksiz modülleri baştan ayıklamaktır. E-ticaret sitesi hizmeti, satış ve operasyon hedeflerinize göre planlanabilir; mevcut mağaza veya veri kaynaklarınız için proje analizi isteyebilirsiniz.