SLA Hatırlatıcılarını İhlale Dönüşmeden Otomatikleştirme

Otomatik SLA hatırlatıcıları, hâlâ harekete geçmek için zaman varken bir bileti görünür kılmalı, ardından süresi geçmiş bir bileti açıkça fark edilir hâle getirmelidir. Doğru kurulum yardım masasına bağlıdır. Bazı platformlar yerel olarak yaklaşan son tarih ve ihlal uyarıları sunarken, özel bir iş akışı zamanlanmış kontroller ve açık eskalasyon adımları gerektirebilir.
Bildirimle değil, saatle başlayın:
- İlk yanıt ve çözüm için ayrı hedefler belirleyin.
- Hedeflerin takvim zamanını mı yoksa çalışma saatlerini mi kullanacağına karar verin.
- Çözüm saatini hangi bilet durumlarının duraklatacağını seçin.
Uzman İpucu: Canlı uyarılara güvenmeden önce her SLA durumunu örnek biletlerle test edin. Yaklaşan son tarih, ihlal edilmiş, duraklatılmış, yeniden atanmış ve zaten tamamlanmış durumları testlere dâhil edin.
Temel Çıkarımlar
Güvenilir hatırlatıcılar doğru son tarihlerle başlar. Uyarı zamanlaması, alıcılar ve eskalasyon prosedürleri, ancak politikanın kendisi doğru olduktan sonra gelir.
| Öğe | Ayrıntılar |
|---|---|
| Her iki saati de tanımlayın | İlk yanıtı ve çözümü ayrı ayrı takip edin; çünkü farklı olaylarla tamamlanırlar. |
| Çalışma süresine uyun | Gece ve hafta sonlarının hedef süresini tüketmemesi gerekiyorsa çalışma takvimi kullanın. |
| Duraklatma durumlarını yapılandırın | Bilet müşteriden veya başka bir dış taraftan yanıt beklerken çözüm hedefini duraklatın. |
| Alıcıları bilinçli seçin | Yaklaşan son tarih ve ihlal uyarılarının bilet üzerinde harekete geçebilecek birine ulaştığından emin olun. |
| Yayına almadan önce test edin | Kontrollü biletlerle son tarihleri, duraklatma davranışını ve bildirimlerin iletilmesini doğrulayın. |
| Önce yerel SLA özelliklerini kullanın | Yerleşik politikalar, çalışma takvimleri, uyarılar, filtreler ve raporlama sunan bir yardım masası, ayrı bir yoklama iş akışı ihtiyacını ortadan kaldırır. |
Sonraki adımda başvurulacak yetkili belgeler ve kılavuzlar
Platforma özel bir örnek için Jira'nın otomatik takip belgelerine göz atın. Belgeler, hem zamanlanmış kuralları hem de SLA eşiği yaklaşımını açıklar ve kapsamı genişletmeden önce küçük bir sorgu kapsamıyla test yapılmasını önerir.
İçindekiler
- SLA Hatırlatıcı Otomasyonunu Adım Adım Oluşturma
- Uyarı Yorgunluğuna Yol Açmayan Eşikleri Seçme
- SLA Uyarıları Ne Söylemeli ve Nereye Gitmeli?
- Duraklatma Durumlarıyla SLA Sayaçlarını Doğru Tutma
- Otomasyona Güvenmeden Önce Test Etme ve Ayarlama
- Deskhero Bu Otomasyonları Sizin İçin Nasıl Yönetiyor?
- Uyarılarınız Yayına Alındıktan Sonra Neleri İzlemelisiniz?
- Uyarı Çakışmaları Olmadan Örtüşen SLA'ları Yönetme
- SLA'lar Otomatik Pilotta Çalışırken Denetime Hazır Kalma
- Kullanıcılar, Yöneticiler ve Müşteriler İçin SLA Mesajları Yazma
- SLA Otomasyonunu Zaten Kullandığınız Araçlara Bağlama
- Editörün Görüşü: Önemli Olan Uyarı Değil, Eylemdir
- Bir Taşıma Projesi Olmadan SLA Hatırlatıcılarınızı Çalıştırın
- Kaynaklar
- SSS
SLA Hatırlatıcı Otomasyonunu Adım Adım Oluşturma
Bir uyarıyı yapılandırmadan önce her SLA'nın tam olarak neyi ölçtüğünü yazın. İlk yanıt hedefi ile çözüm hedefi farklı saatlerdir. Her saati hangi bilet olayının başlattığına, hangi olayın tamamladığına ve son tarihin takvim zamanını mı yoksa çalışma takvimini mi izleyeceğine karar verin.
Ardından hatırlatıcı yolunu yapılandırın.
- Politikayı tanımlayın. Grupları ve öncelikleri ilk yanıt ve çözüm hedefleriyle eşleştirin. Daha özel bir kuralla eşleşmeyen biletler için genel bir politika ekleyin.
- Çalışma takvimini ayarlayın. Hedef için geçerli çalışma saatlerini ve saat dilimini ekleyin. Taahhüt kesintisiz devam ediyorsa takvim zamanını kullanın.
- Duraklatma davranışını yapılandırın. Ekip bilgi beklerken çözüm saatini durduran durumları seçin. Birçok sistem bunu farklı ele aldığından ilk yanıt saatinin duraklatılıp duraklatılamayacağını doğrulayın.
- Bildirimleri etkinleştirin. Yaklaşan son tarih ve ihlal durumlarını kimin alacağına ve yardım masasının hangi desteklenen kanalları kullanacağına karar verin.
- Operasyonel bir yanıt ekleyin. Alıcının yanıt vermek, önceliği değiştirmek, bileti yeniden atamak veya bir ekip liderini sürece dâhil etmek gibi ne yapması gerektiğini belgeleyin. Bildirim ile düzeltici eylemin aynı teknik kural olması gerekmez.
Yardım masasında yerel SLA eşikleri yoksa zamanlanmış bir iş akışı açık biletleri inceleyip son tarihlerini mevcut zamanla karşılaştırabilir. LOW/CODE tarafından 15 dakikalık yoklama örneği belgelenmiştir; ancak uygun aralık en kısa hedefe, API sınırlarına, çalışma saatlerine ve ekibin tolere edebileceği gecikme miktarına bağlıdır. Sonraki çalıştırmalarda aynı bildirimin yeniden gönderilmemesi için bir uyarı durumu kaydedin.
Uyarı Yorgunluğuna Yol Açmayan Eşikleri Seçme
Yararlı bir uyarı, alıcının yanıt vermesi için yeterli zaman bırakır. Özel bir sistemde yüzdeye dayalı bir eşik işe yarayabilir; ancak sabit bir uyarı aralığı, farklı sürelerdeki politikalar arasında çoğu zaman daha kolay anlaşılır.
- Rahatlıkla zamanında: Uyarı göndermeden bileti normal kuyruk görünümlerinde görünür tutun.
- Son tarih yaklaşıyor: Hedef hâlâ karşılanabilir durumdayken sorumlu kullanıcıya veya gruba bildirim gönderin.
- İhlal edildi: Bileti süresi geçmiş olarak işaretleyin ve ekibin belgelenmiş eskalasyon sürecini izleyin.
Temel hedefleri kontrol etmeden evrensel bir yüzde 80 eşiğini kopyalamayın. Bir saatlik hedefte bu, 12 dakika bırakırken üç günlük hedefte yarım günden fazla süre bırakır. Ekibin gerçekte ne kadar eylem süresine ihtiyaç duyduğunu ölçün.
Tekrarlanan hatırlatıcılar hızla gürültü oluşturur. Yerel yardım masası uyarıları her ekran yenilemesinde değil, durum geçişlerinde bildirim göndermelidir. Özel bir yoklama iş akışı, yaklaşan son tarih veya ihlal bildirimini gönderdiğini kaydetmeli ve bu durumu yalnızca politika gerçekten yeniden başladığında sıfırlamalıdır.

