Hizmet Talebi Yönetimi Data Template'iniz

Zendesk Support
Hizmet Talebi Yönetimi `Data Template`'iniz

Hizmet Talebi Yönetimi Data Template'iniz

Bu `template`, Zendesk Support'taki Hizmet Talebi Yönetimi sürecinizi analiz etmek için gerekli verileri çıkarmak üzere kapsamlı bir rehber sunar. Toplanacak temel `data` özniteliklerini, izlenecek ana etkinlikleri ve bu bilgileri sisteminizden doğrudan nasıl çıkaracağınıza dair pratik rehberliği özetler. `Process Mining` girişimleriniz için sağlam bir `event log` oluşturmak üzere bu kaynağı kullanın.
  • Kapsamlı analiz için önerilen özellikler
  • İzlenecek temel `hizmet talebi` etkinlikleri
  • Zendesk Destek verileri için veri çıkarma rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Hizmet Talebi Yönetimi Öznitelikleri

Bunlar, Zendesk Support içinde kapsamlı hizmet talebi yönetimi analizi için `event log`'unuza dahil etmeniz önerilen `data` alanlarıdır.
5 Gerekli 7 Önerilen 10 İsteğe Bağlı
Ad Açıklama
Aktivite
ActivityName
Bir hizmet talebi için meydana gelen iş etkinliğinin veya `event`'inin adı.
Açıklama

Etkinlik, hizmet talebi yaşam döngüsündeki 'Hizmet Talebi Oluşturuldu', 'Talep Temsilciye Atandı' veya 'Hizmet Talebi Çözüldü' gibi ayrı bir adımı veya olayı temsil eder. Bu etkinlikler, Zendesk biletinin denetim kaydında kaydedilen, durum, atanan kişi, öncelik gibi alanlardaki değişikliklerden ve yorum eklemelerinden türetilir.

Etkinlikleri analiz etmek, Process Mining'in temelidir. Süreç haritasının görselleştirilmesini, adımlar arasındaki darboğazların belirlenmesini ve yeniden işleme döngülerinin analizini sağlar. Etkinliklerin sırasını ve sıklığını anlayarak kuruluşlar verimsizlikleri ve süreç iyileştirme fırsatlarını belirleyebilir.

Neden önemli

Bu öznitelik, süreç haritalarının görselleştirilmesini ve süreç akışının, varyasyonların ve uygunluğun analizini sağlayan süreçteki adımları tanımlar.

Nereden alınır

Bu, kavramsal olarak Zendesk Bilet Denetimleri API'sında günlüğe kaydedilen eventlerden türetilmiştir. Örneğin, 'durum' alanındaki 'yeni'den 'açık'a bir değişiklik, 'Talep Tasnif Edildi' gibi bir etkinliğe eşlenebilir.

Örnekler
Servis Talebi OluşturulduAgent Yeniden AtandıHizmet Talebi Çözüldü
Başlangıç Zamanı
EventTimestamp
Aktivitenin meydana geldiği kesin tarih ve saat.
Açıklama

Event Timestamp veya Başlangıç Zamanı, bir etkinliğin gerçekleştiği tam anı kaydeder. Örneğin, bir agent'ın ne zaman atandığını, herkese açık bir yanıtın ne zaman gönderildiğini veya ticket durumunun 'Çözüldü' olarak ne zaman değiştirildiğini yakalar. Bu zamansal veri, her Zendesk ticket'ının denetim log'undan alınır.

Bu nitelik, zamana dayalı herhangi bir analiz için kritik öneme sahiptir. event'leri kronolojik olarak sıralamak, etkinlikler arasındaki süreyi hesaplamak, bekleme sürelerini ölçmek ve genel case cycle time'ını analiz etmek için kullanılır. Bottleneck'leri belirlemek ve SLA'lar gibi zamana dayalı hedeflere karşı performansı değerlendirmek için temeldir.

Neden önemli

Bu timestamp, eventleri kronolojik olarak sıralar ve tüm süre, performans ve darboğaz analizi için gereklidir.

Nereden alınır

Zendesk Bilet Denetimleri API'si, her denetim event'i için 'created_at' alanı.

Örnekler
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
Servis Talebi Kimliği
ServiceRequestId
Zendesk içindeki her hizmet talebi bileti için benzersiz tanımlayıcı.
Açıklama

Hizmet Talebi Kimliği, Zendesk'te genellikle Bilet Kimliği olarak adlandırılır ve her case için birincil anahtar görevi görür. Bir talep oluşturulduğu andan kapatıldığı ana kadar tüm ilgili etkinlikleri, yorumları ve durum değişikliklerini birbirine bağlar. Bu, tek bir talebin yaşam döngüsünün eksiksiz, uçtan uca izlenmesini sağlar.

Process Mining analizinde bu öznitelik temeldir. Süreci tanımlar, süreç akışlarının yeniden yapılandırılmasını, varyantların belirlenmesini ve döngü süresi gibi case düzeyindeki metriklerin hesaplanmasını sağlar. dataset'teki her event, genel süreç içindeki bağlamını anlamak için bir Hizmet Talebi Kimliği ile ilişkilendirilmelidir.

Neden önemli

