1. Dijital Servis Kataloğu Nedir?
Servis kataloğu; “hangi dijital servislerimiz var ve bunların bakımı kimin sorumluluğunda?” sorusunun tek sayfalık cevabıdır. ITIL teorisi gibi görünse de pratikte çok basit bir fayda sağlar: bakım kapsamı tanımlama ve sahipliği somutlaştırır. Özellikle ajans, vendor ve iç ekiplerin birlikte çalıştığı yapılarda, kataloğun yokluğu sürekli çatışma üretir.
Soru : Dijital servis kataloğu nedir, neleri içermelidir?
Cevap: Dijital servis kataloğu; servis adı, kapsam (neler dahil/neler hariç), owner, çalışma saatleri, servis bazlı SLA yönetimi, destek kanalları, bağımlılıklar ve eskalasyon bilgisini içeren envanterdir. Amaç, bakım ve destekte sahiplik belirsizliğini ortadan kaldırmaktır.
Ne yapmalıyım?
- • Kataloğu “liste” değil “operasyon sözleşmesi” gibi düşün.
- • Kapsam dahil/hariç satırını eklemeden yayınlama.
- • Kataloğu ticketing/SLA süreçlerine bağla (aksi halde raf dokümanı olur).
2. Hangi Servisler Bakım Kapsamında? (Web, PMS, OTA, CRM, Çağrı Merkezi vb.)
Bakım kapsamı “web sitesi” ile sınırlı değilse (çoğu otelde değildir), servisleri bileşenlere ayırmak gerekir. B2B’de de portal/API/ödeme/raporlama gibi parçalar farklı sahiplikler taşır; özellikle PMS ve OTA bakım kapsamı ile web tarafının sınırı net yazılmadığında sahiplik hızla karışır.
Tipik servisler (otel)
- •Web sitesi (frontend + CMS)
- •Rezervasyon modülü / booking engine yönlendirme
- •PMS/OTA entegrasyonu (availability, fiyat, paket)
- •CRM / lead & misafir iletişimi
- •Raporlama panelleri (gelir, kanal, kampanya)
- •Çağrı merkezi / mesaj yönetimi entegrasyonları
Tipik servisler (B2B)
- •Portal UI
- •API/entegrasyon katmanı
- •Auth/SSO & permissions
- •Ödeme/checkout
- •Raporlama/export
- •İzleme/alerting & status page
Katalog yalnız servis listesinden ibaret kalmamalı; servis kataloğundan ticket kategorilerine geçiş, çağrı akışlarının hangi servise bağlandığı ve servis bazında performansın nasıl raporlandığı da netleşmelidir.
- •PMS/OTA tarafında fiyat, müsaitlik, kanal ve rezervasyon akışı ayrı servis kalemi olarak tanımlanmalı
- •Çağrı ve rezervasyon talepleri servis kataloğunda doğru sahiplik alanına bağlanmalı
- •Web, entegrasyon ve raporlama kalemleri birbirinden ayrılmalı
- •Servis bazlı performans metrikleri düzenli gözden geçirilmeli
Özellikle çağrı merkezi destek kapsamı net değilse, müşteri talebi ile teknik bakım talebi aynı kuyrukta karışabilir.
Ne yapmalıyım?
- • Servisleri “iş akışı” üzerinden grupla (otel: rezervasyon; B2B: ödeme/rapor).
- • Servis başına “dahil/hariç” kuralı yaz.
- • Ticketing kategori/queue tasarımını servis kataloğuna bağla.
3. Sorumluluk Matrisi (RACI)
RACI; “kim yapar?” kavgasını bitiren pratik bir matrisi ifade eder:
- •R (Responsible): işi yapan
- •A (Accountable): sonuçtan sorumlu/onaylayan
- •C (Consulted): görüş alınan
- •I (Informed): bilgilendirilen
RACI olmadan servis kataloğu eksik kalır; çünkü “owner” tek başına yetmez. Özellikle outsource/hybrid yapılarda RACI matrisi bakım sorumlulukları netleştirilmeden A ve R’nin ayrılması kritik olur.
Soru : RACI matrisi ile sorumlulukları nasıl netleştiririm?
Cevap: Her servis için R (uygulayan), A (hesap veren), C (danışılan) ve I (bilgilendirilen) rollerini yazın. Ticket triage, change onayı ve incident müdahalesinde R/A rolleri net olursa yanlış ekibe yönlendirme ve eskalasyon azalır.
Voice (tek cümle): “Bu hata IT’nin mi ajansın mı işi?” tartışmasını bitirmek için servis kataloğu + RACI yapın.
Ne yapmalıyım?
- • Her servis için tek “A” kuralını uygula.
- • R’leri “alan” bazlı ayır (web, entegrasyon, güvenlik).
- • RACI’yi ticket alanlarına (category/owner) göm.
4. Otel ve B2B İçin Servis Kataloğu Örnekleri
Aşağıdaki örnek tablolar, “kimin neye baktığı”nı tek bakışta görünür kılar. Buradaki amaç; sözleşme dili değil, operasyonel gerçekliktir: çalışma saatleri, SLA hedefi ve eskalasyon.
| Servis | Kapsam (dahil/hariç) | Owner | Çalışma Saatleri | SLA (P1/P2) | R | A | C | I |
|---|---|---|---|---|---|---|---|---|
| Web Sitesi | dahil: içerik, performans; hariç: yeni ürün modülü | İç owner/PM | 09:00–18:00 | TBD/TBD | Ajans Web | İç owner | SEO | GM |
| Rezervasyon Akışı | dahil: yönlendirme, test; hariç: vendor iç sistemi | IT | 09:00–24:00 (otel) | TBD/TBD | Vendor+Ajans | IT | Call Center | GM |
| PMS/OTA Entegrasyonu | dahil: healthcheck; hariç: PMS altyapı hatası | IT | 09:00–18:00 | TBD/TBD | Entegrasyon | IT | Vendor | GM |
| CRM/Lead | dahil: form->CRM; hariç: CRM lisans | Pazarlama | 09:00–18:00 | TBD/TBD | Ajans | Pazarlama | IT | GM |
| Çağrı Merkezi | dahil: mesaj/hat yönlendirme; hariç: operatör süreçleri | Call Center Lead | 7/24 | TBD/TBD | Call Center | Call Center | IT | GM |
| Raporlama | dahil: dashboard uptime; hariç: veri kaynağı sahipliği | Ops | 09:00–18:00 | TBD/TBD | Data/BI | Ops | IT | GM |
Not: SLA hedefleri kurum kapasitesine göre kalibre edilir; burada amaç “alanların standartlaşmasıdır.”
Key Statistics / Data Point (yumuşatılmış): Servis kataloğu net olan kurumlarda, yanlış ekipte açılan ticket oranı ve iç anlaşmazlıkların azalması daha sık gözlenir; çünkü sahiplik ve kapsam yazılıdır. Bu görünürlük servis bazlı bakım raporlaması için de güçlü bir temel oluşturur.
Ne yapmalıyım?
- • İlk sürümde 8–12 servisle başla; sonra genişlet.
- • SLA’yi kataloğa eklemeden bırakma (tartışma geri gelir).
- • Kataloğu “quarterly review” ile güncel tut.
5. Servisler Arası Bağımlılık Ağı
Bir incident çoğu zaman tek servisten kaynaklanmaz; bağımlılıklar zinciri vardır: web → rezervasyon → PMS/OTA → CRM → raporlama. Bu yüzden katalogla birlikte basit bir bağımlılık diyagramı, triage süresini düşürür.
Ne yapmalıyım?
- • Bağımlılık diyagramını “top 5 kritik akış” üzerinden çiz.
- • Her bağımlılığa owner + eskalasyon ekle.
- • Postmortem sonrası bağımlılık haritasını güncelle.
6. Dijital Servis Kataloğu & RACI Şablonunu İndir — Yazılım / Scope & Ownership (v1.0)
Dijital Servis Kataloğu & RACI Şablonunu İndir — Yazılım / Scope & Ownership (v1.0)
Bu şablon; bakım ve destek kapsamını servis bazında netleştirmenizi sağlar: her servis için kapsam (dahil/hariç), owner, çalışma saatleri, SLA hedefleri ve RACI rolleri tek tabloda görünür olur. Amaç, incident anında “kimin bakacağı” tartışmasını bitirmek ve ticketing/SLA süreçlerini somutlaştırmaktır. Çoklu tedarikçiyle çalışan otel ve B2B organizasyonlarına uyarlanabilir.
Kim Kullanır?
IT/ops lideri + vendor/ajans yöneticisi + iş sahibi (GM/ürün lideri).
Nasıl Kullanılır?
- Servis listesini çıkar ve kapsam dahil/hariç maddelerini yaz.
- Owner, saatler, SLA ve RACI’yi doldur; tek “A” kuralını uygula.
- Ticket kategorilerini kataloğa bağla; üç ayda bir review ile güncelle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Servis listesi 8–12 arası
- ▢ ✅ Owner + saatler + SLA dolu
- ▢ ✅ RACI’de her servis tek A
- ▢ ✅ Bağımlılık ağı çıkarıldı
- ▢ ✅ Ticket kategorileri kataloğa bağlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5) Kontrol listesi
- •Servis listesi 8–12 arası
- •Owner + saatler + SLA dolu
- •RACI’de her servis tek A
- •Bağımlılık ağı çıkarıldı
- •Ticket kategorileri kataloğa bağlandı
7. Competitor Gap’i Kapatan “Scope + Ownership” Yaklaşımı
Türkiye’de kapsam tartışmaları çoğu zaman sözleşme metninde kalır. Bu rehberin farkı; servis kataloğunu operasyonel alanlara (owner, saatler, SLA, RACI, bağımlılık) indirgemesidir. Sonuç: bakım bütçesi ve SLA görüşmeleri de “somut servis kalemleri” üzerinden yürür, soyut kavga azalır.
Bakım servislerini somutlaştırmak, RACI’yi yazılı hale getirmek ve kapsam tartışmalarını azaltmak için Bakım ve Destek hizmetiyle service catalogue yapınızı netleştirin. Kapsam, destek sınırları ve çalışma modeliyle ilgili detaylar için Bakım ve Destek hakkında sık sorulan sorular sayfasına da bakabilirsiniz.
Bir Sonraki Adım
Web, PMS/OTA, CRM ve çağrı merkezi gibi çoklu servislerde kapsam ve sahipliği netleştirmek isteyen otel ve B2B organizasyonlar için.
Sık Sorulan Sorular
Dijital servis kataloğu nedir, neleri içermelidir?▾
Bakım kapsamına hangi sistemler giriyor?▾
RACI matrisi ile sorumlulukları nasıl netleştiririm?▾
Otel ve B2B için örnek servis kataloğu tablosu nasıl görünür?▾
“Kimin işi?” tartışmasını nasıl bitiririm?▾
İlgili İçerikler