E Ticaret Sitesi Teklifi Nasıl Alınır? Teknik Şartname ve Firma Karşılaştırma Rehberi

E Ticaret Teklifi Almadan Önce Kapsam Nasıl Belirlenir?

E ticaret teklifi istemeden önce hazırlanması gereken ilk bilgi, projenin ne satacağından çok nasıl çalışacağını açıklayan bir proje özetidir. İş modeli, hedef müşteri, satış kanalları, operasyon süreçleri ve mevcut sistemler tanımlandığında firmalar aynı problemi değerlendirebilir. Karşılaştırılabilir teklifin temeli ortak ve açık bir proje kapsamıdır.

Proje özeti hangi bilgileri içermelidir?

Proje özeti teknik dokümanın yerine geçmez; işletmenin ticari hedeflerini ve temel beklentilerini teknoloji ekibinin anlayabileceği çerçeveye taşır. Yeni kurulacak bir sistem ile mevcut mağazanın yenilenmesi, veri aktarımı ve entegrasyon sorumlulukları açısından farklı kapsamlar doğurur. Projenin planlama boyutunu ayrıntılandırmak için e ticaret sitesi kurma sürecinin nasıl planlandığını ayrıca değerlendirmek yararlı olur.

• B2C, B2B veya hibrit satış modeli
• Hedef müşteri ve satış yapılacak pazarlar
• Mevcut sistemler ve taşınacak veriler
• Ürün, kategori ve varyant yapısı
• Ödeme ve teslimat senaryoları
• Beklenen entegrasyonlar ve operasyon akışları

İyi tasarım, mümkün olduğunca az tasarımdır. - Dieter Rams

E Ticaret Teknik Şartnamesinde Neler Tanımlanmalıdır?

E ticaret teknik şartnamesi, firmalara yalnızca istenen özelliklerin listesini değil, sistemin iş kurallarını, teslimat sınırlarını ve kabul kriterlerini anlatmalıdır. Böylece her firma aynı fonksiyonları, entegrasyonları ve sorumlulukları dikkate alarak teklif hazırlayabilir; yoruma açık kapsam farklılıkları azaltılabilir.

Modüller iş senaryolarıyla birlikte açıklanmalıdır

“Ürün yönetimi”, “kampanya sistemi” veya “B2B modülü” gibi genel ifadeler tek başına yeterli değildir. Örneğin B2B tarafında müşteri gruplarına özel fiyatlar, ödeme vadeleri, sipariş onayı veya satış temsilcisi yetkileri gerekebilir. Teknik şartname, özelliğin adından çok özelliğin hangi kuralla ve hangi kullanıcı için çalışacağını belirtmelidir.

• Ürün, kategori, marka ve varyant yönetimi
• Müşteri hesapları, roller ve yetkiler
• Sepet, sipariş ve iade süreçleri
• Kampanya, kupon ve indirim kuralları
• B2B fiyatlandırma ve bayi senaryoları
• Raporlama ve yönetim paneli ihtiyaçları
• Çoklu dil ve para birimi gereksinimleri

E Ticaret Projesinde Ürün Sayısı Neden Yeterli Değildir?

Ürün sayısı e ticaret projesinin kapsamını etkileyebilir ancak tek başına geliştirme karmaşıklığını göstermez. Az sayıda ürüne sahip bir mağaza; çok sayıda varyant, müşteriye özel fiyat, gelişmiş filtre, farklı stok kaynakları veya karmaşık sipariş kuralları nedeniyle daha kapsamlı bir teknik yapıya ihtiyaç duyabilir.

Katalog ve müşteri modeli birlikte değerlendirilmelidir

Teklif talebinde ürünlerin yalnızca toplam adedi değil, ürünlerin nasıl yönetildiği açıklanmalıdır. Aynı şekilde perakende müşteri, bayi, kurumsal alıcı veya satış temsilcisi gibi roller farklı yetki ve fiyatlandırma mekanizmaları gerektirebilir. Katalog yapısının doğru tarif edilmesi, yönetim panelinin ve veri modelinin gerçek ihtiyaca göre tasarlanmasını sağlar.

• Ürün başına varyant ve özellik sayısı
• Kategori ve marka hiyerarşisi
• Müşteri gruplarına özel fiyatlar
• Stok ve depo yapıları
• Minimum sipariş ve paket kuralları
• Arama, filtreleme ve karşılaştırma ihtiyaçları

E Ticaret Entegrasyonları Teklifte Nasıl Tanımlanmalıdır?

Ödeme, kargo, pazaryeri, ERP ve CRM bağlantıları e ticaret teklifinin en açık tanımlanması gereken teknik alanlarındandır. Entegrasyonun yalnızca adı değil; hangi verinin hangi yönde aktarılacağı, hangi sistemin ana veri kaynağı olacağı ve hata durumlarının nasıl yönetileceği şartnamede açıklanmalıdır.