Bu, bir hizmet talebinin yolculuğundaki tüm eventleri birbirine bağlayan temel case tanımlayıcısıdır ve uçtan uca sürecin analiz edilmesini mümkün kılar.

Nereden alınır

Zendesk Biletleri API'si, 'id' alanı.

Örnekler
102451024610247
Kaynak Sistem
SourceSystem
Verinin hangi sistemden çıkarıldığını gösterir.
Açıklama

Bu öznitelik, hizmet talebi data'sının kaynağını belirtir. Bu süreç görünümü için değer sürekli olarak 'Zendesk Support' olacaktır ve bunu tüm hizmet yönetimi etkinlikleri için kayıt sistemi olarak tanımlar.

Birden çok entegre sistemin bulunduğu ortamlarda, bu alan data soy ağacı ve sorun giderme için çok önemlidir. Analizlerin hedeflenen sisteme doğru şekilde kapsamlandırılmasını sağlar ve çeşitli kaynaklardan birleştirildiğinde data'yı ayırt etmeye yardımcı olur.

Neden önemli

Verinin kaynak sistemini belirler, veri akışını sağlar ve birden çok sistemden gelen veriler birleştirildiğinde karışıklığı önler.

Nereden alınır

Bu, data çekimi ve dönüşümü sırasında eklenen statik bir değerdir ('Zendesk Support').

Örnekler
Zendesk Support
Son Veri Güncellemesi
LastDataUpdate
Verilerin kaynak sistemden son yenilendiği zamanı gösteren `timestamp`.
Açıklama

Bu öznitelik, Zendesk Support'tan yapılan en son data çekiminin tarih ve saatini kaydeder. Analiz edilen data'nın güncelliği hakkında bağlam sağlar, böylece kullanıcıların süreç görünümünün ne kadar güncel olduğunun farkında olmasını sağlar.

Devam eden izleme ve dashboard oluşturma için bu bilgi hayati öneme sahiptir. Analistlerin ve iş kullanıcılarının, neredeyse gerçek zamanlı data mı yoksa önceki bir döneme ait bir anlık görüntüye mi baktıklarını anlamalarını sağlar; bu da sonuçlarının geçerliliğini etkiler.

Neden önemli

Veri tazeliği hakkında önemli bağlam sağlar, kullanıcıların analizin ne kadar güncel olduğunu bilmesini sağlar.

Nereden alınır

Bu, data çekimi anında dataset üzerinde oluşturulan ve damgalanan bir metadata alanıdır.

Örnekler
2023-10-27T08:00:00Z
Atanan Ekip
AssignedTeam
Hizmet talebine atanan destek ekibi veya grubu.
Açıklama

Bu öznitelik, destek kuruluşu içindeki hangi ekibin veya grubun hizmet talebinden sorumlu olduğunu gösterir. Zendesk'te bunlar 'Gruplar' olarak bilinir. Biletler genellikle bir bireysel temsilci tarafından alınmadan önce bir gruba atanır.

Atanan Ekip'e göre analiz yapmak, ekip düzeyinde performansı ve iş yükünü anlamak için çok önemlidir. Hangi ekiplerin hangi tür talepleri işlediği, ortalama çözüm süreleri ve SLA uyumluluk oranları hakkında soruları yanıtlamaya yardımcı olur. Bu, Agent & Team Performance dashboard'u için birincil bir boyuttur.

Neden önemli

Farklı destek grupları arasında ekip performansı, iş yükü dengeleme ve yönlendirme verimliliği analizini sağlar.

Nereden alınır

Zendesk Gruplar API'si, Biletler API yanıtındaki 'group_id' ile birleştirilerek.

Örnekler
1. Kademe DestekTeknik DestekFaturalandırma
Bilet Etiketleri
TicketTags
Kategorizasyon ve yönlendirme için `hizmet talebi`ne uygulanan `tag`'lerin bir listesi.
Açıklama

Etiketler, temsilciler tarafından manuel olarak veya iş kuralları aracılığıyla otomatik olarak biletlere eklenebilen esnek etiketlerdir. Bir bilete Tür veya Öncelik gibi standart alanlar tarafından kapsanmayan belirli bir bağlam veya kategori eklemek için kullanılırlar.

Etiketler, Process Mining analizi için son derece çok yönlü bir özniteliktir. Çok özel senaryoları filtrelemek, özel workflow'ları izlemek veya temel nedenleri belirlemek için kullanılabilirler. Örneğin, önemli müşteriler için süreci analiz etmek için bir 'VIP' etiketi veya hata raporlarının yaşam döngüsünü izlemek için bir 'product_bug' etiketi kullanılabilir.

Neden önemli

Veriyi dilimleme ve zar atma için esnek bir yol sunar, belirli alt süreçlere veya diğer alanlarda yakalanmayan ticket niteliklerine derinlemesine analiz yapmaya olanak tanır.

Nereden alınır

Zendesk Biletleri API'si, 'tags' alanı. Bu bir dizi (array) string'dir.

Örnekler
satış_sorgusufaturalandırma_sorunuözellik_talebivip_müşteri
Hizmet Türü
ServiceType
Hizmet talebinin kategorisi veya türü (örn. Olay, Soru, Sorun, Görev).
Açıklama

