Deskhero
Türkçe
Ücretsiz deneyin

← Back to articles

Destek Yöneticileri İçin Temel Yardım Masası Raporlama Metrikleri

Destek Yöneticileri İçin Temel Yardım Masası Raporlama Metrikleri

En kullanışlı yardım masası raporları talebi, hızı, kaliteyi ve güvenilirliği bir arada ele alır. Talep hacmi, ilk yanıt süresi, çözüm süresi, ilk temasta çözüm, SLA karşılama oranı, birikmiş iş yaşı, yeniden açılma oranı, eskalasyon oranı, Kullanıcı bazında iş yükü, kanal dağılımı ve bilet başına maliyet ile başlayın. Müşteri memnuniyeti metriklerini yalnızca güvenilir bir anket süreciniz ve sonuçları sorumlu bir şekilde yorumlamaya yetecek kadar yanıtınız olduğunda ekleyin.

Pratik bir raporlama sıklığı şöyle görünebilir:

  • Bilet hacmi: günlük anlık görünüm ve haftalık eğilim
  • İlk yanıt süresi: günlük eğilim ve uygun olduğunda canlı SLA izleme
  • Çözüm süresi: günlük eğilim ve haftalık inceleme
  • İlk temasta çözüm: haftalık
  • SLA karşılama oranı: günlük operasyonel görünüm ve haftalık özet
  • Birikmiş iş yaşı: günlük
  • Yeniden açılma ve eskalasyon oranları: haftalık
  • Kullanıcı bazında iş yükü: kuyruk dengeleme amacıyla günlük
  • Kanal dağılımı: haftalık
  • Bilet başına maliyet: aylık

Her şeyi izleyerek başlamayın. Küçük bir puan kartı seçin, temel zaman damgalarının ve alanların güvenilir olduğunu doğrulayın ve ayrıntıları yalnızca birinin karar vermesine yardımcı olduğu ölçüde ekleyin.

Önemli Çıkarımlar

Güvenilir yardım masası raporlaması; temiz olay verileri, net biçimde tanımlanmış formüller ve sonunda bir sorumlu ile eylem belirlenen bir inceleme süreciyle başlar.

Nokta Ayrıntılar
Metrikleri KPI’lardan ayırın Metrik, etkinliği açıklar. KPI ise hedefi, hesap verebilir bir sorumlusu ve kendisine bağlı bir kararı olan metriktir.
Yalnızca ortalamaları değil, dağılımları kullanın Az sayıdaki yavaş biletin tipik deneyimi gizleyememesi için ortalamaları medyanlar, yüzdelik dilimler veya zaman aralıklarıyla birlikte değerlendirin.
Karşılaştırma ölçütlerinin bağlama ihtiyacı vardır Hedef belirlemeden önce kendi temel verilerinizi, kanal dağılımınızı, bilet karmaşıklığını, personel durumunu ve hizmet taahhütlerinizi kullanın.
Öncelik veri kalitesindedir Bir puanı yayımlamadan önce her sayacın hangi olayla başladığını, durakladığını ve tamamlandığını tanımlayın.
Deskhero sabit raporlama görünümleri içerir Deskhero; operasyonel bir Dashboard ve dokuz sabit sekmeden, filtrelerden, grafik ve tablo görünümlerinden ve sekmelerin çoğunda Excel dışa aktarımından oluşan bir Statistics alanı sunar.

İçindekiler

Yardım masası metriği ile KPI arasındaki fark nedir?

Metrik; oluşturulan biletler, medyan ilk yanıt süresi veya açık bilet sayısı gibi ölçülen herhangi bir değerdir. KPI, önemli bir sonucu temsil etmek üzere seçilen metriktir. Bir tanımı, hedefi ya da kabul edilebilir aralığı, sorumlusu ve performans bu aralığın dışına çıktığında uygulanacak bir karşılığı vardır.

Bilet hacmi genellikle tanılayıcı bir metriktir. Talebi açıklar ancak ekibin iyi performans gösterip göstermediğini söylemez. İlk yanıt SLA karşılama oranı, belirlenmiş bir taahhüde göre performansı ölçtüğü için KPI olabilir. Bununla birlikte kalite ve iş yükü verileriyle birlikte değerlendirilmelidir.

