Deskhero
Türkçe
Ücretsiz deneyin

← Back to articles

Destek Yöneticilerinin Takip Etmesi Gereken Helpdesk Raporlama Metrikleri

Destek Yöneticilerinin Takip Etmesi Gereken Helpdesk Raporlama Metrikleri

Temel helpdesk raporlama metrikleri; bilet hacmi, ilk yanıt süresi, çözüm için geçen ortalama süre (MTTR), ilk temasta çözüm (FCR), CSAT, SLA uyumluluğu, birikmiş işler ve yaşlandırma, yeniden açılma oranı, eskalasyon oranı, Kullanıcı kullanım oranı, bilet başına maliyet ve kanal hacmidir. Bunları bir menüden seçilecek seçenekler olarak değil, tek bir set halinde birlikte takip edin; çünkü herhangi bir tek sayıyı izole etmek, yanlış teşviklere yol açar: yalnızca hızı kovalamak yeniden açılma oranlarını artırır; yalnızca CSAT’i kovalamak bilet başına maliyeti yükseltebilir.

Helpdesk raporlama metriklerini tek bir görünümde toplamanın amacı dört işi aynı anda kapsamaktır: verimlilik, kalite, iş yükü ve maliyet. Bunlardan birini kaçırırsanız, eksik bir tablo üzerinden yönetim yaparsınız.

Bugün bir gösterge tablosuna eklemeniz gereken çalışma listesi şöyle:

  • Bilet hacmi: Personel planlamasının talebe göre yapılabilmesi için toplam ve kanal bazında hacim
  • İlk yanıt süresi (FRT): Müşterilerin ilk anlamlı yanıtı almak için ne kadar beklediği
  • MTTR: Önceliğe göre ayrıştırılmış medyan çözüm süresi
  • FCR: Eskalasyon veya takip işlemi olmadan çözülen biletlerin yüzdesi
  • CSAT: Bilet sonrasındaki memnuniyet puanı
  • SLA uyumluluğu: Yanıt ve çözüm hedeflerini karşılayan biletlerin yüzdesi
  • Birikmiş işler ve yaşlandırma: Ne kadar süredir beklediklerine göre gruplandırılmış açık biletler
  • Yeniden açılma oranı: Kapatıldıktan sonra belirli bir zaman aralığında yeniden açılan biletler
  • Eskalasyon oranı: 2. seviye veya üzerine yönlendirilen biletlerin yüzdesi
  • Kullanıcı kullanım oranı: Aktif çalışma süresinin kullanılabilir kapasiteye oranı
  • Bilet başına maliyet: Toplam destek maliyetinin bilet hacmine bölünmesi
  • Kanal hacmi: E-posta, sohbet, telefon ve self servis olarak ayrılmış hacim

Sıradaki adımınız: Hacim, FRT, MTTR, CSAT ve birikmiş iş yaşını gösteren tek sayfalık bir haftalık gösterge tablosu oluşturun. Haftanın kontrolden çıkıp çıkmadığını on beş dakika içinde görmenin en hızlı yolu budur.

Önemli Çıkarımlar

Helpdesk raporlaması, yöneticiler tek bir sayıyı izole biçimde optimize etmek yerine verimlilik, kalite, iş yükü ve maliyet metriklerini birlikte takip ettiğinde işe yarar.

Nokta Detaylar
Tam seti takip edin FRT, MTTR, FCR, CSAT, SLA uyumluluğu, birikmiş iş yaşı, yeniden açılma oranı, eskalasyon oranı, kullanım oranı ve bilet başına maliyeti bir arada değerlendirin.
FCR’yi yeniden açılma oranıyla birlikte ele alın Tek başına yüksek FCR, erken kapatmaları gizleyebilir; yeniden açılma oranı, FCR’nin kaçırdığı noktaları ortaya çıkarır.
Kitleye özel gösterge tabloları oluşturun Yöneticilerin trend ve maliyet verilerine; yöneticilerin iş yükü ve risk verilerine; Kullanıcıların ise kendi kuyruklarına ihtiyacı vardır.
Operasyonlar için gerçek zamanlı, strateji için geçmiş verileri kullanın Kuyruk derinliği ve SLA sayaçları aynı gün içindeki kararları yönlendirir; trend verileri işe alım ve süreç değişikliklerini yönlendirir.
Veri hattını otomatikleştirin Deskhero, e-posta, formlar ve AI chatbot üzerinden gelen biletleri tek bir sistemde yapılandırır ve Excel dışa aktarımları içeren sabit Statistics görünümleri sunar.