Hizmet Türü, hizmet talebinin niteliğini kategorize eder. Zendesk, farklı destek etkileşimlerini ayırt etmek için bir 'tür' alanı kullanır. Bu başlangıç sınıflandırması, biletin 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 çok önemlidir. Analistlerin, genellikle çok farklı çözüm yolları ve SLA'lara sahip farklı talep türleri için süreç akışlarını incelemesini sağlar. Belirli talep türlerini en iyi kimin ele aldığını görmek için Agent & Team Performance dashboard'u için önemli bir boyuttur.

Neden önemli

Talepleri, benzersiz yolları izleyen olaylar ve sorular gibi farklı süreçlerin ayrı ayrı analiz edilmesine olanak tanımak için kategorize eder.

Nereden alınır

Zendesk Biletleri API'si, 'type' alanı.

Örnekler
questionolayproblemtask
Talep Durumu
RequestStatus
`event` anındaki hizmet talebinin durumu (örn. Yeni, Açık, Beklemede).
Açıklama

Talep Durumu, ticket'ın belirli bir zamandaki durumunu temsil eder. Zendesk'in Yeni, Açık, Beklemede, Beklemeye Alındı, Çözüldü ve Kapalı gibi birkaç standart durumu vardır ve bunlar bir talebin yaşam döngüsü boyunca ilerlemesini işaret eder. Bu alandaki değişiklikler, event log'unda etkinlikler oluşturmak için birincil tetikleyicilerdir.

Farklı durumlarda harcanan süreyi analiz etmek, bottleneck analizinin temel bir parçasıdır. Örneğin, 'Pending' veya 'On-hold' durumunda çok fazla zaman harcanması gibi ticket'ların nerede takılı kaldığını belirlemeye yardımcı olur. Durum geçişlerini anlamak, yeniden işleme döngülerini keşfetmek için de anahtardır.

Neden önemli

Durumu takip etmek, talebin ilerlemesini anlamak ve bekleme veya aktif durumlarda ne kadar zaman harcandığını belirlemek için temeldir.

Nereden alınır

Zendesk Biletleri API'si, 'status' alanı.

Örnekler
YeniAçıkBeklemedeÇözüldüKapalı
Talep Kanalı
RequestChannel
Hizmet talebinin gönderildiği kanal (örn. E-posta, Web Formu, Telefon).
Açıklama

Bu öznitelik, hizmet talebinin gönderim kaynağını tanımlar. Zendesk, bir biletin e-posta, web portalı, API entegrasyonu, sohbet veya diğer kanallar aracılığıyla nasıl oluşturulduğunu yakalar. Bu, müşterinin etkileşim yöntemi hakkında bağlam sağlar.

Talep Kanalı, analiz için güçlü bir boyuttur. Çözüm sürelerinin, memnuniyet derecelerinin ve yeniden işleme oranlarının farklı kanallar arasında karşılaştırılmasına izin vererek 'Talep Kanalı Verimliliği' dashboard'unu destekler. Bu, işletmelerin destek kanallarını optimize etmesine ve kullanıcıları en verimli olanlara yönlendirmesine yardımcı olabilir.

Neden önemli

Farklı müşteri destek kanallarının verimliliğini ve sonuçlarını analiz etmeye yardımcı olur, hedeflenen iyileştirmeleri mümkün kılar.

Nereden alınır

Zendesk Biletleri API'si, 'via' nesnesi ve 'channel' özelliği.

Örnekler
webemailapichat
Talep Önceliği
RequestPriority
Hizmet talebine atanan öncelik seviyesi (örn. Düşük, Normal, Yüksek veya Acil).
Açıklama

Talep Önceliği, bir hizmet talebinin aciliyetini gösteren bir sınıflandırmadır. Bu seviye genellikle hedef çözüm sürelerini ve ticket'a uygulanan SLA politikalarını belirler. Öncelik başlangıçta sistem veya kullanıcı tarafından ayarlanabilir ve ticket'ın yaşam döngüsü boyunca bir agent tarafından değiştirilebilir.

Bu nitelik, segmentasyon ve temel neden analizi için çok önemlidir. Yüksek öncelikli ticket'ların düşük öncelikli olanlardan daha hızlı çözülüp çözülmediğini analiz etmeye yardımcı olur ve 'Hizmet Talebi Eskalasyon Trendleri' ve 'SLA Uyumu' dashboard'larında önemli bir faktördür.

Neden önemli

Talepleri aciliyetine göre segmentlere ayırmaya olanak tanır; bu da SLA uyumluluğunu analiz etmek ve kritik sorunların derhal ele alınmasını sağlamak için çok önemlidir.

Nereden alınır

Zendesk Biletleri API'si, 'priority' alanı.

Örnekler
DüşükNormalYüksekAcil
Temsilci Adı
AgentName
`event` anında hizmet talebine atanan temsilcinin adı.
Açıklama

Bu öznitelik, hizmet talebini ele almaktan sorumlu destek temsilcisini tanımlar. Atanan temsilci, biletin yaşam döngüsü boyunca birden çok kez değişebilir ve bu alan, her adımda kimin sorumlu olduğunu yakalar.

