Hizmet Talebi Yönetimi Veri Template'inuz

Zendesk Destek
Hizmet Talebi Yönetimi Veri Template'inuz

Hizmet Talebi Yönetimi Veri Template'inuz

Bu şablon, Zendesk Support'taki BT Hizmet Talebi Yönetimi Yönetimi sürecinizi analiz etmek için gerekli verileri çıkarmak üzere detaylı bir rehber sunar. Toplanacak temel `data` niteliklerini, 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 güçlü bir `event log` oluşturmak üzere bu kaynağı kullanın.
  • Detaylı analiz için önerilen özellikler
  • İzlenecek temel `hizmet talebi` etkinlikleri
  • Zendesk Destek verileri için veri veri çekme kılavuzu
Olay günlüklerine (Event Log) yeni mi başlıyorsunuz? Öğrenin Process Mining event log nasıl oluşturulur.

Hizmet Talep Yönetimi Öznitelikleri

Bunlar, Zendesk Support içinde detaylı hizmet talebi yönetimi analizi için event lognüze (event log) dahil etmeniz önerilen veri alanlarıdır.
5 Gerekli 7 Önerilen 9 Opsiyonel
Ad Açıklama
Aktivite
ActivityName
Bir hizmet talebi için meydana gelen iş etkinliğinin veya olayının (event) adı.
Açıklama

Etkinlik, hizmet talebi süreç döngüsündeki 'BT Hizmet Talebi Yönetimi Oluşturuldu', 'Talep Temsilciye Atandı' veya 'BT Hizmet Talebi Yönetimi Çö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 sunar. Etkinliklerin sırasını ve sıklığını anlayarak kuruluşlar verimsizlikleri ve süreç iyileştirme fırsatlarını belirleyebilir.

Neden Önemli?dir?

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:::::::
Hizmet Talebi OluşturulduTemsilci Yeniden AtandıBT Hizmet Talebi Yönetimi Çözüldü
Başlangıç Zamanı
EventTimestamp
Aktivitenin meydana geldiği tam tarih ve saat.
Açıklama

Event zaman damgası (zaman damgası) 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 büyük önem taşır. 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 büyük önem taşır.

Neden Önemli?dir?

Bu zaman damgası (zaman damgası), 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
Hizmet Talebi Kimliği
ServiceRequestId
Zendesk içindeki her hizmet talebi bileti için benzersiz tanımlayıcı.
Açıklama

BT Hizmet Talebi Yönetimi 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 süreç döngüsünün eksiksiz, uçtan uca izlenmesini sunar.

Process Mining analizinde bu öznitelik temel teşkil eder. 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ı sunar. dataset'teki her event, genel süreç içindeki bağlamını anlamak için bir BT Hizmet Talebi Yönetimi Kimliği ile ilişkilendirilmelidir.

Neden Önemli?dir?

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 sunar.

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 büyük önem taşır. Analizlerin hedeflenen sisteme doğru şekilde kapsamlandırılmasını sunar ve çeşitli kaynaklardan birleştirildiğinde data'yı ayırt etmeye yardımcı olur.

Neden Önemli?dir?

