Destek Talebi Raporu Nasıl Hazırlanır: Adım Adım

Destek talebi raporu çoğunlukla bir tanım problemidir. Oluşturulan talepler, çözülen talepler, ilk yanıt süresi ve çözüm süresi kulağa son derece açık gelse de, her birinin aynı yardım masası içinde birden fazla resmi anlamı vardır.

Sayım kurallarını netleştirirseniz rapor kendi kendini yazar. Bu adımı atlarsanız, iki dürüst insan aynı dışa aktarma dosyasını alıp saatlerce süren farklar yüzünden anlaşmazlığa düşebilir.

Bu kılavuz; raporda nelerin yer alması gerektiğini, tanımların ayrıştığı dört noktayı ve bir talep dışa aktarımından bu raporun nasıl oluşturulacağını kapsamaktadır.

Bir destek talebi raporunda neler yer almalı

Tek başına hacim size neredeyse hiçbir şey söylemez. Sayıları güvenle okunabilir kılan şey, onların nasıl düzenlendiğidir.

Öğe	Neden orada yer alıyor
Dönem içinde oluşturulan talepler	Talep tarafı
Dönem içinde çözülen talepler	Belirtilen bir durum kuralına göre arz tarafı
Dönem sonundaki birikmiş işler	Çözülmemiş veya kapatılmamış her şey
İlk yanıt süresi	Belirtilen bir zaman dilimi ve tanıma göre
Çözüm süresi	Açıkça belirtilmiş şekilde, ilk veya tam çözüm
Yeniden açılan talepler	Diğer sayıların gizlediği kalite sinyali
Yanıtlanmamış talepler	Sürecin tamamen başarısız olduğu yer
Belirtilen bir tarih temeli ve kapsam	Hangi kanalların, markaların ve kuyrukların dahil edildiği

İki satır, boyutlarının gösterdiğinden çok daha fazla ağırlık taşır. Yeniden açılan ve yanıtlanmamış talepler, bir raporun sadece bir skor tablosu olmaktan çıkıp yararlı hale geldiği yerdir.

Zendesk, temel formülleri yayınlayarak tanımların kişisel görüşlerden ziyade kontrol edilebilir olmasını sağlar. Platformun metrikler ve nitelikler referansı her birini tek tek sunar.

En basitinden başlayın. Çözülen talepler "çözülmüş veya kapatılmış taleplerin sayısıdır", dolayısıyla bu metrik tek bir durum yerine iki durumu kapsar.

"İlk yanıt süresi" için iki resmi tanım vardır

Bu, en çok anlaşmazlığa yol açan yol ayrımıdır ve sağlayıcı bu konuda doğrudan uyarıda bulunur.

Zendesk'in SLA belgeleri bunu tek bir satırda özetler: "SLA yanıt süresini yerel Zendesk yanıt süresi metriğiyle karıştırmayın."

Yerel metrik, yanıtı kimin verdiği konusunda katıdır. Zendesk, "ilk yanıt süresinin yalnızca temsilci yanıtlarına göre hesaplandığını" belirtir. Otomatik ve bot kaynaklı eylemler "ilk yanıt süresi hesaplanırken dikkate alınmaz."

SLA metriği ise öyle değildir. Orada ilk yanıt süresi, "talebin oluşturulması ile bir temsilciden gelen ilk herkese açık yorum (veya otomatik yanıt) arasındaki süredir." Zendesk, "herkese açık bir yorumla otomatik yanıt verecek bir tetikleyici ayarlarsanız yanıt süresi metriklerinin karşılanmış sayılacağını" ekler.

Bu ikisini birlikte okuduğunuzda sonuç oldukça nettir. Otomatik yanıtlayıcı SLA hedefinizi karşılarken, yerel ilk yanıt süresi işlemeye devam edebilir.

Dolayısıyla, %98 SLA başarısı ve dört saatlik bir medyan ilk yanıt süresi gösteren bir rapor kendi içinde çelişmez. Sadece iki farklı şeyi, ikisini de doğru şekilde raporlar.

Bilmeye değer iki küçük istisna daha vardır. Bir temsilcinin talebi oluşturduğu ve ilk yorumun herkese açık olduğu durumu ele alalım. Süre metrikleri referansı, ikinci zaman damgasının "temsilcinin ikinci herkese açık yorumuna kaydığını" belirtir.

And paylaşılan talepler hesaba katılmaz. Zendesk, bir temsilcinin talep paylaşımını kullanarak başka bir hesaptan herkese açık bir yorum yapması durumunda, "bunun hesabınızın ilk yanıt süresine dahil edilmediğini" belirtir.