Her entegrasyon ayrı bir veri akışı olarak düşünülmelidir

Örneğin ERP bağlantısında ürün, stok, fiyat, müşteri ve sipariş verilerinin tamamı aynı yönde veya aynı sıklıkta hareket etmeyebilir. Pazaryeri ve ödeme servislerinde de farklı API sınırları bulunabilir. Bu nedenle e ticaret sitesi için gerekli entegrasyonların proje başlamadan belirlenmesi tekliflerin karşılaştırılabilirliğini artırır.

• Sanal POS ve alternatif ödeme sistemleri
• Kargo ve teslimat servisleri
• Pazaryeri bağlantıları
• ERP ve stok yönetimi entegrasyonları
• CRM ve müşteri verisi akışları
• Muhasebe ve e-belge servisleri
• Entegrasyon hata kayıtları ve yeniden deneme süreçleri

E Ticaret Tasarım ve Yazılım Kapsamı Nasıl Ayrıştırılır?

E ticaret yazılım teklifinde tasarım ile geliştirme ayrı teslimatlar olarak tanımlanmalıdır. UX çalışması, arayüz tasarımı, responsive düzenler, yönetim paneli ve yazılım geliştirme birbirine bağlı olsa da farklı iş yükleri oluşturur. Hazır tema kullanımı ile markaya özel tasarımın aynı kapsam olarak değerlendirilmesi yanıltıcı olabilir.

Hazır altyapı ve özel geliştirme dengeli değerlendirilmelidir

Hazır platformlar standart gereksinimlerde hızlı yapılandırma ve mevcut ekosistemlerden yararlanma avantajı sağlayabilir. Özel geliştirme ise farklı iş kuralları ve entegrasyon ihtiyaçlarında daha fazla kontrol sunabilir. Karar; yalnızca başlangıç teklifine değil, özelleştirme sınırlarına, lisans bağımlılığına, veri taşınabilirliğine ve uzun vadeli işletme ihtiyacına göre verilmelidir.

• UX araştırması ve kullanıcı akışları
• Özgün veya tema tabanlı arayüz tasarımı
• Mobil ve farklı ekran uyarlamaları
• Yönetim paneli geliştirmeleri
• Özel modül ve iş kuralları
• Revizyon ve tasarım onay süreçleri

E Ticaret Teklifinde SEO, Performans ve Güvenlik Nedir?

E ticaret sitesi teklifi yalnızca görünen ekranları ve satış fonksiyonlarını kapsamamalıdır. Teknik SEO, GEO uyumluluğu, sayfa performansı, erişilebilirlik ve güvenlik gereksinimleri geliştirme aşamasında tanımlanmadığında bunların sonradan eklenmesi ayrı çalışma gerektirebilir. Bu nedenle kalite kriterlerinin teklif kapsamına açıkça yazılması önemlidir.

Teknik kalite ölçülebilir kabul kriterlerine bağlanmalıdır

Ürün ve kategori URL yapısı, canonical yönetimi, yapılandırılmış veri, indeksleme kontrolleri ve performans yaklaşımı başlangıçtan itibaren mimariye dahil edilmelidir. e ticaret SEO çalışmalarının kapsamı incelendiğinde görünürlüğün yalnızca içerik üretiminden ibaret olmadığı daha net görülür.

• Teknik SEO ve taranabilir site mimarisi
• Ürün ve kategori yapılandırılmış verileri
• Core Web Vitals ve performans kontrolleri
• Mobil kullanılabilirlik ve erişilebilirlik
• KVKK ve çerez yönetimi gereksinimleri
• Yetkilendirme, loglama ve güvenlik kontrolleri
• Yedekleme ve kritik veri koruma süreçleri

E Ticaret Teklifinde Veri Taşıma ve Test Nasıl Yazılır?

Mevcut bir sistem yenileniyorsa veri taşıma, teklifin ayrı bir teslimatı olarak tanımlanmalıdır. Ürünların yanında müşteriler, sipariş geçmişi, varyantlar, görseller, kategoriler, URL'ler ve gerekli ilişkisel veriler de değerlendirilmelidir. Taşınacak veri türü, temizleme sorumluluğu ve doğrulama yöntemi belirtilmeden kapsamın doğru hesaplanması güçleşir.

Test ve kabul şartları yayından önce belirlenmelidir

Geliştirmenin tamamlanması projenin otomatik olarak kabul edildiği anlamına gelmemelidir. Fonksiyonel testler, entegrasyon testleri, farklı ekran ve tarayıcı kontrolleri, sipariş senaryoları ve kullanıcı kabul testleri teklif içinde tanımlanmalıdır. Canlıya geçiş için hangi hataların engelleyici sayılacağı ve düzeltmelerin nasıl yönetileceği de önceden kararlaştırılmalıdır.

