E-ticaret sitesi kurulum teklifi yayına alma aşamasını yalnızca “siteyi açma” olarak tanımlıyorsa, tekliflerin gerçek teslim kapsamını karşılaştırmak zorlaşır. Satışa başlayabilen bir mağaza; ödeme, kargo, vergi, bildirim, yönetici erişimi, ölçüm ve operasyon kontrollerinin birlikte tamamlandığı bir sistemdir. Buna ekip eğitimi, kullanım dokümanı, yayın günü desteği ve ilk siparişlerden sonra hata giderme yöntemi de eklenmelidir. Bu rehber, farklı firmaların fiyatlarını tek başına kıyaslamak yerine, işletmeyi satışa başlatacak somut teslimatları ve eğitim sorumluluklarını aynı kontrol listesi üzerinden değerlendirmenize yardımcı olur.
Yayına Hazır Teslim Teklif Karşılaştırmasında Ne Anlatır?
Yayına hazır teslim, e-ticaret sitesinin yalnızca internette erişilebilir olması değil, tanımlanan satış senaryolarının çalışır durumda doğrulanmış ve işletme ekibine devredilmiş olmasıdır. Bu nedenle teklif karşılaştırmasında “kurulum tamamlandı” cümlesi yerine hangi testlerin geçtiği, hangi hesapların teslim edildiği ve hangi operasyonların ekip tarafından uygulanabildiği incelenmelidir. Benzer şekilde e-ticaret sitesi tekliflerini firma ve kapsam açısından karşılaştırırken yayın ve devir maddelerinin ayrı satırlar halinde görünmesi değerlendirmeyi daha nesnel hâle getirir.
Teslim tanımını sonuç üzerinden okumak
Bir sağlayıcı tasarım, yazılım ve entegrasyon işlerini bitirmiş olabilir; ancak ödeme dönüşleri, kargo kuralları, sipariş e-postaları veya yönetici yetkileri kontrol edilmemişse operasyon tarafında hâlâ açık işler bulunabilir. Teklifteki toplam bedelin düşük ya da yüksek olması tek başına bu farkı açıklamaz. Karşılaştırmanın dayanağı, satışın ilk gününde hangi süreçlerin hazır olduğu ve hangi görevlerin müşteri ekibine bırakıldığıdır. Böylece teklif, teknik üretim listesinden işletmeye devredilen gerçek çalışma modeline dönüşür.
- Canlı alan adı ve güvenli bağlantı kontrolü
- Ödeme ve sipariş senaryolarının doğrulanması
- Kargo, vergi ve bildirim ayarlarının tamamlanması
- Yönetici hesapları ve yetkilerin teslim edilmesi
- Operasyon ekibinin temel işlemleri uygulayabilmesi
Kalite denetimden değil, üretim sürecinin iyileştirilmesinden gelir. - W. Edwards Deming
Yayına Hazır Teslim Hangi Kabul Testlerini İçermelidir?
E-ticaret kabul testi, gerçek satış akışını temsil eden önceden tanımlı senaryoların yayın öncesinde çalıştırılmasıdır. Teklifte “test yapıldı” demek yerine hangi senaryoların deneneceği ve sonucu kimin onaylayacağı yazılmalıdır. Sepete ürün ekleme, kupon uygulama, farklı ödeme sonucu, kargo seçimi, sipariş bildirimi ve iade başlangıcı gibi işlemler temel örneklerdir. Bu kontrolü genişletirken profesyonel e-ticaret sitesi için teknik ve ticari kontrol listesinden yararlanmak eksik teslim kalemlerini görünür kılar.
Kabul kriterlerini işlem bazında yazmak
Kabul testinin değeri, “çalışıyor” gibi yoruma açık ifadeleri ölçülebilir sonuçlara çevirmesidir. Örneğin başarılı ödeme sonrası siparişin doğru statüye geçmesi, müşteriye ve operasyon ekibine doğru bildirimin ulaşması, stok hareketinin beklenen şekilde kaydedilmesi ve başarısız ödeme senaryosunun yanlış sipariş üretmemesi kontrol edilebilir. Entegrasyon bulunan projelerde test ortamı ile canlı ortamın farklı kimlik bilgileri, callback adresleri ve yetkileri de ayrıca doğrulanmalıdır. Onay listesi teslim tutanağının eki hâline getirilebilir.
- Başarılı ve başarısız ödeme akışları
- Kargo yöntemi ve ücret kurallarının kontrolü
- Vergi, fatura ve sipariş tutarı hesapları
- E-posta veya diğer sipariş bildirimleri
- Stok, iptal, iade ve durum değişikliği senaryoları
- Analytics ve temel dönüşüm ölçüm kontrolleri
Mağaza Açılış Kontrolünde Hangi Teslimatlar Netleşmelidir?
Mağaza açılış kontrolü, teknik yayının yanında işletmenin günlük satış operasyonuna başlayabilmesi için gerekli erişim, içerik ve ayarların birlikte doğrulanmasını kapsamalıdır. Yönetici kullanıcıları, ödeme ve kargo hesapları, vergi yapılandırmaları, yasal metinlerin yayın yerleri, iletişim adresleri ve sipariş bildirimleri bu aşamada kontrol edilir. İçerik girişi müşteri sorumluluğundaysa kaç ürün, kategori veya örnek kayıtla test yapılacağı da teklif öncesinde netleştirilmelidir. Aksi hâlde “site hazır” ifadesi iki taraf için farklı anlamlar taşıyabilir.
Teknik yayından operasyonel açılışa geçmek
Yayına alma planında her kontrol maddesinin bir sahibi olması gerekir. Sağlayıcının yapılandıracağı alanlarla müşterinin sağlayacağı banka, kargo, vergi, şirket ve ürün verileri ayrıştırılmalıdır. Ayrıca canlıya geçiş sırasında eski sitenin yönlendirmeleri, alan adı kayıtları, SSL, e-posta gönderim kimliği veya üçüncü taraf erişimleri gibi bağımlılıklar varsa bunlar da açılış listesine eklenmelidir. Böylece gecikmenin kaynağı anlaşılır, son gün ortaya çıkan erişim sorunları azalır ve teslim sorumluluğu belirsiz bir “müşteri bekleniyor” durumuna dönüşmez.
- Canlı yönetici hesapları ve rol yetkileri
- Ödeme, kargo ve vergi yapılandırmaları
- Ürün, kategori ve temel içerik doğrulaması
- Alan adı, SSL ve yönlendirme kontrolleri
- Bildirim gönderen hesap ve adreslerin doğrulanması
E-Ticaret Operasyon Eğitimine Kimler Katılmalıdır?
Ekip eğitimi, tek bir yöneticiye genel panel tanıtımı yapmak yerine gerçek operasyon rollerine göre planlanmalıdır. Ürün ve kategori yöneten kişi katalog işlemlerini, sipariş ekibi sipariş ve durum yönetimini, müşteri hizmetleri iade ve iptal akışlarını, pazarlama ekibi kampanya ve kupon yönetimini, yetkili yönetici ise kullanıcı rolleri ve kritik ayarları öğrenmelidir. Küçük ekiplerde aynı kişi birden fazla role sahip olabilir; önemli olan, eğitim katılımcılarının iş başında kullanacakları fonksiyonlarla eşleşmesidir.
Rol bazlı eğitim kapsamı oluşturmak
Teklifte yalnızca “eğitim verilecektir” ifadesi bulunması, kapsamı karşılaştırmak için yeterli değildir. Eğitim oturumlarının konuları, katılımcı sayısı, çevrim içi veya yüz yüze yöntemi, soru-cevap zamanı ve hangi kullanıcı yetkileriyle uygulama yapılacağı belirtilmelidir. Özellikle farklı departmanların aynı paneli kullandığı yapılarda herkese tam yönetici yetkisi vermek yerine görev bazlı erişim üzerinden eğitim vermek daha sağlıklı bir devir modelidir. Eğitim sırasında örnek sipariş ve örnek kampanya oluşturmak, teorik anlatımdan daha uygulanabilir sonuç verir.
- Katalog ve ürün yönetiminden sorumlu ekip
- Sipariş, kargo ve depo operasyonu
- İade ve müşteri hizmetleri sorumluları
- Kampanya ve pazarlama kullanıcıları
- Yetki ve ayarları yönetecek sistem sorumlusu
Eğitim Dokümanı ve Kayıtları Teklifte Nasıl Kıyaslanır?
Eğitim teslimatı, canlı oturumun yanında sonradan başvurulabilecek materyallerin kapsamıyla değerlendirilmelidir. Kullanım dokümanı, ekran kayıtları, sık yapılan işlemler için kısa yönergeler ve gerekiyorsa rol bazlı kontrol listeleri ekip değişikliklerinde önemli bir bilgi aktarımı sağlar. Teklif karşılaştırırken kaydın müşteriye teslim edilip edilmeyeceği, hangi formatta paylaşılacağı, ne kadar süre erişilebilir olacağı ve dokümanın proje için özelleştirilip özelleştirilmediği açıkça sorulmalıdır. Genel ürün dokümanı ile projeye özel operasyon kılavuzu aynı teslimat değildir.
Tekrar oturumu ve bilgi kalıcılığı
İlk eğitim çoğu zaman mağaza henüz gerçek sipariş yoğunluğunu yaşamadan yapılır. Bu nedenle tekliflerde yayın sonrasında kısa bir tekrar oturumu veya belirlenen soruların topluca ele alınacağı ikinci görüşme bulunması faydalı olabilir. Buradaki amaç sürekli ücretsiz danışmanlık beklemek değil, ilk kullanımda ortaya çıkan uygulama sorularını tanımlı bir teslim modeliyle kapatmaktır. Eğitim süresi tek başına kalite ölçütü değildir; konuların rol bazında işlenmesi, uygulama yapılması, materyal teslimi ve soruların nasıl takip edildiği birlikte değerlendirilmelidir.
- Projeye özel yönetim paneli kullanım dokümanı
- Eğitim oturumunun video veya ekran kaydı
- Sık kullanılan işlemler için kısa yönergeler
- Katılımcı rolleri ve işlenen konu listesi
- Yayın sonrası tekrar oturumu veya soru toplama yöntemi
Yayın Günü Desteği Teklif Kapsamında Nasıl Tanımlanır?
Yayın günü desteği, canlıya geçiş sırasında ortaya çıkabilecek yapılandırma, erişim ve işlem sorunlarına kimin hangi kapsamda müdahale edeceğini tanımlamalıdır. Alan adı yönlendirmesi, ödeme sağlayıcısının canlı anahtarları, kargo bağlantıları, cache temizliği, e-posta gönderimleri ve ilk test siparişleri gibi maddeler bu plana dahil olabilir. Bu desteğin kurulum teklifinde bulunup bulunmadığı, destek saatinin hangi aşamada başladığı ve yalnızca kritik sorunları mı yoksa operasyon sorularını da mı kapsadığı sözleşmede ayrı bir kalem olarak görülmelidir.
Kurulum teslimi ile sürekli desteği ayırmak
Yayın günü desteği ile bakım hizmetini aynı başlıkta toplamak karşılaştırmayı zorlaştırır. Kurulumun doğal parçası olan canlıya geçiş kontrolleri, garanti kapsamındaki hata giderme ve sonraki geliştirme talepleri farklı iş türleridir. Bu ayrımı e-ticaret firması teklifindeki teknik kapsam ve sözleşme maddelerini değerlendirirken açıkça görmek gerekir. Destek kanalının e-posta, kayıt sistemi veya toplantı olarak tanımlanması ve kritik olaylarda iletişim kişisinin belirtilmesi de açılış riskini azaltır.
- Canlıya geçiş sorumlusu ve iletişim kanalı
- İlk test siparişleri için kontrol planı
- Kritik hata ile kullanım sorusunun ayrımı
- Kurulum desteği ile bakım döneminin sınırı
- Üçüncü taraf sağlayıcılardaki bağımlılıkların kaydı
İlk Siparişlerden Sonra Bulunan Hatalar Nasıl Giderilmelidir?
Yayın sonrası hata giderme, kabul testinden geçmiş işlevlerin gerçek kullanımda beklenen şekilde çalışmaması durumunda uygulanacak kayıt ve çözüm sürecini tarif etmelidir. İlk siparişler yeni kombinasyonlar ortaya çıkarabilir; belirli bir ödeme yöntemi, kargo bölgesi, kupon, vergi senaryosu veya stok durumu test listesinden farklı sonuç üretebilir. Teklifte hata bildiriminin nasıl yapılacağı, hangi bilgilerin isteneceği, önceliğin nasıl sınıflandırılacağı ve düzeltme sonrasında tekrar testinin kimin tarafından yapılacağı yazılı olmalıdır.
Hata, değişiklik talebi ve yeni geliştirmeyi ayırmak
En sık anlaşmazlık noktalarından biri, yayın sonrasında görülen her talebin “hata” sayılmasıdır. Sözleşmedeki kabul kriterine uymayan davranış hata olarak ele alınabilirken, daha önce tanımlanmamış yeni rapor, farklı kampanya kuralı veya yeni entegrasyon ihtiyacı kapsam değişikliği olabilir. Bu ayrım teklif aşamasında açıklanırsa hem sağlayıcı hem müşteri beklentisini yönetebilir. Hata kaydında sipariş numarası, kullanılan cihaz, işlem adımı, ekran görüntüsü ve beklenen sonuç gibi bilgiler istenmesi çözüm sürecini hızlandırır.
- Hata bildirim kanalı ve gerekli bilgi seti
- Kritik, yüksek ve normal öncelik tanımları
- Kabul kriterine göre hata değerlendirmesi
- Düzeltme sonrası yeniden test ve kapanış kaydı
- Yeni geliştirme taleplerinin ayrı kapsamlandırılması
Kurulum Firmaları Teslim Kapsamıyla Nasıl Karşılaştırılır?
Kurulum firması karşılaştırma sürecinde teklifleri aynı sütunlara dönüştürmek gerekir. Bir firma yayın, eğitim, dokümantasyon ve kısa süreli hata takibini tek kalemde sunarken başka bir firma bunları opsiyon olarak ayırabilir. Toplam rakama bakmak yerine her teklif için “dahil”, “opsiyonel”, “müşteri sorumluluğu” ve “belirsiz” sınıfları oluşturmak daha doğru bir karşılaştırma sağlar. Proje öncesi ihtiyaçları netleştirmek için e-ticaret sitesi yaptırmadan önce belirlenmesi gereken özellikleri de aynı karşılaştırma dosyasına eklemek kapsam boşluklarını azaltır.
Fiyat farkının arkasındaki teslim farkını görmek
Düşük fiyatlı teklif otomatik olarak eksik, yüksek fiyatlı teklif ise otomatik olarak kapsamlı değildir. Karar, teslimatların açık tanımlanmasına dayanmalıdır. Eğitim saatinin yanında hangi rollerin eğitileceği, yayın desteğinin yanında hangi görevlerin yapılacağı, hata giderme maddesinin yanında hangi işlerin hata sayılacağı okunmalıdır. Böyle bir matris, iki teklif arasındaki fiyat farkının yazılım geliştirme, entegrasyon, veri hazırlığı, yayın desteği veya eğitim gibi hangi kalemlerden kaynaklandığını gösterir. Eksik kalan alanlar için aynı formatta revize teklif istemek firmalar arası kıyası güçlendirir.
- Dahil teslimatlar ve açık kapsam dışı maddeler
- Müşteri tarafına bırakılan hazırlık ve veri işleri
- Eğitim, dokümantasyon ve tekrar oturumu
- Yayın günü destek kapsamı ve sorumlular
- Hata giderme ile yeni geliştirme ayrımı
- Üçüncü taraf lisans ve hesap sorumlulukları
Revize Teklif İsterken Hangi Maddeler Netleştirilmelidir?
Revize teklif, yalnızca toplam tutarın yeniden yazılması değil, belirsiz teslim maddelerinin ölçülebilir hâle getirilmesi için istenmelidir. “Yayına alma dahil”, “eğitim verilir” veya “destek sağlanır” gibi ifadelerin altına test senaryoları, katılımcı rolleri, teslim materyalleri, sorumlular ve yayın sonrası hata süreci eklenmelidir. Böylece satın alma ekibi aynı ihtiyaca verilen teklifleri ortak bir kapsam üzerinden değerlendirebilir; proje ekibi de sözleşme imzalandıktan sonra hangi çıktıların teslim edileceğini baştan bilir.
Kararı satışa başlama yeterliliği üzerinden vermek
Son değerlendirmede amaç, en fazla maddeyi içeren teklifi seçmek değil, işletmenin satışa başlaması için gerekli işlerin kim tarafından ve hangi kabul ölçütleriyle tamamlanacağını görmektir. Ödeme, kargo, vergi, bildirim, erişim ve ölçüm kontrolleri; rol bazlı eğitim; dokümantasyon; yayın günü koordinasyonu ve ilk siparişlerden sonraki hata yönetimi birlikte ele alındığında tekliflerin gerçek farkı görünür olur. Eksik veya belirsiz maddeleri revizyonla netleştirmek, fiyat karşılaştırmasını operasyonel teslim karşılaştırmasına dönüştürür.
- Kabul testleri ve onay sorumlusu
- Eğitim rolleri, oturum kapsamı ve materyaller
- Yayın günü görevleri ve iletişim yöntemi
- İlk siparişler sonrası hata giderme modeli
- Kapsam dışı işler ve değişiklik talebi yöntemi
Kurulum Tekliflerinizi Birlikte Değerlendirelim
Mevcut tekliflerinizi yayın, kabul testi, ekip eğitimi, dokümantasyon ve yayın sonrası destek teslimatları açısından birlikte karşılaştıralım.
Tekliflerinizi Değerlendirin