İçindekiler

Helpdesk Raporlama Metrikleri ve KPI’lar Nedir?

Metrik, ölçtüğünüz herhangi bir sayıdır. KPI ise bir hedefe bağlı olan ve performansın kabul edilebilir olup olmadığını gösteren metriktir. Bilet hacmi bir metriktir; “biletlerin %90’ını 8 iş saati içinde çözmek” ise bir metrik üzerine oluşturulmuş KPI’dır.

Helpdesk raporlama metrikleri genel olarak dört gruba ayrılır. Hangi gruba baktığınızı bilmek, tek bir boyuta aşırı odaklanmanızı önler:

  • Üretkenlik metrikleri: bilet hacmi, Kullanıcı kullanım oranı, Kullanıcı başına günlük kapatılan bilet sayısı
  • Verimlilik metrikleri: ilk yanıt süresi, MTTR, kanala göre ilk yanıt süresi
  • Kalite metrikleri: CSAT, FCR, yeniden açılma oranı, kalite güvence puanları
  • Maliyet metrikleri: bilet başına maliyet, çözülen sorun başına maliyet, birikmiş iş artışlarıyla ilişkili fazla mesai saatleri

Ekiplerin çoğunun yaptığı hata, metrikleri bir iş hedefine karşılık geldikleri için değil, bir araç bunları raporlayabildiği için seçmektir. Liderliğiniz elde tutmaya önem veriyorsa, CSAT ve yeniden açılma oranı ham bilet sayısından daha önemli olabilir. Liderlik kadro planlamasına önem veriyorsa, bilet hacmi ve Kullanıcı kullanım oranı CSAT’ten daha önemli olabilir. Vermeniz gereken karardan başlayın, ardından bu karara bilgi sağlayan metriği seçin.

14 Temel Helpdesk Metriği: Tanımlar, Formüller ve Aksiyonlar

Bu metriklerin her biri bir skor tablosu değil, yöneticinin kullanacağı bir araçtır. Her birinin ne anlama geldiği, nasıl hesaplanacağı, nasıl ayrıştırılacağı ve değiştiğinde gerçekte ne yapmanız gerektiği aşağıda açıklanmıştır.

Bilet hacmi. Bir dönemde alınan toplam bilet sayısıdır. Formül: kanal, öncelik ve kategoriye göre ayrıştırılmış yeni biletlerin sayısı. Ürünle ilgili bir değişiklik olmadan hacim artarsa bir hata, kesinti veya trafiği artıran pazarlama kampanyası olup olmadığını kontrol edin. Kadro artışı olmadan sürdürülen hacim büyümesi, birikmiş iş sorununa ilişkin en erken uyarı işaretinizdir.

Kanal hacmi. E-posta, gömülü web formları, sohbet ve telefon gibi başvuru kaynaklarına göre ayrılmış bilet hacmidir. Bu metrik, otomatik yönlendirmeye yatırım yapmanız gereken noktaları gösterir. Sohbet hacmi üç katına çıkarken çözüm kalitesi geriliyorsa sorun personel açığı değil, eğitim açığıdır.

İlk yanıt süresi (FRT). Biletin oluşturulmasından ilk anlamlı Kullanıcı yanıtına kadar geçen süredir. Formül: (ilk yanıt zaman damgası − oluşturulma zaman damgası) toplamının bilet sayısına bölünmesi. Kanal ve önceliğe göre ayrıştırın. FRT kullanışlıdır, çünkü müşterinin yaşadığı ilk bekleme süresini ölçer. FRT yükselmeye başladığında bir çözüm seçmeden önce yönlendirmeyi, personel planlamasını ve talebi inceleyin. Otomatik alındı bildirimleri anlamlı yanıtlardan ayrı ölçülmelidir. Deskhero’nun AI otomatik yanıtları ilk yanıt olarak sayılır ve insan yanıtlarından ayrı biçimde tanımlanır.

Çözüm için ortalama süre (MTTR). Oluşturulmadan çözüme kadar geçen ortalama veya medyan süredir. Formül: (resolved_at − created_at) toplamının çözülen bilet sayısına bölünmesi. Birkaç gün süren aykırı değerler ortalamayı bozduğunda ortalamayla birlikte medyanı da kullanın. Öncelik ve kategoriye göre ayrıştırın. Acil biletler sabit kalırken düşük öncelikli biletlerde MTTR yükseliyorsa bu, önceliklendirme veya kapasite sorununa işaret edebilir.

