Web Sitesi Teklifleri Nasıl Karşılaştırılır? 12 Kriterlik Puan Kartı

Web sitesi tekliflerini karşılaştırırken yalnızca toplam ücrete bakmak, farklı kapsamları aynı hizmetmiş gibi değerlendirmeye neden olabilir. Bir teklif içerik girişini, entegrasyon testlerini ve yayın sonrası desteği kapsarken başka bir teklif bunları müşteri sorumluluğunda bırakabilir. Rakamlar yan yana dursa da satın alınan iş aynı değildir.

Sağlıklı karşılaştırma için önce bütün ajansların aynı ihtiyaca teklif verdiğinden emin olun. Ardından kapsamı, teslimatları, sorumlulukları, erişim ve devir koşullarını, teknik kaliteyi, zamanlamayı ve yayın sonrası hizmetleri aynı puan kartında inceleyin. Teklifte bulunmayan veya yalnızca genel bir ifadeyle anlatılan hiçbir maddeyi kendiliğinden “dâhil” kabul etmeyin; yazılı olarak netleştirin.

Bu rehberdeki 12 kriterlik puan kartı, teklifleri en düşük fiyata göre sıralamak için değil, fiyat farkının hangi kapsam ve risk farkından doğduğunu görmek için hazırlanmıştır.

Teklifleri Karşılaştırmadan Önce Ortak Bir Zemin Oluşturun

Ajanslara birbirinden farklı bilgi verdiğinizde gelen teklifleri karşılaştırmak zorlaşır. Bir ajans on sayfalık kurumsal siteyi, diğeri çoklu dil ve entegrasyonları, üçüncüsü ise içerik üretimini de hesaba katmış olabilir. Bu durumda toplam bedeller aynı soruya verilmiş cevaplar değildir.

İlk adım, bütün teklif sahiplerine aynı proje özetini göndermektir. Hedef kullanıcıları, sayfa ve modül listesini, içerik durumunu, dilleri, entegrasyonları, hedef tarihi ve beklenen destek modelini mümkün olduğunca açık yazın. Bu çalışma henüz yapılmadıysa web sitesi ihtiyaç dokümanı hazırlama rehberini kullanarak karşılaştırma zeminini oluşturabilirsiniz.

Her teklif için şu üç listeyi ayrı ayrı isteyin:

• Fiyata ve takvime dâhil işler
• İsteğe bağlı veya ayrı fiyatlanan işler
• Açıkça kapsam dışında bırakılan işler ve varsayımlar

Bu ayrım yapılmadan “kurumsal web sitesi”, “SEO uyumlu altyapı” veya “çoklu dil desteği” gibi ifadeler farklı ekipler için farklı teslimatlar anlamına gelebilir.

0-3 Arasında Kanıt Puanı Verin

Her kriteri yalnızca “var” veya “yok” şeklinde işaretlemek yerine açıklık ve kanıt düzeyine göre 0-3 arasında puanlayabilirsiniz:

Bu puanlama matematiksel olarak “en iyi ajansı” seçmez. Bir teklif yüksek toplam puan alsa bile kaynak kod teslimi, kritik entegrasyon veya yayın sonrası sorumluluk gibi sizin için vazgeçilmez bir maddede yetersiz kalabilir. Bu nedenle her kriterin yanına “kritik”, “önemli” veya “isteğe bağlı” şeklinde kendi önem notunuzu da ekleyin.

Web Sitesi Tekliflerini Karşılaştırmak İçin 12 Kriter

1. İş Hedefi ve Başarı Tanımı

Teklif, yalnızca üretilecek sayfaları değil web sitesinin hangi iş sonucuna hizmet edeceğini de göstermelidir. Marka güveni, nitelikli başvuru toplama, ürünlerin daha anlaşılır sunulması, satış, rezervasyon veya müşteri operasyonu gibi hedeflerin proje kararlarıyla ilişkisi kurulmalıdır.

Şu soruları sorun:

• Ajans teklifini hangi iş hedefine göre hazırladı?
• Hangi kullanıcı grupları ve kullanıcı görevleri dikkate alındı?
• Başarı hangi ölçüm veya kabul göstergeleriyle değerlendirilecek?