Temsilci Adı, performans analizi için kritik öneme sahiptir. İş yükü dağılımını, temsilci başına çözüm sürelerini ve yeniden atamaların sıklığını değerlendirmek için verilerin filtrelenmesine ve bölümlere ayrılmasına olanak tanır. Bu, Agent & Team Performance dashboard'unu oluşturmaya ve genel süreç verimliliğine bireysel katkıları anlamaya yardımcı olur.

Neden önemli

Bu öznitelik, temsilci performansını, iş yükü dağılımını ve yeniden atamaların çözüm süreleri üzerindeki etkisini analiz etmek için hayati öneme sahiptir.

Nereden alınır

Zendesk Kullanıcıları API'si, Biletler API yanıtındaki 'assignee_id' ile birleştirilerek.

Örnekler
Ayşe YılmazCan DemirEmily Jones
Agent Yeniden Atama Sayısı
AgentReassignmentCount
Bir talebin bir temsilciden diğerine yeniden atandığı toplam sayı.
Açıklama

Bu öznitelik, bir biletteki 'assignee_id' alanının her değiştiğinde artan bir sayaçtır. Tek bir bilet için yüksek yeniden atama sayısı, yanlış başlangıç yönlendirmesi, temsilci bilgi eksikliği veya tek bir temsilcinin ele alması için çok karmaşık talepler gibi çeşitli süreç sorunlarını gösterebilir.

Bu, süreç verimliliğini ölçmek için önemli bir metriktir ve 'Temsilci Yeniden Atama Oranı' KPI'sını doğrudan destekler. Yüksek yeniden atama sayılarına sahip case'leri analiz etmek, biletlerin doğru kişiye daha hızlı ulaşmasını sağlamak için yönlendirme kurallarını, temsilci eğitimini veya bilgi tabanı kaynaklarını iyileştirme fırsatlarını ortaya çıkarabilir.

Neden önemli

Dahili el değiştirmeleri nicelendirmeye ve süreç sürtünmesini belirlemeye yardımcı olur, çünkü yüksek yeniden atama oranları genellikle gecikmelere ve verimsizliğe yol açar.

Nereden alınır

Her ticket için Zendesk Ticket Audits API'sindeki 'assignee_id' değişikliklerinin sayısının sayılmasıyla hesaplanır.

Örnekler
013
Bitiş Saati
EndTime
Etkinliğin tamamlandığı kesin tarih ve saat.
Açıklama

Bitiş Zamanı, bir etkinliğin tamamlanmasını gösterir. Zendesk'teki birçok event için süre anlıktır, bu nedenle Bitiş Zamanı, Başlangıç Zamanı ile aynıdır. Ancak, 'Talep Beklemeye Alındı' gibi durum tabanlı etkinlikler için Bitiş Zamanı, biletin beklemeye alındığı zaman olacaktır.

Bu öznitelik, darboğaz analizi için anahtar olan belirli etkinliklerin süresini hesaplamak için gereklidir. Bir etkinliğin Başlangıç Zamanı ve Bitiş Zamanı karşılaştırılarak, doğrudan işleme süresi ölçülebilir ve hangi adımların en çok zaman tükettiğini belirlemeye yardımcı olur.

Neden önemli

Bireysel etkinlik sürelerinin hesaplanmasını sağlar; bu da process bottleneck'lerini belirlemek ve adım düzeyinde verimliliği ölçmek için çok önemlidir.

Nereden alınır

Bu, ayrık eventler için genellikle Başlangıç Zamanı ile aynıdır. Durum süreleri için, durumu değiştiren bir sonraki event'in timestamp'idir.

Örnekler
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
Hizmet Talebi Döngü Süresi
ServiceRequestCycleTime
Bir hizmet talebinin oluşturulmasından nihai çözümüne kadar geçen toplam süre.
Açıklama

Bu hesaplanmış metrik, bir hizmet talebinin uçtan uca işleme süresini ölçer. Genellikle 'Hizmet Talebi Çözüldü' etkinliği ile 'Hizmet Talebi Oluşturuldu' etkinliği arasındaki zaman farkı olarak hesaplanır. Bu, herhangi bir destek süreci için en önemli üst düzey KPI'lardan biridir.

Bu öznitelik, 'Ortalama Hizmet Talebi Döngü Süresi' KPI'sını ve 'Uçtan Uca Döngü Süresi' dashboard'unu doğrudan destekler. Bu metriği talep türü veya öncelik gibi farklı boyutlar arasında analiz etmek, genel verimlilik üzerinde hangi faktörlerin en büyük etkiye sahip olduğunu belirlemeye yardımcı olur.

Neden önemli

Bu, genel süreç verimliliğini ve müşteri deneyimini ölçmek için birincil bir KPI olup, bir çözüm sunmanın ne kadar sürdüğünü gösterir.

Nereden alınır

Bir case için ilk ve son (çözüm) event timestamp'ları arasındaki fark olarak hesaplanır.

Örnekler
259200s (3 gün)86400s (1 gün)3600s (1 saat)
İlk Temas Çözünürlüğü mü?
IsFirstContactResolution
Talebin, ilk atanan `agent` tarafından, yeniden atama veya talep edenden yanıt gelmeden çözülüp çözülmediğini gösteren bir `flag`.
Açıklama