"Çözüm süresi" için de iki tanım vardır

Aynı ayrım çözüm metriklerinde de mevcuttur ve burada her iki sürüm de varsayılan olarak sunulur.

İlk çözüm süresi, "talebin oluşturulması ile ilk çözümü arasındaki süre" olup, "talep durumunun ilk kez çözüldü olarak ayarlandığı anda" sona erer.

Tam çözüm süresi ise "talebin oluşturulması ile en son çözümü arasındaki süre" olup, "talep durumunun son kez çözüldü olarak ayarlandığı anda" biter.

Bir kez çözülen bir talep için bu iki değer aynıdır. Çözülen, yeniden açılan ve tekrar çözülen bir talep için ise, ikinci turun ne kadar sürdüğüne bağlı olarak birbirlerinden ayrışırlar.

Yeniden açılan taleplerin raporda yer almasının tam nedeni de budur. Zendesk bunları "çözüldükten sonra yeniden açılan" talepler olarak tanımlar ve metriğin "aynı güncelleme sırasında çözülen ve yeniden açılan talepleri içermediğini" belirtir.

İnsanların gözden kaçırdığı ikinci dereceden bir etki daha vardır. Çözülen taleplerin günlük ortalaması, bunları "yalnızca şu anda çözülmüş veya kapatılmış olmaları durumunda" sayar. Dolayısıyla, bugün yeniden açılan bir talep, geçen ayın çözülen talepler sayısından sessizce düşer.

Bu nedenle Haziran ayında aldığınız bir rapor, Ağustos ayında aynı sonuçları vermeyecektir. Hiçbir şey bozulmamıştır; sadece temel durum değişmiştir.

Bekleme ile çalışma sürelerini birbirinden ayıran iki metrik daha vardır. Talep sahibi bekleme süresi; yeni, açık ve beklemede (on-hold) durumlarında geçirilen toplam süredir; temsilci bekleme süresi ise askıda (pending) durumunda geçirilen toplam süredir.

Bu ikili, bir çözüm ortalamasının yanıtlayamadığı soruyu yanıtlar. Müşterinin beklenmesinden kaynaklanan uzun çözüm süreleri, kuyruk yoğunluğundan kaynaklanan uzun çözüm sürelerinden farklı bir sorundur.

Takvim saatleri mi yoksa çalışma saatleri mi

Her yanıt ve çözüm verisi iki farklı zaman dilimine göre mevcuttur ve bunlardan birini seçmek isteğe bağlı değildir.

Zendesk her ikisini de kaydeder. İlk herkese açık yanıttan sonra, "sistem ilk yanıt süresini takvim saatleri ve çalışma saatleri cinsinden hesaplar." Her iki metrik de "talep verileriyle birlikte saklanır."

Gördüğünüz varsayılan ayar tarafsız değildir. Zendesk, hazır Explore raporlarının "bilgileri takvim saatleri cinsinden gösterdiğini" belirtir. Çalışma saatleri metrikleri ise "mevcuttur ve kendi raporlarınızda kullanılabilir."

Dolayısıyla, dokuz-beş çalışan bir ekip varsayılan raporda yavaş görünecektir. Cuma günü saat 18:00'de gelen bir talep, Pazartesi sabahına kadar yaklaşık 63 takvim saati taşırken, çalışma saati olarak neredeyse sıfır değerindedir.

Canlı sohbet kanalları bir pürüz daha ekler. Mesajlaşma ve sohbet için İlk yanıt süresi (sn) metriği, "mesajlaşma çalışma saatlerinizi ve canlı sohbet çalışma saatleri ayarlarınızı yok sayar."

And sohbet yanıt süresi SLA'leri isteğe bağlıdır. Zendesk, canlı sohbet için yanıt süresi SLA'lerinin "varsayılan olarak kapalı olduğunu" belirtir; dolayısıyla bunların olmaması mükemmel bir performanstan ziyade bir yapılandırma durumudur.

Manuel olarak nasıl yapılır

Seçenek 1: Her metrik grubu için bir sekme

Talep listesini metrik alanlarıyla birlikte dışa aktarın, ardından herhangi bir şeyi özetlemeden önce hacim, yanıt süresi ve çözüm süresini ayrı sekmelere bölün.

Dışa aktarma sırasında yalnızca birini seçmek yerine takvim ve çalışma saati sütunlarını yan yana tutun. Er ya da geç diğer sütun da sizden istenecektir.

Zaman metrikleri için ortalama (mean) yerine medyan (ortanca değer) hesaplayın. Tatil boyunca açık bırakılan birkaç talep, ortalamayı hiçbir talebin gerçekte bulunmadığı bir noktaya çekecektir.