İlk temasta çözüm (FCR). Takip veya eskalasyon olmadan tek bir etkileşimde kapatılan biletlerin yüzdesidir. Formül: ilk temasta çözülen biletler / toplam biletler × 100. FCR ve yeniden açılma oranı her zaman birlikte okunmalıdır. Yeniden açılma oranı yükselirken FCR’nin yüksek olması, Kullanıcıların biletleri zamanından önce kapattığı anlamına gelebilir.

CSAT. Genellikle kapanış anketine bağlı 1–5 arası bir derecelendirme olan, çözüm sonrası memnuniyet puanıdır. Formül: memnun yanıtlar / toplam yanıtlar × 100. Kullanıcıya, kategoriye ve kanala göre ayrıştırın. Genel CSAT sabit kalırken faturalandırma gibi tek bir kategoride CSAT düşüyorsa, koçluk veya süreç incelemesinin nerede gerekli olduğunu ortaya çıkarabilir.

Takip edildiğinde NPS veya CES. Net Tavsiye Skoru sadakati, Müşteri Çaba Skoru ise etkileşimin ne kadar zor hissettirdiğini ölçer. Bunların hiçbiri CSAT’in yerini tutmaz; ancak özellikle CES, müşteriler bir bilet açmadan önce self servis akışlarındaki sürtüşmeleri belirlemek için kullanışlıdır.

SLA uyumluluğu. Sözleşmeyle belirlenen yanıt ve çözüm sürelerini karşılayan biletlerin yüzdesidir. Formül: SLA içinde kalan biletler / toplam biletler × 100. Tek bir birleştirilmiş SLA sayısı, acil biletlerdeki uyumluluğunuz başarısız olurken düşük öncelikli biletlerde iyi görünmesi gibi durumları gizleyebileceğinden, öncelik seviyesine göre ayrıştırın.

Birikmiş işler ve yaşlandırma. Açık biletlerin yaş aralıklarına (0–24 saat, 1–3 gün, 3+ gün) göre gruplandırılmış sayısıdır. Daha eski biletlerden oluşan kuyruğun büyümesi, bir SLA hedefi kaçırılmadan önce kapasite veya iş akışı sorununa işaret edebilir.

Yeniden açılma oranı. Genellikle 48 saat olan belirli bir zaman aralığında yeniden açılan çözülmüş biletlerin yüzdesidir. Formül: yeniden açılan biletler / çözülen biletler × 100. Yeniden açılma oranını FCR ile birlikte ele almak, daha hızlı kapatmanın kalıcı çözüm pahasına gerçekleşip gerçekleşmediğini ortaya çıkarmaya yardımcı olur.

Eskalasyon oranı. 1. seviyenin ötesine yönlendirilen biletlerin yüzdesidir. Formül: eskale edilen biletler / toplam biletler × 100. Bilet hacmi sabit kalırken eskalasyonun artması, bilgi eksikliğine, yönlendirme sorununa veya biletlerin karmaşıklığındaki değişime işaret edebilir.

Kullanıcı kullanım oranı. Aktif çalışma süresinin planlanan kullanılabilir süreye oranıdır. Formül: biletler üzerinde geçirilen süre / planlanan saatler × 100. Sürekli aşırı kullanım tükenmişlik riskini artırabilir; bu nedenle sayıyı iş yükü ve izinlerle birlikte yorumlayın.

Bilet başına maliyet. Dönem için toplam destek maliyetinin (maaşlar, araçlar ve genel giderler) bilet hacmine bölünmesidir. Bu metrik, yöneticilere ve finans ekiplerine destek maliyetini ortak bir çerçevede tartışma imkânı sunar.

Kalite güvence veya kalite puanları. Bilet dökümlerinin üslup, doğruluk ve politikalara uyum gibi ölçütleri kapsayan bir değerlendirme cetveline göre manuel veya AI destekli puanlanmasıdır. Kalite güvence, özellikle anket yanıtlarının az olduğu durumlarda memnuniyet anketlerinin kaçırdığı bağlamı sağlayabilir.

