Yazılım Bakım ve Destek Anlaşması (SLA) Fiyatları Neye Göre Belirlenir?

Yazılım bakım ve destek anlaşmalarının (SLA) fiyatı; kapsanan iş türlerine, taahhüt edilen yanıt sürelerine, aylık saat havuzuna ve sistemin işletme için kritiklik seviyesine göre belirlenir. 2026'da Türkiye'de özel yazılımlar için aylık SLA bedelleri, kapsama göre değişmekle birlikte kabaca 15.000 ₺ ile 150.000 ₺ üzerine uzanan bir aralıkta seyreder; fiyatı belirleyen asıl şey saat sayısı değil, "ne kadar hızlı, hangi işler için" sorusunun cevabıdır. Bu yazıda dört ana fiyat belirleyiciyi ve tipik seviye modellerini örnek tabloyla açıklıyoruz.

SLA Kapsamına Hangi İşler Girer?

İlk fiyat ayrımı, anlaşmanın hangi iş türlerini kapsadığıdır. Üç katman vardır ve her katman bedeli yukarı çeker:

• Düzeltici bakım: Hataların giderilmesi, acil müdahaleler, güvenlik yamaları. Her SLA'nın çekirdeğidir.
• İyileştirici bakım: Performans optimizasyonu, küçük ekran ve akış iyileştirmeleri, sürüm/altyapı güncellemeleri.
• Geliştirici kapsam: Yeni özellik ve modüllerin saat havuzundan geliştirilmesi. En geniş ve en değerli katmandır.

Kapsam belirlenirken en sık yaşanan anlaşmazlık, "bu iş hata mı, yeni istek mi?" tartışmasıdır. İyi bir sözleşme bu ayrımı örneklerle tanımlar: mevcut bir fonksiyonun yanlış çalışması hatadır; olmayan bir raporun istenmesi geliştirmedir. Bu ayrım baştan yazılmadığında her ay aynı pazarlık tekrarlanır.

Yalnızca "hata düzeltme" içeren ucuz bir anlaşma, yazılımın zamanla eskimesini engellemez; bu riski yazılım bakımı neden kritik? yazımızda ayrıntılı anlattık.

Yanıt ve Çözüm Süreleri Fiyatı Nasıl Değiştirir?

SLA'nın kalbi süre taahhütleridir: bildirime ne kadar sürede dönüleceği (yanıt süresi) ve sorunun ne kadar sürede giderileceği (çözüm hedefi). Kritik bir hataya 2 saat içinde müdahale taahhüdü, ekibin sürekli hazır tutulmasını gerektirir; 7/24 nöbet kurgusu, mesai içi destekten belirgin biçimde pahalıdır. Doğru yaklaşım her kayıt için değil, öncelik seviyesine göre süre tanımlamaktır: sistemi durduran hata ile kozmetik bir talep aynı hızda ele alınmak zorunda değildir. Bu ayrım sayesinde bütçenizin büyük kısmı, gerçekten hızlı müdahale gerektiren az sayıda senaryoya ayrılır.

Aylık Saat Havuzu Nasıl Çalışır?

Yaygın model, aylık sabit bir saat havuzudur: örneğin ayda 10, 25 veya 50 saat. Havuz; destek taleplerini, iyileştirmeleri ve anlaşmaya göre küçük geliştirmeleri kapsar. Doğru havuz büyüklüğünü kestirmenin pratik yolu, son 6-12 ayın talep geçmişine bakmaktır: kaç hata bildirildi, kaç küçük istek geldi, bunlar kabaca kaç saat tuttu? İmzalamadan önce şu üç soruyu da mutlaka sorun:

1. Kullanılmayan saatler sonraki aya devreder mi (devir genellikle sınırlıdır)?
2. Havuz aşılırsa ek saat ücreti nedir? 2026'da özel yazılımda saat bedelleri kabaca 1.500 – 4.500 ₺ aralığındadır ve uzmanlık seviyesine göre değişir.
3. Acil müdahaleler havuzdan mı düşer, ayrı mı fiyatlanır?

Kritiklik Seviyesi: Aynı Yazılım, Farklı Fiyat