İlk Temas Çözümü (FCR), bir müşterinin sorununun tek bir etkileşimde çözüldüğünü gösteren kritik bir metric'tir. Bu hesaplanmış nitelik, bir ticket'ın, yeniden atama yapılmadan ve yalnızca bir agent yanıtıyla, ilk atandığı agent tarafından çözüldüyse doğru olan bir boolean flag'idir.

Bu nitelik, 'İlk Temas Çözüm Oranı' KPI'sını doğrudan destekler. FCR vakalarının özelliklerini analiz etmek, süreç mükemmelliği için bir yol haritası sağlayabilir. Tersine, FCR'ı başaramayan vakaları analiz etmek, daha iyi agent eğitimi, geliştirilmiş bilgi tabanı makaleleri veya daha etkili ilk triyaj için fırsatları vurgulayabilir.

Neden önemli

Sorunları tek bir dokunuşta verimli bir şekilde çözme yeteneğini ölçer; bu da hem müşteri memnuniyetinin hem de operasyonel verimliliğin güçlü bir itici gücüdür.

Nereden alınır

Bu, karmaşık bir hesaplanmış özniteliktir. Temsilci yeniden atamalarını ve temsilcilerden gelen herkese açık yanıt sayısını kontrol etmek için bir biletin event log'unun analiz edilmesini gerektirir.

Örnekler
truefalse
Memnuniyet Puanı
SatisfactionRating
Bilet çözüldükten sonra talep eden tarafından verilen memnuniyet puanı.
Açıklama

Bu öznitelik, müşterinin destek deneyimi hakkındaki geri bildirimlerini yakalar ve genellikle bir bilet çözüldü olarak işaretlendikten sonra bir anket aracılığıyla toplanır. Yaygın derecelendirmeler arasında 'İyi' veya 'Kötü' bulunur, bazen bir yorumla birlikte.

Memnuniyet Derecesi kritik bir sonuç metriğidir. Süreç kalıplarını memnuniyet puanlarıyla ilişkilendirmek, hangi süreç davranışlarının mutlu veya mutsuz müşterilere yol açtığını ortaya çıkarabilir. Örneğin, analizler yüksek yeniden atama oranlarının veya uzun çözüm sürelerinin olumsuz memnuniyet derecelendirmeleriyle güçlü bir şekilde ilişkili olduğunu gösterebilir.

Neden önemli

Süreç yürütme ile müşteri sonuçları arasında doğrudan bir bağlantı sağlar, hangi süreç davranışlarının müşteri memnuniyetini sağladığını belirlemeye yardımcı olur.

Nereden alınır

Zendesk Biletleri API'si, 'satisfaction_rating.score' veya 'satisfaction_rating.reason' alanı.

Örnekler
İyiKötüSunuldu
SLA İhlal Edildi mi?
IsSlaBreached
Hizmet talebinin herhangi bir SLA hedefini ihlal edip etmediğini gösteren bir `flag`.
Açıklama

Bu öznitelik, bir bilet için SLA sonucunu gösteren bir boole veya kategorik bayraktır. 'Karşılandı', 'İhlal Edildi' veya 'Aktif' gibi durumları gösterebilir. Bu, gerçek yanıt veya çözüm sürelerinin uygulanan SLA politikasında tanımlanan hedeflerle karşılaştırılmasıyla belirlenir.

Bu, 'SLA Uyumluluk ve İhlal Analizi' dashboard'u için kritik bir özniteliktir. Uyumlu ve uyumsuz biletlerin kolayca sayılmasını ve görselleştirilmesini sağlar. Daha fazla analiz, uzun bekleme süreleri veya aşırı yeniden atamalar gibi temel nedenleri belirlemek için ihlal edilmiş biletlerin süreç özelliklerine odaklanabilir.

Neden önemli

Hizmet seviyesi taahhütlerine karşı performansı doğrudan ölçer, bu da hizmet kalitesinin ve müşteri memnuniyetinin önemli bir göstergesidir.

Nereden alınır

Her ticket için SLA durumu hakkında bilgi sağlayan Zendesk Ticket Metrikleri API'sinden türetilmiştir.

Örnekler
Karşılandıİhlal EdildiAktif
SLA Politikası Adı
SlaPolicyName
Talebe uygulanan Hizmet Seviyesi Anlaşması (SLA) politikasının adı.
Açıklama

Bu öznitelik, hizmet talebi için hedef yanıt ve çözüm sürelerini yöneten belirli SLA politikasını tanımlar. Bir politika genellikle talebin önceliği, türü veya müşterinin abonelik seviyesi gibi faktörlerle belirlenir.

Uygulanan SLA politikasını bilmek, 'SLA Uyumluluk ve İhlal Analizi' dashboard'u için çok önemlidir. Farklı politikaların farklı hedeflere sahip olacağı için performansı değerlendirmek için gerekli bağlamı sağlar. Bu, bir biletin belirli hizmet seviyesi hedeflerini karşılayıp karşılamadığının adil ve doğru bir şekilde değerlendirilmesini sağlar.

Neden önemli

Bir talebin hangi target setine karşı ölçüldüğünü belirleyerek SLA analizi için bağlam sağlar, doğru uyumluluk raporlamayı mümkün kılar.