Metrik Formül Birincil kitle
Bilet hacmi Döneme göre yeni biletlerin sayısı Yönetici, üst düzey yönetici
İlk yanıt süresi Toplam (ilk yanıt süresi − oluşturulma süresi) / biletler Kullanıcı, yönetici
MTTR Medyan (çözüm süresi − oluşturulma süresi) Yönetici, üst düzey yönetici
FCR İlk temasta çözülen biletler / toplam biletler × 100 Yönetici
CSAT Memnun yanıtlar / toplam yanıtlar × 100 Yönetici, üst düzey yönetici
SLA uyumluluğu SLA içinde kalan biletler / toplam biletler × 100 Yönetici, üst düzey yönetici
Birikmiş iş yaşlandırması Açık biletlerin yaş aralığına göre gruplandırılması Yönetici, Kullanıcı
Yeniden açılma oranı Yeniden açılan biletler / çözülen biletler × 100 Yönetici
Eskalasyon oranı Escale edilen biletler / toplam biletler × 100 Yönetici
Kullanıcı kullanım oranı Aktif çalışma süresi / planlanan süre × 100 Yönetici
Bilet başına maliyet Toplam destek maliyeti / bilet hacmi Üst düzey yönetici
Kalite güvence puanı Bilet başına ağırlıklı değerlendirme cetveli puanı Yönetici, Kullanıcı

Bu tanımların farklı ekip büyüklüklerinde nasıl uygulandığına dair ayrıntılı açıklama için destek yöneticileri için temel helpdesk raporlama metrikleri yazısına bakın.

Yöneticiler, Sorumlular ve Kullanıcılar için Gösterge Tabloları Nasıl Farklı Olmalı?

Üst düzey yöneticilerin trend ve maliyet verilerine ihtiyacı vardır. Yöneticilerin iş yükü ve risk verilerine ihtiyacı vardır. Kullanıcıların ise kendi kuyruklarına odaklanan bir görünüme ihtiyacı vardır. Tek bir gösterge tablosu nadiren bu üç kitlenin tamamına iyi hizmet eder; bu nedenle her grubun vermesi gereken kararlardan başlayın.

Üst düzey yönetici bileşenleri: 12 aylık CSAT trendi, aydan aya karşılaştırmalı genel SLA uyumluluğu, bilet başına maliyet, kadro ile karşılaştırmalı bilet hacmi ve eskalasyonlardan alınan en önemli risk maddelerinin kısa listesi.

Yönetici bileşenleri: öncelik ve kuyruğa göre mevcut açık bilet sayısı, kategoriye göre SLA uyumluluğu, Kullanıcı iş yükü dağılımı, FCR trendi, eskalasyon oranı, birikmiş iş yaşı dağılımı ve hareketli kalite güvence ortalamaları.

Kullanıcı bileşenleri: kişisel açık biletler, atanmış kuyruk derinliği, yaklaşan SLA son tarihleri ve ilgili bilgi bağlantıları.

Uzman İpucu: Her gösterge tablosunu odaklı tutun. Daha fazla kutucuk eklemek yerine ayrıntılı inceleme bağlantıları kullanın ve düzenli bir kararı yönlendirmeyen bileşenleri kaldırın.

Yenileme sıklığı, bileşen seçimi kadar önemlidir. Kuyruk derinliği, SLA son tarihleri ve Kullanıcı atamaları güncel veri gerektirir; çünkü aynı gün içinde alınan kararları yönlendirir. CSAT trendleri, bilet başına maliyet ve kalite güvence ortalamaları günlük veya haftalık güncellenebilir; çünkü daha uzun dönemlerde etkili olan kararları destekler. Güncel operasyon verileri, yöneticilerin aşırı yüklenmiş kuyrukları fark etmesine ve son tarihler kaçırılmadan önce işi yeniden dağıtmasına yardımcı olur.

Yöneticiler, yöneticiler ve Kullanıcılar için gösterge tabloları nasıl farklı olmalı? Genel bakış şeması

Gerçek Zamanlı ve Geçmişe Dönük Raporlama: Hangisine İhtiyacınız Var?

Gerçek zamanlı raporlama, o anda alınan operasyonel kararları yönlendirir; geçmişe dönük raporlama ise haftalar veya çeyrekler boyunca alınan stratejik kararları destekler. Bu ikisini karıştırmak, ekiplerin işe alım görüşmesi sırasında canlı bir gösterge tablosuna bakmasına veya öğleden sonra vardiyasını kimin karşılayacağına karar vermek için çeyreklik rapor çıkarmasına yol açar.

