1. SLA nedir, neleri kapsamalıdır?
SLA (Service Level Agreement), hizmetin hangi kapsamda, hangi öncelik seviyelerinde, hangi süre hedefleriyle verileceğini tanımlar. Sadece “yanıt süresi” değil; olay sınıfları, kapsam dışı işler, iletişim kanalı, raporlama frekansı ve ihlal durumunda izlenecek iyileştirme adımlarını da kapsar.
Bakım SLA’si nedir, neleri kapsamalıdır?
Bakım SLA’si; destek kapsamını, öncelik seviyelerini (P1–P4), yanıt/çözüm süre hedeflerini, uptime hedefini, mesai içi-dışı koşullarını ve raporlama/iyileştirme sürecini kapsamalıdır.
Mini örnek (otel): Sezonda gece 23:40’ta rezervasyon akışı durduğunda, “mesai bitti” demek geliri riske atar. SLA, bu tür P1 senaryosunda kim devrede, hangi sürede müdahale edilecek, netleştirir.
Mini Check
- • Kapsam: hangi sistemler SLA içinde (site, rezervasyon, PMS/OTA, analytics)?
- • Öncelik sınıfları: P1–P4 tanımı net mi?
- • Mesai içi/dışı: gece/hafta sonu/season kapsamı yazıyor mu?
Ne yapmalıyım?
- • SLA’yı “süre” değil “model” olarak kur: kapsam + sınıflandırma + ölçüm.
- • P1–P4’ü sadece teknik değil, iş etkisi ile tanımla.
- • Raporlama döngüsünü eklemeden SLA’yı “tamam” sayma.
2. Response, Resolution, uptime ve kapsam tanımları
SLA’nın en kritik hatası; response ile resolution’ın karıştırılmasıdır. Response, talebin alındığı ve çalışmaya başlandığının teyididir. Resolution ise sorunun kalıcı şekilde çözülmesi veya kabul edilebilir bir workaround ile hizmetin geri gelmesidir.
Uptime hedefi nasıl okunmalı?
Uptime yüzdesi tek başına anlamlı değildir; “hangi kapsam” ve “hangi istisnalar” ile tanımlandığı önemlidir. Downtime’ın iş etkisi; otelde rezervasyon/çağrı merkezi, B2B’de ödeme/lead ile direkt bağlantılıdır.
Güvenlik olaylarında P1/P2 tanımlarını netleştirmek ve süreç dilini aynı tutmak için güvenlik sayfası ile birlikte düşünmek gerekir.
Mini Check
- • Response: “teyit” mi, yoksa “ilk müdahale” mi? Tanım net mi?
- • Resolution: kalıcı çözüm mü, workaround mu? Kural yazıyor mu?
- • Uptime: hangi bileşenler dahil (CDN, DNS, rezervasyon motoru yönlendirme)?
Ne yapmalıyım?
- • Response ve resolution’ı ayrı KPI olarak takip et.
- • Uptime hedefini, izleme yöntemini ve istisnalarını yaz.
- • “Kapsam dışı” işleri netleştir (yeni özellik geliştirme vs destek).
3. Öncelik seviyeleri (P1–P4) incident’ler
P1–P4, teknik şiddetten çok iş etkisi ile tanımlanmalıdır. Aynı teknik hata, otelde farklı; B2B’de farklı iş etkisi yaratabilir.
P1–P4 tanım çerçevesi
- •P1 (Kritik): Tam kesinti / gelir üreten akış durdu (rezervasyon/ödeme)
- •P2 (Yüksek): Kısmi kesinti / kritik özellik degrade (fiyat alınamıyor, form düşmüyor)
- •P3 (Orta): İşlevsel hata ama workaround var (UI/rapor sapması)
- •P4 (Düşük): Küçük hata/istek, kozmetik, içerik düzeltme talebi
P1–P4 öncelik seviyeleri nasıl tanımlanır?
P1–P4; etkilediği gelir akışı, kullanıcı sayısı, güvenlik riski ve workaround olup olmamasına göre tanımlanır. P1 tam kesinti; P2 kritik degrade; P3 workaround’lu hata; P4 düşük öncelikli istek/kozmetik işlerdir.
Mini örnekler
- •Otel / P1: Rezervasyon motoruna yönlendirme 500 hatası veriyor.
- •Otel / P2: Oda listesi açılıyor ama fiyat yüklenmiyor.
- •B2B / P1: Ödeme/checkout başarısız.
- •B2B / P2: Lead form CRM’e düşmüyor.
Mini Check
- • Öncelik tanımı “iş etkisi” ile yazıldı mı?
- • P1/P2’de mesai dışı kapsam net mi?
- • Güvenlik olayları P1/P2’de açıkça tanımlı mı?
Ne yapmalıyım?
- • P1–P4 tablolarını “örnek olaylar”la birlikte yaz (otel+B2B).
- • P1/P2 için iletişim kanalı ve escalation adımlarını netleştir.
- • Güvenlik olaylarını aynı dilde sınıflandır (sunucu güvenliğiyle uyumlu).
4. Otel ve B2B için örnek bakım SLA modelleri
Tek tip SLA, iki farklı dünyada sorun çıkarır: otellerde sezon ve gece trafiği; B2B’de iş saatleri ve kritik akışlar farklıdır. Bu yüzden model, “pencere” ve “kapsam” üzerinden uyarlanmalıdır.
Otel için (sezon + gece/hafta sonu gerçekliği)
- •P1: 7/24 kapsama daha yakın (özellikle yüksek sezon)
- •P2: genişletilmiş saatler (örn. 08:00–24:00)
- •P3/P4: mesai saatleri + planlı bakım pencereleri
- •Sezon öncesi checkup ile SLA ihlali riski düşürülür
B2B için (kritik iş saatleri)
- •P1/P2: iş saatleri içinde agresif, iş saatleri dışında net tanımlı
- •P3/P4: sprint/planlama takvimine bağlanır
- •Raporlama: aylık SLA performansı + kök neden + iyileştirme backlog’u
| Öncelik | İş etkisi örneği | Response hedefi | Resolution hedefi | Kapsam penceresi | Not |
|---|---|---|---|---|---|
| P1 | Rezervasyon/ödeme akışı durdu | 15–30 dk | 2–6 saat | Otel: sezon 7/24 / B2B: kritik pencere | Escalation + war-room |
| P2 | Kritik özellik degrade (fiyat/form) | 1–2 saat | 8–24 saat | Genişletilmiş saatler | Workaround kabul kuralı |
| P3 | Workaround’lu hata | 1 iş günü | 3–5 iş günü | Mesai içi | Backlog/sprint’e bağlanır |
| P4 | Kozmetik/istek | 2 iş günü | Planlı | Mesai içi | Kapsam dışı geliştirmeden ayrılır |
Mini Check
- • Otel için sezon/hafta sonu kapsamı yazılı mı?
- • B2B için iş saatleri ve istisnalar net mi?
- • P3/P4 talepleri backlog ve planlama ritmine bağlanıyor mu?
Ne yapmalıyım?
- • SLA’yı iki katman yap: incident (P1–P2) + talepler (P3–P4).
- • Mesai dışı kapsamı “varsayım” değil “kural” haline getir.
- • P3/P4’ü sprint planlamasıyla yönet; aksi halde sürekli kesinti yaratır.
5. Raporlama ve sürekli iyileştirme
SLA raporlanmıyorsa, yönetilmiyordur. Asıl hedef; ihlalleri “kişisel tartışma” yerine “veri odaklı iyileştirme”ye çevirmektir.
Ölç → Rapor → İyileştir döngüsü
- •Ölç: response/resolution, uptime, ihlal sayısı, tekrar eden olay sınıfları
- •Rapor: aylık özet + P1/P2 olay analizi + trendler
- •İyileştir: aksiyonlar (monitoring, runbook, test, kapasite) → bakım planına ekle
Key data point (yumuşatılmış): SLA tanımları net olan projelerde beklenti yönetimi ve memnuniyet genelde daha yüksektir; “kimin neyi ne kadar sürede yapacağı” tartışması veri odaklı diyaloğa dönüşür.
Mini Check
- • Aylık SLA raporu tek sayfada özetleniyor mu?
- • İhlaller için root-cause analizi yapılıyor mu?
- • Preventive aksiyonlar bakım planına ekleniyor mu?
Ne yapmalıyım?
- • SLA raporunu raporlama ritminize bağla.
- • Güvenlik olaylarını P1/P2 kapsamına net yerleştir.
- • İhlal sonrası iyileştirme aksiyonlarını takip etmeden “rapor bitti” deme.
6. Competitor gap: SLA’yı hukuki metin değil operasyon modeli yapmak
Türkiye’de SLA örnekleri çoğu zaman hukuki metin gibi kalır; operasyon tarafında “ne ölçeceğiz, nasıl raporlayacağız, nasıl iyileştireceğiz?” soruları boşta kalır. Bu yazının farkı; SLA’yı ölçülebilir, raporlanabilir ve iyileştirilebilir bir operasyon modeli olarak vermesidir.
Sonuç: İyi SLA; kapsam, P1–P4 öncelikler, response/resolution hedefleri ve uptime’ı netleştirir. Otelde sezon ve mesai dışı; B2B’de iş saatleri ve kritik akışlar modele dahil edilir. Performans ölçülür, raporlanır ve ihlaller “iyileştirme aksiyonları”na çevrilirse SLA gerçek bir güven mekanizmasına dönüşür.
7. Bakım SLA Tasarım & Raporlama Şablonu (İndir)
Bakım SLA Tasarım & Raporlama Şablonunu İndir — Yazılım / SLA Yönetim Modeli (v1.0)
Bu şablon, bakım SLA’nizi “kontrat metni” olmaktan çıkarıp ölçülebilir bir operasyon modeline dönüştürmek için tasarlanmıştır. P1–P4 öncelikler, response/resolution hedefleri, uptime ve kapsam tanımları tek tabloda toplanır. Aylık raporlama ve iyileştirme döngüsüyle ihlaller, aksiyonlara bağlanır.
Kim Kullanır?
Otel ve B2B kurumlarında GM/operasyon lideri + IT/ajans yöneticisi.
Nasıl Kullanılır?
- Kapsamı ve P1–P4 tanımlarını doldurun (iş etkisi odaklı).
- Response/resolution hedeflerini “mesai içi/dışı” pencereleriyle eşleştirin.
- Aylık raporda SLA performansını çıkarın; ihlaller için corrective/preventive aksiyonları backlog’a ekleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ SLA kapsam envanteri çıkarıldı
- ▢ ✅ P1–P4 tanım matrisi örnek olaylarla net
- ▢ ✅ Response/Resolution KPI’ları ayrı takip ediliyor
- ▢ ✅ Uptime kapsamı + istisnalar yazıldı
- ▢ ✅ Aylık rapor + RCA + aksiyon backlog’u hazır
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Yanıt/çözüm sürelerini ve P1–P4 öncelikleri otel/B2B iş etkisine göre netleştirip ölçülebilir bir operasyon modeli kuralım.