E-Ticaret Sitesi Yapan Firmalardan Yeniden Platformlama Teklifi Nasıl İstenir?

Yeniden platformlama teklifine hangi bilgilerle başlanmalı?

Firmalara gönderilecek ilk paket, mevcut mağazanın teknik ve operasyonel fotoğrafını vermelidir. Kullanılan e-ticaret altyapısı, sürüm bilgisi, barındırma modeli, ürün ve varyant sayısı, aylık sipariş hacmi, aktif kullanıcı sayısı, ödeme ve kargo yöntemleri, pazaryeri bağlantıları ve kritik iş akışları aynı formatta sunulmalıdır. Teklifin karşılaştırılabilir olması için tüm adaylara aynı envanter gönderilmelidir.

Mevcut sistem envanteri ne kadar ayrıntılı olmalı?

Envanter yalnızca teknoloji isimlerinden oluşmamalı; hangi sistemin hangi veriyi ürettiği ve hangi bağlantının iş açısından kritik olduğu da belirtilmelidir. Özellikle mevcut mağazadaki özel geliştirmeler, manuel operasyonlar ve dönemsel yoğunluklar iş yükünü doğrudan etkiler. Veri ve kesintisiz geçiş planını hazırlarken e-ticaret yazılımı yenileme projesinde veri taşıma yaklaşımını ayrıca incelemek, teklif kapsamını daha somut hâle getirir.

• Mevcut platform, sürüm ve barındırma yapısı
• Ürün, varyant, müşteri ve sipariş hacimleri
• Ödeme, kargo, ERP, CRM ve pazaryeri bağlantıları
• Özel modüller ve özelleştirilmiş iş akışları
• Yoğun satış dönemleri ve operasyon kısıtları

Planlar değersizdir, ama planlama her şeydir.- Dwight D. Eisenhower

Veri aktarımı kapsamı teklif içinde nasıl tanımlanmalı?

Veri aktarımı, “mevcut veriler taşınacak” şeklinde tek satırla bırakılmamalıdır. Hangi kayıt türlerinin, hangi tarih aralığıyla, hangi alan eşlemeleriyle ve hangi doğrulama yöntemiyle yeni sisteme aktarılacağı açıkça yazılmalıdır. Kapsamın temel birimi kayıt türü ve doğrulama kriteridir. Ürünler, varyantlar, kategoriler, müşteriler, adresler, siparişler, kuponlar, stoklar, görseller ve içerikler ayrı ayrı değerlendirilmelidir.

Hangi kayıtlar mutlaka ayrı kalem olarak sorulmalı?

Her veri grubunda temizleme ihtiyacı, zorunlu alanlar, geçmiş kayıtların korunma süresi ve kişisel verilerin işlenme yöntemi farklı olabilir. Bu nedenle teklif veren firmadan yalnızca aktarım değil, veri hazırlama ve doğrulama iş yükünü de ayırması istenmelidir. Özellikle katalog tarafında ürün verisi temizliği ve katalog aktarımının kapsam üzerindeki etkisi tekliflerin neden farklılaştığını anlamaya yardımcı olur.

• Ürün, kategori, varyant ve medya kayıtları
• Müşteri, adres ve izin tercihleri
• Sipariş, iade ve ödeme geçmişi
• Stok, fiyat, kampanya ve kupon verileri
• Blog, sayfa ve diğer içerik kayıtları
• Aktarım sonrası örnekleme ve mutabakat kontrolleri

Entegrasyonlar ve özel akışlar nasıl teklif kapsamına alınır?

Yeniden platformlama projesinde entegrasyonlar ayrı bir iş paketi olarak tanımlanmalıdır; çünkü bağlantının var olması, yeni altyapıda aynı biçimde çalışacağı anlamına gelmez. API yöntemi, veri yönü, senkronizasyon sıklığı, hata senaryoları ve sorumlu sistem belirtilmelidir. Her entegrasyon için kaynak sistem, hedef sistem, veri alanları ve kabul kriteri yazılmalıdır.

Özel süreçler neden standart modüllerden ayrılmalı?

ERP stok güncellemesi, müşteri segmentine özel fiyat, bayi siparişi, ön sipariş, hediye kartı, abonelik, fatura veya pazaryeri akışı gibi süreçler işletmeye özgü olabilir. Bunların yeni platformda hazır özellik, üçüncü taraf uygulama veya özel geliştirme ile çözülüp çözülmeyeceği teklifte görünmelidir. Aksi durumda başlangıçta düşük görünen teklif, uygulama sırasında yeni geliştirme kalemleriyle genişleyebilir.