SLA Uyarıları Ne Söylemeli ve Nereye Gitmeli?
Bir uyarı bileti tanımlamalı, son tarihi göstermeli ve beklenen yanıtı açıkça belirtmelidir. Alıcının ihtiyaç duymadığı müşteri verilerini eklemekten kaçının.
- Bilet kimliği ve bağlantısı, böylece alıcı doğru görüşmeyi açabilir.
- Hedef türü, örneğin ilk yanıt veya çözüm.
- Son tarih veya geçen süre, açıkça belirtilmiş bir saat diliminde.
- Mevcut durum, öncelik, grup ve atanan kişi, bu alanlar sahipliği etkiliyorsa.
- Tek bir sonraki adım, örneğin yanıt vermek, yeniden atamak veya bir ekip liderinden inceleme istemek.
Destek ekibinin zaten takip ettiği kanalları kullanın. Uygulama içi ve e-posta bildirimleri, atanan kişiye veya sorumlu gruba güvenilir biçimde ulaştığında çoğu zaman yeterlidir. Ayrı bir çağrı veya mesajlaşma sistemi gerekiyorsa süreci bunun üzerine kurmadan önce yardım masasının entegrasyonu desteklediğini doğrulayın.
Uzman İpucu: Kesin bir son tarih veya geri sayım gösterin. Somut bir zamanı önceliklendirmek, belirsiz bir uyarıyı önceliklendirmekten daha kolaydır.

