Hizmet sözleşmesini ancak bir sorun çıktığında okuyorsanız, o sözleşme büyük olasılıkla sizi değil karşı tarafı koruyor demektir. İyi haber şu: dikkat edilmesi gereken madde sayısı sanıldığından az ve hepsi teknik değil, ticari mantıkla anlaşılabilir.
Kısa cevap: dijital hizmet sözleşmesinde neye bakmalı?
Yedi başlık belirleyicidir: hizmet kapsamı, hizmet seviyesi taahhüdü, veri sahipliği, yedekleme sorumluluğu, sorumluluk sınırı, fesih koşulları ve hizmet sonunda veri iadesi. Bu yedisi netse, kalan maddeler genellikle standarttır. Kritik nokta şudur: sözleşmeyi değerlendirirken "her şey yolunda giderse" senaryosuna değil, ilişki sona ererken veya bir sorun çıktığında ne olacağına bakılmalıdır. Bir sözleşmenin kalitesi, başlangıç koşullarında değil çıkış koşullarında görülür.
Sözleşmede aranacak 7 madde
| # | Madde | Ne sorulmalı? | Kırmızı bayrak |
|---|---|---|---|
| 1 | Hizmet kapsamı | Neler dahil, neler ek ücretli? | "Gerekli görülen işler" gibi belirsiz ifadeler |
| 2 | Hizmet seviyesi (SLA) | Erişilebilirlik oranı ve telafi nedir? | Oran var ama telafi yok |
| 3 | Veri sahipliği | Veriler kime ait, kim erişebiliyor? | Sahiplik hiç yazılmamış |
| 4 | Yedekleme sorumluluğu | Kim, ne sıklıkla, ne kadar saklıyor? | "Yedek alınabilir" gibi taahhütsüz ifade |
| 5 | Sorumluluk sınırı | Zarar hâlinde tavan nedir? | Sorumluluğun tamamen kaldırılması |
| 6 | Fesih koşulları | Süre, bildirim ve cezai şart var mı? | Tek taraflı fesih hakkı |
| 7 | Veri iadesi | Hizmet biterse veriler nasıl teslim edilir? | Hiç düzenlenmemiş olması |
Bu yedisi arasında en sık boş bırakılan yedinci maddedir. Sözleşmelerin çoğu ilişkinin nasıl başlayacağını ayrıntılı yazar, nasıl biteceğini hiç yazmaz. Oysa gerçek risk oradadır: hizmet sona erdiğinde verinize hangi formatta, hangi sürede ve hangi bedelle ulaşacağınız belirsizse, teknik olarak bağlanmış olursunuz.
Veri sahipliği ve çıkış hakkı
Dijital hizmetlerde "veri" yalnızca müşteri kayıtları değildir. Şunların hepsi çıkış anında sorun üretebilir:
- Web sitesi dosyaları ve veritabanı. Kaynak dosyalara erişim hakkınızın yazılı olması gerekir.
- Alan adı kaydı. Kayıt sahibi alanında şirketiniz yazmalıdır — bunu sahiplik yazımızda ayrıntılandırdık.
- E-posta arşivi. Yıllara yayılmış yazışmalar, çoğu zaman en kritik veridir.
- Yedekler. Sağlayıcıda tutulan yedeklerin size teslim edilip edilmeyeceği yazılmalıdır.
- Yapılandırma ve entegrasyon bilgileri. DNS kayıtları, API anahtarları, otomasyon kurguları.
- İçerik ve tasarım varlıkları. Özel geliştirilen tema veya modüllerin kullanım hakkı.
Sözleşmede aranacak cümle şudur: hizmet sona erdiğinde veriler makul bir süre içinde, yaygın kullanılan bir formatta ve ek bedel talep edilmeksizin teslim edilir. Bu üç unsurdan biri eksikse çıkış maliyetli hâle gelir.
Sorumluluk sınırı tuzağı
Neredeyse tüm hizmet sözleşmelerinde bir sorumluluk sınırı bulunur ve bu normaldir; sağlayıcının aldığı bedelle orantısız risk üstlenmesi beklenemez. Dikkat edilmesi gereken, sınırın nasıl kurulduğudur:
- Sınır tutarı neye endeksli? Yaygın uygulama, son belirli bir dönemde ödenen hizmet bedelidir. Sembolik bir tutarla sınırlama ise fiilen sorumluluğun kaldırılması anlamına gelir.
- Hangi zararlar kapsam dışı? Dolaylı zarar ve kâr kaybının hariç tutulması yaygındır; ancak veri kaybının da hariç tutulup tutulmadığına bakın.
- Ağır kusur istisnası var mı? Kasıt ve ağır ihmal hâllerinde sınırlamanın uygulanmayacağı belirtilmelidir.
- SLA telafisi tek çare mi? Bazı sözleşmelerde erişilebilirlik ihlali için tanımlanan kredi, "tek ve münhasır çözüm" olarak yazılır; bu, başka talep hakkınızı ortadan kaldırır.
Bu dört soruya verilen cevaplar, sözleşmenin gerçek denge noktasını gösterir. Hizmet seviyesi taahhüdünün nasıl okunacağını SLA sayfamızda da bulabilirsiniz.
Hizmet seviyesi maddesini okumak
Erişilebilirlik oranı tek başına anlamlı değildir; şu üç detayla birlikte okunur:
- Ölçüm kimin tarafından yapılıyor? Yalnızca sağlayıcının ölçümüne dayanan bir taahhüt, doğrulanamaz. Kendi bağımsız izlemenizi kurmak bu yüzden önemlidir — izleme yazımıza bakın.
- Planlı bakımlar kapsam dışı mı? Genellikle öyledir; ancak bakım penceresinin süresi ve önceden bildirim şartı yazılı olmalıdır.
- Telafi nasıl talep edilir? Otomatik mi uygulanır, yoksa belirli bir süre içinde başvurmanız mı gerekir? Başvuru süresi kısa tutulmuşsa hakkınız pratikte kullanılamaz hâle gelebilir.
Netişlem uzman görüşü: sözleşme, ilişkinin nasıl biteceğini anlatır
İşletmeler sözleşmeyi genellikle fiyat ve kapsam üzerinden okuyor. Oysa deneyimimizde bir sözleşmenin değeri, ilişki iyi giderken değil sona ererken ortaya çıkıyor. "Ayrılırsak verilerimi nasıl alırım" sorusunun cevabı yazılı değilse, o soruyu sorduğunuz gün pazarlık gücünüz de kalmıyor.
İkinci gözlemimiz, yedekleme sorumluluğunun havada bırakılması. Sağlayıcı "yedek alıyoruz" diyor, işletme bunu bir taahhüt olarak anlıyor, sözleşmede ise kapsam ve saklama süresi yazmıyor. Bir olay yaşandığında ise "yedek altyapı arızalarına karşıdır" cevabı geliyor. Bu maddenin sayısal olarak yazılması — kaç kopya, ne sıklıkla, ne kadar süreyle — çoğu tartışmayı baştan bitiriyor.
Üçüncüsü, sözleşmenin müzakere edilebilir olduğunun bilinmemesi. Standart metinlerde bile veri iadesi, bildirim süresi ve yedekleme kapsamı gibi maddeler çoğu zaman düzenlenebiliyor. Talep etmeyen işletme, olmayan bir kısıtı varsayıyor.
İnceleme kontrol listesi
- Hizmet kapsamı kalem kalem yazılı; ek ücretli işler ayrı belirtilmiş.
- Erişilebilirlik oranı ve telafi yöntemi tanımlı.
- Ölçümün nasıl yapılacağı yazılı.
- Veri sahipliği açıkça işletmeye ait olarak belirtilmiş.
- Yedekleme kapsamı sayısal: sıklık, kopya sayısı, saklama süresi.
- Güvenlik olayı bildirim süresi tanımlı — bkz. ihlal bildirimi.
- Alt yüklenici kullanımı ve bildirimi düzenlenmiş.
- Sorumluluk sınırı makul ve ağır kusur istisnası var.
- Fesih bildirim süresi karşılıklı ve dengeli.
- Veri iadesi: süre, format ve bedel yazılı.
- Fiyat artışı koşulları ve bildirim süresi belirli.
- Uyuşmazlık çözüm yeri ve uygulanacak hukuk yazılı.
Sık sorulan sorular
Standart sözleşmeleri değiştirebilir miyim?
Çoğu zaman evet, özellikle kurumsal hizmetlerde. Tüm metni yeniden yazmak yerine, kritik üç-dört maddeye ek protokol talep etmek pratik bir yoldur: veri iadesi, yedekleme kapsamı ve bildirim süreleri en sık kabul gören taleplerdir.
SLA taahhüdü olmayan hizmet almalı mıyım?
Kritik olmayan hizmetlerde kabul edilebilir. Ancak işinizin durmasına yol açacak bir hizmette, erişilebilirlik taahhüdü ve telafi yöntemi yazılı olmalıdır. Taahhüt yoksa, kesinti süresinin tamamı sizin riskinizdedir.
Veri iadesi için ek ücret istenebilir mi?
Sözleşmede öngörülmüşse istenebilir. Bu nedenle imzadan önce "hizmet sonunda veriler ek bedel talep edilmeksizin teslim edilir" ifadesinin bulunmasını istemek, sonradan pazarlık yapmaktan çok daha kolaydır.
Fiyat artışı maddesine nasıl bakmalıyım?
Artışın hangi ölçüte bağlı olduğu, yılda kaç kez yapılabileceği ve kaç gün önceden bildirileceği yazılı olmalıdır. Bildirim süresi, aynı zamanda alternatif değerlendirmeniz için gereken süredir; çok kısa tutulması pratikte seçeneksiz bırakır.
Sözleşmeyi kim incelemeli?
Hukuki değerlendirme için danışmanınız, teknik kapsam için ise sistem sorumlunuz bakmalıdır. İkisi ayrı bakarsa gözden kaçan alanlar oluşur: hukukçu teknik kapsamı, teknik ekip ise sorumluluk sınırını değerlendiremez. Birlikte okunan bir sözleşme, iki kez okunandan daha güvenlidir.
Sonuç
Dijital hizmet sözleşmeleri karmaşık görünse de yedi maddeye indirgenebilir. Bu yedisi netse, ilişki iyi giderken de kötü giderken de tarafların ne yapacağı bellidir. Sözleşmeyi değerlendirirken sorulacak en iyi soru şudur: yarın ayrılmak istesem, ne kadar sürede ve hangi bedelle ayrılabilirim?
Mevcut sözleşmelerinizi ve hizmet kapsamınızı birlikte gözden geçirmek isterseniz bize ulaşın. Hizmet ve kullanım sözleşmemizi, SLA garantimizi ve kurumsal hosting çözümlerimizi inceleyebilirsiniz.