Yararlı bir ayrım şöyledir:

  • Tanılayıcı metrikler: bilet hacmi, kanal dağılımı, öncelik dağılımı, kategori dağılımı ve birikmiş işin yapısı
  • Olası KPI’lar: ilk yanıt süresi, çözüm süresi, SLA karşılama oranı, ilk temasta çözüm, yeniden açılma oranı ve müşteri memnuniyeti

Sınıflandırma, kuruluşun neyi iyileştirmeye çalıştığına bağlıdır. Bir maliyet metriği bir destek operasyonu için merkezi öneme sahipken başka bir operasyon için ilgisiz olabilir. Her KPI’ın yanına amaçlanan kararı yazın. Hiç kimse bir değişikliğin hangi eylemi tetiklemesi gerektiğini açıklayamıyorsa bu metrik muhtemelen tanılayıcı görünümde yer almalıdır.

Uzman İpucu: Her KPI’ı tek cümlede belgeleyin: formül, kapsam, zaman aralığı, hariç tutulanlar, sorumlu ve hedef. Bu, iki ekibin aynı etiketi farklı hesaplamalar için kullanmasını önler.

Amaca göre gruplandırılmış temel yardım masası raporlama metrikleri

Metrikleri yanıtladıkları soruya göre gruplandırın. Talep metrikleri kuyruğa neyin girdiğini açıklar. Verimlilik metrikleri işin nasıl ilerlediğini gösterir. Deneyim metrikleri müşteri geri bildirimini yansıtır. Güvenilirlik metrikleri taahhütlerin yerine getirilip getirilmediğini gösterir. Finansal metrikler destek faaliyetlerini maliyetle ilişkilendirir.

Amaca göre kategorilere ayrılmış yardım masası metriklerini gösteren diyagram

Verimlilik metrikleri

Bilet hacmi
Tanım: Bir raporlama döneminde oluşturulan biletler.
Formül: Seçilen dönem içindeki oluşturulma zaman damgasına göre biletleri sayın.
Kullanım: Hacmi gün, kanal, grup, öncelik ve kategori bazında karşılaştırın. Personel sayısını değiştirmeden önce ani artışları araştırın.

Çözülen bilet hacmi
Tanım: Dönem içinde çözülen biletler.
Kullanım: Aynı zaman aralığında oluşturulan ve çözülen bilet hacmini karşılaştırın. Oluşturulan bilet hacmi tekrar tekrar çözülen hacmi aşıyorsa birikmiş işin büyümesi olasıdır.

Kullanıcı bazında iş yükü
Tanım: Sorunuza bağlı olarak her Kullanıcıya atanan, her Kullanıcı tarafından üzerinde işlem yapılan veya çözülen biletler.
Kullanım: Kuyrukları dengeleyin ve iş yoğunlaşmasını belirleyin. Karmaşıklığı, uygunluğu ve kaliteyi hesaba katmadan tek bir iş yükü sayısını performans sıralamasına dönüştürmeyin.

Kanal kırılımı
Tanım: Her kanal üzerinden oluşturulan biletlerin payı.
Formül: Bir kanaldan gelen biletlerin dönem içindeki tüm biletlere bölünmesi.
Kullanım: Personel ve hizmet hedeflerini gerçek talebe göre uyarlayın.

Verimlilik metrikleri

İlk yanıt süresi
Tanım: Raporlama politikanıza göre biletin oluşturulmasından nitelikli ilk insan veya otomatik yanıta kadar geçen süre.
Kullanım: Medyanı, 90. yüzdelik dilimi ve zaman aralıklarını raporlayın. Sayacın takvim zamanını mı yoksa çalışma saatlerini mi kullandığını ve otomatik alındı yanıtlarının sayılıp sayılmadığını belirtin.

Yanıt süresi kontrol kadranını ayarlayan eller