“Modern ve etkileyici site” gibi ifadeler tek başına başarı tanımı değildir. Tasarım ve teknik kararların hangi kullanıcı görevini kolaylaştıracağı açıklanmalıdır.

2. Proje Kapsamı ve Açık Teslimatlar

Teklifte sayfa, modül, özellik ve teslimat listesi bulunmalıdır. “Web sitesi tasarımı ve yazılımı” ifadesi; kaç özgün sayfa şablonu hazırlanacağını, hangi formların veya modüllerin geliştirileceğini, yönetim panelinden hangi alanların düzenlenebileceğini ve hangi belgelerin teslim edileceğini açıklamaz.

Kumsal Ajans tekliflerinde projenin amacı ve genel kapsamı; sunulacak hizmetler, tasarım-yazılım çalışmaları, sayfa ve modül listesi, kullanılacak altyapı, uyumluluk, test, yayın ve devir koşulları ayrı başlıklarda açıklanır. Karşılaştırdığınız diğer tekliflerde de aynı açıklık düzeyini arayın.

Kanıt olarak ayrıntılı kapsam tablosu, sayfa listesi, modül listesi, örnek site haritası veya teslimat listesi isteyebilirsiniz.

3. Kapsam Dışı İşler ve Varsayımlar

İyi bir teklif yalnızca yapılacak işleri değil, yapılmayacak işleri de görünür kılar. İçerik yazımı, ürün girişi, çeviri, stok görsel, video üretimi, veri taşıma, alan adı, barındırma, e-posta kurulumu, üçüncü taraf lisanslar veya entegrasyon ücretleri kapsam dışında olabilir.

Varsayımları ayrıca kontrol edin. Teklif; içeriklerin belirli tarihte hazır olacağını, mevcut sistemin veri aktarımına izin vereceğini veya üçüncü taraf servisin gerekli teknik erişimi sağlayacağını varsayıyor olabilir. Bu koşul gerçekleşmezse takvimin ve ücretin nasıl etkileneceği yazılmalıdır.

Belirsizlik varsa şu soruyu sorun: “Bu proje tanımında sonradan ek ücret doğurabilecek hangi varsayımlar bulunuyor?”

4. İçerik Üretimi, Girişi ve Taşıma Sorumluluğu

Tasarımın hazırlanması, metinlerin yazılması ve içeriklerin sisteme girilmesi aynı hizmet değildir. Teklifte kaç sayfanın, ürünün, hizmetin veya içerik kaydının ajans tarafından girileceği belirtilmelidir. Metin, fotoğraf, video, belge ve çevirilerin kim tarafından, hangi formatta ve hangi tarihte sağlanacağı da açıklanmalıdır.

Mevcut site yenilenecekse içerik taşımanın yalnızca kopyalama mı yoksa düzenleme, temizleme ve yeniden yapılandırma mı olduğu sorulmalıdır. Eski URL’lerin korunması, yönlendirme planı ve metadata aktarımı gibi işler de ayrı teslimatlar olabilir.

İçerik miktarı sayı veya içerik türüyle sınırlandırılmamışsa, tekliflerin aynı işi kapsadığını varsaymayın.

5. Tasarım Süreci, Revizyon ve Onay Sınırları

Revizyon maddesinde yalnızca sayı değil, revizyonun hangi aşamayı ve hangi tür değişikliği kapsadığı yazılmalıdır. “Sınırsız revizyon” ifadesi aşama belirtilmeden kullanıldığında hem müşteri hem ajans açısından belirsiz kalabilir.

Kumsal Ajans’ta tasarım onayı alınana kadar tasarım revizyonları sınırsızdır. Buradaki sınır, onay aşamasıdır: Onaylanmış tasarıma daha sonra geri dönülmesi veya yeni sayfa, özellik ya da kapsam değişikliği talep edilmesi aynı revizyon hakkı içinde değerlendirilmez; ek çalışma olarak ele alınır.

Teklifleri karşılaştırırken şu ayrıntıları arayın:

• Revizyon hangi aşamalarda yapılabilir?
• Geri bildirimleri kim birleştirip iletecek?
• Tasarım ne zaman onaylanmış sayılır?
• Onaylanmış aşamaya dönüş nasıl değerlendirilir?
• Kapsam değiştiren talep ile tasarım düzeltmesi nasıl ayrılır?