Duraklatma Durumlarıyla SLA Sayaçlarını Doğru Tutma
Bir hatırlatıcı ancak saati kadar güvenilirdir. Çözüm hedefleri genellikle bilet müşteriden yanıt beklerken duraklatılır; ancak kesin durumlar ekibin gerçek iş akışıyla eşleşmelidir.
- Açık duraklatma durumları seçin ve her birinin saati neden durdurduğunu belgeleyin.
- Bilet duraklatma durumundan çıktığında saati yeniden başlatın.
- Duraklatma durumuna birden fazla kez girip çıkan biletleri test edin.
- İlk yanıt ve çözüm hedeflerinin aynı duraklatma kurallarını izleyip izlemediğini doğrulayın.
Çalışma takvimleri farklı bir sorunu çözer. Kapalı saatleri hedefin kendisinden çıkarırken duraklatma durumları zamanı biletin durumuna göre hariç tutar. Her ikisini de yapılandırın ve test edin. Hafta sonu, çalışma saatlerine dayalı bir hedefin süresini tüketmemeli; müşteri bekleyen hafta içi bileti de ekip açıkken duraklatılmış olarak kalmalıdır.
Otomasyona Güvenmeden Önce Test Etme ve Ayarlama
Tüm yaşam döngüsünü test etmek için kontrollü biletler kullanın. Geçmiş veriler gerçekçi hedefleri belirlemeye yardımcı olabilir; ancak bildirimlerin iletilmesini ve son tarih değişikliklerini doğrulamak için canlı durum testi daha iyidir.
- Her politikayı kapsayın. Farklı bir SLA politikası seçebilecek her grup ve öncelik birleşimi için bir test bileti oluşturun.
- Kısa geçici hedefler kullanın. Saatlerce veya günlerce beklemeden yaklaşan son tarih ve ihlal durumlarını doğrulayın, ardından gerçek değerleri geri yükleyin.
- Duraklatma durumlarını uygulayın. Çözüm saatini duraklatıp yeniden başlatın ve son tarihin beklendiği gibi değiştiğini doğrulayın.
- Alıcıları kontrol edin. Her bildirimin doğru kişilere ulaşması için atanmış ve atanmamış bir bileti test edin.
- Kaydı inceleyin. Biletin hangi politikanın uygulandığını ve her saatin ne zaman karşılandığını veya kaçırıldığını gösterdiğini doğrulayın.
Yayına aldıktan sonra hatalı uyarıları ve kaçırılan devirleri inceleyin. Uyarılar doğru olduğu hâlde göz ardı ediliyorsa sorun eşik zamanlamasından çok sahiplik veya personel yetersizliği olabilir.
Deskhero Bu Otomasyonları Sizin İçin Nasıl Yönetiyor?
Deskhero özel SLA politikalarına sahiptir. Bunlar, zamanlanmış veya zamana dayalı olmayan genel otomasyon kurallarından ayrıdır.
- Sahipler ve yöneticiler, bilet grupları ve öncelikleriyle eşleşen SLA politikalarını sıralayabilir. İlk eşleşen politika, ilk yanıt ve çözüm hedeflerini belirler.
- Her politika, kendi saat dilimine sahip adlandırılmış bir haftalık çalışma takvimini kullanabilir veya takvim zamanını sayabilir.
- Çözüm saati, çalışma alanında seçilen durumlarda duraklatılır. İlk yanıt saati duraklatılmaz.
- Deskhero, bir bileti bir sonraki son tarihinden önceki son 60 dakika içinde risk altında olarak işaretler ve son tarih geçtikten sonra ihlal edildiğini belirtir.
- Arka plan kontrolü her beş dakikada bir çalışır ve atanan kişiye uygulama içi bildirimlerin yanı sıra e-posta özeti gönderir; bilet atanmamışsa bildirim grup üyelerine gider. Kullanıcılar SLA bildirim kanallarını gruba göre kontrol edebilir.
Bilet listesinde bir SLA sütunu ve SLA filtreleri bulunur; pano risk altındaki ve ihlal edilmiş biletleri öne çıkarır; bilet zaman çizelgesi politika ve saat olaylarını kaydeder. İstatistikler, iş akışı yayına alındıktan sonra SLA karşılama görünümleri sunar.
Uyarılarınız Yayına Alındıktan Sonra Neleri İzlemelisiniz?
İlk soru, hatırlatıcıların ihlalleri önleyip önlemediğidir. Risk altındaki biletleri daha sonra hedefi kaçıran bilet sayısıyla karşılaştırın, ardından uyarıların kurtaramadığı durumları araştırın.
İlk yanıt karşılanma oranını ve çözüm karşılanma oranını ayrı ayrı izleyin. Ayrıca uyarı aralığı içinde son tarihi gelen biletlerin sayısını, hâlihazırda ihlal edilmiş biletlerin sayısını ve en fazla kaçırmaya yol açan politikaları veya grup-öncelik birleşimlerini inceleyin.
Yüzdeleri operasyonel bağlamla birlikte değerlendirin. Yüksek bir genel oran, sürekli ihlal yaşayan tek bir kuyruğu gizleyebilir. Ani bir düşüş, daha yavaş çalışmadan ziyade değişen bir çalışma takvimini, yeni eklenen bir önceliği veya sahiplik açığını yansıtabilir.
Uyarı Çakışmaları Olmadan Örtüşen SLA'ları Yönetme
Bir biletin hem ilk yanıt hedefi hem de çözüm hedefi olabilir. Yanıt yalnızca ilk hedefi tamamladığı için bunları ayrı saatler olarak ele alın. Çözüm hedefi, bilet onu karşılayan olaya ulaşana kadar devam eder.
Bilet arayüzü, her iki hedefin ayrıntılarını korurken sıradaki açık son tarihin hangisi olduğunu göstermelidir. Filtreler ve raporlama da ilk yanıtı çözümden ayırmalıdır; böylece birindeki sağlıklı ölçüm diğerindeki sorunu gizlemez.
Müşterilerin farklı taahhütleri olduğunda grup ve öncelik gibi sabit bilet alanlarıyla eşleşen ayrı politikalar kullanın. Özel politikaları genel politikanın önüne yerleştirin, ardından bir bileti anlamlı her birleşimle test edin. Kullanıcıların bilet üzerinde göremeyeceği veya doğrulayamayacağı gizli sözleşme katmanları icat etmekten kaçının.
SLA'lar Otomatik Pilotta Çalışırken Denetime Hazır Kalma
Hangi politikanın uygulandığını, hesaplanan son tarihleri ve her saatin ne zaman karşılandığını veya kaçırıldığını kaydedin. Bir grup, öncelik veya takvim değişikliği son tarihin yeniden hesaplanmasına neden oluyorsa bu değişiklik de izlenebilir olmalıdır.
Politika değişikliklerini bildirim gelen kutusunun dışında belgeleyin. Değişikliği kimin onayladığını, ne zaman yürürlüğe girdiğini ve mevcut biletlere uygulanıp uygulanmadığını kaydedin. Bu, sonraki müşteri sorularını yanıtlamayı kolaylaştırır ve bir SLA raporunun anlamında sessiz değişiklikler yapılmasını önler.
Sözleşmeye dayalı incelemelerde, görünen her olayın bir denetim günlüğü olduğunu varsaymak yerine platformun davranışını doğrulayın. Deskhero'nun bilet zaman çizelgesi SLA politikası uygulamasını ve saat sonuçlarını kaydeder; İstatistikler alanı ise karşılanma oranlarını raporlar. Resmî saklama gereksinimleri olan kuruluşlar, bu kayıtların kendi yükümlülüklerini karşılayıp karşılamadığını doğrulamalıdır.
Kullanıcılar, Yöneticiler ve Müşteriler İçin SLA Mesajları Yazma
Dâhilî uyarılar ve müşteri güncellemeleri farklı amaçlara hizmet eder. Her birini, okuyucusunun bundan sonra ne yapabileceğine odaklayın.
Kullanıcıya yönelik uyarılar, bilet bağlantısı, hedef türü, son tarih ve acil eylemle başlamalıdır. Kullanıcının bileti ele alması gerekirken politika geçmişini anlatan bir paragraftan kaçının.
Yöneticiye yönelik incelemeler, bir grup, öncelik veya politika genelindeki eğilimleri göstermelidir. Tek bir kaçırılmış bilet eylem gerektirirken tekrarlanan kaçırmalar personel veya süreç kararı gerektirir.
Müşteriye yönelik iletişim doğru ve özgül olmalıdır. Ekip bir gecikme bekliyorsa, insan tarafından incelenmiş bir güncelleme gerçekçi bir sonraki iletişim zamanını belirleyebilir. Dâhilî uyarı etiketlerini göstermeyin veya ekibin destekleyemeyeceği bir çözüm süresi vaat etmeyin.
SLA Otomasyonunu Zaten Kullandığınız Araçlara Bağlama
Gerekli politikaları, takvimleri, duraklatma durumlarını, uyarıları, filtreleri ve raporlamayı kapsıyorsa yerel SLA işlevleriyle başlayın. Yerel son tarihler, paralel bir elektronik tablodan genellikle bilet değişiklikleriyle daha güvenilir biçimde uyumlu kalır.
Yerel destek sınırlı olduğunda ekipler topluluk eklentilerinden ve forumlarda belgelenmiş geçici çözümlerden yararlanmıştır. Bu yaklaşıma güvenmeden önce bakım durumunu ve sürüm uyumluluğunu inceleyin.
Birkaç sistemin tek bir eskalasyon kanalını beslemesi gerektiğinde ayrı bir iş akışı uygun olabilir. Önce gerçeğin kaynağını tanımlayın. Yardım masasında ve entegrasyon katmanında yinelenen SLA hesaplamaları, özellikle saat dilimleri, çalışma saatleri, duraklatma durumları ve yeniden atama konularında zamanla farklılaşabilir.
Editörün Görüşü: Önemli Olan Uyarı Değil, Eylemdir
Yaklaşan son tarih bildirimi yalnızca sahiplik net olduğunda işe yarar. Alıcının bileti ilerletebilmesi için izne, bağlama ve zamana ihtiyacı vardır.
Öncelik saat doğruluğudur. Yanlış bir çalışma takvimi veya duraklatma yapılandırması, güven veren ancak yanıltıcı uyarılar üretir. Mesaj metnini değiştirmeden veya yeni kanallar eklemeden önce son tarih hesaplamasını düzeltin.
Şu sırayla oluşturun: politika hedefleri, çalışma takvimleri, duraklatma davranışı, bildirim alıcıları, operasyonel yanıt ve raporlama. Bu sıra, hatırlatıcıyı herkesin anladığı bir son tarihe bağlı tutar.
Bir Taşıma Projesi Olmadan SLA Hatırlatıcılarınızı Çalıştırın
Deskhero, iki yönlü senkronizasyonla Gmail veya Microsoft 365'e bağlanır. Böylece ekipler, paylaşılan bilet yönetimi ve SLA politikaları eklerken mevcut destek adreslerini koruyabilir.

