E-Ticaret Altyapısı Nasıl Seçilir?

Altyapı seçimi çoğu zaman bir karşılaştırma tablosuyla başlar: Hangi pakette kaç özellik var, hangi tema daha iyi görünüyor, aylık ücret ne kadar. Bu tablolar bir fikir verir ama asıl soruyu cevaplamaz.

Asıl soru şudur: Sizin gerçek sipariş akışınızı hangi sistem daha az sürtünmeyle taşıyor? Bir ürünün sepete eklenmesinden iadenin muhasebeye yansımasına kadar her adım, seçeceğiniz altyapının içinden ya da yanından geçecek. Kâğıt üzerinde aynı görünen iki altyapı, bu akışta çok farklı sonuç verebilir.

Bu rehber marka karşılaştırması yapmaz. Bunun yerine, altyapı adaylarını kendi işletmenize göre sistematik biçimde değerlendirmeniz için bir yöntem sunar.

Altyapı Seçimine Paketlerden Değil, İşletmenizden Başlayın

Paket sayfaları, altyapının neler yapabildiğini anlatır. Sizin ise önce neye ihtiyacınız olduğunu bilmeniz gerekir. Bu sıra ters kurulduğunda, işletme kendi sürecini altyapının sunduğu kalıba uydurmaya başlar.

Altyapı adaylarına bakmadan önce şu soruları yazılı olarak cevaplayın:

• Satış modeli: B2C, B2B veya ikisi birden mi? Kendi site, pazaryeri veya hibrit mi?
• Ürün yapısı: Kaç ürün, kaç varyasyon? Kişiye özel ürün, paket ürün, abonelik veya dijital teslimat var mı?
• Sipariş hacmi: Bugün günde kaç sipariş alıyorsunuz, 12 ay sonra kaç sipariş bekliyorsunuz? Kampanya dönemlerinde ne kadar artıyor?
• Mevcut sistemler: Muhasebe, ERP, depo, kargo, pazaryeri ve CRM tarafında hangi araçlar kullanılıyor ve hangileri değişmeyecek?
• Ekip: Paneli kim kullanacak? Teknik bilgi düzeyi nedir? Dış bir ajans veya geliştirici olacak mı?
• Kırmızı çizgiler: Hangi durumda bir altyapı doğrudan elenir? Örneğin belirli bir ödeme kuruluşuyla çalışamaması veya B2B fiyat listesi desteklememesi.

Bu adımı atlamanın tipik sonucu şudur: Çevrede en çok duyulan ya da en çok önerilen altyapı seçilir, ilk aylarda sorun görünmez. Sonra bayiler için ayrı fiyat, pazaryeri stoğunun eşitlenmesi veya kişiye özel ürün siparişi gibi bir ihtiyaç ortaya çıkar ve altyapının bunu taşımadığı anlaşılır. Bu noktada seçenekler genellikle pahalı bir ek geliştirme, elle yürütülen bir yan süreç ya da altyapı değişikliğidir.

Bu soruların cevabı, altyapı değerlendirmesinin ölçütü olur. Henüz bu noktada değilseniz, önce satışa hazır olmak için gereken parçaları netleştirmek daha doğru bir başlangıçtır.

Global SaaS, Yerel Altyapı, Açık Kaynak ve Özel Yazılımı Nasıl Değerlendirmelisiniz?

Altyapı seçenekleri genellikle dört grupta toplanır. Hiçbiri her işletme için tek başına doğru değildir; her biri farklı bir sorumluluk ve maliyet dağılımı getirir.

Bu tablo bir karar değil, bir başlangıç filtresidir. Asıl ayrım "hangi model daha iyi" sorusunda değil, sorumluluğun kimde olduğu sorusundadır. Hazır bir altyapıda sunucu, güncelleme ve güvenlik yaması sağlayıcının sorumluluğundadır; açık kaynak veya özel yazılımda bu yük sizin ya da çalıştığınız ekibin üzerindedir. Esneklik arttıkça sorumluluk da artar.