Amaç Yenileme sıklığı Zaman ufku Temel metrikler Kitle
Operasyonel (yönlendirme, personel planlaması) Gerçek zamanlıdan saatlik sıklığa Aynı gün Kuyruk derinliği, SLA son tarihleri, Kullanıcı durumu Yönetici, Kullanıcı
Stratejik (işe alım, süreç) Günlükten aylık sıklığa Haftalardan çeyreklere MTTR trendi, CSAT trendi, bilet başına maliyet Yönetici, üst düzey yönetici

Operasyonel gösterge tabloları yönlendirme ve personel planlaması kararlarını desteklemelidir; geçmişe dönük raporlar ise işe alım kararları, eğitim yatırımları ve süreç değişiklikleri için doğru araçtır. İkisini karıştırmak yalnızca gürültülü ve tepkisel bir yönetime yol açar.

Veri tarafında üç alışkanlık, raporlamayla ilgili sorunların çoğunu çözer: raporlamadan önce her bilet kaynağını tek bir sistemde birleştirin; durum zaman damgalarının gerçeği yansıttığını doğrulayın; yerleşik bir rapor yeterli olmadığında tekrarlanabilir dışa aktarımları otomatikleştirin. Bir müşterinin sorunu çözüldükten günler sonra “çözüldü” olarak işaretlenen bilet, kullanılan raporlama aracından bağımsız olarak MTTR’yi çarpıtır.

Araç seçiminde belirleyici faktör genellikle verilerinizin hâlihazırda nerede bulunduğudur. Power BI, Microsoft ağırlıklı ortamlara çoğu zaman uyarken Tableau, birden fazla kaynağı birleştirmek için yaygın olarak kullanılır. Hangisini seçerseniz seçin, dışa aktarımınızın veya API’nizin bilet kimliğini, ilgili durum değişikliklerinin zaman damgalarını, önceliği, kategoriyi, atanan kişiyi ve kanalı içerdiğinden emin olun. Kesin alanları gösterge tablonuzun kullanacağı hesaplamalara göre doğrulayın.

Gerçekçi SLA ve CSAT Hedeflerini Nasıl Belirlersiniz?

Önce mevcut temel seviyenizi ölçerek, bunu benzer bir kıyaslama değeriyle karşılaştırarak ve ardından iyileştirmeyi belirli bir zaman çizelgesine yayarak hedefler belirleyin; doğrudan keyfi bir “sektör lideri” sayıya atlamayın.

  1. Mevcut temel seviyenizi ölçün: Her metrik için en az dört ila altı hafta boyunca ölçüm yapın; böylece tek kötü haftanın etkisini azaltabilirsiniz.
  2. Bir kıyaslama aralığı seçin: Destek modelinize göre uyarlanmış şekilde sektör kaynaklarından veya benzer ekiplerden bir aralık belirleyin (B2B SaaS helpdesk’i ile yüksek hacimli bir e-ticaret ekibi aynı MTTR’yi hedeflememelidir).
  3. Aşamalı bir hedef belirleyin: Örneğin SLA uyumluluğunu gelecek ay %95’e çıkarma talebi yerine, iki çeyrek içinde %82’den %90’a yükseltmek için bir zaman çizelgesi oluşturun.
  4. Hedefleri kapasite planlamasına bağlayın: İyileştirme hedeflerinin yalnızca bir talimat olarak kalmamasını, hedeflere ulaşmak için gereken personel veya otomasyon yatırımıyla desteklenmesini sağlayın.

Her KPI için tanımı, veri kaynağını, temel seviyeyi, hedefi ve gözden geçirme tarihini belgeleyin. Kıyaslama raporları bağlam sağlayabilir; ancak hedefiniz kanalı, önem derecesini, müşteriye verilen sözü, çalışma saatlerini ve mevcut kapasiteyi yansıtmalıdır.

Yöneticiler Hangi Raporlama Hatalarından Kaçınmalı?