• API ve webhook bağlantılarının listesi
• Veri yönü ve senkronizasyon sıklığı
• Hata, tekrar deneme ve loglama yaklaşımı
• Özel fiyat, stok ve sipariş kuralları
• Üçüncü taraf lisans ve hesap bağımlılıkları

Tasarım uyarlaması yeni platform teklifinde nasıl sorulmalı?

Tasarım tarafında “mevcut görünüm taşınacak” ifadesi yeterli değildir. Teklifte hangi sayfa şablonlarının birebir korunacağı, hangi bileşenlerin yeniden geliştirileceği, mobil davranışların nasıl ele alınacağı ve hedef platformun kısıtlarının tasarıma nasıl yansıyacağı tanımlanmalıdır. Tasarım uyarlaması, görsel kopyalama değil işlev ve deneyim eşlemesidir.

Hangi ekranlar ayrı teslimat olarak belirtilmeli?

Ana sayfa, kategori, ürün, arama, sepet, ödeme, müşteri hesabı ve içerik sayfaları en azından ayrı şablonlar olarak listelenmelidir. Özel kampanya sayfaları, B2B ekranları veya üyelik akışları varsa ayrıca eklenmelidir. Tasarım sistemi, mevcut marka varlıkları ve erişilebilirlik beklentileri de verilirse firmalar yeniden tasarım ile uyarlama arasındaki iş farkını daha doğru fiyatlayabilir.

• Ana sayfa ve navigasyon bileşenleri
• Kategori, arama ve filtreleme ekranları
• Ürün detay ve varyant davranışları
• Sepet, ödeme ve üyelik akışları
• Mobil kırılımlar ve özel kampanya şablonları

URL geçişi ve SEO sorumluluğu firmalara nasıl dağıtılır?

URL geçişi, yeniden platformlamanın yalnızca teknik bir alt işi değil, organik görünürlüğü etkileyebilen kritik bir teslimattır. Mevcut URL envanterinin çıkarılması, yeni URL yapısının eşlenmesi, yönlendirme kurallarının hazırlanması, canonical ve robots kontrolleri ile sitemap doğrulaması kimin sorumluluğunda olacaksa teklifte açıkça yazılmalıdır. SEO geçişinde sahiplik belirsizliği, son dakika hatalarının en önemli kaynaklarından biridir.

Ajans, SEO ekibi ve müşteri arasında görev dağılımı nasıl olmalı?

Teknik geliştirme firması yönlendirmeleri uygulayabilir; ancak hangi URL’nin nereye taşınacağına ilişkin karar müşteri veya SEO sorumlusu tarafından onaylanmalıdır. Analytics ve arama konsolu kontrolleri de canlıya alma planına eklenmelidir. Konuyu daha ayrıntılı çerçevelemek için e-ticaret altyapısı geçişinde ERP, CRM, sipariş ve SEO verilerinin korunması başlığındaki riskler teklif talebine yansıtılabilir.

• Mevcut ve yeni URL eşleme dosyası
• 301 yönlendirme uygulama sorumluluğu
• Canonical, robots ve sitemap kontrolleri
• Analytics ve arama konsolu doğrulaması
• Canlı sonrası kırık bağlantı ve indeks kontrolü

Deneme aktarımı ve test planı teklifte neden ayrı olmalı?

Sınırlı veriyle yapılan deneme aktarımı, tam geçişten önce alan eşlemelerini, veri kalitesini ve beklenmeyen bağımlılıkları görmeyi sağlar. Teklifte pilot aktarımın kapsamı, kaç örnek kayıtla yapılacağı, hangi sonuçların kontrol edileceği ve bulunan hataların nasıl düzeltileceği ayrı bir teslimat olarak istenmelidir. Pilot aktarım, geçiş öncesi teknik belirsizliği azaltan bir doğrulama adımıdır.

Kabul testleri hangi işlevleri kapsamalı?

Test planı yalnızca sayfaların açılmasını değil, gerçek kullanıcı ve operasyon senaryolarını kapsamalıdır. Ürün arama, fiyat hesaplama, stok, ödeme, kargo, sipariş oluşturma, e-posta bildirimleri, entegrasyonlar ve yönetim paneli kontrolleri için kimin test edeceği ve hangi hataların canlıya geçişi durduracağı tanımlanmalıdır. UAT yani kullanıcı kabul testi, müşteri ekibinin onay sorumluluğunu da görünür kılar.

