E-Ticaret Sitesi Fiyatları İçin Firma Tekliflerinde Dahil ve Hariç Hizmetler Nasıl Karşılaştırılır?

E-Ticaret Sitesi Fiyat Teklifleri Neden Farklılaşır

E-ticaret sitesi fiyat teklifleri, firmaların aynı projeyi farklı kapsam, teknoloji, ekip yapısı ve destek modeliyle ele alması nedeniyle farklılaşır. Bir teklif yalnızca temel mağaza geliştirmeyi kapsarken başka bir teklif analiz, özel tasarım, entegrasyon, veri aktarımı, test, eğitim ve bakım hazırlığını birlikte içerebilir. Fiyat farkını anlamanın ilk adımı, her teklifin hangi somut teslimatları içerdiğini aynı başlıklar altında karşılaştırmaktır.

Toplam fiyat yerine teslimat yapısını inceleyin

Teklif satırlarının isimleri benzer olsa bile hizmet derinliği aynı olmayabilir. Örneğin “entegrasyon dahil” ifadesi tek bir ödeme bağlantısını da ERP, kargo ve pazaryeri akışlarının tamamını da ifade edebilir. Bu nedenle e-ticaret sitesi fiyatları ve teklif karşılaştırma yaklaşımında olduğu gibi fiyatı; kapsam, sorumluluk, devam eden gider ve teknik bağımlılıklarla birlikte okumak gerekir.

• Proje analizi ve danışmanlık kapsamı
• Özgün tasarım ve arayüz geliştirme seviyesi
• Yazılım ve yönetim paneli kapsamı
• Entegrasyon veri aktarımı ve test sorumlulukları
• Yayın sonrası bakım ve teknik destek modeli
• Lisans hosting ve üçüncü taraf servis giderleri

Price is what you pay. Value is what you get.- Warren E. Buffett

E-Ticaret Sitesi Teklifinde Hangi Hizmetler Bulunmalıdır

E-ticaret sitesi teklifinde proje başlangıcından canlıya geçişe kadar gerekli ana hizmetler açıkça tanımlanmalıdır. İhtiyaç analizi, bilgi mimarisi, UX/UI tasarımı, frontend ve backend geliştirme, yönetim paneli, ürün ve kategori yapısı, ödeme ve kargo bağlantıları, test, eğitim ve yayına alma görevleri teklif içinde ayrı teslimatlar olarak görülebilmelidir.

Her hizmeti kabul edilebilir bir çıktıyla eşleştirin

“Profesyonel e-ticaret sitesi” gibi genel bir tanım satın alma açısından yeterli değildir. Hangi sayfaların tasarlanacağı, yönetim panelinden hangi işlemlerin yapılacağı, hangi cihaz ve tarayıcıların test edileceği ve hangi entegrasyonların kurulacağı yazılı olmalıdır. e-ticaret sitesi teklifinde bulunması gereken özellikler bu ana teslimatların proje ihtiyacına göre kontrol edilmesini kolaylaştırabilir.

• İhtiyaç analizi ve teknik gereksinim çalışması
• UX/UI tasarım ve responsive arayüz geliştirme
• Frontend backend ve yönetim paneli geliştirme
• Ürün kategori müşteri ve sipariş yapıları
• Ödeme kargo ve gerekli sistem entegrasyonları
• Test eğitim canlıya alma ve temel dokümantasyon

Analiz Tasarım ve Yazılım Kapsamı Nasıl Karşılaştırılır

Analiz, tasarım ve yazılım kalemleri iki teklif arasında aynı isimle yer alsa bile aynı iş yükünü ifade etmeyebilir. Analiz aşamasında yalnızca toplantı yapılması ile gereksinimlerin dokümante edilmesi farklıdır; hazır tema uyarlaması ile özgün UI/UX tasarımı da aynı kapsam değildir. Yazılım tarafında ise standart mağaza fonksiyonları ile özel iş kurallarının geliştirilmesi ayrı değerlendirilmelidir.

Özel geliştirmeleri standart özelliklerden ayırın

B2B fiyatlandırma, bayi yetkilendirmesi, özel kampanya motoru, farklı stok kaynakları veya kuruma özgü sipariş akışları ek yazılım gerektirebilir. Teklifte bu ihtiyaçların standart paket kapsamında mı yoksa ek geliştirme olarak mı ele alındığı belirtilmelidir. Böylece proje başladıktan sonra “bu özellik fiyata dahil değildi” biçimindeki kapsam anlaşmazlıklarının önüne geçilebilir.