En yaygın hatalar gösteriş metriklerinin peşinden koşmak, yüzdelik dilimler yerine ortalamaları raporlamak, kaliteyi kontrol etmeden hızı ödüllendirmek ve gösterge tablolarının ekip bazında birbirinden kopuk çalışmasına izin vermektir.

  • Yüzdelik dilim süreleri yerine ortalamayı takip etmek en kötü durumlarınızı gizler. Medyan ve 90. yüzdelik MTTR’yi yan yana raporlayın.
  • Kaliteyi kontrol etmeden yalnızca hızı ödüllendirmek (hızlı kapatmalar, yüksek FCR), Kullanıcıları sorun gerçekten çözülmeden biletleri kapatmaya teşvik edebilir.
  • Yeniden açılma oranını göz ardı etmek bir kalite açığı bırakır; bilet aracınız bunu varsayılan olarak göstermiyorsa bu metriği ekleyin.
  • Tüm kanallara aynı şekilde davranmak sohbet ve e-posta için FRT beklentilerinin büyük ölçüde farklı olduğunu gizler.
  • Zayıf veri hijyeni (yinelenen biletler, yanlış etiketlenmiş öncelikler) sonraki tüm metrikleri sessizce bozar; bilet etiketlerini üç ayda bir denetleyin.

Haftalık Raporda ve Aylık Raporda Neler Yer Almalı?

Haftalık raporlar operasyonel sağlığı, aylık raporlar ise trendi ve iş etkisini kapsar.

  1. Haftanın bilet hacmi ve kanal dağılımı
  2. Hedefle karşılaştırmalı FRT, MTTR, CSAT ve FCR
  3. Kategoriye göre ayrıştırılmış SLA uyumluluğu
  4. Hacme göre en fazla bilet alan ilk beş kategori
  5. Kullanıcı iş yükü dağılımı ve kapasiteyle ilgili uyarılar
  6. Haftanın temel hikâyesini özetleyen bir paragraf

Aylık üst düzey yönetici raporunda CSAT, SLA uyumluluğu ve bilet başına maliyet için aydan aya ve yıldan yıla trendleri, talebe göre personel seviyelerini, başlatılan girişimler ve ölçülen etkileri hakkında kısa bir notu ve mevsimsel hacim artışları gibi ileriye dönük riskleri ele alın.

Kullanışlı bir anlatı cümlesi şöyle olabilir: “Faturalandırma hatasının ardından bu hafta hacim %14 arttı, acil biletlerde SLA uyumluluğu %84’e düştü ve düzeltme yayınlanana kadar geçici ek personel öneriyoruz.” Rakamlar örnek niteliğindedir; ancak bu yapı okuyucuya değişimi, nedeni, sonucu ve aksiyonu sunar. Hazır düzenler için Deskhero’nun müşteri destek gösterge tablosu şablonlarına bakın.

Bu Metrikleri Ham Verilerden Gerçekte Nasıl Hesaplarsınız?

Doğru hesaplama, herhangi bir formülden çok tek bir unsura bağlıdır: tutarlı durum zaman damgaları ve “çözüldü” ile “kapatıldı” kavramlarının net ve üzerinde anlaşılmış bir tanımı. Ekibinizin yarısı düzeltme yayınlandığında, diğer yarısı ise müşteri onayladığında bileti çözülmüş olarak işaretliyorsa MTTR’niz iki farklı şeyi karşılaştırıyor demektir.

  1. FRT = first_response_at − created_at; dönem başına ortalaması veya medyanı alınır
  2. MTTR = resolved_at − created_at; medyanı alınır ve önceliğe göre ayrıştırılır
  3. FCR = (sıfır yeniden atama ve sıfır yeniden açılma içeren biletler) / toplam biletler
  4. Yeniden açılma oranı = 48 saat içinde yeniden açılan biletler / çözülen biletler
  5. Kullanıcı kullanım oranı = time_spent / scheduled_hours
  6. SLA uyumluluğu = SLA’yı karşılayan biletler / toplam biletler

Gerekli ham alanlar: bilet kimliği, created_at, first_response_at, resolved_at, closed_at, durum değişikliği günlüğü, öncelik, kuyruk, atanan kişi, time_spent ve maliyet merkezi.

Bir tarih aralığında FRT ve MTTR için basit bir sorgu şöyledir:

SELECT AVG(first_response_at - created_at) AS avg_frt,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY resolved_at - created_at) AS median_mttr
FROM tickets
WHERE created_at BETWEEN :start_date AND :end_date;

Bunu başlangıç yapısı olarak değerlendirin; ardından söz dizimini ve zaman damgası kurallarını veritabanınıza uyarlayın. Gösterge tablosunda kullanmadan önce sonucu, bilinen az sayıda biletle karşılaştırarak doğrulayın.

BT Destek Metrikleri, Müşteri Hizmetleri Metriklerinden Nasıl Farklı Olmalı?