• Sınırlı veriyle pilot aktarım
• Alan eşleme ve kayıt sayısı kontrolleri
• Kritik alışveriş senaryolarının testi
• Entegrasyon ve hata senaryosu testleri
• UAT onayı ve hata önceliklendirme kuralları

Canlıya geçiş sorumlulukları yeniden platformlamada nasıl yazılır?

Canlıya geçiş, kimlerin hangi sırayla ne yapacağını tanımlayan bir kesim planına bağlanmalıdır. Son veri aktarımı, siparişlerin dondurulması gerekiyorsa zaman penceresi, DNS veya alan adı değişiklikleri, ödeme kontrolleri, entegrasyon aktivasyonu ve geri dönüş planı teklif içinde sorumlularıyla birlikte gösterilmelidir. Canlıya alma, tek bir tarih değil birbirine bağlı görevler dizisidir.

Müşteri ekibinde kalacak işler nasıl belirtilmeli?

Firma bazı hesaplara erişim sağlayamaz, ticari onay veremez veya operasyonel kararları müşteri adına alamaz. Bu nedenle ödeme sağlayıcısı onayı, ERP erişimi, içerik kontrolü, kampanya dondurma kararı ve UAT onayı gibi müşteri tarafındaki görevler ayrıca yazılmalıdır. Bu ayrım, gecikmelerin hangi bağımlılıktan kaynaklandığını proje sırasında daha kolay göstermeyi sağlar.

• Son veri aktarımı ve veri dondurma kararı
• DNS, alan adı ve sertifika işlemleri
• Ödeme ve sipariş doğrulama adımları
• Entegrasyonların canlı moda alınması
• Geri dönüş ve acil durum planı
• Müşteri tarafı onay ve erişim sorumlulukları

Kapsam dışı işler ve varsayımlar tekliflerde nasıl gösterilmeli?

Kapsam dışı kalemler, teklifin dipnotlarında belirsiz biçimde bırakılmamalı; ayrı bir bölümde görünür şekilde yazılmalıdır. İçerik girişi, ürün verisi temizliği, üçüncü taraf lisanslar, eski kodun düzeltilmesi, yeni özellik geliştirme, fotoğraf düzenleme veya SEO içerik üretimi gibi işler dahil değilse açıkça belirtilmelidir. İyi teklif, neyin yapılacağını kadar neyin yapılmayacağını da netleştirir.

Varsayım listesi neden teklif karşılaştırmasının parçasıdır?

Bir firma “veriler temiz teslim edilecek” varsayımıyla, diğeri veri düzenlemeyi dahil ederek fiyat verebilir. Bu iki teklif aynı kapsam değildir. Benzer farkları görmek için e-ticaret sitesi tekliflerindeki dahil ve hariç hizmetleri karşılaştırma yaklaşımı kullanılabilir. Varsayımlar, bağımlılıklar ve ek iş fiyatlandırma yöntemi aynı tabloda istenirse sonradan oluşabilecek anlaşmazlıklar azalır.

• Açık kapsam dışı iş listesi
• Müşteriden beklenen veri ve erişimler
• Üçüncü taraf lisans ve servis ücretleri
• Ek geliştirme talebinin değişiklik süreci
• Varsayım bozulduğunda fiyat ve takvim etkisi

Platform değiştirme teklifleri hangi formatta karşılaştırılmalı?

Teklifler yalnızca toplam bedel üzerinden değil, aynı iş paketleri ve aynı kabul kriterleri üzerinden karşılaştırılmalıdır. Veri aktarımı, tasarım, entegrasyon, SEO geçişi, test, canlıya alma, eğitim ve destek ayrı satırlara bölündüğünde kapsam farkları görünür olur. Karşılaştırma bir fiyat tablosundan önce kapsam eşleştirme çalışmasıdır.

Teklif değerlendirme matrisinde hangi alanlar bulunmalı?

Her sağlayıcı için teslimat, sorumlu taraf, varsayım, kapsam dışı işler, bağımlılıklar, tahmini faz planı ve destek modeli aynı başlıklarla kayıt altına alınmalıdır. Ayrıca referans proje türü, proje ekibinin rolleri ve iletişim modeli gibi nitel unsurlar da eklenebilir. Böylece düşük fiyatlı ama dar kapsamlı bir teklif ile daha geniş sorumluluk alan bir teklif yanlış biçimde eşdeğer kabul edilmez.

• İş paketi ve teslimat tanımı
• Sorumlu taraf ve müşteri bağımlılıkları
• Varsayım ve kapsam dışı kalemler
• Test ve kabul kriterleri
• Faz planı ve canlıya geçiş yaklaşımı
• Canlı sonrası destek modeli