• Analiz çıktılarının doküman ve gereksinim seviyesinde tanımı
• Hazır tasarım ile özgün tasarım ayrımının yapılması
• Standart mağaza fonksiyonlarının açıkça listelenmesi
• Özel iş kurallarının geliştirme kapsamının belirtilmesi
• Yönetim panelindeki kullanıcı ve yetki işlevleri
• Revizyon ve değişiklik taleplerinin sınırları

Veri Aktarımı Entegrasyon ve Test Kapsamı Nasıl Okunur

Veri aktarımı, entegrasyon ve test hizmetleri tekliflerde en sık genelleştirilen kalemler arasındadır. Ürün verisinin aktarılması; yalnızca başlık ve fiyat taşımakla sınırlı olabilir veya varyant, görsel, kategori, stok, SEO alanları ve geçmiş siparişleri kapsayabilir. Benzer şekilde entegrasyonun hangi sistemleri, hangi veri yönlerini ve hangi hata senaryolarını kapsadığı açıklanmalıdır.

Başarılı senaryo kadar hata senaryosunu da sorgulayın

Ödeme, kargo, ERP, CRM veya pazaryeri bağlantıları yalnızca normal çalışma koşullarında test edilmemelidir. Zaman aşımı, hatalı veri, tekrarlanan istek veya servis kesintisi gibi durumlarda sistemin nasıl davranacağı belirlenmelidir. Bu yaklaşım, e-ticaret yazılımı tekliflerini karşılaştırırken entegrasyon başlığının yalnızca “var” veya “yok” olarak değil, gerçek teknik kapsamıyla değerlendirilmesini sağlar.

• Aktarılacak veri türleri ve veri miktarı kapsamı
• Entegrasyon yapılacak sistemlerin açık listesi
• Veri akış yönleri ve senkronizasyon kuralları
• Hata zaman aşımı ve tekrar senaryoları
• Fonksiyonel ve kullanıcı kabul testlerinin kapsamı
• Canlıya geçiş öncesi hata kapatma sorumluluğu

Hosting Lisans ve Üçüncü Taraf Giderleri Nasıl İncelenir

Hosting, sunucu, SSL, ticari lisanslar ve üçüncü taraf servis ücretleri e-ticaret projesinin devam eden maliyetleri arasında yer alabilir ve başlangıç teklifine dahil olmayabilir. Ödeme kuruluşu komisyonları, e-posta servisleri, CDN, arama hizmetleri, ticari eklentiler, tema lisansları veya izleme araçları farklı sağlayıcılara ödenebilir. Bu nedenle her giderin kime, hangi periyotta ve hangi kullanım koşuluyla ödeneceği belirtilmelidir.

Tek seferlik ve tekrarlayan maliyetleri ayırın

Bir teklifin düşük görünmesinin nedeni, sonraki aylarda veya yıllarda oluşacak giderlerin başlangıç bedelinin dışında bırakılması olabilir. e-ticaret altyapılarında fiyat ve toplam maliyet yaklaşımında olduğu gibi lisans, barındırma, kullanım bazlı servis ve yenileme maliyetleri ayrı görünmelidir. Karşılaştırılması gereken değer yalnızca kurulum bedeli değil, sistemi çalışır durumda tutmanın toplam maliyetidir.

• Hosting veya bulut altyapısı ücreti
• SSL CDN e-posta ve izleme servisleri
• Ticari tema modül ve yazılım lisansları
• Ödeme ve diğer işlem bazlı servis giderleri
• Yıllık yenileme veya kullanım bazlı maliyetler
• Fiyat değişiminde müşterinin üstleneceği sorumluluklar

Bakım Sunucu ve Teknik Destek Ücretleri Dahil midir

Bakım, sunucu ve teknik destek ücretlerinin ilk fiyata dahil olup olmadığı teklif üzerinde açıkça görülmelidir. Bazı firmalar belirli bir yayın sonrası destek dönemini proje bedeline dahil ederken bakım anlaşmasını daha sonra başlatabilir; bazıları ise hosting ve bakım hizmetlerini baştan ayrı kalem olarak fiyatlandırabilir. Bu nedenle “destek dahil” ifadesinin hangi süreyi ve hangi işleri kapsadığı ayrıntılandırılmalıdır.

Bakım ile yeni geliştirmeyi birbirinden ayırın

