IT Destek SLA Nedir? Müdahale ve Çözüm Süresi Farkı

İlk yanıt, müdahale ve çözüm: üç ayrı ölçüm

Önce satın aldığınız hizmetin hangi aşamayı taahhüt ettiğini sorun. İlk yanıt, yetkili destek ekibinin talebi ele aldığını bildirmesi veya tanımlanan ilk temasın kurulmasıdır. Müdahale, anlaşmada belirlenen teknik çalışmanın başlaması olabilir; uzaktan bağlantı, inceleme veya sahaya yönlendirme gibi farklı anlamlara gelebilir. Kalıcı çözüm ise olayın kök nedeninin giderilmesi ve sonucun doğrulanmasıdır. Bu rehberde kullanılan operasyon tanımları örnektir; sözleşmenizdeki karşılığı açıkça yazılmalıdır.

Bir otomatik kayıt e-postasını teknik müdahale sayıp saymadığınızı başlangıçta kararlaştırın. İlk temasın insan tarafından mı yapılacağı, hangi kanaldan geleceği ve kayıt numarası taşıyıp taşımayacağı belirsiz bırakılmamalıdır. Temel hizmet kapsamı için IT bakım anlaşması rehberini ayrıca inceleyebilirsiniz; burada odak, aynı kapsamın ölçülme biçimidir.

Üretici desteği ile kendi hizmet anlaşmanızı karıştırmayın

Üretici belgeleri sürelerin ürün ve destek planına bağlı olduğunu gösterir. Microsoft’un Power Platform destek açıklaması, ilk yanıtı destek talebinden mühendisin ilk temasına kadar olan dönem olarak ele alır; önceliği iş etkisiyle ilişkilendirir. Bu tanımı bütün IT sağlayıcılarının ortak taahhüdü gibi kullanmayın.

Dynamics 365 destek açıklaması da ilk yanıt taahhüdünü çözüm süresinden ayırır. Bunlar ilgili Microsoft hizmetlerinin politikalarıdır; Quad Bilişim adına ilan edilmiş süre, paket veya garanti değildir. Bir ürün sağlayıcısının yanıt vermesiyle sizin çalışanınızın yeniden iş yapabilmesi arasındaki kalan sorumluluğu hizmet kapsamınızda ayrıca tanımlayın.

Önceliği talep sahibinin unvanına değil iş etkisine bağlayın

Quad Bilişim’in önerisi, öncelik kararını kısa bir etki kaydıyla desteklemektir. Etkilenen çalışan sayısı, duran iş süreci, kullanılabilir alternatif ve güvenlik etkisi ayrı alanlar olsun. Bir kişinin yazıcısı çalışmıyorken başka bir yazıcı kullanılabiliyorsa olayın etkisi, bütün şubelerin sipariş verememesinden farklıdır. Ancak tek bir kişinin kullandığı sistem kritik bir ödeme veya sevkiyat adımını durduruyorsa kullanıcı sayısı tek başına yeterli ölçüt değildir.

• Hangi iş süreci durmuş veya yavaşlamış durumda?
• Kaç ekip, kullanıcı veya lokasyon etkileniyor?
• Güvenli ve kabul edilmiş bir geçici çalışma yolu var mı?
• Olay büyüyor mu, aynı belirtinin başka kaydı var mı?
• Önceliği kim değiştirebilir ve değişiklik nasıl belgelenir?

P1, P2 veya kritik gibi etiketler kurumlar arasında farklı anlamlara gelebilir. Örnek etiketlerinizi kapsam, iletişim sıklığı ve eskalasyon sorumlusuyla birlikte açıklayın. Belirsiz bir etiketin yanına kısa bir süre yazmak, tek başına uygulanabilir bir hizmet düzeni oluşturmaz.

Çalışma saatleri ve bekleme kuralları süreyi değiştirir

Destek talebinin cuma akşamı açılması ile pazartesi sabahı açılması aynı takvim hesabını doğurmayabilir. Destek penceresinin iş günü mü, kesintisiz mi olduğu; saat dilimi, resmî tatiller ve mesai dışı bildirim kanalı açıkça belirlenmelidir. Ücret veya kapsama ilişkin özel koşulları burada varsaymayın; kendi teklifinizde yazılı olarak kontrol edin.

Dynamics 365 Customer Service SLA açıklaması, hizmet seviyesi ölçümlerinde çalışma takvimlerinin kullanılabildiğini belirtir. Kurumunuzda hangi sistem kullanılırsa kullanılsın, geçen gerçek süre ile anlaşma takvimine göre sayılan süreyi ayrı göstermek raporu anlaşılır kılar.

Müşteriden bilgi, erişim izni veya üreticiden yanıt bekleniyorsa sayacın durup durmayacağını önceden belirleyin. Bekleme kaydında gerekçe, istenen bilgi, sorumlu ve yeniden değerlendirme zamanı olsun. Sadece hedefi kaçırmamak için kaydı beklemeye almak yerine, müşterinin neyi tamamlaması gerektiğini görünür hâle getirin.

Örnek olay: kısa yanıt neden kısa çözüm anlamına gelmez?