Bu açıklamalar yoksa “iki tur” veya “sınırsız” ifadeleri tek başına karşılaştırılabilir değildir.

6. Teknik Altyapı ve Yönetim Paneli Kapsamı

Teklifte yalnızca kullanılan teknoloji adını görmek yeterli değildir. Altyapının editörlere hangi işlemleri yaptıracağı, kullanıcı rollerini nasıl yöneteceği, yeni sayfa veya içerik türleri için ne kadar esnek olduğu ve bakım sorumluluğunun kimde kalacağı açıklanmalıdır.

Projeye özel yapılandırılan bir içerik yönetim platformunda şu sorular önemlidir:

• Müşteri hangi içerikleri panelden düzenleyebilir?
• Yetkilendirme ve kullanıcı rolleri bulunuyor mu?
• Çoklu dil içerikleri birbirine bağlı mı yönetiliyor?
• Form kayıtları, medya, yönlendirmeler ve SEO alanları nasıl kontrol ediliyor?
• Lisans, güncelleme veya bağımlılık maliyetleri var mı?
• Proje başka bir ekibe devredildiğinde gerekli teknik bilgi ve dosyalar sağlanacak mı?

Teknik tercihi yalnızca “özel” veya “hazır” etiketiyle puanlamayın. İhtiyacınıza uygunluk, işletilebilirlik, devir ve uzun vadeli sorumluluk daha önemlidir.

7. Entegrasyonlar ve Üçüncü Taraf Maliyetleri

CRM, ERP, ödeme, rezervasyon, kargo, SMS, e-posta, harita veya başka bir servisle bağlantı kurulacaksa her entegrasyon ayrı tanımlanmalıdır. Yalnızca servis adının yazılması, veri akışının ve sorumluluğun açık olduğu anlamına gelmez.

Teklifte şu bilgiler bulunmalıdır:

• Hangi sistem hangi veriyi gönderip alacak?
• Entegrasyon tek yönlü mü, çift yönlü mü?
• Test hesabını ve teknik erişimi kim sağlayacak?
• API, lisans, SMS, e-posta, ödeme veya kullanım ücretini kim ödeyecek?
• Üçüncü taraf servis değişirse yapılacak uyarlama mevcut kapsama dâhil mi?
• Entegrasyon çalışmadığında hangi ekip hangi bölümü inceleyecek?

Kumsal Ajans bu başlıkları servis, veri akışı, kapsam ve sorumluluk düzeyinde ayırır; üçüncü taraf kullanım ücretlerini ayrıca belirtir. Diğer tekliflerde entegrasyon yalnızca “dâhil” şeklinde geçiyorsa kapsamı yazılı olarak açtırın.

8. Alan Adı, Sunucu, Hesaplar, Tasarım Dosyaları ve Kaynaklara Erişim

Proje sonunda kimin hangi varlığa erişeceği teklif ve sözleşmede açık olmalıdır. Bu bölüm hukuki yorum yerine teslim edilecek varlıkların, lisans istisnalarının ve erişim yönteminin somut listesini içermelidir.

Kumsal Ajans’ta proje bedeli ve ilgili üçüncü taraf maliyetleri tamamlandıktan sonra müşteriye ait varlıklar, proje ve sözleşme kapsamına göre teslim edilir:

• Projeye özel kaynak kodlar Git deposu, arşiv veya müşterinin belirlediği altyapı üzerinden aktarılabilir.
• Ajansın genel kütüphaneleri, lisanslı bileşenler ve üçüncü taraf yazılımlar kendi lisans koşullarıyla ayrıca değerlendirilir.
• Figma, Adobe veya benzeri çalışma dosyaları teklif kapsamındaysa teslim edilir.
• Alan adı müşteri adına kayıtlıysa erişimler paylaşılır; ajans hesabındaysa uygun transfer süreci yürütülür.
• Müşteriye ait sunucularda yönetici erişimleri devredilir. Yönetilen veya paylaşımlı hizmetlerde proje dosyaları, yedekler ve ilgili hesap bilgileri teslim kapsamına göre sağlanır.
• Yönetim paneli, DNS, SSL, CDN, analitik ve diğer servisler güvenli bir teslim listesiyle kayıt altına alınır.