Çözüm süresi
Tanım: Biletin oluşturulmasından çözüme kadar geçen süre.
Kullanım: Grup, öncelik, kategori ve eskalasyon durumuna göre segmentlere ayırın. Müşteri beklenirken sayacın durakladığı durumlarda bu kuralı belgeleyin.

İlk temasta çözüm
Tanım: Uygun biletlerin, daha sonra takip veya seçilen gözlem penceresi içinde yeniden açılma olmadan ilk destek etkileşimi sırasında çözülen payı.
Kullanım: Dönemleri karşılaştırmadan önce gözlem penceresini ve uygun kanalları tanımlayın. Basit bir yeniden açılmama işareti, ilk temasta çözümü belirlemek için her zaman yeterli değildir.

Çözüm için gereken yanıtlar
Tanım: Çözümden önce karşılıklı gönderilen yanıtların sayısı.
Kullanım: Önlenebilir yazışma trafiği oluşturan kategorileri belirleyin. Düşük sayı yalnızca sorun gerçekten çözüldüğünde anlamlıdır.

Müşteri deneyimi metrikleri

Müşteri memnuniyeti
Tanım: Tanımlanmış bir etkileşim sonrası anketine verilen yanıtların payı veya ortalaması.
Kullanım: Puanla birlikte yanıt sayısını ve yanıt oranını her zaman raporlayın. Özellikle örneklem boyutu küçük olduğunda yazılı yorumları inceleyin ve dikkatli segmentasyon yapın.

Net Tavsiye Skoru
Tanım: Tanımlanmış bir tavsiye anketindeki destekçilerin yüzdesinden kötüleyenlerin yüzdesinin çıkarılması.
Kullanım: Bunu bilet düzeyindeki memnuniyetin doğrudan alternatifi olarak değil, daha geniş bir ilişki ölçüsü olarak değerlendirin.

Yeniden açılma oranı
Tanım: Tanımlanmış bir süre içinde yeniden açılan çözümlenmiş biletlerin, uygun çözümlenmiş biletlere bölünmesi.
Kullanım: Oran değiştiğinde kategorileri, Kullanıcıları ve kapatma uygulamalarını inceleyin. Yeniden açılma, çözümün eksik kaldığını gösterebilir; ancak müşterinin eski bir yazışmaya yeni bir sorun eklemesini de yansıtabilir.

Güvenilirlik ve SLA metrikleri

SLA karşılama oranı
Tanım: Uygulanabilir hedefi karşılayan tamamlanmış yanıt veya çözüm sayaçlarının, raporlama kapsamındaki tamamlanmış sayaçlara bölünmesi.
Kullanım: Karşılama oranını, hâlihazırda risk altında veya ihlal edilmiş biletlerin canlı sayısından ayrı tutun. İlki geçmişe dönük bir değerlendirme, ikincisi ise operasyonel bir anlık görünümdür.

Birikmiş iş yaşı
Tanım: Açık biletlerin yaş dağılımı.
Kullanım: Yaş aralıklarını ve en eski biletleri gösterin. Tek bir evrensel sınır uygulamak yerine hizmet taahhütlerinizle uyumlu eşikler seçin.

Eskale edilme oranı
Tanım: Başka bir gruba veya uzmana eskale edilen biletlerin uygun biletlere bölünmesi.
Kullanım: Kategori ve önceliğe göre segmentlere ayırın. Eskalasyon bir bilgi açığına işaret edebilir; ancak karmaşık işler için doğru yol da olabilir.

Finansal metrikler

Bilet başına maliyet
Tanım: Bir dönem için tahsis edilen destek maliyetlerinin, o dönemde ele alınan uygun biletlere bölünmesi.
Kullanım: Hangi maaşların, yazılımların, yüklenicilerin ve genel giderlerin dahil edildiğini belgeleyin. Benzer dönemleri ve benzer bilet kitlelerini karşılaştırın.

Kanal veya kategori bazında maliyet
Tanım: Bir kanal veya kategori için tahsis edilen maliyetin, o kanal ya da kategorideki uygun bilet hacmine bölünmesi.
Kullanım: Bunu yalnızca zaman ve maliyet tahsisi hesaplamayı destekleyecek kadar sağlamsa kullanın. Yanlış kesinlik, alanı boş bırakmaktan daha kötüdür.