Verinin kaynak sistemini belirler, veri akışını sunar 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 Destek
Son Veri Güncellemesi
LastDataUpdate
Verilerin kaynak sistemden son yenilendiği zamanı gösteren `zaman damgası (zaman damgası)dır.
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 sunar, böylece kullanıcıların süreç görünümünün ne kadar güncel olduğunun farkında olmasını sunar.

Devam eden izleme ve kontrol paneli oluşturma için bu bilgi büyük önem taşır. 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ı sunar; bu da sonuçlarının geçerliliğini etkiler.

Neden Önemli?dir?

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

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 büyük önem taşır. 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 kontrol paneli'u için birincil bir boyuttur.

Neden Önemli?dir?

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

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 süreç döngüsünü izlemek için bir 'product_bug' etiketi kullanılabilir.

Neden Önemli?dir?

Veriyi veriyi detaylıca inceleme için esnek bir yol sunar, belirli alt süreçlere veya diğer alanlarda yakalanmayan ticket niteliklerine derinlemesine analiz yapmaya sunar.

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
Servis Tipi
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 büyük önem taşır. Analistlerin, genellikle çok farklı çözüm yolları ve SLA'lara sahip farklı talep türleri için süreç akışlarını incelemesini sunar. Belirli talep türlerini en iyi kimin ele aldığını görmek için Agent & Team Performance kontrol paneli'u için önemli bir boyuttur.

Neden Önemli?dir?

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 süreç 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 temel rol oynar.

Neden Önemli?dir?

Durumu takip etmek, talebin ilerlemesini anlamak ve bekleme veya aktif durumlarda ne kadar zaman harcandığını belirlemek için büyük önem taşır.

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 sunar.

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' kontrol paneli'unu destekler. Bu, işletmelerin destek kanallarını optimize etmesine ve kullanıcıları en verimli olanlara yönlendirmesine yardımcı olabilir.

Neden Önemli?dir?

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

Nereden Alınır??

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

Örnekler:::::::
webe-postaapisohbet
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 süreç döngüsü boyunca bir agent tarafından değiştirilebilir.

Bu nitelik, segmentasyon ve kök neden analizi için büyük önem taşır. 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 'BT Hizmet Talebi Yönetimi Eskalasyon Trendleri' ve 'SLA Uyumu' kontrol paneli'larında önemli bir faktördür.

Neden Önemli?dir?

Talepleri aciliyetine göre segmentlere ayırmaya sunar; bu da SLA uyumluluğunu analiz etmek ve kritik sorunların derhal ele alınmasını güçlüak için büyük önem taşır.

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 süreç 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 büyük önem taşır. İş 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 sunar. Bu, Agent & Team Performance kontrol paneli'unu oluşturmaya ve genel süreç verimliliğine bireysel katkıları anlamaya yardımcı olur.

Neden Önemli?dir?

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 büyük önem taşır.

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ı güçlüak için yönlendirme kurallarını, temsilci eğitimini veya bilgi tabanı kaynaklarını iyileştirme fırsatlarını ortaya çıkarabilir.

Neden Önemli?dir?

Dahili el değiştirmeleri ölçmeye ve süreçteki aksaklıkları 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ş Zamanı
EndTime
Etkinliğin tamamlandığı tam 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?dir?

Bireysel etkinlik sürelerinin hesaplanmasını sunar; bu da process bottleneck'lerini belirlemek ve adım düzeyinde verimliliği ölçmek için büyük önem taşır.

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 zaman damgası (zaman damgası)'idir.

Örnekler:::::::
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
İlk Temas Çözümü 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 göstergedir.
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?dir?

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 belirleyicisidir.

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 temel 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?dir?

Süreç yürütme ile müşteri sonuçları arasında doğrudan bir bağlantı sunar, 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 göstergedir.
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' kontrol paneli'u için kritik bir özniteliktir. Uyumlu ve uyumsuz biletlerin kolayca sayılmasını ve görselleştirilmesini sunar. 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?dir?

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 Politika 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' kontrol paneli'u için büyük önem taşır. Farklı politikaların farklı hedeflere sahip olacağı için performansı değerlendirmek için gerekli bağlamı sunar. Bu, bir biletin belirli hizmet seviyesi hedeflerini karşılayıp karşılamadığının adil ve doğru bir şekilde değerlendirilmesini sunar.

Neden Önemli?dir?

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

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ı sunar.

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?dir?

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

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ü sunar. 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?dir?

Talepleri şirkete göre gruplandırarak B2B hizmet analizini sunar; bu da kurumsal düzeyde müşteri ilişkilerini ve SLA'ları yönetmek için büyük önem taşır.

Nereden Alınır??

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

Örnekler:::::::
Acme Şirketi`Global Tech Inc.`Çözümleri Yenilikçi Hale Getir
Yeniden İşleme mi?
IsRework
Hizmet talebinin çözüldükten sonra yeniden açılıp açılmadığını gösteren doğru/yanlış işaretçi'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, 'BT Hizmet Talebi Yönetimi Yeniden İşleme Oranı' KPI'sını ve 'Yeniden İşleme ve Yeniden Açılma Etkinlik Analizi' kontrol paneli'unu hesaplamak için büyük önem taşır. 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?dir?

Çö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 Opsiyonel

Hizmet Talep Yönetimi Aktiviteleri

Bunlar, hizmet taleplerinizin doğru süreç keşfi için event lognüze (event log) kaydetmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
7 Önerilen 6 Opsiyonel
Aktivite Açıklama
BT Hizmet Talebi Yönetimi Çö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?dir?

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
BT Hizmet Talebi Yönetimi 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?dir?

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

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
BT Hizmet Talebi Yönetimi 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?dir?

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
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?dir?

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 büyük önem taşır.

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' işaretçi'inin doğru olarak ayarlandığı ticket 'Comment' event'lerinden yakalanır.

Event tipi explicit
Hizmet Talebi Oluşturuldu
Yeni bir `ticket`'ın bir talep eden tarafından herhangi bir kanal aracılığıyla gönderilmesiyle `hizmet talebi` süreç 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ı sunar.
Neden Önemli?dir?

Bu etkinlik, her hizmet talebi için birincil başlangıç event'i olarak olarak kullanılır ve uçtan uca döngü sürelerini hesaplamak ve talep alım hacimlerini analiz etmek için büyük önem taşır.

Nereden Alınır??

Bu, Zendesk bilet denetim log'unda bir 'Oluşturma' event türü olarak kaydedilir. Bu event'in zaman damgası (zaman damgası)'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?dir?

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?dir?

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 büyük önem taşır.

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
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?dir?

Dahili notları izlemek, temsilciler veya ekipler arasındaki işbirliğine dair önemli bilgi sunar; 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' işaretçi'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?dir?

Ö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?dir?

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 büyük önem taşır.

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?dir?

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ü sunar.

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 Escalate Edildi
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?dir?

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
Temsilci 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?dir?

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 temel rol oynar.

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
Önerilen Opsiyonel

Veri Çıkarma Kılavuzları

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