Hizmet Talebi Yönetimi Data Template'iniz
Hizmet Talebi Yönetimi Data Template'iniz
- Kapsamlı analiz için önerilen özellikler
- İzlenecek temel `hizmet talebi` etkinlikleri
- Zendesk Destek verileri için veri çıkarma rehberliği
Hizmet Talebi Yönetimi Öznitelikleri
| 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,
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
Ö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
Bu nitelik, zamana dayalı herhangi bir analiz için kritik öneme sahiptir.
Neden önemli
Bu
Nereden alınır
Zendesk Bilet Denetimleri API'si, her denetim
Ö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
Neden önemli
Bu, bir hizmet talebinin yolculuğundaki tüm
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 Birden çok entegre sistemin bulunduğu ortamlarda, bu alan
Neden önemli
Nereden alınır
Bu,
Ö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 Devam eden izleme ve
Neden önemli
Nereden alınır
Bu,
Ö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
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,
Neden önemli
Nereden alınır
Zendesk Biletleri API'si, 'tags' alanı. Bu bir dizi (
Ö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
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, Farklı durumlarda harcanan süreyi analiz etmek,
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'
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 Bu nitelik, segmentasyon ve temel neden analizi için çok önemlidir. Yüksek öncelikli
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
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
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
Ö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 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
Nereden alınır
Bu, ayrık
Ö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'
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
Ö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 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
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
Ö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'
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
Ö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'
Neden önemli
Bir talebin hangi
Nereden alınır
Zendesk Bilet Metrikleri API'si. SLA
Ö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
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 Bu öznitelik, 'Hizmet Talebi Yeniden İşleme Oranı' KPI'sını ve 'Yeniden İşleme ve Yeniden Açılma Etkinlik Analizi'
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
Örnekler
truefalse
|
|||
Hizmet Talebi Yönetimi Etkinlikleri
| 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
Nereden alınır
Bu, bilet
Yakala
'public'
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
Yakala
Denetim
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
Nereden alınır
Yakala
Denetim
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
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ıç
Nereden alınır
Bu, Zendesk bilet denetim
Yakala
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
Nereden alınır
Zendesk
Yakala
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
Yakala
'assignee_id' alanını bir
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
Yakala
'assignee_id' alanındaki ikinci ve sonraki 'Change'
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
Yakala
'public'
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
Yakala
Denetim
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
Yakala
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
Yakala
Denetim
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
Nereden alınır
Bu standart bir
Yakala
'group_id' değişikliğinden veya özel bir 'escalation' alanından çıkarılır.
Event tipi
inferred
|
|||