Kullanılan servisler, lisanslar, yenileme tarihleri ve devam ettirilmesi gereken abonelikler için bir devir dokümanı isteyin. Fikri mülkiyet ve sözleşme hükümlerinin hukuki sonucunu değerlendirmek gerekiyorsa uygun bir hukuk uzmanından destek alın.

9. SEO, Erişilebilirlik, Performans ve Ölçüm Kapsamı

“SEO uyumlu”, “hızlı” veya “erişilebilir” ifadelerinin hangi teslimatları kapsadığı açıklanmalıdır. SEO başlığı altında sayfa başlıkları ve açıklamaları, taranabilir bağlantılar, sitemap, robots kontrolleri, canonical yapısı, yönlendirmeler, yapılandırılmış veri, görsel alternatifleri ve ölçüm hesapları gibi işler ayrı ayrı belirtilmelidir.

Google Search Essentials, taranabilir bağlantılar ve kullanıcıya faydalı içerik gibi temel uygulamaları öne çıkarır; aynı zamanda bu gereksinimleri karşılamanın taranma, dizine eklenme veya sıralama garantisi olmadığını açıkça belirtir. Bu nedenle teklifte “Google’da kesin ilk sayfa” gibi garanti yerine yapılacak teknik ve içerik çalışmalarının ölçülebilir listesi bulunmalıdır.

Erişilebilirlik için hedeflenen kapsam, klavye kullanımı, kontrast, form etiketleri, alternatif metinler ve test sorumluluğu tanımlanabilir. W3C erişilebilirlik planlama rehberi, hedeflerin ve görevlerin proje planına dâhil edilmesini önerir.

Performans tarafında hangi sayfa türlerinin, cihazların, ölçüm araçlarının ve kabul koşullarının kullanılacağını sorun. Analitik, Search Console, Tag Manager veya reklam hesaplarının kimin mülkiyetinde olacağı ve kurulum sonrası erişimlerin nasıl devredileceği de teklif içerisinde yer almalıdır.

10. Test, Canlıya Geçiş, Yedekleme ve Teslim Belgeleri

Bir web sitesinin tasarım ve geliştirmesinin tamamlanması, yayına hazır olduğu anlamına gelmez. Teklifte hangi tarayıcıların ve cihazların kontrol edileceği, formların nasıl test edileceği, entegrasyon senaryolarının kim tarafından onaylanacağı ve hataların nasıl kayıt altına alınacağı açıklanmalıdır.

Kritik web uygulamalarında güvenlik gereksinimlerini ve doğrulama kapsamını yapılandırmak için OWASP ASVS gibi birincil standartlardan yararlanılabilir. Her kurumsal site aynı güvenlik testine ihtiyaç duymaz; teklifin risk ve işlev düzeyine uygun bir doğrulama planı sunması gerekir.

Canlıya geçiş bölümünde şu maddeleri kontrol edin:

• Yayın öncesi onayı kim verecek?
• Mevcut siteden geçiş ve yönlendirmeler nasıl yapılacak?
• Yedek ve geri dönüş planı var mı?
• Formlar, analitik ve entegrasyonlar canlı ortamda tekrar doğrulanacak mı?
• Yönetim paneli eğitimi ve teslim belgeleri ne zaman sağlanacak?
• Hata, erişim ve servis listeleri hangi dokümanda tutulacak?

11. Takvim, Ekip Rolleri ve Müşteri Sorumlulukları

Takvim yalnızca başlangıç ve bitiş tarihinden oluşmamalıdır. Keşif, bilgi mimarisi, tasarım, onay, geliştirme, içerik girişi, test ve yayın aşamaları ayrı kilometre taşlarıyla gösterilmelidir.

Müşterinin içerik, çeviri, kurumsal dosya, entegrasyon erişimi ve geri bildirimleri hangi tarihte sağlayacağı da plana dâhil edilmelidir. Karar vericiler başlangıçta belirlenmezse farklı kişilerden gelen çelişkili yorumlar tasarım ve geliştirme sürecini uzatabilir.