Buradaki en büyük engel, bir e-tablonun durum geçmişini görememesidir. Her talebin yalnızca güncel durumunu alırsınız, bu nedenle yeniden açılma davranışını geçmişi yeniden kurgulayarak değil, yeniden açılma sayısından elde etmeniz gerekir.

Seçenek 2: İlk olarak yazılan bir tanımlar sekmesi

Yanıt süresi tanımını, zaman dilimini, çözüm metriğini, çözüldü durum kuralını, kapsamdaki kanalları ve tarih temelini kaydedin.

Ardından, raporun neyi iddia etmediğini kaydedin. SLA başarısı ile yerel ilk yanıt süresinin farklı şeyleri ölçtüğünü yazılı hale getirmek, iyi niyetli bir iş arkadaşınızın bunları tek bir sayıymış gibi sunmasını engeller.

Sınır ise her zamanki gibidir. Bir kuralı belgelemek onu uygulamaz ve gelecek çeyrekte birisi pivot tabloyu hafızasından yeniden oluşturur.

Seçenek 3: Ortalama almadan önce segmentlere ayırın

Herhangi bir zaman metriğini hesaplamadan önce kanala göre ayrım yapın. E-posta, sohbet ve telefon taleplerinin dinamikleri farklıdır ve harmanlanmış bir medyan bunların hiçbirini doğru tanımlamaz.

Ardından veriyi saptıran talepleri hariç tutun veya işaretleyin. Haftalarca müşteri yanıtı bekleyen talepler, çözüm ortalamasının içinde yer almak yerine kendi satırlarında bulunmalıdır.

Neleri hariç tuttuğunuzu ve bunlardan kaç tane olduğunu gösterin. Filtreyi göremeyen bir okuyucu, hiçbir filtre uygulanmadığını varsayacaktır.

Buradaki kısıtlama, segmentasyonun işi katlamasıdır. Üç kanal çarpı iki zaman dilimi çarpı iki çözüm metriği, takip edilmesi gereken on iki farklı sayı demektir.

Ortak engel. Her üçü de dışa aktarımın her kuyruk için tek bir tarih temelinde, tek bir tarih aralığını kapsadığını varsayar. Sekmeler arasında karışık tarih aralıkları kullanılması, bu rapordaki en yaygın sessiz hatadır.

Manuel yöntemin yavaşladığı yerler

İlk destek talebi raporu bir öğleden sonranızı alır. Dördüncüsü ise daha uzun sürer, çünkü yardım masası bu süreçte arka planda değişmiştir.

Yeni bir kanal devreye alınır, bu nedenle harmanlanmış medyan performansla ilgisi olmayan nedenlerle değişir. Yeni bir bölge için çalışma saatleri düzenlenir ve geçmişteki tüm çalışma saati verileri bunlarla birlikte kayar.

Ardından yeniden açılma etkisi devreye girer. Geçen çeyreğin sayıları artık aynı çıkmaz ve bunun nedenini açıklamak raporu yeniden oluşturmaktan daha uzun sürer.

Yalnızca baskı altındayken ortaya çıkan dördüncü bir maliyet daha vardır. Birisi bu çeyrekte desteğin hızlanıp hızlanmadığını sorar. Dürüst bir yanıt için öncelikle zaman diliminin, tanımın ve kanal dağılımının belirtilmesi gerekir.

Aynı tablonun memnuniyet tarafı için NPS raporu oluşturma kılavuzumuza göz atın. Eğer sorun doğrudan hacmin kendisiyse, satış öncesi müşteri desteği için yapay zeka temsilcisi oluşturma hakkındaki rehberimiz talepleri yönlendirme konusunu ele almaktadır.

Powerdrill Bloom ile nasıl oluşturulur

Adım 1: Talep dışa aktarım dosyanızı yükleyin

Talep dışa aktarımını veya talep ve SLA dışa aktarımlarını birlikte yükleyin. Powerdrill Bloom, sütunları yükleme anında analiz eder; böylece boş zaman damgaları, karışık tarih biçimleri ve ilk yanıtı eksik olan talepler, herhangi bir medyan hesaplanmadan önce yüzeye çıkar.

Adım 2: Raporu doğal dilde tanımlayın

Tanımları yeniden oluşturmak yerine doğrudan belirtin. Yanıt süresi tanımını, zaman dilimini, hangi çözüm metriğini istediğinizi, çözüldü durum kuralını ve kapsamdaki kanalları adlandırın.

Ardından hataları yakalayan soruları sorun. Kaç talebin hiç temsilci yanıtı almadığını sorun. Hangi taleplerin yeniden açıldığını sorun. Tek bir harmanlanmış rakam yerine kanal başına medyan değerleri isteyin.