İlk yanıt ve çözüm hedeflerini grup ve önceliğe göre yapılandırın, gerektiğinde haftalık çalışma takvimi ekleyin ve çözümü hangi durumların duraklatacağını seçin. Deskhero daha sonra bir sonraki son tarihi görüntüler, bir saat içinde süresi dolacak biletleri öne çıkarır, sorumlu Kullanıcılara bildirim gönderir ve SLA sonuçlarını kaydeder.
30 günlük ücretsiz deneme için kredi kartı gerekmez. Bir posta kutusu bağlayın, küçük bir politika kümesi yapılandırın ve kurulumu daha fazla gruba genişletmeden önce SLA yaşam döngüsünün tamamını test edin.
Kaynaklar
- Jira Service Management Cloud'da takipleri otomatikleştirin | Atlassian Desteği
- Kod Yazmadan SLA İhlal Uyarıları Oluşturun | LOW/CODE
SSS
SLA, SLO ve SLI Arasındaki Fark Nedir?
SLA, taraflar arasındaki bir hizmet taahhüdüdür. SLO, bir hizmetin performansına yönelik bir hedeftir ve genellikle bu taahhüt kapsamında kalmak için dâhilî olarak kullanılır. SLI ise hedefi değerlendirmek için kullanılan ölçülmüş değerdir.
SLA İhlal Uyarısı Olarak Ne Kabul Edilir?
İhlal uyarısı, açık bir ilk yanıt veya çözüm son tarihinin geçtiğini belirtir. Yaklaşan son tarih uyarısı farklıdır; çünkü ekibin hedefi karşılamak için hâlâ zamanı vardır.
4 Saatlik SLA Ne Anlama Gelir?
Bu, ilk yanıt veya çözüm gibi politikanın belirttiği eylemin, söz konusu politika tarafından hesaplandığı üzere dört saat içinde tamamlanması gerektiği anlamına gelir. Saat, takvim zamanını veya çalışma takvimini kullanabilir.
SLA, KPI'dan Nasıl Farklıdır?
SLA bir hizmet taahhüdünü ifade eder. KPI performansı ölçer ve sözleşmeye dayalı son tarihler olmayan birçok hedefi izlemek için kullanılabilir.
Deskhero Özel Kod Olmadan SLA Hatırlatıcılarını Otomatikleştirebilir mi?
Evet. Deskhero'da yerleşik SLA politikaları, sabit bir yaklaşan son tarih uyarı aralığı, ihlal algılama, uygulama içi ve e-posta bildirimleri, bilet filtreleri, pano görünümleri ve SLA raporlaması bulunur. Bu işlevler genel otomasyon kurallarından ayrıdır.