Hangi modelin sizin için aday olduğunu belirlerken şu sorular yol gösterir:

• Satışın büyük kısmı Türkiye'de mi, yurt dışında mı olacak?
• İş modeliniz standart bir mağaza akışına mı uyuyor, yoksa özgün kurallar (teklif onayı, bayi hiyerarşisi, üretime bağlı sipariş) mı içeriyor?
• Bakım, güncelleme ve güvenlikten sorumlu olacak bir teknik ekibiniz ya da sürekli çalışacağınız bir yazılım ortağınız var mı?
• Yakın dönemde ihtiyacınız olan özellikler hazır olarak mı bekleniyor, yoksa geliştirilmesi mi gerekecek?

Bu sorular modeli tek başına belirlemez ama aday listesini daraltır. Örneğin teknik ekibi olmayan ve standart bir akışla satış yapacak bir işletmenin açık kaynak veya özel yazılımı ilk aday olarak değerlendirmesi, genellikle gereksiz bir sorumluluk yükü anlamına gelir. Hazır sistemin sınırına ne zaman gelindiğini ve hazır altyapı ile özel yazılım arasında hangi modelin uygun olduğunu ayrı bir rehberde ele aldık.

İhtiyaçlarınızı Üç Gruba Ayırın: Olmazsa Olmaz / Yakında Gerekli / Nice-to-Have

Özellik listeleri her şeyi eşit gösterir. Oysa bir B2B firması için cari hesap desteği vazgeçilmezken, ürün karşılaştırma modülü yalnızca güzel bir ek olabilir. İhtiyaçlarınızı üç gruba ayırmak, değerlendirmeyi özellik sayısından kurtarır.

Her ihtiyacı yazarken bir de kabul ölçütü ekleyin. "Kargo entegrasyonu olmalı" yerine "sipariş onaylandığında gönderi kaydı otomatik oluşmalı ve takip numarası müşteriye iletilmeli" yazın. Ölçütü olmayan ihtiyaç, demo sırasında doğrulanamaz.

İki tuzağa dikkat edin. Birincisi, her şeyi olmazsa olmaz olarak işaretlemek; bu durumda hiçbir aday elemeyi geçemez ya da liste anlamını yitirir. İkincisi, yakında gerekli olanları tamamen yok saymak; altı ay sonra eklenmesi gereken bir pazaryeri bağlantısı, altyapı değiştirme sebebine dönüşebilir.

Entegrasyon Var Demek Operasyon Çalışıyor Demek Değildir

Altyapı tanıtımlarında en sık görülen ifade "entegrasyonu var" ifadesidir. Bu ifade bir bağlantının teknik olarak mevcut olduğunu söyler; operasyonunuzu taşıyıp taşımadığını söylemez.

Bir entegrasyonu değerlendirirken şu soruları sorun:

• Yön: Veri tek yönlü mü akıyor, çift yönlü mü? Örneğin stok yalnızca siteden pazaryerine mi gidiyor, yoksa pazaryerindeki satış sitedeki stoğu da düşürüyor mu?
• Sıklık: Veri anlık mı, birkaç dakikada bir mi, günde bir mi eşitleniyor? Son stok satışlarında bu fark belirleyicidir.
• Kapsam: Sipariş, stok, fiyat, iade, iptal ve fatura bilgilerinden hangileri aktarılıyor?
• Hata davranışı: Bağlantı kesildiğinde ne oluyor? Veri kuyruğa alınıp sonra mı gönderiliyor, yoksa kayboluyor mu? Hata kimseye bildiriliyor mu?
• Sahiplik: Entegrasyonu altyapı sağlayıcısı mı, üçüncü taraf bir uygulama mı, yoksa ayrı bir yazılımcı mı sağlıyor? Sorun çıktığında kimi arayacaksınız?
• Maliyet: Entegrasyon pakete dahil mi, ayrı aylık ücretli mi, işlem başına mı ücretlendiriliyor?

