Hizmet Talebi Yönetimi Veri Seti Templateiniz
Hizmet Talebi Yönetimi Veri Seti Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- İzlenecek temel hizmet talebi aktiviteleri
- Zendesk Support verileri için çıkarma yönlendirmeleri
Hizmet Talebi Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
EventTimestamp
|
Faaliyetin gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Olay zaman damgası veya Başlangıç zamanı, bir faaliyetin gerçekleştiği kesin anı kaydeder. Örneğin bir temsilcinin ne zaman atandığını, herkese açık bir yanıtın ne zaman gönderildiğini veya kayıt durumunun 'Resolved' olarak ne zaman değiştirildiğini gösterir. Bu zamansal veri, her Zendesk kaydının denetim günlüğünden alınır. Bu öznitelik, zamana dayalı tüm analizler için önemlidir. Olayları kronolojik sıraya koymak, faaliyetler arasındaki süreyi hesaplamak, bekleme sürelerini ölçmek ve genel vaka çevrim süresini analiz etmek için kullanılır. Darboğazları belirlemek ve SLA gibi zamana dayalı hedeflere göre performansı değerlendirmek için temel bir girdidir.
Neden önemli?
Bu zaman damgası olayları kronolojik sıraya koyar ve süre, performans ve darboğaz analizlerinin tamamı için gereklidir.
Nereden alınır?
Zendesk Ticket Audits API, her denetim olayı için 'created_at' alanı.
Örnekler
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
Faaliyet
ActivityName
|
Bir hizmet talebi için gerçekleşen iş faaliyetinin veya olayın adı. | ||
|
Açıklama
Faaliyet, hizmet talebi yaşam döngüsündeki belirli bir adımı veya olayı temsil eder. Örneğin 'Hizmet talebi oluşturuldu', 'Talep temsilciye atandı' veya 'Hizmet talebi çözüldü'. Bu faaliyetler, durum, atanan kişi ve öncelik gibi alanlardaki değişiklikleri ve yorum eklenmesini izleyen Zendesk kayıt denetim günlüğündeki kayıtlardan türetilir. Faaliyetleri analiz etmek, Process Mining'in temelini oluşturur. Süreç haritasını görselleştirmenize, adımlar arasındaki darboğazları belirlemenize ve yeniden işleme döngülerini analiz etmenize olanak tanır. Kuruluşlar, faaliyetlerin sırasını ve sıklığını anlayarak verimsizlikleri ve süreç iyileştirme fırsatlarını belirleyebilir.
Neden önemli?
Bu öznitelik, süreçteki adımları tanımlar ve süreç haritalarının görselleştirilmesini, süreç akışının, varyasyonların ve uyumluluğun analiz edilmesini sağlar.
Nereden alınır?
Kavramsal olarak Zendesk Ticket Audits API'de günlüğe alınan olaylardan türetilir. Örneğin 'status' alanının 'new' değerinden 'open' değerine değişmesi, 'Talep önceliklendirildi' gibi bir faaliyete eşlenebilir.
Örnekler
Hizmet talebi oluşturulduTemsilci yeniden atandıHizmet talebi çözüldü
|
|||
|
Hizmet Talebi Kimliği
ServiceRequestId
|
Zendesk içindeki her hizmet talebi kaydının benzersiz tanımlayıcısı. | ||
|
Açıklama
Zendesk'te genellikle Kayıt Kimliği olarak adlandırılan Hizmet Talebi Kimliği, her vaka için birincil anahtar görevi görür. Talep oluşturulduğu andan kapatıldığı ana kadar ilgili tüm faaliyetleri, yorumları ve durum değişikliklerini birbirine bağlar. Böylece tek bir talebin yaşam döngüsü uçtan uca eksiksiz biçimde izlenebilir. Process Mining analizinde bu öznitelik temel bir role sahiptir. Vakayı tanımlar, süreç akışlarının yeniden oluşturulmasını, varyantların belirlenmesini ve çevrim süresi gibi vaka düzeyindeki metriklerin hesaplanmasını sağlar. Genel süreç içindeki bağlamını anlayabilmek için Veri Seti içindeki her olay bir Hizmet Talebi Kimliğiyle ilişkilendirilmelidir.
Neden önemli?
Bu, bir hizmet talebinin yolculuğundaki tüm olayları birbirine bağlayan temel vaka tanımlayıcısıdır ve uçtan uca sürecin analiz edilmesini sağlar.
Nereden alınır?
Zendesk Tickets API, 'id' alanı.
Örnekler
102451024610247
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin hangi sistemden çıkarıldığını gösterir. | ||
|
Açıklama
Bu öznitelik, hizmet talebi verilerinin kaynağını belirtir. Bu süreç görünümünde değer sürekli olarak 'Zendesk Support' olur ve tüm hizmet yönetimi faaliyetleri için kayıt sistemini tanımlar. Birden fazla entegre sistemin bulunduğu ortamlarda bu alan, veri soyunu izlemek ve sorun gidermek için önemlidir. Analizlerin doğru sistemle sınırlandırılmasını sağlar ve çeşitli kaynaklardan birleştirilen verilerin ayırt edilmesine yardımcı olur.
Neden önemli?
Verilerin kaynak sistemini tanımlar, veri soyunun izlenmesini sağlar ve birden fazla sistemden gelen veriler birleştirildiğinde karışıklığı önler.
Nereden alınır?
Bu, veri çıkarma ve dönüştürme sırasında eklenen statik bir değerdir ('Zendesk Support').
Örnekler
Zendesk Support
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Zendesk Support'tan en son veri çıkarma işleminin tarih ve saatini kaydeder. Analiz edilen verilerin güncelliği hakkında bağlam sağlar ve kullanıcıların süreç görünümünün ne kadar güncel olduğunu anlamasına yardımcı olur. Sürekli izleme ve Dashboard kullanımı için bu bilgi önemlidir. Analistlerin ve iş kullanıcılarının gerçek zamana yakın verileri mi yoksa önceki bir döneme ait anlık görüntüyü mü incelediğini anlamasını sağlar. Bu durum, ulaşılan sonuçların geçerliliğini etkiler.
Neden önemli?
Verilerin güncelliği hakkında önemli bağlam sağlar ve kullanıcıların analizin ne kadar güncel olduğunu anlamasına yardımcı olur.
Nereden alınır?
Bu, veri çıkarma sırasında oluşturulan ve Veri Seti'ne zaman damgasıyla eklenen bir meta veri alanıdır.
Örnekler
2023-10-27T08:00:00Z
|
|||
|
Atanan ekip
AssignedTeam
|
Hizmet talebine atanan destek ekibi veya grup. | ||
|
Açıklama
Bu öznitelik, destek kuruluşu içindeki hangi ekip veya grubun hizmet talebinden sorumlu olduğunu gösterir. Zendesk içinde bu gruplar 'Groups' olarak adlandırılır. Talepler, tek bir temsilciye atanmasından önce çoğu zaman bir gruba atanır. Atanan Ekibe göre analiz yapmak, ekip düzeyindeki performansı ve iş yükünü anlamak için önemlidir. Hangi ekiplerin hangi talep türlerini ele aldığını, ortalama çözüm sürelerini ve SLA uyumluluk oranlarını anlamanıza yardımcı olur. Bu, Temsilci ve Ekip Performansı Dashboardu için temel boyutlardan biridir.
Neden önemli?
Ekip performansını, iş yükü dengesini ve farklı destek grupları arasındaki yönlendirme verimliliğini analiz etmenizi sağlar.
Nereden alınır?
Tickets API yanıtındaki 'group_id' alanını birleştirerek Zendesk Groups API.
Örnekler
1. Seviye DestekTeknik DestekFaturalama
|
|||
|
Bilet etiketleri
TicketTags
|
Hizmet talebini kategorilere ayırmak ve yönlendirmek için uygulanan etiketlerin listesi. | ||
|
Açıklama
Etiketler, temsilciler tarafından manuel olarak veya iş kuralları aracılığıyla otomatik şekilde biletlere eklenebilen esnek tanımlardır. Tür veya Öncelik gibi standart alanlarda yer almayan belirli bağlamları ya da kategorileri bilete eklemek için kullanılır. Etiketler, Process Mining analizleri için son derece kullanışlı bir özniteliktir. Çok özel senaryolara göre filtreleme yapmak, özel iş akışlarını izlemek veya kök nedenleri belirlemek için kullanılabilir. Örneğin, VIP etiketi önemli müşterilere ait süreci analiz etmek, product_bug etiketi ise hata raporlarının yaşam döngüsünü izlemek için kullanılabilir.
Neden önemli?
Verileri esnek biçimde dilimleyip ayrıntılı incelemenizi sağlar. Böylece diğer alanlarda yer almayan belirli alt süreçleri veya bilet özniteliklerini analiz edebilirsiniz.
Nereden alınır?
Zendesk Tickets API, 'tags' alanı. Bu alan bir dizi metin değerinden oluşur.
Örnekler
satış_talebifaturalama_sorunuözellik_talebivip_müşteri
|
|||
|
Hizmet türü
ServiceType
|
Hizmet talebinin kategorisi veya türü, örneğin Incident, Question, Problem veya Task. | ||
|
Açıklama
Hizmet Türü, hizmet talebinin niteliğini sınıflandırır. Zendesk, farklı destek etkileşimlerini ayırmak için 'type' alanını kullanır. Bu ilk sınıflandırma, talebin doğru ekibe yönlendirilmesine ve uygun süreçlerin uygulanmasına yardımcı olur. Bu öznitelik filtreleme ve karşılaştırma için gereklidir. Analistlerin farklı talep türlerine ait süreç akışlarını incelemesini sağlar. Bu türlerin çözüm yolları ve SLA hedefleri çoğu zaman birbirinden oldukça farklıdır. Belirli talep türlerini kimin en iyi ele aldığını görmek için Temsilci ve Ekip Performansı Dashboardunda temel bir boyut olarak kullanılır.
Neden önemli?
Incident ve Question gibi farklı süreçleri ayrı ayrı analiz etmenizi sağlar. Bu talepler birbirinden farklı yollar izler.
Nereden alınır?
Zendesk Tickets API, 'type' alanı.
Örnekler
soruolaysorungörev
|
|||
|
Talep durumu
RequestStatus
|
Olay gerçekleştiği sırada hizmet talebinin durumu, örneğin New, Open veya Pending. | ||
|
Açıklama
Talep durumu, biletin belirli bir zamandaki durumunu gösterir. Zendesk, bir talebin yaşam döngüsü boyunca ilerlemesini işaretleyen New, Open, Pending, On-hold, Solved ve Closed gibi standart durumlar sunar. Bu alandaki değişiklikler, Event Log içinde aktivitelerin oluşturulmasını tetikleyen başlıca unsurlardır. Farklı durumlarda geçirilen süreyi analiz etmek, darboğaz analizinin temel parçalarından biridir. Biletlerin nerede takıldığını, örneğin Pending veya On-hold durumunda neden çok uzun süre kaldığını belirlemenize yardımcı olur. Durum geçişlerini anlamak, yeniden işleme döngülerini keşfetmek için de önemlidir.
Neden önemli?
Durumu izlemek, talebin ilerleyişini anlamak ve bekleme ya da aktif durumlarda ne kadar süre geçirildiğini belirlemek için temel bir gerekliliktir.
Nereden alınır?
Zendesk Tickets API, 'status' alanı.
Örnekler
YeniAçıkBeklemedeÇözüldüKapatıldı
|
|||
|
Talep kanalı
RequestChannel
|
Hizmet talebinin gönderildiği kanal, örneğin E-posta, Web Formu veya Telefon. | ||
|
Açıklama
Bu öznitelik, hizmet talebinin gönderildiği kanalı gösterir. Zendesk, bir talebin e-posta, web portalı, API entegrasyonu, sohbet veya başka kanallar üzerinden oluşturulup oluşturulmadığını kaydeder. Böylece müşterinin etkileşim yöntemi hakkında bağlam sağlar. Talep Kanalı, analiz için etkili bir boyuttur. Farklı kanallardaki çözüm sürelerini, memnuniyet puanlarını ve yeniden çalışma oranlarını karşılaştırarak 'Talep Kanalı Verimliliği' Dashboardunu destekler. Bu bilgiler, işletmelerin destek kanallarını optimize etmesine ve kullanıcıları en verimli kanallara yönlendirmesine yardımcı olabilir.
Neden önemli?
Farklı müşteri destek kanallarının verimliliğini ve sonuçlarını analiz etmenize, hedefli iyileştirmeler yapmanıza yardımcı olur.
Nereden alınır?
Zendesk Tickets API, 'via' nesnesi ve bu nesnenin 'channel' özelliği.
Örnekler
webe-postaapisohbet
|
|||
|
Talep önceliği
RequestPriority
|
Düşük, Normal, Yüksek veya Acil gibi hizmet talebine atanan öncelik düzeyi. | ||
|
Açıklama
Talep Önceliği, bir hizmet talebinin aciliyetini gösteren sınıflandırmadır. Bu düzey, çoğu zaman talebe uygulanacak hedef çözüm sürelerini ve SLA politikalarını belirler. Öncelik başlangıçta sistem veya kullanıcı tarafından belirlenebilir ve talebin yaşam döngüsü boyunca bir temsilci tarafından değiştirilebilir. Bu öznitelik segmentasyon ve temel neden analizi için önemlidir. Yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı çözülüp çözülmediğini analiz etmenizi sağlar. Ayrıca 'Hizmet Talebi Eskalasyon Eğilimleri' ve 'SLA Uyumluluğu' Dashboardlarında temel bir etkendir.
Neden önemli?
Talepleri aciliyet düzeyine göre segmentlere ayırmanızı sağlar. Bu, SLA uyumluluğunu analiz etmek ve acil sorunların zamanında ele alınmasını sağlamak için önemlidir.
Nereden alınır?
Zendesk Tickets API, 'priority' alanı.
Örnekler
DüşükNormalYüksekAcil
|
|||
|
Temsilci adı
AgentName
|
Olay gerçekleştiği sırada hizmet talebine atanmış temsilcinin adı. | ||
|
Açıklama
Bu öznitelik, hizmet talebini ele almaktan sorumlu destek temsilcisini gösterir. Atanan temsilci, talebin yaşam döngüsü boyunca birden çok kez değişebilir ve bu alan her adımda kimin sorumlu olduğunu kaydeder. Temsilci Adı, performans analizi için önemlidir. İş yükü dağılımını, temsilci başına çözüm sürelerini ve yeniden atama sıklığını değerlendirmek üzere verileri filtrelemenizi ve segmentlere ayırmanızı sağlar. Bu bilgiler, Temsilci ve Ekip Performansı Dashboardunu oluşturmanıza ve kişisel katkıların genel süreç verimliliğine etkisini anlamanıza yardımcı olur.
Neden önemli?
Bu öznitelik, temsilci performansını ve iş yükü dağılımını analiz etmek, yeniden atamaların çözüm sürelerine etkisini değerlendirmek için gereklidir.
Nereden alınır?
Zendesk Users API, Tickets API yanıtındaki 'assignee_id' alanıyla birleştirilerek.
Örnekler
Jane DoeJohn SmithEmily Jones
|
|||
|
Bitiş zamanı
EndTime
|
Faaliyetin tamamlandığı kesin tarih ve saat. | ||
|
Açıklama
Bitiş zamanı, bir faaliyetin tamamlandığı anı gösterir. Zendesk'teki birçok olay anlık gerçekleştiği için Bitiş zamanı Başlangıç zamanıyla aynıdır. Ancak 'Talep beklemeye alındı' gibi duruma dayalı faaliyetlerde Bitiş zamanı, kaydın beklemeden çıkarıldığı an olur. Bu öznitelik, belirli faaliyetlerin süresini hesaplamak için gereklidir ve darboğaz analizinde önemli rol oynar. Bir faaliyetin Başlangıç zamanı ile Bitiş zamanını karşılaştırarak işlem süresini doğrudan ölçebilir ve en fazla zaman alan adımları belirleyebilirsiniz.
Neden önemli?
Tek tek faaliyetlerin sürelerini hesaplamayı sağlar. Bu, süreç darboğazlarını belirlemek ve adım düzeyinde verimliliği ölçmek için önemlidir.
Nereden alınır?
Ayrık olaylarda genellikle Başlangıç zamanıyla aynıdır. Durum sürelerinde ise durumu değiştiren sonraki olayın zaman damgasıdır.
Örnekler
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
İlk iletişimde çözüm var mı
IsFirstContactResolution
|
Talebin, yeniden atama yapılmadan veya talep sahibinden yanıt alınmadan ilk atanan temsilci tarafından çözülüp çözülmediğini gösteren işaret. | ||
|
Açıklama
İlk İletişimde Çözüm (FCR), müşterinin sorununun tek bir etkileşimde çözüldüğünü gösteren önemli bir metriktir. Bu hesaplanmış öznitelik, bir bilet ilk atandığı temsilci tarafından, yeniden atama yapılmadan ve yalnızca bir temsilci yanıtıyla çözüldüğünde true değerini alır. Bu öznitelik, 'İlk İletişimde Çözüm Oranı' KPI'ını doğrudan destekler. FCR vakalarının özelliklerini analiz etmek, süreç mükemmelliği için bir model oluşturabilir. FCR sağlanamayan vakaları incelemek ise daha iyi temsilci eğitimi, geliştirilmiş bilgi tabanı makaleleri veya daha etkili ilk değerlendirme için fırsatları ortaya çıkarabilir.
Neden önemli?
Sorunları tek bir etkileşimde verimli biçimde çözme becerisini ölçer. Bu, hem müşteri memnuniyetini hem de operasyonel verimliliği güçlü biçimde etkiler.
Nereden alınır?
Bu, karmaşık bir hesaplanmış özniteliktir. Bir biletin Event Logunu inceleyerek temsilci yeniden atamalarını ve temsilcilerin herkese açık yanıt sayısını kontrol etmeyi gerektirir.
Örnekler
truefalse
|
|||
|
Memnuniyet puanı
SatisfactionRating
|
Bilet çözüldükten sonra talep sahibi tarafından verilen memnuniyet puanı. | ||
|
Açıklama
Bu öznitelik, müşterinin destek deneyimine ilişkin geri bildirimini gösterir. Geri bildirim genellikle bir bilet Solved olarak işaretlendikten sonra yapılan anketle toplanır. Yaygın puanlar arasında 'Good' ve 'Bad' bulunur; bazı yanıtlarda yorum da yer alabilir. Memnuniyet puanı, önemli bir sonuç metriğidir. Süreç örüntülerini memnuniyet puanlarıyla ilişkilendirmek, hangi süreç davranışlarının memnun veya memnuniyetsiz müşterilere yol açtığını ortaya çıkarabilir. Örneğin analiz, yüksek yeniden atama oranlarının veya uzun çözüm sürelerinin olumsuz memnuniyet puanlarıyla güçlü biçimde ilişkili olduğunu gösterebilir.
Neden önemli?
Süreç yürütümü ile müşteri sonuçları arasında doğrudan bağlantı kurarak müşteri memnuniyetini etkileyen süreç davranışlarını belirlemenize yardımcı olur.
Nereden alınır?
Zendesk Tickets API, 'satisfaction_rating.score' veya 'satisfaction_rating.reason' alanı.
Örnekler
İyiKötüSunuldu
|
|||
|
SLA ihlal edildi mi
IsSlaBreached
|
Hizmet talebinin SLA hedeflerinden herhangi birini ihlal edip etmediğini gösteren işaret. | ||
|
Açıklama
Bu öznitelik, bir biletin SLA sonucunu gösteren doğru/yanlış veya kategorik bir işarettir. Karşılandı, İhlal edildi veya Etkin gibi durumları gösterebilir. Sonuç, gerçek yanıt ya da çözüm sürelerinin uygulanan SLA politikasında tanımlanan hedeflerle karşılaştırılmasıyla belirlenir. Bu öznitelik, SLA uyumluluğu ve ihlal analizi Dashboardu için büyük önem taşır. Uyumluluğu olan ve olmayan biletlerin kolayca sayılmasını ve görselleştirilmesini sağlar. Ardından ihlal edilen biletlerin süreç özellikleri incelenerek uzun bekleme süreleri veya çok sayıda yeniden atama gibi kök nedenler belirlenebilir.
Neden önemli?
Performansı hizmet düzeyi taahhütlerine göre doğrudan ölçer. Bu, hizmet kalitesinin ve müşteri memnuniyetinin temel göstergelerinden biridir.
Nereden alınır?
Her biletin SLA durumu hakkında bilgi sağlayan Zendesk Ticket Metrics API'den türetilir.
Örnekler
Karşılandıİhlal edildiEtkin
|
|||
|
SLA politikası adı
SlaPolicyName
|
Talebe uygulanan Hizmet Düzeyi Anlaşması (SLA) politikasının adı. | ||
|
Açıklama
Bu öznitelik, hizmet talebi için hedef yanıt ve çözüm sürelerini belirleyen özel SLA politikasını tanımlar. Politika genellikle talebin önceliği, türü veya müşterinin abonelik düzeyi gibi faktörlere göre belirlenir. Uygulanan SLA politikasını bilmek, SLA uyumluluğu ve ihlal analizi Dashboardu için gereklidir. Farklı politikaların farklı hedefleri olabileceği için performansı değerlendirmek üzere gerekli bağlamı sağlar. Böylece bir biletin kendisi için belirlenen hizmet düzeyi hedeflerini karşılayıp karşılamadığı adil ve doğru şekilde değerlendirilebilir.
Neden önemli?
Bir talebin hangi hedeflere göre ölçüldüğünü göstererek SLA analizine bağlam sağlar ve doğru uyumluluk raporlamasına imkan verir.
Nereden alınır?
Zendesk Ticket Metrics API. SLA verileri çoğu zaman biletin metrikleriyle ilişkilendirilir.
Örnekler
Acil - 1 Saat İçinde YanıtStandart - 24 Saat İçinde ÇözümPremium Müşteri SLA'sı
|
|||
|
Talep sahibinin adı
RequestorName
|
Hizmet talebini gönderen son kullanıcının veya müşterinin adı. | ||
|
Açıklama
Bu öznitelik, hizmet talebini başlatan kişiyi gösterir. Talebi belirli bir müşteriyle ilişkilendirmek, destek sürecini kullanıcı odaklı bir bakışla incelemenizi sağlar. Süreç analizinde talep sahibi, belirli müşterilere veya müşteri segmentlerine ait örüntüleri incelemek için kullanılabilir. Örneğin bazı müşterilerin daha uzun çözüm süreleri yaşayıp yaşamadığını veya daha yüksek yeniden işleme oranlarına sahip olup olmadığını araştırabilirsiniz. Bu bulgular, kullandıkları ürün ya da hizmetle ilgili sorunlara işaret edebilir.
Neden önemli?
Süreci müşteriyle ilişkilendirerek müşteriye özgü sorunları, tekrarlanan talepleri ve memnuniyet düzeylerini analiz etmenizi sağlar.
Nereden alınır?
Tickets API yanıtındaki 'requester_id' alanını birleştirerek Zendesk Users API.
Örnekler
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Talep sahibinin kuruluşu
RequestorOrganization
|
Talep sahibinin bağlı olduğu kuruluş veya şirket. | ||
|
Açıklama
Bu öznitelik, hizmet talebini belirli bir müşteri kuruluşuyla ilişkilendirir. Hizmet düzeyi anlaşmaları ve destek sözleşmeleri çoğu zaman kuruluş düzeyinde tanımlandığından, bu özellikle B2B destek senaryolarında önemlidir. Verileri kuruluşa göre analiz etmek, destek performansını şirket düzeyinde görmenizi sağlar. Çok sayıda bilet oluşturan, tekrarlanan sorunlar yaşayan veya düşük memnuniyet puanlarına sahip kuruluşları belirlemenize yardımcı olabilir. Bu bilgi, hesap yönetimi ve müşterilerin genel durumundaki eğilimleri belirlemek için değerlidir.
Neden önemli?
Talepleri şirkete göre gruplayarak B2B hizmet analizini mümkün kılar. Bu, müşteri ilişkilerini ve SLA'ları kuruluş düzeyinde yönetmek için önemlidir.
Nereden alınır?
Tickets API yanıtındaki 'organization_id' alanını birleştirerek Zendesk Organizations API.
Örnekler
Acme CorporationGlobal Tech Inc.Innovate Solutions
|
|||
|
Temsilci yeniden atama sayısı
AgentReassignmentCount
|
Bir talebin bir temsilciden başka bir temsilciye toplam kaç kez yeniden atandığı. | ||
|
Açıklama
Bu öznitelik, bir biletteki 'assignee_id' alanı her değiştiğinde artan bir sayaçtır. Tek bir biletteki yüksek yeniden atama sayısı; yanlış ilk yönlendirme, temsilcinin yeterli bilgiye sahip olmaması veya talebin tek bir temsilcinin yönetemeyeceği kadar karmaşık olması gibi çeşitli süreç sorunlarına işaret edebilir. Bu, süreç verimliliğini ölçmek için temel bir metriktir ve 'Temsilci Yeniden Atama Oranı' KPI'ını doğrudan destekler. Yeniden atama sayısı yüksek vakaları analiz etmek, yönlendirme kurallarını, temsilci eğitimini veya bilgi tabanı kaynaklarını iyileştirme fırsatlarını ortaya çıkarabilir. Böylece biletler daha hızlı biçimde doğru kişiye ulaşır.
Neden önemli?
Dahili devirleri ölçmenize ve süreçteki sürtünme noktalarını belirlemenize yardımcı olur. Yüksek yeniden atama oranları çoğu zaman gecikmelere ve verimsizliğe yol açar.
Nereden alınır?
Her bilet için Zendesk Ticket Audits API'deki 'assignee_id' değişikliklerinin sayılmasıyla hesaplanır.
Örnekler
013
|
|||
|
Yeniden işleme var mı
IsRework
|
Hizmet talebi çözüldükten sonra yeniden açıldıysa true olan işaret. | ||
|
Açıklama
Bu doğru/yanlış işareti, yeniden çalışma içeren vakaları belirler. Bir hizmet talebi, durumu Çözüldü durumundan yeniden açık bir duruma geçtiğinde genellikle yeniden çalışma olarak kabul edilir. Bu durum, ilk çözümün yeterli olmadığını ve müşterinin aynı sorunla ilgili tekrar iletişime geçtiğini gösterir. Bu öznitelik, Hizmet Talebi Yeniden Çalışma Oranı temel performans göstergesini ve Yeniden Çalışma ve Yeniden Açma Etkinlik Analizi Dashboardunu hesaplamak için gereklidir. Yeniden çalışma içeren vakaları işaretleyerek verimsiz süreç akışlarını ayırabilir, yeniden açmaların kök nedenlerini bulabilir ve ilk iletişimde çözüm oranını artırabilirsiniz.
Neden önemli?
Çözümün kalıcı olmadığı süreç hatalarını belirler. Böylece müşteri memnuniyetini doğrudan etkileyen kalite ve verimlilik sorunlarını görünür kılar.
Nereden alınır?
Zendesk Ticket Audits API'de bir biletin durum dizisi analiz edilerek hesaplanır. 'solved' durumundan 'open' durumuna geçiş, yeniden işlemeyi gösterir.
Örnekler
truefalse
|
|||
Hizmet Talebi Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Herkese açık yanıt gönderildi
|
Bu faaliyet, bir temsilciden talep sahibine gönderilen her türlü iletişimi gösterir. Zendesk kayıt verilerinde 'public' özniteliğinin true olduğu açık bir 'Comment' olayı olarak kaydedilir. | ||
|
Neden önemli?
Bu olaylar iletişim sıklığını analiz etmek, temsilci yanıt sürelerini ölçmek ve çözüm için gereken etkileşim sayısını belirlemek açısından önemlidir.
Nereden alınır?
Kayıt verilerindeki açık bir 'Comment' olayıdır. Olay ayrıntılarında, bu olayı iç notlardan ayıran 'public: true' özniteliği bulunur.
Yakalayın
'public' bayrağının true olarak ayarlandığı kayıt 'Comment' olaylarından alınır.
Olay türü
explicit
|
|||
|
Hizmet talebi çözüldü
|
Bir temsilcinin çözüm sunduğu ve kayıt durumunu 'solved' olarak değiştirdiği noktayı gösterir. Talep, temsilcinin bakış açısından tamamlanmış sayılır ancak talep sahibi tarafından yeniden açılabilir. | ||
|
Neden önemli?
Bu, temsilcinin aktif çalışmasının sona erdiğini gösteren önemli bir kilometre taşıdır. Bu duruma ulaşma süresi, çözüm verimliliğinin temel ölçütlerinden biridir.
Nereden alınır?
Kayıt denetim günlüğünde 'status' alanındaki 'Change' olayından çıkarılır; yeni değer 'solved' olur.
Yakalayın
Denetim günlüğünde durumun 'solved' olduğu bir 'Change' olayından çıkarılır.
Olay türü
inferred
|
|||
|
Hizmet talebi kapatıldı
|
Hizmet talebinin nihai ve kalıcı olarak kapatılmasını gösterir. Bir kayıt, belirli bir süre 'solved' durumunda kaldıktan sonra otomatik olarak 'closed' durumuna geçer ve artık yeniden açılamaz. | ||
|
Neden önemli?
Bu faaliyet, hizmet talebi sürecinin kesin sonunu gösterir. Tam vaka süresini hesaplamak için son uç noktayı sağlar.
Nereden alınır?
Kayıt denetim günlüğünde 'status' alanındaki 'Change' olayından çıkarılır; yeni değer 'closed' olur.
Yakalayın
Denetim günlüğünde durumun 'closed' olduğu bir 'Change' olayından çıkarılır.
Olay türü
inferred
|
|||
|
Hizmet talebi oluşturuldu
|
Yeni bir kayıt herhangi bir kanal üzerinden talep sahibi tarafından gönderildiğinde hizmet talebi yaşam döngüsünün başlangıcını gösterir. Bu olay, Zendesk kayıt denetim günlüğünde 'Create' olayı olarak kaydedilir ve sürecin kesin başlangıç zamanını sağlar. | ||
|
Neden önemli?
Bu faaliyet, her hizmet talebi için temel başlangıç olayıdır. Bu nedenle uçtan uca çevrim sürelerini hesaplamak ve talep giriş hacimlerini analiz etmek için gereklidir.
Nereden alınır?
Zendesk kayıt denetim günlüğünde 'Create' olay türü olarak kaydedilir. Bu olayın zaman damgası, hizmet talebi kaydının oluşturulma zamanıdır.
Yakalayın
Doğrudan kayıt denetim günlüğündeki 'Create' olayından alınır.
Olay türü
explicit
|
|||
|
Hizmet talebi yeniden açıldı
|
Talep sahibi 'solved' durumundaki bir talebe yanıt verdiğinde gerçekleşir ve durum otomatik olarak yeniden 'open' olur. Bu, önerilen çözümün yeterli olmadığını gösterir. | ||
|
Neden önemli?
Bu faaliyet, yeniden işleme için temel göstergedir. Sıklığını analiz etmek, çözüm kalitesini ölçmeye ve müşteri memnuniyetsizliğinin nedenlerini belirlemeye yardımcı olur.
Nereden alınır?
Kayıt denetim günlüğünde 'status' alanındaki 'Change' olayından çıkarılır; önceki değer 'solved', yeni değer ise 'open' olur.
Yakalayın
Durumun 'solved' değerinden 'open' değerine değişmesinden çıkarılır.
Olay türü
inferred
|
|||
|
SLA hedefi ihlal edildi
|
Bir hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi tanımlanmış bir SLA hedefini karşılayamadığı anı gösterir. Bir hedef kaçırıldığında Zendesk bunu açık bir olay olarak günlüğe kaydeder. | ||
|
Neden önemli?
Bu olay, uyumluluk takibi için önemlidir ve SLA Uyum Oranı KPI'ının temel girdilerinden biridir. Hizmet taahhütlerinin karşılanamadığı noktaları belirler.
Nereden alınır?
Zendesk kayıt olayları veya denetim günlüğündeki 'SLABreach' olayından alınır. Olay, hangi SLA metriğinin ihlal edildiğini belirtir.
Yakalayın
Kayıt verilerindeki açık 'SLABreach' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Talep temsilciye atandı
|
Bir hizmet talebi ilk kez belirli bir temsilciye atandığında gerçekleşir. Kayıt denetim günlüğünde 'assignee_id' alanının null veya grup kimliğinden bir değere doldurulduğu 'Change' olayından çıkarılır. | ||
|
Neden önemli?
Bu olay, temsilcinin aktif çalışmasının başlangıcını gösterir ve ilk yanıt süresini, ilk atama gecikmesini ve temsilci iş yükü dağılımını ölçmek için önemlidir.
Nereden alınır?
Kayıt denetim günlüğünde 'assignee_id' alanına belirli bir kullanıcı kimliğinin atandığı ilk 'Change' olayından çıkarılır.
Yakalayın
'assignee_id' alanını bir temsilciye atayan ilk değişiklik olayından çıkarılır.
Olay türü
inferred
|
|||
|
İç not eklendi
|
Bir temsilci tarafından hizmet talebine, yalnızca diğer temsilcilerin görebileceği bir iç not veya yorum eklenmiştir. Bu işlem, 'public' özniteliğinin false olduğu bir 'Comment' olayı olarak kaydedilir. | ||
|
Neden önemli?
İç notları izlemek, temsilciler veya ekipler arasındaki iş birliği hakkında içgörü sağlar. Bu iş birliği gecikmeye neden olabilir veya sorunların verimli çözülmesini sağlayabilir.
Nereden alınır?
Kayıt verilerindeki açık bir 'Comment' olayıdır. Olay ayrıntılarında, bunun iç not olduğunu gösteren 'public: false' özniteliği bulunur.
Yakalayın
'public' bayrağının false olarak ayarlandığı kayıt 'Comment' olaylarından alınır.
Olay türü
explicit
|
|||
|
Öncelik değiştirildi
|
Hizmet talebinin 'Low', 'Normal', 'High' veya 'Urgent' gibi öncelik düzeyinin güncellendiğini gösterir. Kayıt denetim günlüğünde 'priority' alanındaki 'Change' olayı olarak kaydedilir. | ||
|
Neden önemli?
Öncelik değişikliklerini analiz etmek, zaman içinde aciliyeti artan talepleri belirlemeye ve önceliklendirme sürecinin etkili yönetilip yönetilmediğini değerlendirmeye yardımcı olur.
Nereden alınır?
Zendesk kayıt denetim günlüğünde 'priority' alanındaki 'Change' olayı olarak kaydedilir ve önceki ile yeni değerleri gösterir.
Yakalayın
Denetim günlüğündeki 'priority' alanına ait 'Change' olaylarından çıkarılır.
Olay türü
inferred
|
|||
|
SLA hedefi uygulandı
|
Bir Hizmet Seviyesi Anlaşması (SLA) politikasının hizmet talebi kaydına uygulandığı anı gösterir. Kayıt özellikleri etkin bir SLA politikasının koşullarıyla eşleştiğinde bu olay açıkça günlüğe kaydedilir. | ||
|
Neden önemli?
Bir SLA'nın ne zaman uygulandığını izlemek, uyumluluğu takip etmek, olası ihlalleri analiz etmek ve farklı talep türleri için beklenen hizmet zaman çizelgesini anlamak açısından önemlidir.
Nereden alınır?
Zendesk kayıt olayları veya denetim günlüğündeki 'SLAPolicyApplied' olayından alınır. Bu olay, hangi politikanın eşleştiğini belirtir.
Yakalayın
Kayıt verilerindeki açık 'SLAPolicyApplied' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Talep beklemeye alındı
|
Hizmet talebinin durumu genellikle temsilcinin talep sahibinden veya üçüncü bir taraftan bilgi beklediğini gösterecek şekilde 'on-hold' olarak değiştirildiğinde gerçekleşir. Bir durum değişikliği olayından çıkarılır. | ||
|
Neden önemli?
Bu, destek ekibinin doğrudan kontrolü dışındaki bekleme sürelerini ayırıp ölçmeye yardımcı olur ve temsilcinin işlem süresini daha doğru görmenizi sağlar.
Nereden alınır?
Kayıt denetim günlüğünde 'status' alanındaki 'Change' olayından çıkarılır; yeni değer 'on-hold' olur.
Yakalayın
Denetim günlüğünde durumun 'on-hold' olduğu bir 'Change' olayından çıkarılır.
Olay türü
inferred
|
|||
|
Talep üst seviyeye aktarıldı
|
Bir hizmet talebinin daha üst bir destek seviyesine, farklı bir ekibe veya yönetime resmî olarak aktarılmasını gösterir. Genellikle kaydın atandığı gruptaki değişiklikten veya aktarmaları izlemek için kullanılan özel bir alandaki değişiklikten çıkarılır. | ||
|
Neden önemli?
Üst seviyeye aktarmaları izlemek; karmaşık talepleri, ön safta çalışan temsilcilerin eğitim ihtiyaçlarını ve daha üst düzey müdahale gerektiren sistemik sorunları belirlemeye yardımcı olur.
Nereden alınır?
Bu standart bir olay değildir. 'group_id' alanının bir üst seviye aktarma grubuna değiştiği 'Change' olayından veya aktarma takibi için kullanılan özel kayıt alanındaki değişiklikten çıkarılmalıdır.
Yakalayın
'group_id' alanındaki veya özel 'escalation' alanındaki değişiklikten çıkarılır.
Olay türü
inferred
|
|||
|
Temsilci yeniden atandı
|
Bir hizmet talebinin sorumluluğunun bir temsilciden diğerine aktarılmasını gösterir. İlk atamadan sonra 'assignee_id' alanında gerçekleşen sonraki 'Change' olaylarından çıkarılır. | ||
|
Neden önemli?
Yeniden atamaları izlemek, süreç verimsizliklerini, hatalı yönlendirmeyi veya bilgi eksikliklerini belirlemeye yardımcı olan Temsilci Yeniden Atama Oranı KPI'ını hesaplamak için önemlidir.
Nereden alınır?
Kayıt denetim günlüğündeki 'assignee_id' alanına ait 'Change' olaylarından çıkarılır; kayda ait ilk atama olayı hariç tutulur.
Yakalayın
'assignee_id' alanındaki ikinci ve sonraki 'Change' olaylarından çıkarılır.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Hizmet talebi sürecinizi bugün optimize etmeye başlayın. Zendesk Support içindeki darboğazları ortaya çıkarmak ve verimliliği artırmak için bu Veri Seti Templateinden yararlanın.
Hizmet Talebi Yönetimini optimize edin. Gecikmeleri şimdi azaltın.
Yavaş hizmet sunumuna ve kullanıcı memnuniyetsizliğine son verin. %70 otomasyona ulaşın.
Kredi kartı gerekmez. Hızlı kurulum.