Aynı büyüklükteki iki yazılımın SLA bedeli, iş üzerindeki etkisine göre farklılaşır. Bir saatlik kesintisi ciro kaybı yaratan e-ticaret altyapısı ile ayda bir kullanılan raporlama aracı aynı güvenceyi gerektirmez. Kritiklik arttıkça yedeklilik, izleme (monitoring) ve nöbet maliyeti fiyata yansır. Bütçeyi doğru kurmak için sistemlerinizi kritikliğe göre sınıflandırmak, hepsine tek tip pahalı güvence almaktan daha akılcıdır. Bu değerlendirme, özel yazılım maliyetini belirleyen faktörlerin doğal bir devamıdır.

Fiyatı Etkileyen Diğer Faktörler Nelerdir?

Dört ana belirleyicinin dışında, teklifler arasındaki farkı açıklayan ikincil etkenler de vardır:

• Teknoloji yığını: Yaygın teknolojilerle yazılmış bir sistemin bakımı, niş veya eskimiş teknolojilerdekinden daha ekonomiktir; uzman bulunabilirliği doğrudan saat ücretine yansır.
• Dokümantasyon ve kod kalitesi: Belgesiz, düzensiz bir kod tabanını devralan ekip önce sistemi öğrenmek zorundadır; ilk aylarda ek bir "devralma" bedeli görebilirsiniz.
• Yazılımı geliştiren firmayla mı çalışıyorsunuz: Sistemi yazan ekip kodu tanıdığı için genellikle daha hızlı ve öngörülebilir hizmet verir; üçüncü taraf bakım ise devir sürecinin sağlıklı yönetilmesini gerektirir.
• Kullanıcı ve işlem hacmi: Trafik büyüdükçe izleme, ölçekleme ve olay müdahale ihtiyacı artar.

Sabit Aylık Bedel mi, Kullandıkça Öde mi?

İki fiyatlama modeli yaygındır. Sabit aylık bedel, bütçeyi öngörülebilir kılar ve ekibin sisteminize sürekli hakim kalmasını sağlar; sakin aylarda "boşa mı ödüyorum" hissi yaratabilir ama kriz anında hazır bir ekip demektir. Kullandıkça öde (saat bazlı) modelde ise yalnızca harcanan efor faturalanır; kulağa ekonomik gelir fakat taahhütlü yanıt süresi içermediği için kritik bir hatada sıraya girersiniz. Sahada en dengeli kurgu, çekirdek bir saat havuzunu sabit bedelle alıp aşımları önceden anlaşılmış saat ücretiyle ödemektir.

Tipik SLA Seviyeleri Nasıl Görünür?

Aşağıdaki tablo, pazarda sık görülen üç seviyeli modelin temsili bir örneğidir. Rakamlar ve süreler kapsama göre değişir; kendi anlaşmanızı sistemlerinizin kritikliğine göre şekillendirmelisiniz.

Seviye seçerken şu soruyu sorun: bu sistem bir gün boyunca dursa işletmeme maliyeti ne olur? Cevap aylık altın paket bedelinden büyükse üst seviye kendini zaten ödüyor demektir; küçükse bronz veya gümüş yeterlidir. Birden fazla yazılımınız varsa her biri için ayrı seviye belirlemek, tümünü tek pakette toplamaktan neredeyse her zaman daha ekonomiktir.

Sözleşmede Nelere Dikkat Etmelisiniz?

Fiyat kadar metnin kendisi de önemlidir. İmzalamadan önce şu maddeleri netleştirin:

• Öncelik seviyelerinin (kritik/yüksek/normal) somut tanımları — "kritik" kelimesi yoruma açık bırakılmamalı.
• Ölçüm ve raporlama: yanıt süreleri nasıl kayıt altına alınacak, aylık rapor verilecek mi?
• Taahhüt ihlalinde yaptırım: ceza ya da ek saat telafisi — yaptırımı olmayan taahhüt, iyi niyet beyanından ibarettir.
• Fiyat artış formülü: yıllık artışın hangi endekse veya orana bağlanacağı baştan yazılmalı.
• Çıkış koşulları: anlaşma sona erdiğinde devir sürecinin ve bilgi aktarımının nasıl yapılacağı.
• Kaynak kodun ve dokümantasyonun güncel tutulması; teknik borcun büyümemesi için teknik borç yönetiminin anlaşmada yer alması.

QuantKOD olarak geliştirdiğimiz her projede bakım dönemini teslimin devamı olarak görüyor, SLA kapsamını sistemin kritikliğine göre birlikte boyutlandırıyoruz. Bakım ve destek hizmetlerimizin ayrıntısını hizmetler sayfamızda bulabilirsiniz.