Kısa cevap: bekleme etiketi değil, onaylı kural belirler
Bir talebin beklemeye alınması süreyi kendiliğinden durdurmamalıdır. Hangi bekleme nedeninin hangi hedefi durduracağı hizmet politikasında açıkça tanımlanmalıdır. Müşteriden bilgi beklemek, iç ekip ataması beklemek ve dış tedarikçiden yanıt beklemek farklı durumlardır. Hepsini tek bir bekleme alanında toplamak hesabı açıklamayı zorlaştırır. İlk yanıt ve çözüm hedeflerinin aynı bekleme davranışına sahip olması da zorunlu değildir.
İlk yanıt ile çözüm süresi neden ayrı tutulur?
İlk yanıt, talebin ele alınması konusunda kullanıcıya verilen karşılığı; çözüm süresi ise hizmet ihtiyacının sonuçlandırılmasını izler. Hızlı bir yanıt verilmesi sorunun çözüldüğünü göstermez. Otomatik alındı mesajının ilk yanıt sayılıp sayılmayacağı bile politika içinde belirlenmelidir. Bu ayrım yapılmazsa, iyi görünen bir yanıt göstergesi uzun çözüm beklemelerini gizleyebilir. İki hedefi aynı raporda ama ayrı anlamlarıyla değerlendirmek daha açıklayıcıdır.
Mesai dışı açılan talepte saat ne zaman başlar?
Başlangıç olayı ile takvime dahil edilen zaman farklı konulardır. Talep mesai dışında kaydedilebilir; süre hesabı ise tanımlanan hizmet takvimine göre ilerler. Takvimde çalışma günleri, saat aralıkları, tatiller ve saat dilimi belirtilmelidir. Farklı bölgelerde çalışan ekipler için bu bilgiler özellikle önemlidir. Talebin açılış zamanını değiştirmek yerine hangi zaman dilimlerinin hesaba katıldığını açık biçimde kaydetmek gerekir.
Basit bir çalışma saati örneği nasıl görünür?
Örnek bir politikada çalışma saatleri hafta içi 09.00–18.00, ilk yanıt hedefi iki çalışma saati olsun. Cuma 17.00’de açılan talep için aynı gün bir saat sayılır; araya tatil girmiyorsa kalan bir saat pazartesi 09.00’dan itibaren ilerler ve hedef 10.00 olur. Bu yalnızca belirtilen varsayımların örneğidir. Kesintisiz hizmet takvimi veya farklı bir tatil tanımı aynı talep için farklı sonuç üretir.
Politika değişince eski ihlaller yeniden hesaplanmalı mı?
Yeni bir hedef tanımlamak geçmişteki taahhüdü otomatik olarak değiştirmez. Her talebin hangi politika ve takvim sürümüyle değerlendirildiği korunmalıdır. Hatalı veri için düzeltme gerekiyorsa bunun gerekçesi ve etkisi ayrıca izlenmelidir. Aksi halde rapor dönemleri arasında karşılaştırma yapmak zorlaşır; aynı kayıt bir ay ihlal, sonraki ay başarılı görünebilir. Ölçüm geçmişini açıklanabilir tutmak, yalnızca güncel hedefi göstermekten daha değerlidir.
Argamos SLA yönetimi bu ayrımları nasıl korur?
Argamos, ilk yanıt ve çözüm sürelerini ayrı takip eder; çalışma takvimi, bekleme nedenleri ve sürümlü SLA politikalarını kayıt bağlamına taşır. Müşteri desteğinde ürün ve destek hakkı ilgili hizmet seviyesine bağlanır. Kurum içi taleplerde iç destek politikası kullanılır. Böylece teknik destek ekibi bir sonucu incelerken yalnızca geçen süreyi değil, o süreyi anlamlandıran kapsamı ve kuralı da görebilir.
SLA raporunu okurken hangi sorular sorulmalı?
Hangi hedefin ölçüldüğünü, takvimin ne olduğunu, beklemelerin nasıl sayıldığını ve yeniden açılmanın nasıl ele alındığını sorun. İhlal oranını tek başına değerlendirmek yerine talep türü, veri kapsamı ve politika sürümünü inceleyin. Sürekli beklemeye taşınan kayıtlar süreç sorununa işaret edebilir. Amaç raporu yeşile çevirmek değil, hizmet taahhüdünün nerede ve neden karşılanamadığını anlaşılır hale getirerek iyileştirme yapmaktır.