Ekibiniz için gerçekçi hedefler ve karşılaştırma ölçütleri nasıl belirlenir?

Evrensel yardım masası karşılaştırma ölçütleri nadiren gerçekten evrenseldir. Bir hedef; kanala, çalışma saatlerine, bilet karmaşıklığına, önceliğe, personel durumuna ve müşterilere verilen söze bağlıdır. Öncelikle hedefleri kendi operasyonunuzdan türetin.

  1. Metrikleri tanımlayın. Başlangıç olayını, bitiş olayını, duraklamaları, hariç tutulanları ve uygun kitleyi yazın.
  2. Temel veri oluşturun. Normal değişkenliği kapsayacak kadar geçmiş veri kullanın. Yalnızca ortalamaları değil, medyan ve yüzdelik değerleri karşılaştırın.
  3. Temel veriyi segmentlere ayırın. İş akışları farklı olduğunda kanalları, öncelikleri, grupları ve başlıca bilet kategorilerini ayırın.
  4. Hedefi bir taahhütle ilişkilendirin. SLA hedefleri hizmet vaadiyle eşleşmelidir. İç iyileştirme hedefleri zorlayıcı ancak operasyonel açıdan uygulanabilir olmalıdır.
  5. Süreç değişikliklerinden sonra hedefi gözden geçirin. Yeni yönlendirme, personel, otomasyon veya ürün sürümleri temel veriyi değiştirebilir.
Metrik Hedef yaklaşımı Önerilen sıklık
İlk yanıt süresi Kanala, önceliğe ve hizmet taahhüdüne göre belirleyin Günlük
Çözüm süresi Öncelik ve bilet kategorisine göre belirleyin Günlük ve haftalık
İlk temasta çözüm Kategori bazında temel veri oluşturun ve bir gözlem penceresi tanımlayın Haftalık
Müşteri memnuniyeti Yalnızca yanıt hacmi ve yanlılık anlaşıldıktan sonra belirleyin Haftalık veya aylık
SLA karşılama oranı Yayımlanan veya sözleşmeyle belirlenen taahhütle eşleştirin Günlük ve haftalık
Birikmiş iş yaşı Öncelik ve hizmet politikasına bağlı eşikler kullanın Günlük
Yeniden açılma oranı Kategori ve kapatma politikasına göre temel veri oluşturun Haftalık
Bilet başına maliyet Tutarlı biçimde tanımlanmış bir iç eğilimi izleyin Aylık

Örneklemi küçük veya günlük değişkenliği yüksek metriklerde hareketli zaman aralıkları kullanın. Operasyonel değişiklikleri belirlemeniz gerektiğinde dönem karşılaştırmalarından yararlanın. Her iki durumda da okuyucuların sonucun ne kadar istikrarlı olduğunu değerlendirebilmesi için uygun bilet sayısını gösterin.

Her hedef kitlenin gerçekten kullanacağı dashboard’lar nasıl tasarlanır?

Bir dashboard, her kart hedef kitlesi için bir soruyu yanıtladığında işe yarar. Operasyonel görünümler insanların hemen harekete geçmesine yardımcı olmalıdır. Yönetim görünümleri eğilimleri ve istisnaları açıklamalıdır. Yönetici görünümleri destek sonuçlarını hizmet, risk ve maliyetle ilişkilendirmelidir.

Hedef kitle-metrik eşlemesi

Kullanıcılar; açık işlerini, ilk yanıt bekleyen biletlerini, süresi yaklaşan veya ihlal edilmiş SLA sayaçlarını ve sıradaki bileti seçmeye yetecek kuyruk bağlamını görmeye ihtiyaç duyar.

Çalışma alanı öğelerini ve zamanlayıcıyı yöneten eller