Nereden alınır

Zendesk Bilet Metrikleri API'si. SLA data'sı genellikle biletin metrikleriyle ilişkilendirilir.

Örnekler
Acil - 1 Saat YanıtStandart - 24 Saat ÇözümPremium Müşteri SLA'sı
Talep Eden 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 tanımlar. Talebi belirli bir müşteriye bağlamak, destek sürecine kullanıcı odaklı bir bakış açısı sağlar.

Süreç analizinde, talep eden belirli müşteriler veya müşteri segmentleri için kalıpları analiz etmek için kullanılabilir. Örneğin, bazı müşterilerin daha uzun çözüm süreleri deneyip deneyimlemediği veya daha yüksek yeniden işleme oranlarına sahip olup olmadığı incelenebilir; bu da kullandıkları bir ürün veya hizmetle ilgili sorunları gösterebilir.

Neden önemli

Süreci müşteriye bağlar, müşteriye özel sorunların, tekrar eden taleplerin ve memnuniyet seviyelerinin analiz edilmesini sağlar.

Nereden alınır

Zendesk Kullanıcıları API'si, Biletler API yanıtındaki 'requester_id' ile birleştirilerek.

Örnekler
Alice JohnsonBob Williams`Charlie Brown`
Talep Eden Kuruluş
RequestorOrganization
Talep edenin ait olduğu kuruluş veya şirket.
Açıklama

Bu öznitelik, hizmet talebini belirli bir müşteri kuruluşuna bağlar. Bu, hizmet seviyesi anlaşmalarının ve destek sözleşmelerinin genellikle kuruluş düzeyinde tanımlandığı B2B destek senaryolarında özellikle önemlidir.

Kuruluşa göre data analizi, destek performansının şirket düzeyinde bir görünümünü sağlar. Yüksek hacimli biletler oluşturan, tekrar eden sorunlar yaşayan veya düşük memnuniyet puanlarına sahip kuruluşları belirlemeye yardımcı olabilir. Bu, hesap yönetimi ve daha geniş müşteri sağlığı eğilimlerini belirlemek için değerlidir.

Neden önemli

Talepleri şirkete göre gruplandırarak B2B hizmet analizini sağlar; bu da kurumsal düzeyde müşteri ilişkilerini ve SLA'ları yönetmek için çok önemlidir.

Nereden alınır

Zendesk Kuruluşlar API'si, Biletler API yanıtındaki 'organization_id' ile birleştirilerek.

Örnekler
Acme Corporation`Global Tech Inc.`Çözümler Yenile
Yeniden İşleme mi?
IsRework
Hizmet talebinin çözüldükten sonra yeniden açılıp açılmadığını gösteren doğru/yanlış `flag`'i.
Açıklama

Bu boole bayrağı, yeniden işleme tabi tutulan case'leri tanımlar. Bir hizmet talebi, durumu 'Çözüldü'den tekrar açık bir duruma dönerse yeniden işleme olarak kabul edilir; bu, ilk çözümün yeterli olmadığını ve müşterinin aynı sorun hakkında takip etmesi gerektiğini gösterir.

Bu öznitelik, 'Hizmet Talebi Yeniden İşleme Oranı' KPI'sını ve 'Yeniden İşleme ve Yeniden Açılma Etkinlik Analizi' dashboard'unu hesaplamak için çok önemlidir. Yeniden işleme case'lerini işaretleyerek analistler bu verimsiz süreç akışlarını izole edebilir, yeniden açılmaların temel nedenlerini keşfedebilir ve ilk temasta çözümü iyileştirmek için çalışabilir.

Neden önemli

Çözümün nihai olmadığı süreç başarısızlıklarını belirler, doğrudan müşteri memnuniyetini etkileyen kalite ve verimlilik sorunlarını vurgular.

Nereden alınır

Zendesk Ticket Audits API'sindeki bir ticket için durum dizisinin analiz edilmesiyle hesaplanır. 'solved'dan 'open'a geçiş, yeniden işleme olduğunu gösterir.

Örnekler
truefalse
Gerekli Önerilen İsteğe Bağlı

Hizmet Talebi Yönetimi Etkinlikleri

Bunlar, hizmet taleplerinizin doğru süreç keşfi için `event log`'unuza kaydetmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
7 Önerilen 6 İsteğe Bağlı
Aktivite Açıklama
Herkese Açık Yanıt Gönderildi
Bu etkinlik, bir temsilciden talep edene gönderilen herhangi bir iletişimi işaretler. Bu, 'public' özniteliğinin doğru olduğu Zendesk bilet verilerinde açık bir 'Comment' (`yorum`) `event`'i olarak yakalanır.
Neden önemli

Bu eventler, 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 için çok önemlidir.

Nereden alınır

Bu, bilet data'sında açık bir 'Comment' (yorum) event'idir. event detayları, bunu dahili notlardan ayıran 'public: true' özniteliğini içerir.

Yakala

'public' flag'inin doğru olarak ayarlandığı ticket 'Comment' event'lerinden yakalanır.