Kumsal Ajans tekliflerinde proje aşamaları, iş takvimi, teslim planı ile müşteri ve ajans sorumlulukları ayrı bölümlerde gösterilir. Eğitim de süre, yöntem, konu ve katılımcı sayısıyla tanımlanır; örneğin belirli sayıda katılımcıya belirli süreli çevrim içi yönetim paneli eğitimi gibi ölçülebilir bir kapsam kullanılabilir.

12. Garanti, Bakım, Destek ve Ek Geliştirme Koşulları

Bu dört kavram aynı hizmet değildir. Teklifleri karşılaştırırken aşağıdaki ayrımı arayın:

• Garanti: Teslim edilen ve onaylanan kapsamdaki yazılım hatalarının belirtilen süre ve koşullarla giderilmesi. Yeni talepler, kullanıcı hataları, içerik değişiklikleri veya üçüncü taraf servis sorunları garanti dışında tutulabilir.
• Bakım: Sistem, altyapı, yazılım bileşenleri, güvenlik, uyumluluk, güncelleme, yedekleme, izleme veya performans çalışmalarının bakım sözleşmesine göre yürütülmesi.
• Destek: Kullanım soruları, erişim sorunları veya operasyonel ihtiyaçlar için belirtilen kanal, yanıt süresi ve saat kotasıyla yardım sağlanması.
• Ek geliştirme: Onaylanan kapsamdan sonra istenen yeni sayfa, modül, özellik, entegrasyon veya iş akışının ayrı analiz ve fiyatlandırmayla ele alınması.

Yalnızca “12 ay destek” yazılması yeterli değildir. Bu sürede hangi kanalın kullanılacağı, kaç saat çalışma bulunduğu, yanıt süresi, garanti ile destek arasındaki sınır ve yeni taleplerin nasıl fiyatlanacağı açıklanmalıdır.

12 Kriterlik Teklif Puan Kartı

Aşağıdaki tabloyu her teklif için ayrı ayrı doldurabilirsiniz. Puanın yanına mutlaka teklifin ilgili sayfasını, verilen belgeyi veya cevap bekleyen soruyu yazın.

Toplam puanı aldıktan sonra kritik maddeleri ayrıca inceleyin. Örneğin ödeme entegrasyonu zorunluysa bu maddede düşük puan alan teklif, toplamda yüksek görünse bile proje için uygun olmayabilir.

Açıkça Kurgulanmış Bir Karşılaştırma Senaryosu

Aşağıdaki örnek gerçek bir müşteri vakası değildir; yöntemin nasıl kullanılacağını göstermek için oluşturulmuş bir senaryodur.

Orta ölçekli bir üretim şirketinin kurumsal web sitesini yenilemek için iki teklif aldığını düşünelim. Teklif A’nın başlangıç bedeli daha düşük, ancak içerik girişi, entegrasyonların veri akışı, kaynak teslimi ve destek modeli belirtilmemiş olsun. Teklif B’nin bedeli daha yüksek, fakat sayfa ve modül listesi, içerik adedi, testler, eğitim, devir dokümanı ve bakım seçenekleri ayrı ayrı açıklanmış olsun.

Bu durumda doğru soru “Hangisi daha ucuz?” değildir. Şu sorular sorulmalıdır:

• Eksik maddeler Teklif A’ya eklendiğinde toplam maliyet nasıl değişecek?
• Hangi teklif müşterinin yönetmesi gereken işleri daha açık gösteriyor?
• Kritik erişimler ve kaynaklar proje sonunda nasıl teslim edilecek?
• Üçüncü taraf ücretleri ve yayın sonrası ihtiyaçlar hangi seçenekte daha görünür?
• Belirsizlik giderilmeden imzalanacak hangi maddeler daha sonra değişiklik talebine dönüşebilir?

Teklif A gerekli açıklamaları yazılı olarak tamamladığında daha uygun seçenek hâline gelebilir. Teklif B’nin daha ayrıntılı olması da otomatik olarak doğru çözüm olduğu anlamına gelmez. Puan kartının amacı bir ajansı peşinen öne çıkarmak değil, kararın hangi kanıta dayandığını görünür kılmaktır.

İmza Öncesinde Sorulacak Son Sorular