Ekip liderleri; oluşturulan ve çözülen bilet hacmini, birikmiş iş yaşını, yanıt süresi dağılımını, SLA riskini ve Kullanıcı bazında iş yükünü görmeye ihtiyaç duyar. Ayrıca bir sayının arkasındaki biletlere ulaşmak için ayrıntılı inceleme bağlantılarına ihtiyaçları vardır.

Destek yöneticileri; grup, öncelik, kanal ve kategori bazındaki eğilimlere ve her KPI için net tanımlara ihtiyaç duyar. Üst düzey puan kartı, değişikliği açıklayan bir tabloya veya grafiğe yönlendirmelidir.

Yöneticiler genellikle az sayıda hizmet, kalite, risk ve maliyet göstergesine ihtiyaç duyar. Hedefi, mevcut değeri, yönü ve önemli değişikliklerin kısa bir açıklamasını gösterin.

  • Oluşturulan ve çözülen biletler: aynı aralığı kullanan eğilim çizgileri
  • İlk yanıt dağılımı: medyan, 90. yüzdelik dilim ve zaman aralıkları
  • Çözüm eğilimi: önceliğe veya kategoriye göre segmentlere ayrılmış
  • Şu anda SLA: hâlihazırda ihlal edilmiş, süresi yaklaşan ve duraklatılmış sayaçlar
  • SLA karşılama oranı: seçilen dönem için hedeflerini karşılayan tamamlanmış sayaçlar
  • Yaşa göre birikmiş iş: kullanışlı yaş aralıklarındaki açık bilet sayıları
  • İş yükü tablosu: ilgili bağlamla grup ve Kullanıcı bazında etkinlik
  • Kanal ve konu kırılımları: talep dağılımı ve yinelenen temalar

Raporlama sıklığı

  • Canlı operasyonel görünüm: açık biletler, ilk yanıt bekleyenler ve mevcut SLA riski
  • Günlük inceleme: hacim, birikmiş iş yaşı, ilk yanıt, çözüm süresi ve ihlaller
  • Haftalık inceleme: eğilimler, istisnalar, yeniden açılma oranı, eskalasyon oranı ve iyileştirme eylemleri
  • Aylık inceleme: hizmet sonuçları, maliyet, kapasite ve hedef değişiklikleri

Her toplantıyı kararlara bağlayın. Haftalık inceleme, adı belirlenmiş bir sorumlu, son tarih ve değişikliğin işe yarayıp yaramadığını gösterecek metrikle sona ermelidir.

Raporlamadan önce verilerinizi doğru hâle getirme

Metrikler yalnızca olay tanımları kadar güvenilirdir. Bir dashboard oluşturmadan önce bilet sisteminin oluşturma, yanıt, durum, atama ve çözüm olaylarını tutarlı biçimde kaydettiğini doğrulayın.

Asgari bilet şeması

Bir raporlama dışa aktarımı genellikle şu alanlara ihtiyaç duyar:

  • ticket_id: değişmeyen bilet tanımlayıcısı
  • created_at: bilet oluşturma zaman damgası
  • first_qualifying_response_at: ilk yanıt tanımında kullanılan zaman damgası
  • resolved_at: çözüm zaman damgası
  • assignee_id: mevcut veya olay anındaki sorumlu; açıkça etiketlenmelidir
  • group_id: sorumlu grup
  • channel: kaynak kanal
  • priority: kontrollü öncelik değeri
  • status: kontrollü durum değeri
  • tags: mümkün olduğunda kontrollü kategoriler
  • sla_policy_id: mevcut olduğunda uygulanabilir politika
  • reopened_count: yeniden açılma olaylarının sayısı

Her platform aynı şemayı sunmaz. Bunları kesin alan adlarına ilişkin bir iddia olarak değil, raporlama kavramları olarak değerlendirin. Bir değer değişebiliyorsa raporun mevcut değere mi yoksa olay anındaki değere mi ihtiyaç duyduğuna karar verin.

Etiketleme ve taksonomi

Personel planlamasını, yönlendirmeyi veya iyileştirme çalışmalarını etkileyen kategoriler için kontrollü bir taksonomi kullanın. Listeyi tutarlı biçimde kullanılabilecek kadar küçük tutun. Kategori eğilimlerine güvenmeden önce kategorilendirilmemiş biletleri ve neredeyse aynı etiketleri denetleyin.