BT desteği ve müşteriye dönük destek, her ikisi de bilet kuyruklarıyla çalışsa da başarıyı farklı biçimde ölçer. BT destek metrikleri, olay önem derecesine bağlı MTTR, eskalasyon oranı ve SLA uyumluluğuna daha fazla ağırlık verir; çünkü kesinti maliyeti, biraz yavaş bir yanıtın maliyetini fazlasıyla aşar. P1 kesinti bileti, parola sıfırlama talebinden farklı bir SLA sayacına ve farklı bir eskalasyon yoluna ihtiyaç duyar; bunları tek bir MTTR sayısında birleştirmek her iki durumu da gizler.

Müşteri hizmetleri ve e-ticaret desteği ise CSAT, FCR ve kanal hacmine daha fazla ağırlık verebilir; çünkü iş etkisi sistem çalışma süresinden çok müşteriyi elde tutma ve tekrarlanan satın alımlarda görülür. Sipariş durumu sorularını yanıtlayan bir Shopify satıcısı, nadir gerçekleşen teknik bir eskalasyondaki MTTR’den çok müşteri kanallarındaki FRT’yi önemseyebilir. Deskhero’nun Shopify entegrasyonu, eşleşen biletlere canlı müşteri, sipariş, teslimat ve takip bağlamı ekler; ürün kataloğu da AI yanıt taslaklarına bilgi sağlayabilir.

Çözüm, metrik setlerinden birini seçip diğerini bırakmak değildir. Ekibiniz her iki destek modelini de yürütüyorsa gösterge tablonuzu modele göre bölümlere ayırın; böylece kurum içi BT kuyruğu ile müşteriye dönük kuyruk, ikisine de tam olarak uymayan tek bir birleştirilmiş sayı yerine ayrı SLA seviyelerine, ayrı eskalasyon kurallarına ve ayrı kıyaslama hedeflerine sahip olur.

Trend Analizi ve Tahminleme Helpdesk Planlamasını İyileştirebilir mi?

Trend analizi, anlık bir metriği planlama aracına dönüştürür; tahminleme ise talebe tepki vermek yerine talebin önünde personel planlamanıza olanak tanır. Sabit bir CSAT sayısı bugün nerede olduğunuzu gösterir; 12 aylık CSAT trend çizgisi ise geçen çeyrekteki süreç değişikliğinin gerçekten işe yarayıp yaramadığını gösterir.

En pratik kullanım alanı hacim tahminidir. Bir ürün lansmanı döngüsü nedeniyle bilet hacmi her kasım ayında düzenli olarak artıyorsa, bu mevsimsel düzeni kadro sayısıyla birlikte göstermek geçici personeli önceden talep etmenizi sağlar. Aynı mantık eskalasyon oranı için de geçerlidir: sürekli yükseliş, SLA uyumluluğu bozulmadan önce inceleme başlatılmasını sağlayabilir.

Destek analitiği iki farklı görevi yerine getirebilir: kuyruğun günlük olarak sağlıklı tutulması ve ürün ile müşteri deneyimi ekiplerine aktarılacak yinelenen temaları bulmak için bilet içeriğinin analiz edilmesi. Raporlama programının kuyruk yönetiminden fazlasını desteklemesi için hem operasyonel performansı hem de yinelenen konuları takip edin.

Bu Metrik Seti Modern Helpdesk’ler için Neden İşe Yarıyor?

En sık gördüğüm hata kötü metrikleri seçmek değil, iyi metrikleri izole biçimde seçmek. Yeniden açılma oranı olmadan FCR raporlayan bir ekip, müşteriler aynı şikâyeti ikinci kez bildirmeye başlayana kadar kâğıt üzerinde harika görünür. Verimlilik sayılarını bir kalite kontrolüyle eşleştirmek, bir helpdesk’in kendini daha kötü hizmet sunacak şekilde optimize etmesini gerçekten önleyen unsurdur.

Verimlilik, kalite, iş yükü ve maliyeti birlikte ele alan bu gruplama işe yarar; çünkü personel ve ürün kararlarının gerçekte nasıl alındığını yansıtır. Yalnızca CSAT’e bakarak işe alım yapmaz veya yalnızca bilet başına maliyete bakarak bilet yönlendirmezsiniz. Her hafta tam sete birlikte bakmanız gerekir.

Bu Raporlama Uygulamalarını Helpdesk’inize Taşıyın