Adım 3: Grafiği, raporu veya sunumu dışa aktarın

Kanal başına metrik tablosunu veya arkasında birikmiş işlerin yer aldığı, oluşturulan ve çözülen talepleri karşılaştıran bir grafiği alın. Sayıların yanında tanımları da taşıyan slaytlar aynı işlemden elde edilir.

Sık yapılan hatalar

SLA başarısını ilk yanıt süresi olarak sunmak. Biri otomatik yanıtı kabul ederken, diğeri otomatik eylemleri tamamen hariç tutar.

Takvim saatlerini çalışma saatleriyle karşılaştırmak. Varsayılan rapor size ilkini sunar, oysa hedefiniz muhtemelen ikincisine göre belirlenmiştir.

Yanıt ve çözüm süreleri için ortalamayı kullanmak. Terk edilmiş birkaç talep, ortalamayı hiçbir gerçek talebin bulunmadığı bir noktaya taşır.

Kanalları harmanlamak. Sohbet ve e-posta medyanları yapısal olarak farklıdır ve bunları harmanlamak her ikisini de gizler.

Hangisi olduğunu belirtmeden çözüm süresini raporlamak. İlk ve tam çözüm süreleri, yuvarlama varyasyonları değil, ayrı ayrı saklanan metriklerdir.

Çözülen taleplerin sayısını kesin kabul etmek. Çözülen taleplerin sayısı yalnızca şu anda çözülmüş veya kapatılmış olan talepleri içerir, bu nedenle yeniden açılan talepler geçmişi değiştirir.

Yanıtlanmamış talepleri dışarıda bırakmak. Bunlar, bir temsilciden birden az yanıt almış talepler olarak tanımlanır ve raporun ortaya çıkarabileceği en net başarısızlık göstergesidir.

Sonuç

Yanıt tanımını belirtin, zaman dilimini adlandırın, ilk veya tam çözümü seçin, durum kuralını ifade edin, kanala göre segmentlere ayırın ve yeniden açılan ile yanıtlanmamış talepleri gösterin. Bu, birinin üzerinde aksiyon alabileceği bir destek talebi raporu ortaya çıkarır.

Raporun yapamayacağı şey ise başka bir şirketin sayılarıyla temiz bir karşılaştırma sunmaktır. Tanımlar yapılandırılabilir olduğundan, bir yerde okuduğunuz bir kıyaslama değeri neredeyse kesinlikle farklı şekilde ölçülmüştür.

Bunun yerine, sabit bir kurallar kümesi üzerinden kendi geçmişinizle karşılaştırın. Gerçekten bir gelişme olup olmadığını size söyleyecek olan sürüm budur.

Her ay bunu yeniden oluşturmak bir gününüzü alıyorsa, talep dışa aktarımınızda Powerdrill Bloom'u deneyin. Ayrıca AI report generator sayfasına ve voice of customer summarizer aracına göz atın.

Sıkça sorulan sorular

SLA başarım neden ilk yanıt süremle eşleşmiyor?

Farklı olayları ölçerler. Zendesk'in SLA ilk yanıt süresi otomatik bir yanıtla karşılanabilirken, yerel ilk yanıt süresi metriği otomatik ve bot eylemlerini tamamen hariç tutar.

İlk çözüm süresini mi yoksa tam çözüm süresini mi raporlamalıyım?

Hangisini belirttiyseniz onu raporlayın. İlk çözüm süresi, bir talebin ilk kez çözüldü olarak ayarlandığı anda sona erer. Tam çözüm süresi ise son kez çözüldüğünde biter; dolayısıyla yeniden açılan talepler bu ikisini birbirinden ayırır.

Destek metrikleri takvim saatine göre mi yoksa çalışma saatine göre mi ölçülür?

Her ikisi de saklanır. Zendesk'in hazır Explore raporları takvim saatlerini gösterir; çalışma saatleri metrikleri ise kendi oluşturduğunuz raporlar için mevcuttur.

Geçen çeyreğin çözülen talepler sayısı neden değişti?

Çözülen taleplerin sayısı, şu anda çözülmüş veya kapatılmış olan talepleri içerir. Dönem bittikten sonra yeniden açılan bir talep, o dönemin sayısından düşer.

Çözüm süremi bir sektör kıyaslama değeriyle karşılaştırabilir miyim?

Sadece kabaca karşılaştırabilirsiniz. Tanımlar, zaman dilimi ve kanal dağılımı yapılandırılabilir olduğundan, yayınlanan bir rakam muhtemelen sizinkinden farklı kurallara göre ölçülmüştür.