Event tipi explicit
Hizmet Talebi Çözüldü
Bu etkinlik, bir temsilcinin bir çözüm sağladığı ve bilet durumunu 'çözüldü' olarak değiştirdiği noktayı işaretler. Talep, temsilcinin bakış açısından tamamlanmış kabul edilir, ancak talep eden tarafından yeniden açılabilir.
Neden önemli

Bu, aktif temsilci çalışmasının sonunu gösteren önemli bir kilometre taşıdır. Bu duruma ulaşma süresi, çözüm verimliliğinin birincil ölçüsüdür.

Nereden alınır

Ticket denetim log'undaki 'status' alanındaki, yeni değerin 'solved' olduğu bir 'Change' event'inden çıkarılır.

Yakala

Denetim log'unda durumun 'solved' olduğu bir 'Change' event'inden çıkarılır.

Event tipi inferred
Hizmet Talebi Kapatıldı
`Hizmet talebi`nin nihai, kalıcı kapanışını temsil eder. Bir `ticket`, 'solved' durumunda belirli bir süre kaldıktan sonra otomatik olarak 'closed' durumuna geçer ve artık yeniden açılamaz.
Neden önemli

Bu etkinlik, hizmet talebi sürecinin kesin sonunu işaretler. Tam case süresini hesaplamak için son bitiş noktasını sağlar.

Nereden alınır

Ticket denetim log'undaki 'status' alanındaki, yeni değerin 'closed' olduğu bir 'Change' event'inden çıkarılır.

Yakala

Denetim log'unda durumun 'closed' olduğu bir 'Change' event'inden çıkarılır.

Event tipi inferred
Hizmet Talebi Yeniden Açıldı
Bir talep eden, 'solved' durumundaki bir talebe yanıt verdiğinde meydana gelir ve durumunu otomatik olarak tekrar 'open' olarak değiştirir. Bu, önerilen çözümün yeterli olmadığını gösterir.
Neden önemli

Bu etkinlik, yeniden işin birincil göstergesidir. Sıklığını analiz etmek, çözüm kalitesini ölçmeye ve müşteri memnuniyetsizliğinin nedenlerini belirlemeye yardımcı olur.

Nereden alınır

Ticket denetim log'undaki 'status' alanındaki, önceki değerin 'solved' ve yeni değerin 'open' olduğu bir 'Change' event'inden çıkarılır.

Yakala

Durum değişikliğinden 'solved'dan 'open'a çıkarılır.

Event tipi inferred
Servis Talebi Oluşturuldu
Yeni bir `ticket`'ın bir talep eden tarafından herhangi bir kanal aracılığıyla gönderilmesiyle `hizmet talebi` yaşam döngüsünün başlangıcını işaret eder. Bu, Zendesk `ticket` denetim `log`'unda bir 'Create' `event`'i olarak yakalanır ve süreç için kesin bir başlangıç zamanı sağlar.
Neden önemli

Bu etkinlik, her hizmet talebi için birincil başlangıç event'i olarak hizmet eder ve uçtan uca döngü sürelerini hesaplamak ve talep alım hacimlerini analiz etmek için çok önemlidir.

Nereden alınır

Bu, Zendesk bilet denetim log'unda bir 'Oluşturma' event türü olarak kaydedilir. Bu event'in timestamp'i, hizmet talebi biletinin oluşturulma zamanıdır.

Yakala

Ticket denetim log'undaki 'Create' event'inden doğrudan yakalanır.

Event tipi explicit
SLA Hedefi İhlal Edildi
Bu etkinlik, bir hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi tanımlanmış bir SLA hedefini karşılayamadığı anı işaretler. Zendesk, bir hedef kaçırıldığında bunu açık bir `event` olarak günlüğe kaydeder.
Neden önemli

Bu, uyumluluk izleme için kritik bir event'tir ve SLA Uyumluluk Oranı KPI'sı için önemli bir girdidir. Hizmet taahhütlerini yerine getirememe durumlarını kesin olarak belirler.

Nereden alınır

Zendesk ticket event'leri veya denetim log'u içindeki 'SLABreach' event'inden yakalanır. event, hangi SLA metriğinin ihlal edildiğini belirtir.

Yakala

Ticket verilerindeki açık 'SLABreach' event'i aracılığıyla belirlenir.

Event tipi explicit
Talep Temsilciye Atandı
Bu etkinlik, bir hizmet talebinin ilk kez belirli bir temsilciye atandığında meydana gelir. Bu, bilet denetim `log`'undaki 'değişiklik' `event`'inden (assignee_id alanının boş veya bir grup kimliğinden doldurulduğu yerden) çıkarılır.
Neden önemli

Bu, bir temsilcinin aktif çalışmasının başlangıcını işaretler ve ilk yanıt sürelerini, ilk atama gecikmesini ve temsilci iş yükü dağılımını ölçmek için kritik öneme sahiptir.

Nereden alınır

Ticket denetim log'undaki 'assignee_id' alanındaki, belirli bir kullanıcı kimliğinin ayarlandığı ilk 'Change' event'inden çıkarılır.

Yakala

'assignee_id' alanını bir agent'a ayarlayan ilk değişiklik event'inden çıkarılır.