Güvenlik güncellemeleri, hata düzeltmeleri, yedek kontrolü ve temel izleme bakım kapsamında değerlendirilebilirken yeni özellikler, tasarım değişiklikleri veya yeni entegrasyonlar ek geliştirme sayılabilir. Teknik desteğin çalışma saatleri, iletişim kanalı ve kritik olaylarda uygulanacak süreç de belirtilmelidir. Böylece e-ticaret bakım ücretleri ile e-ticaret teknik destek fiyatları aynı hizmetmiş gibi değerlendirilmez.

• Hosting ve sunucu yönetiminin teklif durumu
• Güvenlik ve bağımlılık güncellemelerinin kapsamı
• Yedekleme ve geri yükleme kontrol sorumluluğu
• Hata düzeltme ve bakım hizmetinin sınırları
• Destek günleri saatleri ve iletişim kanalları
• Yeni geliştirmelerin ayrıca ücretlendirilme yöntemi

Revizyon ve Ek Geliştirme Maliyetleri Nasıl Denetlenir

Revizyon ve ek geliştirme maliyetleri, proje sırasında bütçenin beklenenden fazla büyümesine yol açabilecek başlıca alanlardandır. Teklifte tasarım revizyonlarının kapsamı, onay sonrasında yapılacak değişikliklerin nasıl ele alınacağı ve yeni özellik taleplerinin hangi yöntemle fiyatlandırılacağı belirtilmelidir. Belirsiz değişiklik yönetimi, başlangıç fiyatı düşük olan bir teklifin proje ilerledikçe daha maliyetli hale gelmesine neden olabilir.

Değişiklik talebinin fiyatlama mekanizmasını önceden görün

Ek geliştirmeler sabit iş kalemi, saatlik çalışma, ayrı teklif veya sprint bazlı yöntemlerle fiyatlandırılabilir. Burada önemli olan kullanılan yöntemden çok, talebin kapsamının nasıl tahmin edildiği ve müşteri onayı olmadan maliyet oluşturulup oluşturulamayacağıdır. Ek iş süreci yazılı değilse, tekliflerin gerçek toplam maliyetini başlangıçta karşılaştırmak zorlaşır.

• Tasarım revizyonlarının adet veya kapsam sınırı
• Onay sonrası değişikliklerin değerlendirme yöntemi
• Yeni özellik taleplerinin fiyatlandırma modeli
• Ek iş başlamadan önce müşteri onayı şartı
• Kapsam değişikliğinin takvim üzerindeki etkisi
• Ek geliştirmenin bakım hizmetinden ayrılması

Kaynak Kod Sahipliği ve Garanti Koşulları Nasıl Okunur

Kaynak kod sahipliği, veri kontrolü ve garanti veya hata düzeltme koşulları teklif ile sözleşmede birbirinden ayrı olarak tanımlanmalıdır. Projeye özel geliştirilen kodun müşteriye hangi haklarla teslim edileceği, kod deposuna erişim verilip verilmeyeceği ve üçüncü taraf bileşenlerin hangi lisanslara tabi olduğu açık olmalıdır. Müşteri, ürün, sipariş ve kullanıcı verilerine sağlayıcı değişse bile erişebilmelidir.

Garanti ifadesinin hangi hataları kapsadığını belirleyin

“Garanti süresi” ifadesi yeni özellik geliştirme taahhüdü anlamına gelmemelidir. Teslim edilen kapsam içinde yazılım hatalarının nasıl düzeltileceği, kullanıcı kaynaklı değişikliklerin veya üçüncü taraf servis güncellemelerinin nasıl ele alınacağı açıklanmalıdır. Kod, veri, alan adı, hosting ve entegrasyon hesaplarının kontrol modeli de sözleşmenin sona ermesi halinde uygulanacak devir planıyla birlikte değerlendirilmelidir.

• Projeye özel kaynak kodun kullanım ve devir hakları
• Kod deposu ve sürüm geçmişine erişim
• Ürün sipariş müşteri ve diğer verilerin sahipliği
• Üçüncü taraf yazılımların lisans koşulları
• Hata düzeltme döneminin kapsam ve istisnaları
• Sözleşme sonunda kod veri ve hesap devri

SLA ve Yayın Sonrası Destek Koşulları Nasıl Karşılaştırılır

SLA ve yayın sonrası destek koşulları, sitenin çalışmaya başlamasından sonra oluşacak teknik olayların nasıl yönetileceğini gösterir. Kritik satış kesintisi, ödeme problemi, sipariş oluşturma hatası ve düşük etkili görsel sorun aynı öncelikte değerlendirilmemelidir. SLA içinde olay sınıfları, ilk müdahale hedefleri, çalışma saatleri, eskalasyon yöntemi ve durum bilgilendirme süreci açıkça tanımlanmalıdır.