Geçiş süresi ve hedef yayın tarihi firmalara nasıl verilmeli?

Hedef yayın tarihi tek başına yeterli değildir; bu tarihin iş zorunluluğu mu yoksa tercih mi olduğu ve hangi kilometre taşlarının geriye doğru planlanması gerektiği açıklanmalıdır. Veri hazırlığı, tasarım onayı, entegrasyon geliştirme, pilot aktarım, UAT ve canlıya alma için müşteri tarafındaki karar süreleri de takvime dahil edilmelidir. Takvim, yalnızca sağlayıcının çalışma süresi değil ortak bağımlılıkların toplamıdır.

Takvim tekliflerinde hangi fazlar ayrı görünmeli?

Firmalardan keşif, geliştirme, içerik ve veri hazırlığı, test, geçiş provası ve canlıya alma fazlarını ayrı göstermeleri istenebilir. Eğitim ve operasyon hazırlığı da son güne bırakılmamalıdır. Bu noktada yayına alma ve ekip eğitiminin tekliflerde nasıl karşılaştırıldığı zaman planını oluştururken yararlı bir kontrol listesi sağlar.

• Keşif ve teknik analiz fazı
• Tasarım ve geliştirme fazı
• Veri hazırlığı ve pilot aktarım
• UAT ve hata düzeltme dönemi
• Geçiş provası ve canlıya alma
• Ekip eğitimi ve operasyon hazırlığı

Canlıya geçiş sonrası destek süresi nasıl tanımlanmalı?

Canlı sonrası destek için tek bir ideal süre yoktur; mağazanın karmaşıklığına, entegrasyon sayısına, sipariş hacmine ve iç ekibin kapasitesine göre kapsam belirlenmelidir. Teklifte süreden önce hangi hataların destek kapsamına girdiği, yanıt ve müdahale modeli, izleme sorumluluğu ve bakım dönemine geçiş koşulları açıklanmalıdır. Destek süresi kadar desteğin sınırları ve servis modeli de önemlidir.

Garanti dönemi ile sürekli bakım birbirinden nasıl ayrılır?

Proje tesliminden kaynaklanan hata düzeltmeleri ile yeni özellik, optimizasyon veya üçüncü taraf değişiklikleri aynı paket sayılmamalıdır. Sağlayıcının operasyon sonrası kapasitesini değerlendirirken e-ticaret altyapısı sağlayıcısının teknik kapasitesi ve destek hizmetini doğrulama kriterleri kullanılabilir. Kritik satış dönemleri varsa destek penceresi bu takvimle de ilişkilendirilmelidir.

• Hata düzeltme ve garanti kapsamı
• Yanıt ve müdahale iletişim modeli
• İzleme ve olay takibi sorumluluğu
• Yeni geliştirme taleplerinin ayrıştırılması
• Sürekli bakım dönemine geçiş koşulları

Firmalara gönderilecek nihai teklif talebi nasıl hazırlanmalı?

Nihai teklif talebi, aday firmaların aynı sorulara aynı sırada cevap vereceği yapılandırılmış bir doküman olmalıdır. Mevcut sistem envanteri, hedef platform beklentileri, veri kapsamı, entegrasyonlar, tasarım gereksinimleri, URL geçişi, test, canlıya alma, sorumluluk matrisi, varsayımlar, kapsam dışı işler ve destek beklentisi tek pakette toplanmalıdır. Aynı formatta teklif istemek, karar sürecini hızlandıran en pratik adımdır.

Teklif talebi gönderilmeden önce son kontrol ne olmalı?

Dokümanı göndermeden önce bilinmeyen noktalar açıkça “belirlenecek” olarak işaretlenmeli, firmalardan bunlara ilişkin varsayımlarını yazmaları istenmelidir. Ayrıca pilot veri aktarımı ve teknik keşif ihtiyacı teklifin ayrı bir ön fazı olarak sorulabilir. Böylece işletme, farklı e-ticaret geçiş sağlayıcısı seçeneklerini yalnızca rakamlarla değil teslim sorumluluğu, risk yönetimi ve canlı sonrası destek açısından da karşılaştırabilir.

• Teknik ve operasyonel mağaza envanteri
• İş paketleri ve beklenen teslimatlar
• Müşteri ve sağlayıcı sorumluluk matrisi
• Kapsam dışı işler, varsayımlar ve bağımlılıklar
• Pilot aktarım, test ve kabul kriterleri
• Canlıya alma ve destek beklentileri