Müşteri Hizmetleri Veri Şablonunuz
Müşteri Hizmetleri Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Müşteri hizmetleri süreciniz için takip edilecek temel aktiviteler
- Zendesk Support için veri çıkarma rehberliği
Müşteri Hizmetleri Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç Zamanı
StartTime
|
Bir etkinlik veya olayın ne zaman başladığını gösteren `timestamp` (zaman damgası). | ||
|
Açıklama
Başlangıç Zamanı veya olay zaman damgası, belirli bir aktivitenin meydana geldiği kesin tarih ve saati kaydeder. Örneğin, bir müşteri yorumunun ne zaman eklendiğini, bir ajanın ne zaman atandığını veya talebin durumunun ne zaman 'Çözüldü' olarak değiştiğini yakalar. Bu zaman damgası, olayların kronolojik sırasını belirlediği için process mining için temeldir. Aktiviteler arasındaki süreleri hesaplamak, döngü sürelerini ölçmek, SLA'lara karşı performansı analiz etmek ve hizmet sürecinin zamansal dinamiklerini anlamak için kullanılır.
Neden önemli
Bu zaman damgası, olayları sıralamak, süreleri hesaplamak ve hizmet talebi sürecinin zaman çizelgesini analiz etmek için esastır.
Nereden alınır
Denetim izindeki her olay için Zendesk Ticket Audits API,
Örnekler
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
|
|||
|
Hizmet Talebi
ServiceRequest
|
Her müşteri hizmeti talebi için benzersiz tanımlayıcı, aynı zamanda talep veya vaka olarak da bilinir. | ||
|
Açıklama
Hizmet Talebi, tek bir müşteri sorgusu veya sorunuyla ilgili tüm aktiviteleri oluşturulmasından nihai çözümüne kadar bağlayan birincil vaka tanımlayıcısıdır. Her etkileşim, güncelleme veya dahili eylem bu benzersiz kimliğe bağlıdır. Process mining'de, Hizmet Talebine göre gruplandırılmış olayları analiz etmek, müşteri hizmetleri yolculuğunun uçtan uca eksiksiz bir görünümünü sağlar. Toplam çözüm süresi gibi temel metrikleri hesaplamak, süreç sapmalarını belirlemek ve her müşteri sorununun yaşam döngüsünü anlamak için temel oluşturur.
Neden önemli
Bu, tüm süreç adımlarını birbirine bağlayan temel Vaka Kimliğidir ve her bir müşteri hizmetleri yolculuğunun yeniden yapılandırılmasını ve analizini sağlar.
Nereden alınır
Zendesk Tickets API,
Örnekler
102451287415332
|
|||
|
Faaliyet Adı
ActivityName
|
Hizmet talebi yaşam döngüsü içinde meydana gelen belirli olayın veya görevin adı. | ||
|
Açıklama
Aktivite Adı, müşteri hizmetleri sürecindeki 'Hizmet Talebi Oluşturuldu', 'Talep Ajana Atandı' veya 'Hizmet Talebi Çözüldü' gibi tek bir adımı veya dönüm noktasını açıklar. Bu olaylar zaman damgalıdır ve her hizmet talebi için eylem dizisini oluşturur. Bu öznitelik, süreç akışını görselleştirmek, süreç varyantlarını keşfetmek ve olayların sıklığını ve sırasını analiz etmek için kritiktir. Analistlerin hangi eylemlerin gerçekleştirildiğini anlamasına ve yaygın yolları, darboğazları ve standart prosedürden sapmaları belirlemesine olanak tanır.
Neden önemli
Bu öznitelik, süreç haritasının görselleştirilmesine ve süreç akışlarının ve varyasyonlarının analizine olanak tanıyan süreç adımlarını tanımlar.
Nereden alınır
Zendesk bilet denetim günlüklerinden veya değişiklikleri ve eylemleri kaydeden olay akışlarından türetilmiştir.
Örnekler
Servis Talebi OluşturulduTalep Ajana Atandıİlk Temsilci Genel Yanıtı GönderildiHizmet Talebi Çözüldü
|
|||
|
Kaynak Sistem
SourceSystem
|
Verinin çıkarıldığı kayıt sistemi. | ||
|
Açıklama
Bu öznitelik, hizmet talebi verilerinin kaynak sistemini belirtir, bu durumda Zendesk Support'tur. Özellikle birden fazla sistemden veri birleştirilirken, veri yönetimi ve soy ağacı oluşturma konusunda yardımcı olur. Analizde, verilerin kaynağına doğru şekilde atfedilmesini sağlar, bu da veri bütünlüğünü korumak ve sürecin bağlamını, özellikle çoklu sistem ortamlarında, anlamak için önemlidir.
Neden önemli
Verinin kaynağını belirler, bu da veri yönetimi ve entegre ortamlardaki süreç verilerini ayırt etmek için kritik öneme sahiptir.
Nereden alınır
Bu, veri çıkarma işlemi sırasında verinin kaynağını etiketlemek için eklenen statik bir değerdir.
Örnekler
Zendesk Support
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemden en son veri yenileme veya çekme işleminin zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, veri setinin Zendesk Support'tan son güncellendiği zamanı gösterir. Analiz edilen verinin güncelliği hakkında bağlam sağlar. Son güncelleme zamanını bilmek, analistler ve iş kullanıcıları için en güncel süreç bilgilerini görüp görmediklerini anlamaları açısından çok önemlidir. Verinin yeniliği hakkındaki beklentileri yönetmeye yardımcı olur ve raporlama ve izleme amaçları için hayati önem taşır.
Neden önemli
Verinin güncelliği hakkında netlik sağlar, kullanıcıların süreç analizinin ne kadar yeni olduğunu anlamasını garanti eder.
Nereden alınır
Bu, veri çıkarma işlemi sırasında oluşturulan ve depolanan, çıkarma işinin zaman damgasını kaydeden bir meta veri alanıdır.
Örnekler
2023-10-27T02:00:00Z
|
|||
|
Atanan Temsilci
AssignedAgent
|
Hizmet talebini ele almak üzere atanmış müşteri hizmetleri ajanının adı veya kimliği. | ||
|
Açıklama
Bu öznitelik, belirli bir zamanda bir aktiviteden veya hizmet talebinden sorumlu ajanı tanımlar. Talep yeniden atanırsa yaşam döngüsü boyunca değişebilir. Atanan Ajana göre analiz yapmak, ajan iş yükünü, performansını ve verimliliğini anlamanın anahtarıdır. Farklı ajanlar arasında işlem süreleri ve vaka hacimlerinin karşılaştırılmasına izin vererek 'Ajan İş Yükü ve Verimliliği' dashboard'unu destekler, koçluk fırsatlarını belirlemeye ve dengeli iş yüklerini sağlamaya yardımcı olur.
Neden önemli
Hangi ajanın bir eylemi gerçekleştirdiğini izler; bireysel performansın, iş yükü dağıtımının ve kaynak tahsisinin analizini sağlar.
Nereden alınır
Zendesk Tickets API,
Örnekler
Can DemirAyşe YılmazDestekBotu
|
|||
|
Çözüm Süresi
ServiceRequestResolutionTime
|
Bir hizmet talebinin oluşturulduğu andan nihai olarak çözüldüğü ana kadar geçen toplam süre. | ||
|
Açıklama
Bu metrik, bir hizmet talebinin uçtan uca süresini ölçer. 'Hizmet Talebi Çözüldü' aktivitesinin zaman damgası ile 'Hizmet Talebi Oluşturuldu' aktivitesinin zaman damgası arasındaki fark olarak hesaplanır. Bu, herhangi bir müşteri hizmetleri süreci için en önemli KPI'lardan biridir. 'Hizmet Talebi Çözüm Süresi Analizi' dashboard'u ve 'Ortalama Hizmet Talebi Çözüm Süresi' KPI'ı için birincil metriktir. Bu süreyi analiz etmek, sistemik gecikmeleri belirlemeye ve destek sürecinin genel verimliliğini ölçmeye yardımcı olur.
Neden önemli
Uçtan uca vaka süresini ölçer; bu, genel süreç verimliliğini ve müşteri deneyimini değerlendirmek için kritik bir temel performans göstergesidir.
Nereden alınır
Her Hizmet Talebi için oluşturma zaman damgasının nihai çözüm zaman damgasından çıkarılmasıyla hesaplanır.
Örnekler
720086400172800
|
|||
|
Hizmet Talebi Türü
ServiceRequestType
|
Hizmet talebinin 'Soru', 'Olay', 'Problem' veya 'Görev' gibi sınıflandırması. | ||
|
Açıklama
Bu öznitelik, hizmet talebini niteliğine göre kategorize eder. Bu sınıflandırma genellikle talep oluşturulduğunda veya tasnif edildiğinde ayarlanır ve uygun iş akışını ve önceliği belirlemeye yardımcı olur. Analizde, Hizmet Talebi Türüne göre segmentlere ayırmak temeldir. Bu, 'Hizmet Talebi Çözüm Süresi Analizi' ve 'Dahili Eskalasyon Oranı ve Nedenleri' gibi dashboard'larda gösterildiği gibi, farklı sorun türleri için çözüm sürelerini, eskalasyon oranlarını ve süreç akışlarını karşılaştırmaya olanak tanır. Bu, belirli talep türlerinin ele alınmasının daha sorunlu veya verimsiz olup olmadığını belirlemeye yardımcı olur.
Neden önemli
Farklı türdeki sorunlar arasında performans karşılaştırması ve analizine olanak sağlamak için talepleri kategorize eder, bu da hedeflenen süreç iyileştirmesi için çok önemlidir.
Nereden alınır
Zendesk Tickets API,
Örnekler
SoruOlayProblemGörev
|
|||
|
İletişim Kanalı
CommunicationChannel
|
Hizmet talebinin gönderildiği veya iletişimin gerçekleştiği kanal. | ||
|
Açıklama
Bu öznitelik, e-posta, web formu, sohbet veya telefon gibi kullanılan iletişim yöntemini tanımlar. Müşterilerin hizmet masasıyla nasıl etkileşim kurduğunu yansıtır. Kanal kullanımını anlamak, kaynak planlaması ve müşteri deneyimini iyileştirmek için önemlidir. 'İletişim Kanalı Kullanımına Genel Bakış' dashboard'u bu veriyi analiz ederek hangi kanalların en popüler olduğunu ve belirli kanalların daha uzun çözüm süreleri veya farklı süreç yolları ile ilişkili olup olmadığını gösterir. Bu, hizmet iyileştirmelerine veya otomasyona nerede yatırım yapılacağına karar vermede yardımcı olabilir.
Neden önemli
Müşterilerin ve ajanların nasıl etkileşim kurduğunu göstererek, kanal verimliliğinin ve bunun süreç ile müşteri deneyimi üzerindeki etkisinin analizini sağlar.
Nereden alınır
Zendesk Tickets API,
Örnekler
webemailapichat
|
|||
|
Öncelik
Priority
|
Hizmet talebine atanan öncelik düzeyi, örneğin 'Düşük', 'Normal', 'Yüksek' veya 'Acil'. | ||
|
Açıklama
Öncelik, bir hizmet talebinin aciliyetini gösterir ve genellikle kuyruktaki konumunu ve hedef çözüm süresini etkiler. Ajanların önce en kritik konulara odaklanmasına yardımcı olur. Bu öznitelik, performans ve SLA analizi için hayati öneme sahiptir. 'Hizmet Talebi Çözüm Süresi Analizi' dashboard'u, veriyi önceliğe göre segmentlere ayırarak, yüksek öncelikli taleplerin düşük öncelikli olanlardan daha hızlı ele alınıp alınmadığını ve kaynakların iş ihtiyaçlarına göre etkin bir şekilde tahsis edilip edilmediğini ortaya koyar.
Neden önemli
Bir talebin aciliyetini gösterir; bu, SLA uyumluluğunu analiz etmek ve kritik sorunların zamanında ele alınmasını sağlamak için kritik öneme sahiptir.
Nereden alınır
Zendesk Tickets API,
Örnekler
DüşükNormalYüksekAcil
|
|||
|
SLA Hedef Çözüm Süresi
SlaTargetResolutionTime
|
Bir hizmet talebinin SLA politikasına göre çözülmesi beklenen hedef süre. | ||
|
Açıklama
Bu öznitelik, bir talebi çözmek için Hizmet Seviyesi Anlaşması (SLA) hedefini tanımlar. Bu hedef genellikle dinamiktir ve talebin önceliği, türü veya müşterinin hizmet planı gibi faktörlere bağlıdır. Bu, 'SLA Uyumluluk Performansı' dashboard'u için temel bir özniteliktir. Gerçek çözüm süresinin ölçüldüğü bir karşılaştırma noktası olarak hizmet eder. Bu hedefe karşı performansı analiz etmek, hizmet sunum kalitesini niceliksel olarak belirlemeye ve müşterilere karşı sözleşme yükümlülüklerinin yerine getirildiğinden emin olmaya yardımcı olur.
Neden önemli
Müşteriye verilen hizmet taahhüdünü tanımlar, zamanında performans ve SLA uyumluluğunu ölçmek için bir referans noktası görevi görür.
Nereden alınır
Bir bilete uygulanan SLA politikalarından türetilmiştir. Bu bilgi, Zendesk Bilet Metrikleri API'si aracılığıyla edinilebilir.
Örnekler
144002880086400
|
|||
|
SLA İhlal Edildi mi?
IsSlaBreached
|
Hizmet talebinin çözüm süresinin SLA hedefini aşıp aşmadığını gösteren bir boolean bayrağı. | ||
|
Açıklama
Bu hesaplanmış öznitelik, bir hizmet talebinin çözüm süresi için tanımlanmış Hizmet Seviyesi Anlaşmasını karşılayıp karşılamadığını gösteren basit bir doğru veya yanlış bayrağıdır. Gerçek çözüm süresinin planlanan SLA hedefiyle karşılaştırılmasıyla elde edilir. Bu bayrak, SLA uyumluluk analizini basitleştirir. 'SLA Uyumluluk Performansı' dashboard'u ve 'SLA Uyumluluk Oranı' KPI'ı için temel veri noktasıdır ve kaç talebin hizmet hedeflerini karşıladığını ve kaçının karşılamadığını hızlı bir şekilde birleştirmeyi ve görselleştirmeyi sağlar.
Neden önemli
Her vaka için SLA performansına dair net, ikili bir sonuç sunarak uyumluluk izlemeyi ve raporlamayı basitleştirir.
Nereden alınır
Veri dönüşümü sırasında toplam çözüm süresinin SlaTargetResolutionTime ile karşılaştırılmasıyla hesaplanır.
Örnekler
truefalse
|
|||
|
Bilgi Talebi Sayısı
InformationRequestCount
|
Tek bir hizmet talebi için müşteriden bilgi talep edilme sayısı. | ||
|
Açıklama
Bu hesaplanmış metrik, her hizmet talebi için 'Müşteriden Bilgi Talep Edildi' aktivitesinin gerçekleşme sayısını sayar. Yüksek bir sayı, ajanların gerekli tüm bilgileri başlangıçta toplamadığını gösterir. Bu öznitelik, 'Tekrarlanan Bilgi Talebi Analizi' dashboard'unda kullanılır. Bu sayıyı izlemek, süreç verimsizliklerini ve ajan eğitimi için alanları belirlemeye yardımcı olur. Bilgi talep edilme sayısını azaltmak, çözüm sürelerini önemli ölçüde kısaltabilir ve müşteri deneyimini iyileştirebilir.
Neden önemli
Müşteri ile karşılıklı iletişimi niceliksel olarak belirler; bu da çözüm sürelerini uzatan ve müşteri deneyimini kötüleştiren verimsizlikleri vurgular.
Nereden alınır
Her Hizmet Talebi için ActivityName'in 'Müşteriden Bilgi Talep Edildi' olduğu olayların sayısını sayarak hesaplanır.
Örnekler
013
|
|||
|
Bitiş Saati
EndTime
|
Bir aktivitenin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Bitiş Zamanı, bir aktivitenin tamamlanma süresini temsil eder. Birçok olay logu yapısında, bir sonraki aktivitenin Başlangıç Zamanı, mevcut aktivitenin Bitiş Zamanı olarak işlev görebilir. 'Ajan Sorunu Araştırır' gibi duruma dayalı aktiviteler için, o durumun ne zaman sona erdiğini işaret eder. Bu öznitelik, performans analizinin temel bir bileşeni olan aktivitelerin kesin süresini hesaplamak için esastır. Hangi adımların en çok zaman aldığını belirlemeye yardımcı olur ve detaylı darboğaz analizi ile kaynak verimliliği hesaplamaları için temel sağlar.
Neden önemli
Aktivite sürelerinin hesaplanmasını sağlar, bu da darboğazları belirlemek ve performansı ölçmek için kritik öneme sahiptir.
Nereden alınır
Bu, genellikle belirli bir Hizmet Talebi için dizideki sonraki olayın Başlangıç Zamanı alınarak türetilir.
Örnekler
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
|
|||
|
Çözüm Kodu
ResolutionCode
|
Talebin nihai çözümü veya kapanma nedenini gösteren bir kod veya kategori. | ||
|
Açıklama
Çözüm Kodu, bir hizmet talebinin sonucu hakkında yapılandırılmış bilgi sağlar. Örnekler arasında 'Ajan Tarafından Çözüldü', 'Tekrar Eden', 'Eylem Gereksiz' veya 'Bilinen Sorun' bulunur. Basit bir 'Kapalı' durumundan daha fazla bağlam sunar. Bu öznitelik, temel neden analizi için özellikle değerlidir. 'Yeniden Açılan Hizmet Talebi Trendleri' dashboard'u için, çözüm koduna göre yeniden açılma oranlarını analiz etmek, belirli çözüm türlerinin daha az etkili olup olmadığını ortaya çıkarabilir ve bu da müşterilerin destekle yeniden etkileşime geçmesine neden olabilir.
Neden önemli
Bir hizmet talebinin sonucu hakkında bilgi sağlar, bu da temel neden analizi ve taleplerin neden yeniden açıldığını anlamak için çok önemlidir.
Nereden alınır
Bu genellikle Zendesk'te özel bir talep alanıdır. Kesin alan adı, belirli Zendesk yapılandırmasına bağlıdır.
Örnekler
İlk Temasta Çözüm2. Kademeye Eskale EdildiMüşteri BekleniyorÜrün Hatası
|
|||
|
Memnuniyet Puanı
SatisfactionRating
|
Hizmet talebi çözüldükten sonra müşteri tarafından verilen memnuniyet puanı. | ||
|
Açıklama
Bu öznitelik, müşterinin hizmet deneyimine ilişkin geri bildirimlerini yakalar; bu, genellikle talep çözüldükten sonra bir anket aracılığıyla toplanır. Yaygın derecelendirmeler arasında 'İyi', 'Kötü' veya sayısal bir puan bulunur. Bu, müşteri duyarlılığının doğrudan bir ölçüsüdür ve temel bir sonuç metriğidir. 'Müşteri Duyarlılığı Puanı' KPI'ını hesaplamak için kullanılır. Memnuniyet derecelendirmelerini, çözüm süresi veya ajan etkileşim sayısı gibi süreç verileriyle birlikte analiz etmek, hangi süreç davranışlarının daha iyi müşteri sonuçlarına yol açtığını ortaya çıkarabilir.
Neden önemli
Sağlanan hizmete ilişkin doğrudan müşteri geri bildirimini ölçer, süreç performansını müşteri sonuçlarıyla ilişkilendirir.
Nereden alınır
Zendesk Tickets API,
Örnekler
goodbadoffered
|
|||
|
Temsilci Grubu
AgentGroup
|
Hizmet talebinin atandığı destek grubu veya ekip. | ||
|
Açıklama
Bu öznitelik, hizmet talebinden sorumlu ajan ekibini temsil eder. Talepler genellikle beceriye, ürün alanına veya dile göre belirli gruplara yönlendirilir. Ajan Grubuna göre analiz yapmak, ekip düzeyinde performansı, iş yükü dağılımını ve ekipler arası eskalasyon modellerini anlamaya yardımcı olur. Bireysel ajan analizinden daha üst düzey bir görünüm sağlar ve belirli departmanlar veya fonksiyonlar içindeki sistemik sorunları belirlemeye yardımcı olabilir.
Neden önemli
Ekip sorumluluğunu izler; grup performansının, ekipler arası devirlerin ve farklı destek katmanları veya uzmanlık alanları genelinde kaynak tahsisinin analizini sağlar.
Nereden alınır
Zendesk Tickets API,
Örnekler
1. Kademe DestekTeknik DestekFaturalandırma
|
|||
|
Ürün Hizmet Kategorisi
ProductServiceCategory
|
Müşterinin talebinin ilgili olduğu belirli ürün, hizmet veya özellik. | ||
|
Açıklama
Bu öznitelik, hizmet talebini bir ürün veya hizmet alanına göre kategorize ederek detaylı bağlam sağlar. Genellikle bir ajan tarafından manuel olarak veya talep içeriğine göre otomatik olarak ayarlanır. Bu kategorizasyon, 'Talep Kategorizasyon Doğruluğu' ve 'Araştırma Döngüsü Süresi Dağılımı' dashboard'ları için hayati öneme sahiptir. Hangi ürünlerin en çok destek talebi oluşturduğunu, hangilerinin çözülmesi en karmaşık olduğunu ve ilk kategorizasyonun nihai çözümle uyumlu olup olmadığını derinlemesine analiz etmeye olanak tanır, bu da yönlendirme ve ajan eğitimini iyileştirmeye yardımcı olur.
Neden önemli
Talepleri belirli iş alanlarına, ürünlere veya hizmetlere bağlar, böylece sorunlu alanlar ve bunların süreç üzerindeki etkileri üzerine odaklanmış analizlere olanak tanır.
Nereden alınır
Bu genellikle Zendesk'te özel bir talep alanıdır. Kesin alan adı, belirli Zendesk yapılandırmasına bağlıdır.
Örnekler
Mobil UygulamaAbonelik YönetimiAPI EntegrasyonuDonanım
|
|||
|
Yeniden Açıldı mı?
IsReopened
|
Bir hizmet talebinin çözüldü olarak işaretlendikten sonra yeniden açılıp açılmadığını gösteren bir boolean bayrağı. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebinin daha önce çözüldü veya kapatıldı olarak ayarlandıktan sonra açık duruma geri dönmesi durumunda doğru olan bir bayraktır. İlk çözümün yeterli olmadığını gösterir. Bu bayrak, yeniden işleme ve ilk temasta çözüm başarısızlıklarını izlemek için kritiktir. Ek dikkat gerektiren vakaları kolayca saymayı ve analiz etmeyi sağlayarak 'Yeniden Açılan Hizmet Talebi Trendleri' dashboard'unu ve 'Hizmet Talebi Yeniden Açılma Oranı' KPI'ını doğrudan destekler; bu da genellikle daha derin temel sorunları gösterir.
Neden önemli
Yeniden işleme ve başarısız çözümleri belirler, sağlanan çözümlerin kalitesini ve etkinliğini ölçmeye yardımcı olur.
Nereden alınır
Veri dönüşümü sırasında, bir biletin durumunun 'çözüldü' veya 'kapalı'dan tekrar 'açık'a değişip değişmediği kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
Müşteri Hizmetleri Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet Talebi Çözüldü
|
Bir temsilci, müşteriye bir çözüm sunduktan sonra hizmet talebini 'çözüldü' olarak işaretler. Bu geçici bir durumdur, çünkü bilet kalıcı olarak kapatılmadan önce bir müşteri yanıtıyla yeniden açılabilir. | ||
|
Neden önemli
Bu, çözüm süresini ve ajan verimliliğini ölçmek için birincil dönüm noktasıdır. Ajana göre işin tamamlandığı noktayı işaret eder ve talep yeniden açılırsa yeniden işleme analizleri için bir temel sağlar.
Nereden alınır
Bu, Zendesk Ticket Audits API'sinde 'status' alanı 'çözüldü' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir.
Yakala
Bilet durumunun 'çözüldü' olarak ayarlandığı Bilet Denetimlerindeki 'Değişiklik' olaylarını belirleyin.
Event tipi
explicit
|
|||
|
Hizmet Talebi Kapatıldı
|
Bu, hizmet talebinin kalıcı olarak kapanışını işaret eden son aktivitedir. Genellikle talep 'çözüldü' olarak işaretlendikten sonra belirli bir süre geçtikten sonra, müşteriden yeni yanıt gelmeksizin otomatik olarak gerçekleşir. | ||
|
Neden önemli
Kesin son olay olarak, biletin yaşam döngüsünü tamamlar. 'Çözüldü'den 'kapalı'ya kadar geçen süre, olası yeniden açılmalar için bir pencereyi temsil eder ve 'kapalı' olayı, çözümün kabul edildiğini doğrular.
Nereden alınır
Bu, Zendesk Ticket Audits API'sinde 'status' alanı 'kapalı' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir.
Yakala
Bilet durumunun 'kapalı' olarak ayarlandığı Bilet Denetimlerindeki 'Değişiklik' olaylarını belirleyin.
Event tipi
explicit
|
|||
|
Hizmet Talebi Yeniden Açıldı
|
Bu aktivite, bir müşteri 'çözüldü' durumundaki bir talebe yanıt verirse meydana gelir. Zendesk, sorunun tam olarak çözülmediğini göstererek durumu otomatik olarak 'açık' konumuna geri değiştirir. | ||
|
Neden önemli
Yeniden açılmalar, İlk Temasta Çözüm başarısızlığının ve düşük çözüm kalitesinin kritik bir göstergesidir. Yeniden açılan taleplerin sıklığını ve nedenlerini analiz etmek, ajan eğitimini ve çözüm prosedürlerini iyileştirme alanlarını belirlemeye yardımcı olur.
Nereden alınır
Bu, Ticket Audits API'sinde 'status' 'çözüldü'den tekrar 'açık' konumuna geçtiğinde yakalanan açık bir durum değişikliğidir.
Yakala
Durum 'Değişiklik' olaylarını 'çözüldü'den 'açık'a izleyin.
Event tipi
explicit
|
|||
|
Müşteriden Bilgi Talep Edildi
|
Bir temsilcinin devam etmek için müşteriden daha fazla bilgiye ihtiyaç duyduğunda ve bilet durumunu 'beklemede' olarak değiştirdiğinde gerçekleşir. Bu durum değişikliği, sürecin artık harici bir tarafı beklediğini açıkça belirtir. | ||
|
Neden önemli
Bu aktivite, müşteriye bağımlılıkları vurgular ve dahili SLA sürelerini duraklatır. Tek bir talepte sık veya tekrarlanan örnekler, eksik başlangıç bilgi toplama işaret edebilir ve daha uzun çözüm sürelerine yol açabilir.
Nereden alınır
Bu, Zendesk Ticket Audits API'sinde kaydedilen açık bir durum değişikliği olayıdır. 'status' alanı 'pending' olarak değiştiğinde yakalanır.
Yakala
Bilet durumunun 'beklemede' olarak ayarlandığı Bilet Denetimlerindeki 'Değişiklik' olaylarını belirleyin.
Event tipi
explicit
|
|||
|
Servis Talebi Oluşturuldu
|
Bu aktivite, müşteri hizmetleri sürecinin başlangıcını işaret eder; Zendesk'te e-posta, web formu veya sohbet gibi herhangi bir kanaldan yeni bir talep oluşturulduğunda. Bu olay, sistem tarafından benzersiz bir talep kimliği ve oluşturma zaman damgası ile açıkça kaydedilir. | ||
|
Neden önemli
Birincil başlangıç olayı olarak, genel vaka süresini hesaplamak ve zaman içindeki gelen talep hacimlerini analiz etmek için esastır. İlk yanıt süresi ve toplam çözüm süresi gibi temel performans göstergelerini ölçmek için bir temel görevi görür.
Nereden alınır
Bu, Zendesk Ticket Audits API'sinde yakalanan açık bir olaydır. Bir talep için 'Oluştur' olayına karşılık gelir ve ilk oluşturma zaman damgasını sağlar.
Yakala
Bilet Denetimleri günlüğündeki bilet oluşturma olayından yakalanır.
Event tipi
explicit
|
|||
|
Talep Ajana Atandı
|
Bu olay, hizmet talebinin belirli bir ajana atanmış olduğunu gösterir. Yönlendirme kurallarına göre otomatik olarak veya bir ekip lideri veya ajan tarafından manuel olarak gerçekleşebilir. | ||
|
Neden önemli
Atama, hesap verebilirlik ve iş yükü yönetimi için kritik bir dönüm noktasıdır. Atama süresini ve yeniden atama kalıplarını analiz etmek, triyaj ve dağıtım sürecindeki darboğazları ortaya çıkarır.
Nereden alınır
Bu, Zendesk Ticket Audits API'sinde 'assignee_id' alanı doldurulduğunda veya değiştirildiğinde kaydedilen açık bir 'Değişim' olayıdır.
Yakala
Ticket Audits logundaki 'assignee_id' alanındaki değişiklikleri izleyin.
Event tipi
explicit
|
|||
|
Dahili Eskalasyon Tetiklendi
|
Bir hizmet talebinin farklı bir dahili ekibe veya daha yüksek bir destek katmanına aktarılmasını temsil eder. Bu genellikle talebin atanan grubu değiştiğinde anlaşılır. | ||
|
Neden önemli
Eskalasyonları izlemek, süreç zayıflıklarını, ön cephe desteğindeki bilgi eksikliklerini ve karmaşık talep türlerini belirlemek için anahtardır. Yüksek eskalasyon oranları, daha iyi eğitim veya süreç dokümantasyonu ihtiyacını gösterebilir.
Nereden alınır
'group_id' alanının değiştirildiği Bilet Denetimleri API'sindeki bir 'Değişiklik' olayından çıkarılır. Bir gruptaki değişiklik, ekipler arasında bir aktarım anlamına gelir.
Yakala
Bilet Denetim günlüğündeki 'group_id' alanındaki değişiklikleri izleyin.
Event tipi
inferred
|
|||
|
İlk Onay Gönderildi
|
Müşteriye gönderilen, talebinin alındığını onaylayan otomatik ilk yanıtı temsil eder. Bu genellikle talep oluşturulduktan hemen sonra şablonlu bir e-posta bildirimi gönderen bir Zendesk tetikleyicisi tarafından yapılır. | ||
|
Neden önemli
Bu aktiviteyi izlemek, ilk yanıt hızını ölçmek ve müşteri beklentilerini yönetmek için çok önemlidir. Talep oluşturma ile bu onay arasındaki süre, müşteri memnuniyeti için temel bir metriktir.
Nereden alınır
Bilet üzerindeki ilk genel yorumun yazarı otomatik bir kullanıcıysa veya bilet oluşturulduktan saniyeler içinde gerçekleşmişse bu yorumdan çıkarılır. Bu, Bilet Yorumları akışı analiz edilerek belirlenebilir.
Yakala
Bilet oluşturulduktan hemen sonra bir otomasyon veya tetikleyici tarafından oluşturulan ilk genel yorumu belirleyin.
Event tipi
inferred
|
|||
|
İlk Temsilci Genel Yanıtı Gönderildi
|
Bu aktivite, bir ajanın müşteriye otomatik bir onay yerine ilk kez herkese açık bir yorum göndermesini işaret eder. Bu olay, ajanın müşterinin sorunuyla ilk etkileşiminin önemli bir göstergesidir. | ||
|
Neden önemli
Bu, hizmet duyarlılığının kritik bir göstergesi olan 'İlk Yanıt Süresi' SLA'sını ölçmek için önemli bir dönüm noktasıdır. Otomatik iletişimi, aktif, insan odaklı araştırma ve desteğin başlangıcından ayırır.
Nereden alınır
Yazarın insan bir temsilci (otomatik sistem kullanıcısı değil) olduğu Bilet Yorumları akışındaki ilk genel yorumu bularak belirlenir.
Yakala
Talep yorumlarını tarayın, ajanlardan gelen herkese açık yorumları filtreleyin ve en erken zaman damgalı olanı seçin.
Event tipi
inferred
|
|||
|
Memnuniyet Anketi Gönderildi
|
Müşteri memnuniyeti (CSAT) anketinin müşteriye otomatik olarak gönderildiği noktayı temsil eder. Bu genellikle talep çözüldü olarak işaretlendikten kısa bir süre sonra gerçekleşir. | ||
|
Neden önemli
Bu aktivite, müşteri geri bildirim döngüsünü başlatır. Anketlerin ne zaman ve gönderilip gönderilmediğini anlamak, memnuniyet puanlarını bağlamsallaştırmak ve geri bildirim programının etkinliğini ölçmek için önemlidir.
Nereden alınır
Bu, bir otomasyon logundan veya talebe eklenen belirli bir etiketle çıkarılabilir. Ticket Audits API'sindeki 'satisfaction_rating' bölümü de anketin ne zaman sunulduğunu kaydeder.
Yakala
'csat_sent' gibi etiketleri arayın veya memnuniyet derecelendirmesinin sunulduğu zaman damgasını kullanın.
Event tipi
inferred
|
|||
|
Memnuniyet Derecesi Alındı
|
Bu olay, müşterinin memnuniyet anketine yanıtını gönderdiğinde meydana gelir ve 'İyi' veya 'Kötü' gibi bir derecelendirme sağlar. Derecelendirme ve ilgili yorum talebe karşı kaydedilir. | ||
|
Neden önemli
Doğrudan müşteri geri bildirimi, hizmet kalitesini ve müşteri duyarlılığını ölçmek için paha biçilmezdir. Bu derecelendirmeleri süreç akışı bağlamında analiz etmek, belirli aktiviteleri veya temsilcileri sonuçlarla ilişkilendirmeye yardımcı olur.
Nereden alınır
Müşterinin puanı ve yorumuyla 'satisfaction_rating' alanı doldurulduğunda, Bilet Denetimleri API'sinde bir 'Değişiklik' olayı olarak yakalanır.
Yakala
'satisfaction_rating' alanındaki değişiklikler için Bilet Denetim günlüklerini filtreleyin.
Event tipi
explicit
|
|||
|
Müşteri Yanıtladı
|
Bu olay, bir müşterinin, genellikle 'beklemede' durumunda olan bir talebe yanıt vermesiyle tetiklenir. Zendesk, ajanın işine devam edebileceğini işaret ederek talep durumunu otomatik olarak 'beklemede' konumundan 'açık' konumuna geri geçirir. | ||
|
Neden önemli
Bu aktivite, bir bekleme süresinin sonunu işaret eder ve sürecin devam etmesi için bir tetikleyicidir. Müşterilerin yanıt vermek için harcadıkları süreyi analiz etmek, ajan taleplerinin netliği hakkında içgörüler sağlayabilir.
Nereden alınır
Bu olay, son kullanıcıdan gelen yeni bir herkese açık yorumla ilişkilidir ve bu, Ticket Audits API'sinde durumun 'beklemede' konumundan 'açık' konumuna açık bir şekilde değişmesini tetikler.
Yakala
Durum 'Değişiklik' olaylarını 'beklemede'den 'açık'a izleyin veya bir son kullanıcıdan gelen yeni herkese açık yorumları belirleyin.
Event tipi
explicit
|
|||
|
SLA İhlali Gerçekleşti
|
Bu aktivite, bir hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi önceden tanımlanmış bir Hizmet Seviyesi Anlaşmasını karşılayamadığı anı işaret eder. Bu olay, talep aktivitesi zaman damgalarının SLA politikalarına göre karşılaştırılmasıyla hesaplanır. | ||
|
Neden önemli
SLA ihlalleri, müşteri memnuniyetini ve sözleşme uyumluluğunu doğrudan etkiler. Ne zaman ve neden meydana geldiklerini analiz etmek, sistemik gecikmeleri, kaynak kıtlıklarını veya gerçekçi olmayan performans hedeflerini belirlemek için kritiktir.
Nereden alınır
Bu, SLA ihlal zaman damgalarını ('breached_at') depolayan Zendesk Ticket Metrics API'sinden alınabilir. Alternatif olarak, talep olayı zaman damgaları tanımlı SLA kurallarına göre karşılaştırılarak hesaplanabilir.
Yakala
Ticket Metrics API'sinden 'breached_at' zaman damgasını kullanın veya çözüm süresini SLA politika süresiyle karşılaştırarak hesaplayın.
Event tipi
calculated
|
|||
|
Talep Kategorize Edildi ve Önceliklendirildi
|
Bu aktivite, bir ajan veya otomasyon, tür, kategori ve öncelik gibi talep alanlarını ayarladığında veya güncellediğinde meydana gelir. Bu adım, talebin geçmişinde bir değişiklik olayı olarak kaydedilir. | ||
|
Neden önemli
Doğru kategorizasyon ve önceliklendirme, etkin yönlendirme ve kaynak tahsisi için hayati öneme sahiptir. Bu aktiviteyi analiz etmek, ilk tasnifin doğruluğunu ve çözüm süreleri üzerindeki etkisini belirlemeye yardımcı olur.
Nereden alınır
Zendesk Bilet Denetimleri API'sinden 'Değişiklik' olayları olarak yakalanır. 'öncelik', 'tür' veya kategorizasyonla ilgili özel alanlara yapılan ilk güncellemeyi arayarak belirlenebilir.
Yakala
Oluşturulduktan sonra temel kategorizasyon alanlarındaki ilk 'Değişiklik' olayı için Bilet Denetim günlüklerini filtreleyin.
Event tipi
explicit
|
|||