Entegrasyon listesinde bir logonun bulunması, bu soruların hiçbirine cevap vermez. Cevapları demo sırasında, mümkünse çalışan bir örnek üzerinde görmek gerekir.

Pratik bir yöntem, her kritik entegrasyon için tek cümlelik bir senaryo yazmaktır: "Pazaryerinde satılan son ürün, en geç beş dakika içinde sitede de tükendi olarak görünmeli." Sağlayıcıdan bu senaryonun nasıl çalıştığını göstermesini isteyin. Senaryo gösterilemiyorsa, entegrasyonun sizin operasyonunuz için hangi koşulda yeterli olduğu belirsiz kalır.

Gerçek Siparişinizi Aday Altyapıda Çalıştırın

Bir altyapıyı anlamanın en güvenilir yolu, kendi siparişinizi onun içinde baştan sona yürütmektir. Satış sunumunda gösterilen hazır demo mağaza, sizin ürün yapınızı, kampanyalarınızı ve entegrasyonlarınızı yansıtmaz.

Ana akış testi

Deneme ortamında ya da demo sırasında, kendi gerçek ürünlerinizden birini kullanarak şu akışı izleyin:

Ürün → kampanya/indirim → ödeme → sipariş → stok → belge → kargo → teslimat → iade → mutabakat

Bu testi yalnız teknik ekip yapmamalıdır. Siparişi her gün yönetecek operasyon sorumlusu ve faturayı kontrol edecek muhasebe tarafı da sürece katılmalıdır; bir adımın "çalışıyor" sayılıp sayılmadığına onlar karar verir. Her adımda kimin ne yaptığını ve ne kadar sürdüğünü not edin. Bu notlar, toplam sahip olma maliyetindeki iç operasyon emeğinin de temelini oluşturur.

Her adımda iki şeye bakın: Adım çalışıyor mu ve bunu yapmak için panelde kaç el işlemi gerekiyor? Çalışan ama her siparişte beş elle müdahale isteyen bir akış, sipariş hacmi arttıkça operasyon yükü olarak geri döner.

İstisna testleri

Sorunsuz bir sipariş, altyapının iyi gün performansını gösterir. Operasyonu asıl zorlayan ise istisnalardır:

Bu testlerin hepsini demo ortamında yapmak her zaman mümkün olmayabilir. Bu durumda sağlayıcıya her senaryonun nasıl yönetildiğini sorun ve cevabı mümkünse ekran üzerinde gösterilmesini isteyin. "Bu durumda sistem otomatik halleder" cevabı, gösterilene kadar bir vaattir.

Destory Notu

Altyapı değerlendirmelerinde en çok zaman kaybettiren sorunlar ana akışta değil, istisnalarda çıkıyor. Çift bildirimle oluşan mükerrer sipariş veya kısmi iadede yanlış güncellenen stok, ilk haftalarda fark edilmezse muhasebe kapanışında büyük bir düzeltme işine dönüşüyor.

SEO, Performans ve Güvenliği Vaat Üzerinden Değerlendirmeyin

"SEO uyumlu", "hızlı" ve "güvenli" ifadeleri neredeyse her altyapının tanıtımında yer alır. Bu ifadeleri kabul etmek yerine, doğrulanabilir sorulara dönüştürün.

SEO için:

• Ürün, kategori ve içerik sayfalarında başlık, açıklama ve URL yapısı düzenlenebiliyor mu?
• Canonical etiketleri, filtre ve sıralama sayfalarının indekslenmesi kontrol edilebiliyor mu?
• URL değiştiğinde veya ürün kaldırıldığında kalıcı yönlendirme tanımlanabiliyor mu?
• Site haritası ve yapılandırılmış veri (ürün, fiyat, stok bilgisi) otomatik üretiliyor mu?
• Başka bir altyapıdan geçiyorsanız, eski URL'lerin yeni sayfalara yönlendirilmesi nasıl yapılacak?