Ayrı e-posta ve form dışa aktarımlarından elle rapor oluşturmak önlenebilir bir iş yükü yaratır. Deskhero, bir Gmail veya Microsoft 365 posta kutusunu helpdesk’e dönüştürür ve e-posta, gömülü form ve AI chatbot biletlerini tek bir sistemde saklar. Dashboard; bilet hacmini, ortalama ilk yanıt süresini, ortalama çözüm süresini ve durum başına geçen süreyi gösterir. Sabit Statistics alanı; filtreler ve sekme başına Excel dışa aktarımlarıyla trend, yanıt süresi yüzdelik dilimleri, SLA, ekip, kanal, AI ve konu görünümleri ekler.

Deskhero

E-posta, gömülü web formu veya yerleşik AI chatbot üzerinden oluşturulan biletler tek bir ortak gelen kutusuna düşer. AI yanıt taslakları çalışma alanının daha geniş bilgi havuzunu kullanabilir; müşteriye dönük chatbot yanıtları ve AI otomatik yanıtları ise yalnızca onaylanmış herkese açık SSS’yi kullanır. Çok dilli destek, Kullanıcıların biletleri ve yanıtları çevirmesine yardımcı olur. Topics kümesi yinelenen temaları öne çıkarırken Statistics dışa aktarımları ve REST API, daha ileri analizlere geçiş yolları sunar. Deskhero özel rapor oluşturucu içermez; bu nedenle özel bir gösterge tablosuna ihtiyaç duyan ekipler, dışa aktarılan veya API üzerinden erişilebilen verileri bir BI aracında kullanmalıdır.

Raporlama iş akışınızı yeniden oluşturuyorsanız, kredi kartı gerektirmeyen 30 günlük ücretsiz denemeyi başlatabilir ve Deskhero içindeki Dashboard ve Statistics görünümlerini inceleyebilirsiniz.

Bu Raporlama Uygulamalarını Helpdesk’inize Taşıyın. Genel bakış şeması

Kaynaklar

Bu kaynaklar, yukarıda ele alınan kıyaslamaları, gösterge tablosu tasarım kurallarını ve araç yönlendirmelerini destekler; her biri konunun belirli bir bölümünü daha ayrıntılı biçimde inceler.

SSS

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

Temel set; bilet hacmi, ilk yanıt süresi, MTTR, FCR, CSAT, SLA uyumluluğu, birikmiş iş yaşlandırması, yeniden açılma oranı, eskalasyon oranı, Kullanıcı kullanım oranı ve bilet başına maliyeti içerir. Bunlar tek tek değil, birlikte takip edilmelidir.

Temel 5 CX metriği nelerdir?

Çoğu ekip CX raporlamasını CSAT, FCR, ilk yanıt süresi, yeniden açılma oranı ve SLA uyumluluğu üzerine kurar; çünkü bu beş metrik hız, kalite ve güvenilirliği tek ve okunabilir bir tabloda birleştirir.

Bir BT help desk’i için KPI örnekleri nelerdir?

BT help desk KPI’ları genellikle önem derecesi seviyesine göre MTTR’yi, P1 olaylarındaki SLA uyumluluğunu, eskalasyon oranını ve birikmiş iş yaşlandırmasını içerir; çünkü BT desteği, genel müşteri hizmetlerine kıyasla olayın önem derecesine daha fazla ağırlık verir.

Bir BT departmanı için iyi KPI’lar nelerdir?

Bilet düzeyindeki metriklerin yanı sıra BT departmanları, hizmet kalitesini personel maliyeti ve kapasiteyle dengelemek için genellikle bilet başına maliyeti, Kullanıcı kullanım oranını ve ilk temasta çözümü takip eder.

Helpdesk raporları ne sıklıkla çalıştırılmalıdır?

Kuyruk derinliği ve SLA son tarihleri gibi operasyonel bileşenler güncel verilere ihtiyaç duyar; CSAT ve bilet başına maliyet gibi trend metrikleri ise çoğu zaman haftalık veya aylık sıklıkla güncellenebilir.

Deskhero gibi bir helpdesk platformu bu raporlamayı otomatik olarak gerçekleştirebilir mi?

Deskhero; e-posta, web formları ve AI chatbot üzerinden gelen biletleri tek bir sistemde toplar. Sabit Statistics sekmeleri filtreler ve sekme başına Excel dışa aktarımlarıyla trendleri, yanıt sürelerini, SLA’yı, Kullanıcıları, kanalları, AI’ı ve konuları kapsar. Daha ileri analizlere ihtiyaç duyan ekipler için REST API de kullanılabilir.