Hizmet Talebi Yönetimi Veri Template'inuz
Hizmet Talebi Yönetimi Veri Template'inuz
- Detaylı analiz için önerilen özellikler
- İzlenecek temel `hizmet talebi` etkinlikleri
- Zendesk Destek verileri için veri veri çekme kılavuzu
Hizmet Talep Yönetimi Öznitelikleri
| 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,
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
Ö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
Bu nitelik, zamana dayalı herhangi bir analiz için büyük önem taşır.
Neden Önemli?dir?
Bu zaman damgası (zaman damgası),
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
|
|||
|
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
Neden Önemli?dir?
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?dir?
Nereden Alınır??
Bu,
Ö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 Devam eden izleme ve
Neden Önemli?dir?
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 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
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,
Neden Önemli?dir?
Nereden Alınır??
Zendesk Biletleri API'si, 'tags' alanı. Bu bir dizi (
Ö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
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, Farklı durumlarda harcanan süreyi analiz etmek,
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'
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 Bu nitelik, segmentasyon ve kök neden analizi için büyük önem taşır. Yüksek öncelikli
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
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
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
Ö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 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
Nereden Alınır??
Bu, ayrık
Ö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 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?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
Ö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'
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
Ö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'
Neden Önemli?dir?
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ı 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
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 Bu öznitelik, 'BT Hizmet Talebi Yönetimi Yeniden İşleme Oranı' KPI'sını ve 'Yeniden İşleme ve Yeniden Açılma Etkinlik Analizi'
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
Örnekler:::::::
truefalse
|
|||
Hizmet Talep Yönetimi Aktiviteleri
| 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??
Yakala
Denetim
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
Nereden Alınır??
Yakala
Denetim
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??
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
Nereden Alınır??
Bu, bilet
Yakala
'public' işaretçi'inin doğru olarak ayarlandığı
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ıç
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?dir?
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?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??
Yakala
'assignee_id' alanını bir
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
Yakala
'public' işaretçi'inin yanlış olarak ayarlandığı
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
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?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
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?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??
Yakala
Denetim
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
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
|
|||
|
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??
Yakala
'assignee_id' alanındaki ikinci ve sonraki 'Change'
Event tipi
inferred
|
|||