Performans için: Demo mağazanın hızı değil, sizin katalog büyüklüğünüzde, gerçek ürün görselleriyle ve mobil cihazda ölçülen hız önemlidir. Mümkünse aday altyapıyı kullanan ve sizinkine benzer büyüklükteki canlı mağazaları mobilde inceleyin. Tema ve eklenen uygulamaların hızı nasıl etkilediğini de sorun.

Güvenlik için:

• Kart verisi altyapıda mı işleniyor, yoksa doğrudan ödeme kuruluşunun ortamında mı? Sağlayıcı ödeme güvenliği uyumluluğunu (örneğin PCI DSS) nasıl belgeliyor?
• Yönetim panelinde iki adımlı doğrulama, kullanıcı bazlı yetki ve işlem kaydı var mı?
• Yedekleme kim tarafından, hangi sıklıkta yapılıyor ve geri dönüş nasıl isteniyor?
• Kişisel verilerin nerede barındırıldığı ve hangi alt hizmet sağlayıcılarla paylaşıldığı açıklanıyor mu?

Bu soruların cevabı "evet, var" olduğunda bile, ekran üzerinde gösterilmesini isteyin.

İlk Fiyatı Değil, Toplam Sahip Olma Maliyetini Karşılaştırın

Paket fiyatı, altyapı maliyetinin yalnızca görünen kısmıdır. Doğru karşılaştırma, toplam sahip olma maliyeti (TCO) üzerinden yapılır:

TCO = başlangıç + sabit giderler + hacme bağlı giderler + iç operasyon emeği + çıkış/geçiş maliyeti

İç operasyon emeği en sık atlanan kalemdir. Ucuz ama sipariş başına birkaç dakikalık elle işlem gerektiren bir altyapı, sipariş sayısı arttıkça pahalı bir altyapıdan daha maliyetli hale gelebilir. Basit bir hesap bunu gösterir: Sipariş başına 4 dakikalık elle işlem, günde 50 siparişte günde üç saati aşan bir iş yükü demektir. Bu süre, bir ekip üyesinin zamanının önemli bir kısmının yalnızca altyapının eksik bıraktığı işlere gitmesi anlamına gelir.

Çıkış/geçiş maliyeti ise bugün sıfır görünür, çünkü henüz ödenmemiştir. Ancak veri taşınabilirliği zayıf bir altyapıda bu maliyet, ileride altyapı değiştirme kararını erteleten ya da çok pahalı hale getiren bir bağımlılığa dönüşür.

Karşılaştırmayı iki zaman diliminde yapın:

• 12 aylık değerlendirme: Kuruluş maliyetinin ağır bastığı ilk yılı gösterir. Nakit planlaması ve başlangıç bütçesi için kullanılır.
• 36 aylık değerlendirme: Sabit ve hacme bağlı giderlerin, büyüme senaryonuzla birlikte nasıl değiştiğini gösterir. İlk yılı ucuz olan bir seçeneğin üç yıllık toplamda pahalı kalması bu görünümde ortaya çıkar.

36 aylık hesapta sipariş hacmini sabit tutmayın; kendi büyüme beklentinize göre en az iki senaryo (temkinli ve beklenen) kurun. Komisyon ve işlem başına ücretler büyüme ile birlikte artarken, elle yapılan işlerin maliyeti de katlanır.

Bu bölüm TCO'yu bir seçim kriteri olarak kullanır. Adayların ilk yılını kendi rakamlarınızla 12 aylık toplam maliyeti modellemek için ilk yıl TCO rehberimizdeki çalışma tablosunu ve senaryoları kullanabilirsiniz.

Verinizin Nasıl Çıkacağını Satın Almadan Önce Öğrenin

