Destek taleplerine "en kısa sürede döneriz" demek bir taahhüt değil, bir temennidir. Müşteri bunu duyduğunda kendi zihninde bir süre belirler; siz başka bir süre düşünürsünüz. İki taraf da sözünü tuttuğunu sanır, biri hayal kırıklığına uğrar.
SLA tam olarak bu boşluğu kapatmak için vardır. Bu yazı SLA'nın ne olduğunu, KPI'dan farkını, hangi bileşenlerden oluştuğunu ve gerçekçi bir hedefin nasıl belirleneceğini anlatıyor.
SLA nedir?
SLA (Service Level Agreement — hizmet seviyesi anlaşması), bir hizmetin hangi kalite düzeyinde sunulacağını yazılı olarak taahhüt eden anlaşmadır. Destek bağlamında tipik olarak iki şeyi tanımlar: bir talebe ne kadar sürede ilk yanıt verileceği ve ne kadar sürede çözüleceği. Anlaşma olması, ölçülebilir olmasını ve karşılanmadığında bir sonucu bulunmasını gerektirir; ölçülmeyen ya da sonucu olmayan bir vaat SLA değil, iyi niyet beyanıdır.
SLA, SLO, SLI ve KPI: hangisi ne?
Bu dört kavram sık karıştırılır ve karıştırıldığında konuşma bulanıklaşır. Aradaki fark basittir:
Kavram | Nedir | Örnek |
|---|---|---|
SLI (gösterge) | Ölçülen ham değer | "İlk yanıt süresi: 3 saat 12 dakika" |
SLO (hedef) | İçeride belirlenen ulaşılmak istenen seviye | "Taleplerin %90'ında ilk yanıt 4 saatin altında" |
SLA (anlaşma) | Müşteriye verilen, sonucu olan taahhüt | "4 saati aşarsak o ayın bedelinden indirim uygulanır" |
KPI (performans göstergesi) | Yönetimin izlediği performans ölçütü | "Aylık ortalama çözüm süresi" |
Pratik ayrım şu: SLI ölçer, SLO hedefler, SLA taahhüt eder, KPI yönetir. SLA dışarıya bakar ve bağlayıcıdır; SLO içeriye bakar ve genellikle SLA'dan daha sıkı tutulur. Aradaki payı bırakmak, kötü bir haftanın sözleşme ihlaline dönüşmesini engeller.
Sık yapılan hata, içeride belirlenen bir hedefi doğrudan müşteriye taahhüt olarak vermektir. Hedef ile taahhüt aynı sayı olduğunda tampon kalmaz.
Bir SLA'da bulunması gereken beş bileşen
1. Kapsam
SLA hangi taleplere uygulanır? Genellikle her talep aynı taahhüde girmez: yeni özellik istekleri, eğitim soruları ve arıza bildirimleri farklı şeylerdir. Kapsam yazılmazsa müşteri her talebi aynı sürede bekler.
2. Öncelik tanımları
Taahhüt önceliğe göre değişir; öncelik tanımı yoksa taahhüt de yoktur. Kritik olanı kimin belirlediği açıkça yazılmalıdır — müşteri mi, siz mi, yoksa tanımlı kurallar mı?
3. İlk yanıt süresi
Talebin ulaşmasından ilk insan yanıtına kadar geçen süre. Bu bileşen en çok tartışılan olduğu için ayrı bir bölümde ele alıyoruz.
4. Çözüm süresi
Talebin kapanmasına kadar geçen süre. Dikkat: çözüm süresi çoğu zaman sizin kontrolünüzde değildir — müşteriden bilgi beklediğiniz süreyi saymamak için "duraklatma" kuralı tanımlanmalıdır. Aksi halde müşterinin yanıt vermediği üç gün sizin performansınıza yazılır.
5. Çalışma saatleri ve istisnalar
Süre sayacı ne zaman işler? Mesai saatleri içinde mi, 7/24 mü? Resmî tatiller nasıl sayılır? Cuma 17:30'da gelen talep için "4 saat" ne anlama geliyor? Bu bileşen yazılmadığında SLA'nın diğer dört maddesi de yoruma açık kalır.
İlk yanıt süresi nasıl ölçülür?
Görünürde basit bir metrik, pratikte tanımı tartışmalıdır. Üç soruya net cevap vermeniz gerekir.
Otomatik yanıt sayılır mı? Hayır. "Talebiniz alınmıştır" mesajı bir alındı bildirimidir, yanıt değildir. Otomatik mesajı ilk yanıt saymak metriği anlamsızlaştırır: süre mükemmel görünür, müşteri deneyimi değişmez. Bu, SLA raporlarını güzelleştirmenin en yaygın ve en zararlı yoludur.
Sayaç ne zaman başlar? Talebin size ulaştığı an. Sistemin talebi işlediği an değil, müşterinin gönderdiği an. Aradaki fark küçük görünür ama kanal gecikmesini müşteriden gizler.
Ne "yanıt" sayılır? Talebi ele alan, gerçek bilgi veya soru içeren bir insan mesajı. "İlgileniyoruz" cümlesi teknik olarak yanıttır ama müşteri açısından değildir; ölçtüğünüz şey ile müşterinin hissettiği şey ayrışmaya başlarsa metrik sizi yanıltır.
Bu üç kararı yazılı hale getirin. Ekipteki iki kişi ilk yanıtı farklı tanımlıyorsa, elinizdeki sayı ortalama değil karışımdır.
Öncelik seviyeleri nasıl tanımlanır?
Seviye | Tanım ölçütü | Tipik durum |
|---|---|---|
Kritik | İş duruyor, alternatif yol yok | Sistem erişilemiyor, ödeme alınamıyor |
Yüksek | İş aksıyor ama geçici çözüm var | Bir modül hatalı, elle telafi ediliyor |
Düşük | İş devam ediyor | Görsel hata, iyileştirme talebi, soru |
Tanımı etkiye göre yapın, aciliyet hissine göre değil. "Müdür istedi" bir öncelik ölçütü değildir; "üretim durdu" ölçüttür. Aksi halde her talep kritik olur ve öncelik sistemi çöker.
Bir de şu kuralı yazın: önceliği kim değiştirebilir? Müşteri kendi talebini kritik olarak işaretleyebiliyorsa, kısa sürede bütün talepler kritik gelir.
Gerçekçi bir hedef nasıl belirlenir?
Buradaki en yaygın hata, hedefi dışarıdan almaktır: bir yazıda okunan "standart" süre alınır ve sözleşmeye yazılır. Sonra tutturulamaz.
Doğru sıra tersidir — önce ölçün, sonra taahhüt edin:
Mevcut durumu ölçün. Son üç ayın ilk yanıt ve çözüm sürelerini önceliğe göre ayırarak çıkarın. Taahhüde girmeden önce nerede olduğunuzu bilmelisiniz.
Ortalamaya değil, yüzdelik dilime bakın. Ortalama yanıltıcıdır: birkaç hızlı yanıt, birkaç çok geç yanıtı gizler. Müşteri ortalamayı deneyimlemez, kendi talebini deneyimler. "Taleplerin %90'ında" gibi bir dil kullanın.
Hedefi mevcut performansın biraz üstüne koyun. Bugün 90. yüzdelik diliminiz 6 saatse, taahhüdü 5 saat yapın; 1 saat yapmayın. Tutulabilir bir taahhüt, iddialı bir taahhütten değerlidir.
Tamponu SLO ile bırakın. İçeride 4 saati hedefleyip dışarıya 6 saat taahhüt etmek meşru ve sağlıklıdır.
Üç ay sonra yeniden bakın. Kapasiteniz ve talep profiliniz değişir; SLA da değişebilir olmalıdır.
Neden burada "sektör ortalaması" vermiyoruz: Doğrulanmış, güncel ve Türkiye pazarına ait bir kaynağımız yok. Uydurulmuş bir rakam vermek, o rakamı sözleşmeye yazan okuyucuyu doğrudan zarara sokar. Kendi verinizle çalışmak yalnız daha dürüst değil, daha isabetli.
Çok kanallı destekte SLA nasıl çalışır?
Talepler tek bir kanaldan geliyorsa ölçüm kolaydır. Gerçekte ise e-posta, telefon, WhatsApp ve varsa müşteri paneli aynı anda kullanılır — ve her kanal farklı bir beklenti taşır. WhatsApp'tan yazan müşteri dakikalar içinde yanıt bekler; e-posta gönderen aynı kişi saatlerce bekleyebilir. Aynı SLA'yı her kanala uygulamak bu farkı görmezden gelir.
İki seçenek var. Birincisi kanal başına farklı taahhüt vermek: WhatsApp için daha kısa, e-posta için daha uzun süre. Dürüst ama yönetimi zordur ve hızlı kanalı teşvik ederek yükü oraya kaydırır.
İkincisi — ve pratikte daha sürdürülebilir olanı — tek taahhüt, tek kuyruk: hangi kanaldan gelirse gelsin talep aynı yere düşer, aynı sürede yanıtlanır ve müşteriye kanal fark etmeksizin aynı söz verilir. Bu yaklaşımın ön koşulu, kanalların gerçekten tek kuyrukta birleşmesidir. Talepler farklı yerlerde biriktiği sürece ne ölçüm ne de taahhüt anlamlı olur; SLA'dan önce çözülmesi gereken şey budur.
- Küçük bir ekibiz, SLA'ya gerçekten ihtiyacımız var mı?
Sözleşmeye koymanız gerekmeyebilir, ama içeride bir hedef belirlemeniz her ölçekte işe yarar. SLA'sız çalışan ekiplerde yanıt sırası çoğu zaman "en son yazana" göre oluşur; hedef koymak sıralamayı etkiye göre yapmanızı sağlar.
- SLA ile garanti aynı şey mi?
Hayır. Garanti ürünün kendisine dair bir vaattir (çalışır, bozulursa değiştirilir). SLA hizmetin sunuluş biçimine dair bir vaattir (ne kadar sürede döneriz). Bir üründe garanti olmadan SLA, SLA olmadan garanti olabilir.
- Yanıt süresini kısaltmak müşteri memnuniyetini artırır mı?
Bir noktaya kadar. Araştırmalar bir yana, kendi verinizde şunu görürsünüz: çok geç yanıt memnuniyeti keskin şekilde düşürür, ama çok hızlı yanıt aynı oranda artırmaz. Asıl belirleyici olan genellikle öngörülebilirliktir — ne zaman döneceğinizi söyleyip o söze uymak, sürekli hızlı olmaya çalışmaktan daha sürdürülebilirdir.
- Talep müşteriden bilgi beklerken sayaç durmalı mı?
Evet, ve bu kural SLA metnine yazılmalıdır. Aksi halde ölçtüğünüz şey sizin performansınız değil, müşterinin yanıt hızı olur. Duraklatma kuralı olmayan SLA, kontrol edemediğiniz bir şey için taahhüt vermek anlamına gelir.
- Kaç öncelik seviyesi olmalı?
Üç. İki seviye ayrımı fazla kabalaştırır, dörtten fazlası sınıflandırmayı sezgisel olmaktan çıkarır ve pratikte orta seviyeler birbirine karışır.
- Bakım sözleşmesinde SLA nasıl yazılır?
Bakım sözleşmelerinde SLA, teklifin ayrılmaz parçasıdır — sonradan eklenen bir ek değil. Teklifte kapsam sınırı (aylık kaç saat), yanıt taahhüdü ve kapsam dışına ne olacağı birlikte yazılmalıdır; üçünden biri eksikse sözleşme ilk anlaşmazlıkta yoruma açılır. Bakım tekliflerinde ağırlığın nereye verileceğini ayrıca ele aldık.
- SLA'yı nerede takip etmeliyiz?
Talebin kendisinin yaşadığı yerde. Ayrı bir tabloda tutulan SLA ölçümü güncel kalmaz; süreyi hesaplayan sistem ile talebi kaydeden sistem aynı olmalıdır. Bu akışın nasıl kurulduğunu sayfasında ele aldık.
Destek taleplerini tek kuyrukta toplayıp vade, öncelik ve yanıt süresini aynı kayıt üzerinden izlemek isterseniz ile müşterilerinize kendi panellerini açabilir, talepleri ekibinizin düşürebilirsiniz; deneyebilirsiniz.