Otomasyon alanların atanmasına yardımcı olabilir; ancak otomatik sınıflandırmanın da incelenmesi gerekir. Her bileti yanıltıcı bir kategoriye zorlamak yerine bilinmeyen veya düşük güvenilirlikli sonuçları izleyin.

Enstrümantasyon kontrol listesi

  • [ ] Tüm zaman damgaları tek bir kayıtlı zaman standardını ve belgelenmiş bir görüntüleme saat dilimini kullanıyor
  • [ ] İlk yanıt tanımı otomatik yanıtların sayılıp sayılmadığını belirtiyor
  • [ ] Çalışma saati ve takvim saati sayaçları birbirine karıştırılmıyor
  • [ ] Çözüm sayaçları için duraklatılan durumlar belgeleniyor
  • [ ] Yeniden açılma ve eskalasyon olaylarının açık tanımları var
  • [ ] Mevcut sorumlu, çözüm anındaki sorumluyla karıştırılmıyor
  • [ ] Silinen, birleştirilen, spam, test ve içe aktarılan biletler için belirlenmiş bir dahil etme politikası var
  • [ ] Her puan, uygun bilet sayısını gösteriyor

Uzman İpucu: Küçük bir örneklemi elle yeniden hesaplayın. Dashboard sonucu bilet olaylarından yeniden üretilemiyorsa hedef belirlemeden önce tanımı veya veriyi düzeltin.

Metriklerinizi yanıltıcı hâle getiren raporlama tuzakları

  • Bilet sayısını performans olarak değerlendirmek. Hacim talebi ölçer. Performans hakkında sonuç çıkarmadan önce bunu birikmiş iş, hız ve kaliteyle birlikte değerlendirin.

  • Dağılım olmadan ortalama raporlamak. Ortalamalar uzun beklemeleri gizleyebilir. Medyan, yüzdelik dilim veya zaman aralığı görünümü ekleyin.

  • Kullanıcıları yalnızca kapatılan bilet sayısına göre sıralamak. Bilet karmaşıklığı, çalışma saatleri, yeniden atama ve kalite sayıların tümünü etkiler. İş yükü tablolarını işi dengelemek için kullanın; bunları tek başına performans puanı olarak kullanmayın.

  • Benzer olmayan bilet kitlelerini karıştırmak. Farklı öncelikler, kanallar ve kategoriler çoğu zaman farklı hedefler gerektirir. Karşılaştırmadan önce segmentlere ayırın.

  • Canlı SLA durumunu geçmişe dönük karşılama oranıyla karıştırmak. Hâlihazırda ihlal edilmiş bir bilet operasyonel bir sorundur. Hedefini karşılayamayan tamamlanmış bir sayaç ise karşılama oranına aittir. Bu iki kitleyi birleştirmeyin.

  • Payda değişikliklerini görmezden gelmek. Bir yüzde, uygun kitlenin değişmesi nedeniyle hareket edebilir. Her zaman arkasındaki sayıyı gösterin.

  • Kesinlik uydurmak. Ele alma süresi, maliyet tahsisi veya anket kapsamı eksikse sınırlamayı belirtin ya da metriği kullanmayın.

Bugün kopyalayabileceğiniz, uygulamaya hazır dashboard şablonu

Aşağıdaki şablon platformdan bağımsızdır. Alan adlarını ve formülleri veri modelinize uyacak şekilde düzenleyin, ardından her düzenlemeyi belgeleyin.

Elektronik tablo şeması ve formüller