Altyapı seçerken ayrılma ihtimalini düşünmek kötümser görünebilir. Ama veri taşınabilirliği, ancak satın almadan önce pazarlık konusu olabilir.

Burada üç kavram sık karıştırılır:

Bir altyapının "verilerinizi dışa aktarabilirsiniz" demesi, verinin başka bir sisteme eksiksiz taşınabileceği anlamına gelmez. Ürün listesi dışa aktarılabilirken varyasyon yapısı, ürün görselleri, müşteri sipariş geçmişi, iade kayıtları veya URL yapısı aktarımın dışında kalabilir.

Satın almadan önce şunları netleştirin:

• Ürün, varyasyon, kategori, müşteri, sipariş, iade ve kampanya verilerinin hangisi dışa aktarılabiliyor?
• Dışa aktarım panelden kendiniz mi yapılıyor, yoksa sağlayıcıya talep mi iletiliyor?
• Sözleşme sona erdiğinde veriye ne kadar süre erişebiliyorsunuz?
• Müşteri şifreleri gibi taşınması teknik olarak mümkün olmayan veriler için ne öneriliyor?

Mümkünse deneme sürecinde küçük bir veri setini dışa aktarın ve dosyayı açıp inceleyin. Bu, sözleşmedeki ifadeden daha net bir cevap verir.

Teknik Destek ve Sorumluluk Sınırlarını Netleştirin

Bir sorun çıktığında kimin, ne kadar sürede, hangi kanaldan cevap vereceği; altyapının kendisi kadar önemlidir. Özellikle birden fazla tarafın dahil olduğu yapılarda (altyapı sağlayıcısı, ajans, entegrasyon firması, ödeme kuruluşu) sorumluluk boşlukları oluşabilir.

Şu soruları yazılı olarak netleştirin:

• Kanal ve süre: Destek hangi kanaldan veriliyor? Kritik bir sorunda (ödeme alınamıyor, site erişilemiyor) ilk yanıt süresi ne?
• Kapsam: Tema, özel geliştirme ve üçüncü taraf uygulamalardaki sorunlar destek kapsamında mı?
• Kesinti yönetimi: Planlı bakımlar önceden bildiriliyor mu? Kesinti yaşandığında durum nereden takip ediliyor?
• Sorumluluk sınırı: Bir entegrasyon hatası nedeniyle yanlış stok veya fatura oluşursa, sorunun kaynağını kim tespit ediyor?
• İşletilebilirlik: Ekibiniz günlük işlemleri (ürün ekleme, kampanya kurma, iade yönetimi) dış destek olmadan yapabiliyor mu?

Bir ajans veya yazılım ortağıyla çalışıyorsanız, sorumluluk paylaşımını ayrıca yazılı hale getirin: Altyapı sağlayıcısının, ajansın ve entegrasyon firmasının hangi sorunlarda devreye gireceği belli olmalıdır. Aksi halde bir sipariş sorunu taraflar arasında "bizim tarafımızda değil" cevabıyla dolaşabilir.

Destek kalitesini anlamak için, aday altyapıyı kullanan bir işletmeyle konuşmak çoğu zaman sözleşme metninden daha fazla bilgi verir.

Karar Matrisini Doldurun

Önceki bölümlerdeki değerlendirmeleri tek bir tabloda toplamak, kararın kişisel izlenimlere değil ölçütlere dayanmasını sağlar.

Ağırlıklar

Aşağıdaki ağırlıklar örnek ağırlıklardır. Kendi işletmenizin önceliklerine göre değiştirilmelidir. Örneğin çok kanallı satış yapan bir işletmede entegrasyonun ağırlığı artabilir; içerikle trafik çeken bir markada SEO'nun ağırlığı yükselebilir.

Puanlama

Her kriteri 0 ile 4 arasında puanlayın:

• 0: Karşılanmıyor veya gösterilmedi
• 1: Kısmen karşılanıyor; önemli el işlemi veya ek geliştirme gerekiyor
• 2: Karşılanıyor ama belirgin sınırlamalarla
• 3: Karşılanıyor; küçük sınırlamalar var
• 4: Gerçek senaryoda sorunsuz çalıştığı gösterildi

Ağırlıklı puanı hesaplamak için her kriterin puanını ağırlığıyla çarpın ve toplayın. En yüksek toplam puan 4'tür. Örneğin sipariş ve iade akışında 3, entegrasyonda 2, TCO'da 3 ve diğer dört kriterde 2 puan alan bir aday için hesap şöyledir: 0,25×3 + 0,20×2 + 0,15×3 + 0,40×2 = 2,40.

Puanları tek kişi değil, testlere katılan ekip birlikte vermelidir. Her puanın yanına kısa bir gerekçe yazın; "2 puan: kısmi iadede stok elle düzeltiliyor" gibi. Gerekçe, birkaç ay sonra kararın neden verildiğini hatırlamak için de işe yarar.

İki kural puanlamayı güvenilir kılar. Birincisi: Gösterilmeyen özellik çalışıyor kabul edilmez. "Var" denilen ama demo veya testte görülmeyen bir özellik 0 puan alır. İkincisi: Yalnızca yol haritasında olan özellik de çalışıyor kabul edilmez. "Önümüzdeki çeyrekte geliyor" cevabı, bugünkü değerlendirmede puan getirmez.

Ayrıca olmazsa olmaz ihtiyaçlardan birini karşılamayan aday, toplam puanı ne olursa olsun elenir. Matris, bu elemeyi geçen adaylar arasında karar vermek için kullanılır.

İki adayın toplam puanı birbirine çok yakınsa, kararı en yüksek ağırlıklı kriterdeki fark belirlemelidir. Sipariş ve iade akışında daha iyi puan alan aday, genellikle günlük operasyonda daha az sürtünme yaratır. Puanlar yine eşitse, veri taşınabilirliği daha güçlü olan seçenek ileride daha fazla hareket alanı bırakır.

Altyapı Kararını Satış Sisteminizin İçinde Değerlendirin

Altyapı, satış sisteminin bir parçasıdır; sistemin kendisi değildir. Doğru altyapı seçilse bile ürün içerikleri zayıfsa, trafik planı yoksa veya sipariş operasyonu tanımlanmamışsa satış beklenen düzeye ulaşmaz. Tersine, iyi kurgulanmış bir satış modeli ve operasyon, ortalama bir altyapıyla bile sağlıklı çalışabilir.

Bu nedenle altyapı kararını tek başına değil; satış modeli, kanal stratejisi, operasyon kapasitesi ve büyüme planıyla birlikte verin. Bu bütünü nasıl ele aldığımızı dijital ticaret yaklaşımımızda anlatıyoruz.

Seçilen altyapıyı ödeme ve operasyonla bağlamak için kurulum rehberine geçin.

Şeffaflık notu

Destory, IdeaSoft iş ortağıdır. Ancak altyapı önerisini iş ortaklığı ilişkisine göre değil; satış modeli, sipariş akışı, operasyon ihtiyacı, toplam sahip olma maliyeti ve veri taşınabilirliği üzerinden değerlendirir.

Değerlendirmenizde Türkiye odaklı hazır altyapıları da aday listesine almak istiyorsanız, IdeaSoft seçeneklerini inceleyebilirsiniz. Hangi aday incelenirse incelensin, yukarıdaki testler ve karar matrisi aynı şekilde uygulanmalıdır.

Altyapı seçiminde amaç en çok özelliğe sahip sistemi bulmak değil; işletmenizin gerçek sipariş akışını en az sürtünmeyle taşıyan, maliyeti öngörülebilir ve gerektiğinde terk edilebilir bir sistemi seçmektir.