Aşağıdaki zaman çizelgesi tamamen varsayımsaldır; gerçek müşteri olayı veya Quad hizmet taahhüdü değildir. Ofisteki ekip, bir uygulamaya erişemediği için saat 09.00’da kayıt açsın. Destek sorumlusu 09.10’da ilk teması kursun, 09.20’de teknik incelemeye başlasın. Saat 10.00’da onaylı geçici yöntemle iş akışı geri gelsin; kök neden düzeltmesi ertesi gün kontrollü değişiklikle tamamlansın.

• İlk yanıt için geçen süre: 10 dakika.
• Teknik müdahale başlangıcı için geçen süre: 20 dakika.
• İş akışının geçici olarak geri gelmesine kadar: 60 dakika.
• Kalıcı çözüm: ayrı tarih ve kabul kaydı.

Bu örnekte ilk yanıtın hızlı olması tek başına çözüm hedefinin karşılandığını göstermez. Geçici yöntemin kim tarafından kabul edildiğini, hangi kısıtların sürdüğünü ve kalıcı düzeltmenin nasıl doğrulanacağını kayda ekleyin. İş akışı geri geldiğinde kayıt kapanacak mı, yoksa kalıcı işlem tamamlanana kadar başka bir bağlantılı iş açık mı kalacak? Bu karar baştan belli olmalıdır.

Aylık raporda yalnızca ortalamaya bakmayın

Ortalama yanıt süresi, az sayıdaki uzun beklemeyi gizleyebilir. Raporu öncelik seviyelerine göre ayırın; toplam kayıt sayısını, hedef içinde kalanları, hedefi aşanları ve beklemeye alınanları birlikte gösterin. Süreleri hangi başlangıç ve bitiş olayından hesapladığınızı rapora yazın. Aynı olay yeniden açıldığında eski süreyi sıfırlamak yerine yeniden açılma durumunu ayrıca işaretlemek daha açıklayıcıdır.

Örnek olarak aynı tanımla ölçülen 20 talebin 18’i ilk yanıt hedefine uyduysa bu kayıt grubu için uyum oranı yüzde 90’dır. Bu, kullanıcı memnuniyetinin yüzde 90 olduğu veya bütün sistemlerin yüzde 90 erişilebilir kaldığı anlamına gelmez. Örneklem küçükse oranı tek başına büyük bir başarı göstergesi gibi sunmayın; geciken iki kaydın nedenini ve düzeltici işlemini inceleyin.

Teklif ve operasyon kontrol listesi

Görüşmeye yalnızca süre sorusuyla gitmek yerine aşağıdaki alanları doldurulabilir bir liste olarak kullanın. Boş kalan başlık, satın alma ve operasyon ekiplerinin birlikte netleştireceği bir konudur. IT outsource modelini değerlendirirken de aynı listeyle iki teklifin gerçekten aynı işi kapsayıp kapsamadığını kontrol edebilirsiniz.

1. Kapsamdaki sistemleri, lokasyonları ve hariç tutulan işleri yazın.
2. Bildirim kanalını, kayıt başlangıcını ve yetkili kişileri belirleyin.
3. İlk yanıt, müdahale, geri dönüş ve çözüm tanımlarını ayırın.
4. Öncelik matrisini ve çalışma takvimini ekleyin.
5. Bekleme nedenlerini ve eskalasyon akışını açıklayın.
6. Kabul ölçütlerini, kapanış ve yeniden açılma kurallarını belirleyin.
7. Aylık rapor örneğinde olay bazındaki kanıtları görün.

Güvenlik açısından destek kaydına parola veya erişim anahtarı yapıştırmayın. Erişim gerektiğinde kurumun onayladığı yetkilendirme yöntemini kullanın. Kayıt kalitesi, hız kadar önemlidir; izinli ve izlenebilir bir işlem akışı olmadan yalnızca kısa süreye odaklanmak sağlıklı destek yönetimi değildir.

Sık sorulan sorular

SLA ile bakım anlaşması aynı şey mi?

Bakım anlaşması hizmetin kapsamını ve koşullarını düzenleyebilir; SLA ise hizmet seviyesinin nasıl tanımlanıp ölçüleceğine odaklanır. Belge yapısı sağlayıcıya göre değişebilir. Kapsam ve ölçümün birbiriyle tutarlı olması gerekir.

İlk yanıt süresi, sorunun çözülme süresi mi?

Hayır. İlk yanıt, tanımlanan ilk temas aşamasını ölçer. Teknik müdahalenin başlaması, hizmetin geri gelmesi ve kalıcı çözüm ayrı olaylar olarak izlenmelidir.

Her firma için aynı SLA süresi kullanılabilir mi?

Hayır. İş etkisi, destek takvimi, kapsam, erişim koşulları ve bağımlılıklar farklıdır. Evrensel bir dakika veya saat değeri varsaymak yerine, ölçüm tanımlarını kendi hizmet koşullarınızda netleştirin.

Teknik kaynaklar

• Microsoft: Power Platform destek, önem derecesi ve ilk yanıt
• Microsoft: Dynamics 365 destek ve çözüm süresi açıklaması
• Microsoft: Hizmet seviyesi anlaşmalarına genel bakış

Kaynak kontrolü: 22 Ekim 2026. Operasyon listeleri ve varsayımsal hesap örnekleri Quad Bilişim’in özgün önerileridir; evrensel süre standardı veya hizmet garantisi değildir.