Sütun adı Formül veya kaynak Notlar
ticket_id Bilet sistemi Değişmeyen anahtar
created_at Bilet olayı Tek bir zaman standardında saklayın
first_response_at İlk nitelikli yanıt olayı Otomatik yanıtların nasıl ele alındığını belgeleyin
resolved_at Çözüm olayı Yeniden açılmaların nasıl ele alındığını belgeleyin
frt_minutes Oluşturma ile ilk yanıt arasındaki fark Takvim dakikası veya çalışma dakikası
resolution_minutes Oluşturma ile çözüm arasındaki fark Uygunsa belgelenen duraklamaları çıkarın
reopened_count Yeniden açılma olaylarının sayısı Bir gözlem penceresi seçin
sla_first_reply_met SLA sayacı sonucu Uygulanabilir tamamlanmış sayaç yoksa boş
sla_resolution_met SLA sayacı sonucu Uygulanabilir tamamlanmış sayaç yoksa boş
channel Bilet kaynağı Kontrollü değer
priority Bilet alanı Kontrollü değer
group_id Bilet alanı veya olay geçmişi Mevcut değer mi, olay anındaki değer mi olduğunu belirtin

Örnek SQL parçacıkları

MySQL’de takvim zamanına göre ilk yanıt:

SELECT ticket_id,
       TIMESTAMPDIFF(MINUTE, created_at, first_response_at) AS frt_minutes
FROM tickets
WHERE first_response_at IS NOT NULL;

Mevcut sorumluya ve güne göre oluşturulan biletler:

SELECT assignee_id,
       DATE(created_at) AS ticket_date,
       COUNT(*) AS tickets_created
FROM tickets
GROUP BY assignee_id, DATE(created_at)
ORDER BY ticket_date DESC, tickets_created DESC;

Tamamlanmış ilk yanıt SLA karşılama oranı:

SELECT
  AVG(CASE WHEN sla_first_reply_met = 1 THEN 1.0 ELSE 0.0 END) * 100 AS attainment_pct
FROM tickets
WHERE sla_first_reply_met IS NOT NULL
  AND created_at >= :period_start
  AND created_at < :period_end;

Bu örneklerde basitleştirilmiş alanlar ve takvim zamanı kullanılmıştır. Üretim raporlaması, kaynak sistemdeki uygunluk, çalışma saati, duraklama, birleştirme ve silme kurallarının aynısını uygulamalıdır.

Dashboard sekme düzeni

  1. Operasyon sekmesi: açık kuyruk, ilk yanıt bekleyenler, mevcut SLA riski ve en eski biletler
  2. Yönetim sekmesi: oluşturulan ve çözülen bilet eğilimi, yanıt dağılımı, çözüm eğilimi, SLA karşılama oranı, birikmiş iş yaşı ve iş yükü tabloları
  3. Yönetici sekmesi: hedefleri ve kısa açıklamalarıyla seçilmiş hizmet, kalite, risk ve maliyet KPI’ları

Uzman İpucu: Dashboard’un yanında bir metrik sözlüğü bulundurun. Geçmiş değişikliklerin açıklanabilir kalması için formül ve hedef değişikliklerini sürümleyin.

Raporlama gerçekte nerede karşılığını verir?

Raporlama; kuyruk yönetimini, personel planlamasını, yönlendirmeyi, dokümantasyonu veya ürün çalışmalarını değiştirdiğinde karşılığını verir. Hiçbir karar üretmeyen gelişmiş bir grafik, ekibin eski biletleri temizlemesine yardımcı olan basit bir birikmiş iş görünümünden daha az kullanışlıdır.

Bir talep ölçüsü, bir hız ölçüsü, bir güvenilirlik veya kalite ölçüsü ve birikmiş iş yaşıyla başlayın. Bunları birlikte inceleyin. Hacim artarken yanıt süresi sabit kalıyorsa ekibin kapasitesi olabilir. Çözülen bilet hacmi oluşturulan bilet hacminin gerisinde kalıyor ve birikmiş iş yaşlanıyorsa sorun, tek bir üst düzey ortalama endişe verici hâle gelmeden önce görünür durumdadır.

Bir örüntüden arkasındaki biletlere geçmek için ayrıntılı incelemeleri kullanın. En iyi inceleme sorusu yalnızca “Sayı neden değişti?” değildir. Asıl soru şudur: “Değişikliğe hangi biletler neden oldu, bunların ortak noktası ne ve bundan sonra neyi farklı yapacağız?”