• Taşınacak veri türleri ve kapsamı
• Veri temizleme ve eşleştirme sorumluluğu
• Test ortamı ve örnek veri hazırlığı
• Fonksiyonel ve entegrasyon testleri
• Kullanıcı kabul testleri
• Canlıya geçiş kontrol listesi
• Taşıma sonrası veri doğrulaması

E Ticaret Projesinde Kod ve Veri Kime Ait Olmalıdır?

Kaynak kodu, müşteri verileri, ürün içerikleri, alan adı, hosting ve yönetici hesaplarının sahipliği teklif ve sözleşmede ayrı ayrı açıklanmalıdır. İşletmenin kendi ticari verilerine erişimi ve bunları dışa aktarabilmesi sözleşmesel olarak güvence altına alınmalıdır. Kaynak kodunun devri ise kullanılan lisans modeli ve üçüncü taraf bileşenlerden ayrı değerlendirilmelidir.

Sahiplik ile kullanım hakkı aynı kavram değildir

Projede kullanılan bazı kütüphaneler, temalar veya servisler üçüncü taraf lisanslarına tabi olabilir. Bu nedenle “kaynak kodu teslim edilir” ifadesinin hangi özel geliştirmeleri kapsadığı açıklanmalıdır. Alan adı, analitik hesapları, ödeme hesapları ve sunucu erişimleri de mümkün olduğunca işletmenin kontrolünde tutulmalı; firma değişikliğinde devir prosedürü önceden tanımlanmalıdır.

• Özel geliştirilen kaynak kodunun durumu
• Üçüncü taraf lisans ve eklentiler
• Veritabanı ve ticari veri sahipliği
• Alan adı ve hosting hesapları
• Ödeme ve harici servis hesapları
• Tasarım dosyaları ve teknik dokümantasyon
• Proje sonunda devir teslim koşulları

E Ticaret Firma Teklifleri Aynı Kapsamda Nasıl Kıyaslanır?

E ticaret firma karşılaştırma sürecinde toplam teklif tutarını tek ölçüt olarak kullanmak doğru bir karşılaştırma sağlamaz. Bir teklifte tasarım, veri aktarımı, lisanslar ve destek dahilken diğerinde bunlar ayrı bırakılmış olabilir. Firmalar aynı teknik şartnameye cevap verdiğinde kapsam farkları görünür hâle gelir ve ticari değerlendirme daha anlamlı yapılabilir.

Teklifler teslimat ve sorumluluk bazında puanlanmalıdır

Teknik yeterlilik, proje yönetimi, entegrasyon deneyimi, dokümantasyon, destek modeli ve devir koşulları birlikte değerlendirilmelidir. Firma seçimini daha sistematik yapmak isteyen işletmeler, e ticaret sitesi geliştirme ajansı seçim kriterlerini teklif karşılaştırma matrisiyle birlikte kullanabilir.

• Teklif edilen fonksiyonların kapsam eşitliği
• Entegrasyonların dahil ve hariç sınırları
• Tasarım ve revizyon teslimatları
• Lisans ve üçüncü taraf giderleri
• Test, eğitim ve veri taşıma kapsamı
• Sahiplik ve devir koşulları
• Garanti, bakım ve destek modeli

E Ticaret Teklifinde Garanti ve Destek Nasıl Belirlenir?

Bakım, garanti ve teknik destek koşulları e ticaret projesi teklifinde belirsiz ifadelerle bırakılmamalıdır. Garanti döneminde hangi yazılım hatalarının düzeltileceği, yeni geliştirme taleplerinin nasıl ayrılacağı, güncelleme ve yedekleme sorumlulukları ile destek kanalının kapsamı açık biçimde tanımlanmalıdır. Böylece ilk yatırım ile sürekli işletme giderleri birbirinden ayrılabilir.

Teklif istemeden önce son kontrol listesi hazırlanmalıdır

Firmalara gönderilecek ortak doküman; proje hedefi, modüller, entegrasyonlar, veri taşıma, teknik kalite, sahiplik ve satış sonrası hizmetleri aynı başlıklarla içermelidir. Ödeme entegrasyonlarının özel kapsamını belirlemek için e ticaret platformunda ödeme entegrasyonu sürecini incelemek de şartnameyi ayrıntılandırmaya yardımcı olabilir. Böyle bir yapı, firmaların varsayımlar yerine aynı gereksinimlere teklif vermesini sağlar.

• Proje özeti ve iş modeli hazır mı?
• Modüller ve kullanıcı rolleri tanımlı mı?
• Entegrasyonların veri akışları belirtilmiş mi?
• Veri taşıma ve test kapsamı yazılmış mı?
• Lisans ve işletme giderleri ayrılmış mı?
• Kod, veri ve hesap sahipliği açıklanmış mı?
• Garanti, bakım ve destek şartları net mi?
• Tüm firmalara aynı şartname gönderiliyor mu?