Müdahale ile kalıcı çözümü aynı süre olarak okumayın

İlk müdahale, teknik ekibin sorunu incelemeye başlamasını; çözüm ise geçici veya kalıcı iyileştirmenin uygulanmasını ifade eder. Her proje için tek bir standart süre bulunmadığından kritik hizmetler ve bağımlı servisler dikkate alınmalıdır. e-ticaret firması teklifini teknik kapsam ve sözleşmeyle değerlendirme yaklaşımı, SLA maddelerini teslimat ve destek sorumluluklarıyla birlikte incelemeye yardımcı olur.

• Kritik yüksek orta ve düşük hata seviyeleri
• Her seviye için ilk müdahale hedefi
• Geçici ve kalıcı çözüm yaklaşımı
• Mesai içi ve mesai dışı destek koşulları
• Eskalasyon ve durum bilgilendirme yöntemi
• Üçüncü taraf servis sorunlarının kapsamı

En Düşük Fiyatlı Teklif Hangi Riskleri Taşıyabilir

En düşük fiyatlı teklif, gerekli tüm hizmetleri içeriyorsa uygun bir seçenek olabilir; ancak düşük fiyat tek başına avantaj olarak yorumlanmamalıdır. Analiz, test, veri aktarımı, bakım, dokümantasyon, kaynak kod teslimi veya yayın sonrası destek gibi kalemlerin çıkarılması başlangıç maliyetini azaltırken sonraki aşamalarda ek bütçe ve operasyon riski oluşturabilir. Bu nedenle fiyat farkının hangi hizmet veya sorumluluk farkından kaynaklandığı mutlaka açıklanmalıdır.

Eksik kapsamın iş sürekliliğine etkisini hesaplayın

Düşük maliyetli tekliflerde küçük ekip kapasitesi, sınırlı test, ortak kullanılan lisanslar, yetersiz dokümantasyon veya belirsiz destek koşulları bulunabilir; ancak bunlar her düşük fiyatlı teklif için varsayılmamalıdır. Risk değerlendirmesi kanıta dayanmalıdır. Asıl soru teklifin ucuz olup olmadığı değil, iş için gerekli kapsamın eksiksiz ve sürdürülebilir biçimde fiyatlandırılıp fiyatlandırılmadığıdır.

• Eksik analiz veya gereksinim dokümantasyonu
• Hazır bileşenlerin kapsamının açıklanmaması
• Test ve güvenlik çalışmalarının sınırlı tutulması
• Bakım ve desteğin proje bedeli dışında bırakılması
• Kaynak kod veya kritik hesaplarda sağlayıcı bağımlılığı
• Sonradan fiyatlanacak işlerin yüksek belirsizliği

E-Ticaret Fiyat Teklifleri İçin Karşılaştırma Listesi

E-ticaret sitesi fiyat teklifi karşılaştırma sürecini sağlıklı yürütmek için tüm teklifler ortak bir kontrol listesine aktarılmalıdır. Her kalem için hizmetin dahil, hariç veya ayrıca fiyatlanacak durumda olduğu işaretlenebilir; ancak karar yalnızca puan toplamına bağlanmamalıdır. Kaynak kod erişimi, veri sahipliği, kritik entegrasyon veya destek gibi temel gereksinimlerin eksikliği, toplam skordan bağımsız olarak ayrıca değerlendirilmelidir.

Son karardan önce toplam maliyet ve riski birlikte değerlendirin

e-ticaret sitesi tekliflerini firma bazında karşılaştırma yaklaşımıyla kapsamlar eşitlendikten sonra proje ekibi, teknik deneyim ve teslim sonrası destek kapasitesi incelenebilir. Firmadan örnek bakım kapsamı, lisans listesi, teslimat planı ve destek koşulları istenmesi belirsiz kalemleri azaltır. Böylece seçim, yalnızca ilk fiyatı değil işletme döneminde oluşacak teknik ve operasyonel maliyetleri de kapsayan daha bütüncül bir değerlendirmeye dayanır.

• Analiz tasarım ve geliştirme kapsamı 0–5 puan
• Veri aktarımı entegrasyon ve test kapsamı 0–5 puan
• Hosting lisans ve devam eden gider açıklığı 0–5 puan
• Bakım SLA ve teknik destek kapsamı 0–5 puan
• Kaynak kod veri ve hesap sahipliği 0–5 puan
• Ek geliştirme ve toplam maliyet şeffaflığı 0–5 puan