Deskhero ilk günden itibaren raporlamaya hazır veriler sunar

Deskhero; bağlı Gmail, Google Workspace ve Microsoft 365 posta kutularını paylaşılan bilet kuyruklarına dönüştürür. Ayrıca gömülü formlardan ve SSS kaynaklı yapay zekâ sohbet botundan gelen biletleri de kabul eder.

Deskhero

Deskhero; bilet durumu görünümleri, ilk yanıt bekleyen biletler, bilet hacmi eğilimleri, ortalama ilk yanıt süresi, ortalama çözüm süresi ve durum başına ortalama sürenin yer aldığı operasyonel bir Dashboard içerir. Statistics alanında genel görünüm, eğilimler, yanıt süreleri, SLA, ekip, yapay zekâ ve otomasyon, kanallar, konu istatistikleri ve konu kümesi olmak üzere dokuz sabit sekme bulunur.

Statistics alanı tarih ve gruba göre filtrelenebilir; SLA sekmesinde ek olarak politika filtresi bulunur. Grafik kartları grafik ve tablo görünümleri arasında değiştirilebilir ve sekmelerin çoğu Excel’e aktarılabilir. Veriler, oturum açmış Kullanıcının erişebildiği gruplarla sınırlıdır ve genellikle yaklaşık beş dakika boyunca önbelleğe alınır. Canlı SLA şeridi, geçmişe dönük karşılama oranından ayrıdır.

Deskhero özel rapor oluşturucu içermez. Konu görünümlerinde de veri eşikleri vardır: konu kümelemesi yaklaşık 100 bilet gerektirir ve belirli aralıklarla yeniden oluşturulur. Kredi kartı olmadan 30 günlük ücretsiz deneme kullanılabilir.

Kaynaklar

Bu kılavuz, Deskhero’nun ürün uygulamasında belgelenen raporlama davranışını kullanır. Aşağıdaki ilgili Deskhero kılavuzları, dashboard’lar ve bilet alımı hakkında ek bağlam sağlar.

SSS

Hizmet masası raporlaması için temel metrikler nelerdir?

Bilet hacmi, oluşturulan ve çözülen bilet hacmi, ilk yanıt süresi, çözüm süresi, SLA karşılama oranı, birikmiş iş yaşı, yeniden açılma oranı, eskalasyon oranı, Kullanıcı bazında iş yükü ve kanal dağılımıyla başlayın. Kaynak verileri güvenilir olduğunda memnuniyet ve maliyet metriklerini ekleyin.

Bir BT yardım masası için iyi KPI’lar nelerdir?

İlk yanıt, çözüm, SLA karşılama oranı, ilk temasta çözüm, yeniden açılma oranı ve müşteri memnuniyeti yararlı KPI’lar olabilir. Yalnızca önemli bir sonuca, net bir hedefe ve ekibin uygulayabileceği bir eyleme bağlı metrikleri seçin.

CSAT anketlerini ne sıklıkla göndermelisiniz?

Müşteri yolculuğuna uyan, uygun biletin çözülmesinden sonra gönderim gibi tutarlı bir tetikleyici seçin. Anketi kısa tutun, aynı müşteriye tekrar tekrar istek göndermekten kaçının ve puanla birlikte yanıt sayısını ve yanıt oranını raporlayın.

İyi bir ilk temasta çözüm oranı nedir?

Her ekip için geçerli, evrensel olarak yararlı bir oran yoktur. İlk temasın ne sayıldığını tanımlayın, takipler veya yeniden açılmalar için bir gözlem penceresi belirleyin, oranı kategori ve kanal bazında temel verilerle karşılaştırın ve erken kapatmayı teşvik etmeden iyileştirin.

Bilet başına maliyet nasıl hesaplanır?

Bir dönem için tutarlı biçimde tahsis edilen destek maliyetlerini, o dönemde ele alınan uygun biletlere bölün. Hangi iş gücü, yazılım, yüklenici ve genel gider maliyetlerinin dahil edildiğini belgeleyin, ardından benzer dönemleri ve bilet kitlelerini karşılaştırın.