Karar vermeden önce cevaplanmamış maddeleri tek bir listede toplayın ve bütün teklif sahiplerine aynı soruları gönderin:

1. Teklifte açıkça kapsam dışında kalan işler hangileri?
2. Müşteri tarafından sağlanması gereken içerik, erişim ve onaylar nelerdir?
3. Tasarım revizyonunun aşama ve onay sınırı nedir?
4. Üçüncü taraf lisans ve kullanım ücretleri hangileridir?
5. Kaynaklar, tasarım dosyaları, hesaplar ve devir belgeleri nasıl teslim edilir?
6. Test ve kabul ölçütleri nelerdir?
7. Garanti, bakım, destek ve yeni geliştirme talepleri nasıl ayrılır?
8. Takvim hangi müşteri veya üçüncü taraf bağımlılıklarına bağlıdır?

Sözlü açıklamaların teklif veya sözleşme ekinde yazılı hâle getirilmesini isteyin. Hukuki veya ticari sonucu önemli olan hükümler için ilgili uzmanların incelemesini alın.

Sonuç: Fiyatı Kapsam ve Kanıtla Birlikte Okuyun

Web sitesi teklifi karşılaştırmasının amacı en uzun dokümanı veya en yüksek puanı seçmek değildir. Amaç, hangi işin hangi koşulla teslim edileceğini, müşterinin hangi sorumlulukları üstleneceğini ve proje sonrasında hangi ihtiyaçların ek maliyet oluşturabileceğini karar öncesinde görebilmektir.

Önce bütün teklifleri aynı ihtiyaç dokümanına göre hizalayın. Ardından 12 kriteri kanıt düzeyine göre puanlayın, kritik maddeleri toplam puandan ayrı değerlendirin ve belirsizlikleri yazılı sorularla kapatın. Böylece fiyatı tek başına değil, kapsam, işletme sorumluluğu ve riskle birlikte okuyabilirsiniz.

Kendi projenizin kapsamını değerlendirmek veya karşılaştırılabilir bir teklif hazırlatmak isterseniz Kumsal Ajans web tasarım hizmetinin kapsamını inceleyebilirsiniz.

Sık Sorulan Sorular

En düşük web sitesi teklifi neden her zaman en uygun seçenek değildir?

Çünkü teklifler aynı sayfa, içerik, entegrasyon, test, eğitim, devir ve destek kapsamını içermeyebilir. Düşük bedelli teklif eksik kalemler tamamlandığında değişebilir. Karar verirken toplam fiyatı kapsam ve teklif dışı işler ile birlikte değerlendirin.

“Sınırsız revizyon” ifadesi teklifte yeterli midir?

Hayır. Sınırsız revizyonun hangi aşama için geçerli olduğu ve ne zaman sona erdiği açıklanmalıdır. Kumsal Ajans’ta tasarım revizyonu tasarım onayı alınana kadar sınırsızdır; onaylanmış tasarıma dönüş veya kapsam değişikliği ek çalışma olarak değerlendirilir.

Kaynak kod ve tasarım dosyaları her projede teslim edilir mi?

Teslim kapsamı teklife, sözleşmeye, kullanılan lisanslara ve proje yapısına göre değişebilir. Projeye özel kaynakların teslim yöntemi, genel kütüphane ve üçüncü taraf lisans istisnaları ile çalışma dosyalarının kapsama dâhil olup olmadığı teklif aşamasında yazılı olarak açıklanmalıdır.

Garanti, bakım ve teknik destek arasındaki fark nedir?

Garanti onaylanan kapsamdaki yazılım hatalarını; bakım sistemin sürekliliği için planlanan güncelleme, yedekleme ve izleme çalışmalarını; destek ise kullanım ve operasyon sırasında verilen yardımı kapsar. Yeni özellik ve modüller ek geliştirme olarak ayrıca değerlendirilir.

Teklif puanı yüksek olan ajans mutlaka seçilmeli midir?

Hayır. Puan kartı kararın yerini almaz; tekliflerin açıklık ve kanıt düzeyini karşılaştırmayı kolaylaştırır. Projeniz için kritik bir entegrasyon, devir veya destek maddesi yetersizse toplam puan yüksek olsa bile bu eksik ayrıca değerlendirilmelidir.