Event tipi inferred
Agent Yeniden Atandı
Bir `hizmet talebi`nin sahipliğinin bir `agent`'tan diğerine devredilmesini temsil eder. Bu, ilk atamadan sonra 'assignee_id' alanındaki herhangi bir sonraki 'Change' `event`'inden çıkarılır.
Neden önemli

Yeniden atamaları izlemek, süreç verimsizliklerini, yanlış yönlendirmeyi veya bilgi eksikliklerini belirlemeye yardımcı olan Temsilci Yeniden Atama Oranı KPI'sını hesaplamak için anahtardır.

Nereden alınır

Ticket denetim log'undaki 'assignee_id' alanındaki 'Change' event'lerinden çıkarılır, ticket için en ilk atama event'i hariç.

Yakala

'assignee_id' alanındaki ikinci ve sonraki 'Change' event'lerinden çıkarılır.

Event tipi inferred
Dahili Not Eklendi
Bir `agent` tarafından `hizmet talebi`ne yalnızca diğer `agent`'lara görünür olan dahili bir not veya yorum eklenmiştir. Bu, 'public' niteliğinin yanlış olduğu bir 'Comment' `event`'i olarak kaydedilir.
Neden önemli

Dahili notları izlemek, temsilciler veya ekipler arasındaki işbirliğine dair içgörü sağlar; bu, bir gecikme kaynağı veya etkili problem çözmenin anahtarı olabilir.

Nereden alınır

Bu, bilet data'sında açık bir 'Comment' (yorum) event'idir. event detayları, bunun dahili bir not olduğunu gösteren 'public: false' özniteliğini içerir.

Yakala

'public' flag'inin yanlış olarak ayarlandığı ticket 'Comment' event'lerinden yakalanır.

Event tipi explicit
Öncelik Değiştirildi
Hizmet talebinin 'Düşük', 'Normal', 'Yüksek' veya 'Acil' gibi öncelik seviyesinin güncellendiğini gösterir. Bu, `ticket` denetim `log`'undaki 'priority' alanında bir 'Change' `event`'i olarak yakalanır.
Neden önemli

Öncelik değişikliklerini analiz etmek, zamanla aciliyeti artan talepleri belirlemeye ve önceliklendirmenin etkili bir şekilde yönetilip yönetilmediğini değerlendirmeye yardımcı olur.

Nereden alınır

Zendesk ticket denetim log'u içindeki 'priority' alanında, önceki ve yeni değerleri gösteren bir 'Change' event'i olarak kaydedilir.

Yakala

Denetim log'undaki 'priority' alanındaki 'Change' event'lerinden çıkarılır.

Event tipi inferred
SLA Hedefi Uygulandı
Bir Hizmet Seviyesi Anlaşması (SLA) politikasının `hizmet talebi ticket`'ına uygulandığı anı temsil eder. Bu `event`, `ticket`'ın özellikleri aktif bir SLA politikasının koşullarıyla eşleştiğinde açıkça `log`lanır.
Neden önemli

Bir SLA'nın ne zaman uygulandığını takip etmek, uyumluluğu izlemek, olası ihlalleri analiz etmek ve farklı talep türleri için beklenen hizmet zaman çizelgesini anlamak için çok önemlidir.

Nereden alınır

Zendesk ticket event'leri veya denetim log'u içindeki 'SLAPolicyApplied' event'inden yakalanır. Bu event, hangi politikanın eşleştiğini belirtir.

Yakala

Ticket verilerindeki açık 'SLAPolicyApplied' event'i aracılığıyla belirlenir.

Event tipi explicit
Talep Beklemeye Alındı
Bu etkinlik, hizmet talebinin durumu 'beklemede' olarak değiştirildiğinde meydana gelir; bu genellikle temsilcinin talep edenden veya üçüncü bir taraftan bilgi beklediğini gösterir. Bu, bir durum değişikliği `event`'inden çıkarılır.
Neden önemli

Bu, destek ekibinin doğrudan kontrolü dışındaki bekleme sürelerini izole etmeye ve ölçmeye yardımcı olarak, temsilci işlem süresinin daha doğru bir görünümünü sağlar.

Nereden alınır

Ticket denetim log'undaki 'status' alanındaki, yeni değerin 'on-hold' olduğu bir 'Change' event'inden çıkarılır.

Yakala

Denetim log'unda durumun 'on-hold' olduğu bir 'Change' event'inden çıkarılır.

Event tipi inferred
Talep Yükseltildi
Bir `hizmet talebi`nin daha yüksek bir destek katmanına, farklı bir ekibe veya yönetime resmi eskalasyonunu temsil eder. Bu genellikle `ticket`'ın atanmış grubundaki bir değişiklikten veya eskalasyonları izlemek için belirlenmiş özel bir alandaki bir değişiklikten çıkarılır.
Neden önemli

Eskalasyonları izlemek, karmaşık talepleri, ön cephe agentları için 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 event değildir. 'group_id' alanındaki bir 'değişiklik' event'inden bir escalation grubuna veya escalation takibi için kullanılan özel bir bilet alanındaki bir değişiklikten çıkarılmalıdır.

Yakala

'group_id' değişikliğinden veya özel bir 'escalation' alanından çıkarılır.

Event tipi inferred
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi Zendesk Support'tan Nasıl Alırsınız