Müşteri Hizmetleri Veri Şablonunuz
Müşteri Hizmetleri Veri Şablonunuz
- Toplanması önerilen öznitelikler
- Müşteri hizmetleri sürecinizde izlenecek önemli etkinlikler
- Zendesk Support için veri çıkarma rehberi
Müşteri hizmetleri öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
StartTime
|
Bir etkinliğin veya olayın ne zaman başladığını gösteren zaman damgası. | ||
|
Açıklama
Başlangıç Zamanı veya olay zaman damgası, belirli bir etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. Örneğin müşteri yorumunun eklendiği, temsilcinin atandığı veya ticket durumunun 'Resolved' olarak değiştiği zamanı gösterir. Bu zaman damgası, olayların kronolojik sırasını oluşturduğu için Process Mining açısından temel öneme sahiptir. Etkinlikler arasındaki süreleri hesaplamak, çevrim sürelerini ölçmek, SLA'lara göre 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 gereklidir.
Nereden alınır?
Zendesk Ticket Audits API, denetim izindeki her olay için
Örnekler
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
|
|||
|
Hizmet talebi
ServiceRequest
|
Ticket veya vaka olarak da adlandırılan her müşteri hizmeti talebinin benzersiz tanımlayıcısı. | ||
|
Açıklama
Hizmet Talebi, tek bir müşteri sorusu veya sorunuyla ilgili tüm etkinlikleri, oluşturulmasından nihai çözüme kadar birbirine bağlayan birincil vaka tanımlayıcısıdır. Her etkileşim, güncelleme veya dahili işlem bu benzersiz kimliğe bağlanır. Process Mining'de Hizmet Talebi temelinde gruplanan olayları analiz etmek, müşteri hizmetleri yolculuğunu uçtan uca görmenizi sağlar. Bu alan, toplam çözüm süresi gibi temel metrikleri hesaplamanın, süreç sapmalarını belirlemenin ve her müşteri sorununun yaşam döngüsünü anlamanın temelini oluşturur.
Neden önemli?
Bu, her bir müşteri hizmetleri yolculuğunun yeniden oluşturulmasını ve analiz edilmesini sağlayan, tüm süreç adımlarını birbirine bağlayan temel Vaka Kimliğidir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
102451287415332
|
|||
|
Etkinlik adı
ActivityName
|
Hizmet talebi yaşam döngüsü içinde gerçekleşen belirli olayın veya görevin adı. | ||
|
Açıklama
Etkinlik Adı, müşteri hizmetleri sürecindeki tek bir adımı veya aşamayı tanımlar. Örneğin 'Hizmet talebi oluşturuldu', 'Talep temsilciye atandı' veya 'Hizmet talebi çözüldü'. Bu olaylara zaman damgası eklenir ve her hizmet talebindeki işlem sırasını 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 büyük önem taşır. Analistlerin hangi işlemlerin gerçekleştirildiğini anlamasına, yaygın yolları, darboğazları ve standart prosedürden sapmaları belirlemesine yardımcı olur.
Neden önemli?
Bu öznitelik, süreç haritasının görselleştirilmesini ve süreç akışlarıyla varyasyonlarının analiz edilmesini sağlayan süreç adımlarını tanımlar.
Nereden alınır?
Değişiklikleri ve işlemleri kaydeden Zendesk ticket denetim günlüklerinden veya olay akışlarından elde edilir.
Örnekler
Hizmet talebi oluşturulduTalep temsilciye atandıİlk temsilci herkese açık yanıtı gönderildiHizmet talebi çözüldü
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin çıkarıldığı kayıt sistemi. | ||
|
Açıklama
Bu öznitelik, hizmet talebi verilerinin kaynak sistemini belirtir. Bu örnekte kaynak Zendesk Support'tur. Özellikle birden fazla sistemden veri birleştirildiğinde veri yönetişimine ve veri soyunun izlenmesine yardımcı olur. Analizde verilerin doğru kaynağa atanmasını sağlar. Bu, veri bütünlüğünü korumak ve özellikle çok sistemli ortamlarda sürecin bağlamını anlamak için önemlidir.
Neden önemli?
Verilerin kaynağını tanımlar. Veri yönetişimi ve entegre ortamlardaki süreç verilerini birbirinden ayırmak için önemlidir.
Nereden alınır?
Veri çıkarma işlemi sırasında eklenen ve verilerin kaynağını etiketleyen statik bir değerdir.
Örnekler
Zendesk Support
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Kaynak sistemden yapılan en son veri yenileme veya çıkarma işleminin zaman damgası. | ||
|
Açıklama
Bu öznitelik, veri setinin Zendesk Support'tan en son ne zaman güncellendiğini gösterir. Analiz edilen verilerin güncelliği hakkında bağlam sağlar. Son güncelleme zamanını bilmek, analistlerin ve iş kullanıcılarının en güncel süreç bilgilerini görüp görmediklerini anlamaları için önemlidir. Verilerin ne kadar güncel olduğuna ilişkin beklentileri yönetmeye yardımcı olur ve raporlama ile izleme açısından büyük önem taşır.
Neden önemli?
Verilerin güncelliğini netleştirerek kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sağlar.
Nereden alınır?
Veri çıkarma işlemi sırasında oluşturulan ve saklanan, çı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 almakla görevlendirilen müşteri hizmetleri temsilcisinin adı veya kimliği. | ||
|
Açıklama
Bu öznitelik, belirli bir zamanda bir etkinlikten veya hizmet talebinden sorumlu olan temsilciyi belirler. Talep yeniden atandığında bu değer yaşam döngüsü boyunca değişebilir. Atanan Temsilciye göre analiz yapmak, temsilci iş yükünü, performansını ve verimliliğini anlamak için önemlidir. Bu analiz, farklı temsilcilerin işlem sürelerini ve vaka hacimlerini karşılaştırarak Temsilci İş Yükü ve Verimliliği Dashboardını destekler. Böylece koçluk fırsatlarını belirleyebilir ve iş yüklerinin dengeli dağıtılmasını sağlayabilirsiniz.
Neden önemli?
Bir işlemi hangi temsilcinin gerçekleştirdiğini izler. Böylece bireysel performans, iş yükü dağılımı ve kaynak tahsisi analiz edilebilir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
John SmithJane DoeSupportBot
|
|||
|
Hizmet talebi türü
ServiceRequestType
|
'Question', 'Incident', 'Problem' veya 'Task' gibi hizmet talebi sınıflandırması. | ||
|
Açıklama
Bu öznitelik, hizmet talebini niteliğine göre kategorilere ayırır. Sınıflandırma genellikle talep oluşturulduğunda veya önceliklendirme sırasında belirlenir ve uygun iş akışıyla önceliğin belirlenmesine yardımcı olur. Analizde Hizmet Talebi Türüne göre segmentasyon yapmak temel bir adımdır. Hizmet Talebi Çözüm Süresi Analizi ve İç Eskalasyon Oranı ve Nedenleri gibi Dashboardlarda gösterildiği üzere farklı sorun türlerinin çözüm sürelerini, eskalasyon oranlarını ve süreç akışlarını karşılaştırmanızı sağlar. Böylece belirli talep türlerinin ele alınmasının daha sorunlu veya verimsiz olup olmadığını belirleyebilirsiniz.
Neden önemli?
Talepleri kategorilere ayırarak farklı sorun türlerinde performans karşılaştırması ve analizi yapılmasını sağlar. Hedefli süreç iyileştirmeleri için önemlidir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
SoruOlaySorunGö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 belirler. Müşterilerin hizmet masasıyla nasıl etkileşim kurduğunu gösterir. 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ı, en popüler kanalları ve belirli kanalların daha uzun çözüm süreleriyle veya farklı süreç yollarıyla ilişkili olup olmadığını görmek için bu verileri analiz eder. Hizmet iyileştirmelerine veya otomasyona hangi alanlarda yatırım yapılacağına karar vermenize yardımcı olabilir.
Neden önemli?
Müşterilerin ve temsilcilerin nasıl iletişim kurduğunu gösterir. Böylece kanal verimliliği ile bunun süreç ve müşteri deneyimi üzerindeki etkisi analiz edilebilir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
webe-postaapichat
|
|||
|
Öncelik
Priority
|
'Low', 'Normal', 'High' veya 'Urgent' gibi hizmet talebine atanan öncelik düzeyi. | ||
|
Açıklama
Öncelik, bir hizmet talebinin aciliyetini gösterir ve çoğu zaman kuyruktaki konumunu ve hedef çözüm süresini etkiler. Temsilcilerin en kritik sorunlara önce odaklanmasına yardımcı olur. Bu öznitelik performans ve SLA analizi için gereklidir. Hizmet Talebi Çözüm Süresi Analizi Dashboardı, verileri önceliğe göre segmentlere ayırır. Böylece yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı ele alınıp alınmadığını ve kaynakların işletme ihtiyaçlarına göre etkili biçimde dağıtılıp dağıtılmadığını görebilirsiniz.
Neden önemli?
Bir talebin aciliyetini gösterir. SLA uyumluluğunu analiz etmek ve acil sorunların zamanında ele alınmasını sağlamak için önemlidir.
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ülmesinin beklendiği hedef süre. | ||
|
Açıklama
Bu öznitelik, bir talebin çözülmesi için Hizmet Seviyesi Anlaşmasında tanımlanan SLA hedefini belirler. Bu hedef genellikle dinamiktir ve talebin önceliği, türü veya müşterinin hizmet planı gibi faktörlere bağlıdır. Bu öznitelik, SLA Uyumluluğu Performansı Dashboardının temel verilerinden biridir. Gerçek çözüm süresinin ölçüldüğü kıyaslama noktası olarak kullanılır. Performansı bu hedefe göre analiz etmek, hizmet sunumunun kalitesini ölçmenize ve müşterilere yönelik sözleşme yükümlülüklerinin yerine getirildiğinden emin olmanıza yardımcı olur.
Neden önemli?
Müşteriye verilen hizmet sözünü tanımlar. Zamanında performansı ve SLA uyumluluğunu ölçmek için bir ölçüt görevi görür.
Nereden alınır?
Bir ticket'a uygulanan SLA politikalarından elde edilir. Bu bilgi Zendesk Ticket Metrics API üzerinden kullanılabilir.
Örnekler
144002880086400
|
|||
|
SLA ihlal edildi mi
IsSlaBreached
|
Hizmet talebinin çözüm süresinin SLA hedefini aşıp aşmadığını gösteren boolean işareti. | ||
|
Açıklama
Bu hesaplanmış öznitelik, bir hizmet talebinin çözüm süresi için tanımlanan Hizmet Seviyesi Anlaşmasını karşılayıp karşılamadığını gösteren basit bir doğru veya yanlış işaretidir. Gerçek çözüm süresi ile planlanan SLA hedefi karşılaştırılarak hesaplanır. Bu işaret, SLA uyumluluğu analizini kolaylaştırır. SLA Uyumluluğu Performansı Dashboardının ve SLA Uyumluluk Oranı KPI’ının temel veri noktasıdır. Böylece hizmet hedeflerini karşılayan ve karşılamayan taleplerin sayısını hızlıca toplulaştırabilir ve görselleştirebilirsiniz.
Neden önemli?
Her kayıt için SLA performansını net bir ikili sonuçla gösterir, uyumluluk izleme ve raporlamasını kolaylaştırır.
Nereden alınır?
Veri dönüşümü sırasında toplam çözüm süresi SlaTargetResolutionTime ile karşılaştırılarak hesaplanır.
Örnekler
truefalse
|
|||
|
Bilgi talebi sayısı
InformationRequestCount
|
Tek bir hizmet talebi için müşteriden bilgi istenen toplam sayı. | ||
|
Açıklama
Bu hesaplanmış metrik, her hizmet talebi için "Information Requested From Customer" etkinliğinin gerçekleşme sayısını hesaplar. Yüksek bir sayı, temsilcilerin gerekli tüm bilgileri başlangıçta toplamadığını gösterir. Bu öznitelik, Tekrarlanan Bilgi Talebi Analizi Dashboardında kullanılır. Bu sayıyı izlemek, süreç verimsizliklerini ve temsilci eğitimi gerektiren alanları belirlemenize yardımcı olur. Bilginin istenme sayısını azaltmak, çözüm sürelerini önemli ölçüde kısaltabilir ve müşteri deneyimini iyileştirebilir.
Neden önemli?
Müşteriyle gerçekleşen karşılıklı iletişimi ölçer ve çözüm sürelerini uzatan, müşteri deneyimini olumsuz etkileyen verimsizlikleri ortaya çıkarır.
Nereden alınır?
Her Service Request için ActivityName değerinin 'Information Requested From Customer' olduğu olayların sayısı hesaplanarak elde edilir.
Örnekler
013
|
|||
|
Bitiş zamanı
EndTime
|
Bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Bitiş Zamanı, bir etkinliğin tamamlandığı zamanı gösterir. Birçok olay günlüğü yapısında sonraki etkinliğin Başlangıç Zamanı, mevcut etkinliğin Bitiş Zamanı olarak kullanılabilir. 'Temsilci sorunu inceliyor' gibi durum tabanlı etkinliklerde, bu durumun sona erdiği anı gösterir. Bu öznitelik, performans analizinin temel unsurlarından biri olan etkinlik sürelerini kesin biçimde hesaplamak için gereklidir. En fazla zaman alan adımları belirlemenize, ayrıntılı darboğaz analizi yapmanıza ve kaynak verimliliğini hesaplamanıza yardımcı olur.
Neden önemli?
Etkinlik sürelerinin hesaplanmasını sağlar. Bu, darboğazları belirlemek ve performansı ölçmek için önemlidir.
Nereden alınır?
Genellikle belirli bir Hizmet Talebi için dizideki sonraki olayın StartTime değeri alınarak elde edilir.
Örnekler
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
|
|||
|
Çözüm kodu
ResolutionCode
|
Talebin nihai çözümünün veya kapanışının nedenini gösteren kod ya da kategori. | ||
|
Açıklama
Çözüm Kodu, bir hizmet talebinin sonucuyla ilgili yapılandırılmış bilgi sağlar. Örnekler arasında "Solved by Agent", "Duplicate", "No Action Needed" ve "Known Issue" yer alır. Basit bir "Closed" durumuna göre daha fazla bağlam sunar. Bu öznitelik, temel neden analizi için özellikle değerlidir. Yeniden Açılan Hizmet Taleplerindeki Eğilimler Dashboardında yeniden açılma oranlarını çözüm koduna göre analiz etmek, belirli çözüm türlerinin daha az etkili olup olmadığını ortaya çıkarabilir. Bu durum, müşterilerin destek ekibiyle yeniden iletişime geçmek zorunda kalmasına yol açabilir.
Neden önemli?
Hizmet talebinin sonucu hakkında içgörü sağlar. Temel neden analizi ve taleplerin neden yeniden açıldığını anlamak için önemlidir.
Nereden alınır?
Bu, genellikle Zendesk'te özel bir ticket alanıdır. Alanın kesin adı, Zendesk yapılandırmasına göre değişir.
Ö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, genellikle kayıt çözüldükten sonra bir anket aracılığıyla toplanan müşterinin hizmet deneyimine ilişkin geri bildirimini içerir. Yaygın değerlendirmeler arasında 'İyi', 'Kötü' veya sayısal bir puan bulunur. Bu, müşteri duyarlılığının doğrudan ölçümüdür ve önemli bir sonuç metriğidir. 'Müşteri Duyarlılığı Puanı' KPI'ını hesaplamak için kullanılır. Memnuniyet puanlarını çözüm süresi veya temsilci etkileşimi sayısı gibi süreç verileriyle birlikte analiz etmek, hangi süreç davranışlarının daha iyi müşteri sonuçları sağladığını ortaya çıkarabilir.
Neden önemli?
Sunulan hizmete ilişkin müşteri geri bildirimini doğrudan ölçer ve süreç performansını müşteri sonuçlarıyla ilişkilendirir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
iyikötüsunuldu
|
|||
|
Temsilci grubu
AgentGroup
|
Hizmet talebinin atandığı destek grubu veya ekip. | ||
|
Açıklama
Bu öznitelik, hizmet talebinden sorumlu temsilcilerden oluşan ekibi gösterir. Talepler genellikle beceri, ürün alanı veya dile göre belirli gruplara yönlendirilir. Temsilci Grubu temelinde analiz yapmak, ekip düzeyindeki performansı, iş yükü dağılımını ve ekipler arasındaki eskalasyon modellerini anlamaya yardımcı olur. Bireysel temsilci analizinden daha üst düzey bir görünüm sunar ve belirli departman veya işlevlerdeki sistemik sorunları belirlemenize yardımcı olabilir.
Neden önemli?
Ekip sorumluluğunu izler. Grup performansını, ekipler arası devirleri ve farklı destek kademeleri veya uzmanlık alanları arasındaki kaynak tahsisini analiz etmenizi sağlar.
Nereden alınır?
Zendesk Tickets API,
Örnekler
1. Kademe DestekTeknik DestekFaturalandırma
|
|||
|
Ürün hizmet kategorisi
ProductServiceCategory
|
Müşteri 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 kategorilere ayırarak ayrıntılı bağlam sağlar. Genellikle bir temsilci tarafından manuel olarak veya talebin içeriğine göre otomatik biçimde belirlenir. Bu kategorilendirme, Talep Kategorilendirme Doğruluğu ve İnceleme Çevrim Süresi Dağılımı Dashboardları için büyük önem taşır. Hangi ürünlerin en fazla destek talebi oluşturduğunu, hangilerinin çözülmesinin daha karmaşık olduğunu ve ilk kategorilendirmenin son çözümle uyumlu olup olmadığını ayrıntılı olarak analiz etmenizi sağlar. Böylece yönlendirmeyi ve temsilci eğitimini iyileştirebilirsiniz.
Neden önemli?
Talepleri belirli iş alanları, ürünler veya hizmetlerle ilişkilendirir. Böylece sorunlu alanları ve bunların süreç üzerindeki etkisini odaklı biçimde analiz edebilirsiniz.
Nereden alınır?
Bu, genellikle Zendesk'te özel bir ticket alanıdır. Alanın kesin adı, Zendesk yapılandırmasına göre değişir.
Ö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 boolean işareti. | ||
|
Açıklama
Bu öznitelik, daha önce çözüldü veya kapatıldı durumuna getirilen bir hizmet talebi yeniden açık durumuna geçtiğinde true olan bir işarettir. İlk çözümün yeterli olmadığını gösterir. Bu işaret, yeniden çalışmayı ve ilk temasta çözüm başarısızlıklarını izlemek için önemlidir. Yeniden Açılan Hizmet Taleplerindeki Eğilimler Dashboardını ve Hizmet Talebi Yeniden Açılma Oranı KPI’ını doğrudan destekler. Böylece ek ilgi gerektiren vakaları kolayca sayabilir ve analiz edebilirsiniz. Bu durum çoğu zaman daha derindeki sorunlara işaret eder.
Neden önemli?
Yeniden çalışmayı ve başarısız çözümleri belirleyerek sunulan çözümlerin kalitesini ve etkililiğini ölçmenize yardımcı olur.
Nereden alınır?
Veri dönüşümü sırasında bir kaydın durumunun 'resolved' veya 'closed' değerinden yeniden 'open' değerine geçip geçmediği kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
Müşteri hizmetleri aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet talebi çözüldü
|
Bir temsilci, müşteriye çözüm sunduktan sonra hizmet talebini 'solved' olarak işaretler. Bu geçici bir durumdur, çünkü müşteri yanıtı gelmeden önce ticket yeniden açılabilir. | ||
|
Neden önemli?
Bu, çözüm süresini ve temsilci verimliliğini ölçmek için temel aşamadır. Temsilcinin çalışmanın tamamlandığına inandığı noktayı gösterir ve ticket yeniden açılırsa yeniden çalışma analizine temel oluşturur.
Nereden alınır?
Zendesk Ticket Audits API'de 'status' alanı 'solved' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir.
Yakalayın
Ticket Audits içinde ticket durumunun 'solved' olarak ayarlandığı 'Change' olaylarını belirleyin.
Olay türü
explicit
|
|||
|
Hizmet talebi kapatıldı
|
Bu, hizmet talebinin kalıcı olarak kapatıldığını gösteren son etkinliktir. Genellikle ticket 'solved' olarak işaretlendikten sonra müşteriden yeni bir yanıt gelmeden belirli bir süre geçince otomatik olarak gerçekleşir. | ||
|
Neden önemli?
Kesin bitiş olayı olarak ticket yaşam döngüsünü tamamlar. 'solved' durumundan 'closed' durumuna kadar geçen süre, yeniden açılma ihtimalinin bulunduğu aralığı gösterir. 'closed' olayı ise çözümün kabul edildiğini doğrular.
Nereden alınır?
Zendesk Ticket Audits API'de 'status' alanı 'closed' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir.
Yakalayın
Ticket Audits içinde ticket durumunun 'closed' olarak ayarlandığı 'Change' olaylarını belirleyin.
Olay türü
explicit
|
|||
|
Hizmet talebi oluşturuldu
|
Bu etkinlik, e-posta, web formu veya sohbet gibi herhangi bir kanaldan Zendesk'te yeni bir ticket oluşturulduğunda müşteri hizmetleri sürecinin başladığını gösterir. Sistem, bu olayı oluşturma sırasında benzersiz bir ticket kimliği ve zaman damgasıyla açıkça kaydeder. | ||
|
Neden önemli?
Birincil başlangıç olayı olarak bu etkinlik, toplam vaka süresini hesaplamak ve zaman içindeki gelen talep hacmini analiz etmek için gereklidir. İlk yanıt süresi ve toplam çözüm süresi gibi temel performans göstergelerini ölçmek için başlangıç noktası oluşturur.
Nereden alınır?
Bu, Zendesk Ticket Audits API'de kaydedilen açık bir olaydır. Bir ticket için 'Create' olayına karşılık gelir ve ilk oluşturma zaman damgasını sağlar.
Yakalayın
Ticket oluşturma olayından, Ticket Audits günlüğünde kaydedilir.
Olay türü
explicit
|
|||
|
Hizmet talebi yeniden açıldı
|
Müşteri, durumu 'solved' olan bir ticket'a yanıt verdiğinde gerçekleşir. Zendesk, sorunun tamamen çözülmediğini göstermek için durumu otomatik olarak yeniden 'open' olarak değiştirir. | ||
|
Neden önemli?
Yeniden açılmalar, İlk Temasta Çözüm başarısızlığının ve çözüm kalitesinin düşük olduğunun önemli göstergeleridir. Yeniden açılan ticket'ların sıklığını ve nedenlerini analiz etmek, temsilci eğitimini ve çözüm prosedürlerini iyileştirebileceğiniz alanları belirlemenize yardımcı olur.
Nereden alınır?
Ticket Audits API'de 'status' alanı 'solved' durumundan yeniden 'open' durumuna geçtiğinde kaydedilen açık bir durum değişikliğidir.
Yakalayın
'solved' durumundan 'open' durumuna gerçekleşen 'Change' olaylarını izleyin.
Olay türü
explicit
|
|||
|
Müşteriden bilgi istendi
|
Bir temsilcinin ilerlemek için müşteriden daha fazla bilgiye ihtiyaç duyması ve ticket durumunu 'pending' olarak değiştirmesiyle gerçekleşir. Bu durum değişikliği, sürecin artık dış bir tarafın yanıtını beklediğini açıkça gösterir. | ||
|
Neden önemli?
Bu etkinlik, müşteriye bağlı noktaları gösterir ve dahili SLA sayaçlarını duraklatır. Tek bir ticket üzerinde sık veya tekrarlanan biçimde gerçekleşmesi, başlangıçta yeterli bilgi toplanmadığını ve çözüm sürelerinin uzayabileceğini gösterebilir.
Nereden alınır?
Zendesk Ticket Audits API'de kaydedilen açık bir durum değişikliği olayıdır. 'status' alanı 'pending' olarak değiştirildiğinde kaydedilir.
Yakalayın
Ticket Audits içinde ticket durumunun 'pending' olarak ayarlandığı 'Change' olaylarını belirleyin.
Olay türü
explicit
|
|||
|
Talep temsilciye atandı
|
Bu olay, hizmet talebinin işlenmek üzere belirli bir temsilciye atandığını gösterir. Atama, yönlendirme kurallarına göre otomatik olarak veya ekip lideri ya da temsilci tarafından manuel olarak yapılabilir. | ||
|
Neden önemli?
Atama, sorumluluk ve iş yükü yönetimi açısından önemli bir aşamadır. Atamaya kadar geçen süreyi ve yeniden atama modellerini analiz etmek, triyaj ve dağıtım sürecindeki darboğazları ortaya çıkarır.
Nereden alınır?
Zendesk Ticket Audits API'de açık bir 'Change' olayıdır ve 'assignee_id' alanı doldurulduğunda veya değiştirildiğinde kaydedilir.
Yakalayın
Ticket Audits günlüğünde 'assignee_id' alanındaki değişiklikleri izleyin.
Olay türü
explicit
|
|||
|
Dahili eskalasyon tetiklendi
|
Bir hizmet talebinin farklı bir dahili ekibe veya daha üst bir destek kademesine aktarılmasını ifade eder. Bu durum genellikle ticket'ın atandığı grubun değiştirilmesiyle anlaşılır. | ||
|
Neden önemli?
Eskalasyonları izlemek, süreç zayıflıklarını, ilk kademe desteğindeki bilgi eksiklerini ve karmaşık talep türlerini belirlemek için önemlidir. Yüksek eskalasyon oranları, daha iyi eğitim veya süreç dokümantasyonu gerektiğini gösterebilir.
Nereden alınır?
Zendesk Ticket Audits API'de 'group_id' alanının değiştirildiği bir 'Change' olayından çıkarılır. Grup değişikliği, ekipler arasında bir devir gerçekleştiğini gösterir.
Yakalayın
Ticket Audits günlüğünde 'group_id' alanındaki değişiklikleri izleyin.
Olay türü
inferred
|
|||
|
İlk bilgilendirme gönderildi
|
Müşteriye talebinin alındığını bildiren otomatik ilk yanıtı ifade eder. Bu işlem genellikle, ticket oluşturulduktan hemen sonra şablonlu bir e-posta bildirimi gönderen bir Zendesk tetikleyicisi tarafından gerçekleştirilir. | ||
|
Neden önemli?
Bu etkinliği izlemek, ilk yanıt verme hızını ölçmek ve müşteri beklentilerini yönetmek için önemlidir. Talebin oluşturulması ile bu bilgilendirme arasındaki süre, müşteri memnuniyeti açısından önemli bir metriktir.
Nereden alınır?
Yazarı otomatik bir kullanıcı olan veya ticket oluşturulduktan birkaç saniye içinde gerçekleşen ilk herkese açık yorumdan çıkarılır. Bu bilgi, Ticket Comments akışı analiz edilerek belirlenebilir.
Yakalayın
Ticket oluşturulduktan hemen sonra bir otomasyon veya tetikleyici tarafından oluşturulan ilk herkese açık yorumu belirleyin.
Olay türü
inferred
|
|||
|
İlk temsilci herkese açık yanıtı gönderildi
|
Bu etkinlik, otomatik bilgilendirmeden farklı olarak bir temsilcinin müşteriye ilk kez herkese açık yorum gönderdiği anı gösterir. Müşterinin sorunuyla ilk aktif ilgilenmeyi gösterdiği için önemli bir olaydır. | ||
|
Neden önemli?
Bu, hizmete yanıt verme hızının önemli bir göstergesi olan 'First Reply Time' SLA'sını ölçmek için temel bir aşamadır. Otomatik iletişim ile insan tarafından yürütülen aktif inceleme ve desteğin başlangıcını birbirinden ayırır.
Nereden alınır?
Ticket Comments akışında, yazarın otomatik sistem kullanıcısı değil insan bir temsilci olduğu ilk herkese açık yorum bulunarak belirlenir.
Yakalayın
Ticket yorumlarını tarayın, temsilcilerin herkese açık yorumlarını filtreleyin ve zaman damgası en erken olan yorumu seçin.
Olay türü
inferred
|
|||
|
Memnuniyet anketi gönderildi
|
Müşteriye otomatik olarak müşteri memnuniyeti (CSAT) anketinin gönderildiği noktayı ifade eder. Bu işlem genellikle ticket 'solved' olarak işaretlendikten kısa süre sonra gerçekleşir. | ||
|
Neden önemli?
Bu etkinlik, 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ğlam içinde değerlendirmek ve geri bildirim programının etkinliğini ölçmek için önemlidir.
Nereden alınır?
Bir otomasyon günlüğünden veya ticket'a belirli bir etiket eklenmesinden çıkarılabilir. Ticket Audits API'deki 'satisfaction_rating' bölümü de anketin sunulduğu zamanı kaydeder.
Yakalayın
'csat_sent' gibi etiketleri arayın veya memnuniyet puanlamasının sunulduğu zamana ait zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Memnuniyet puanı alındı
|
Müşteri, memnuniyet anketine 'Good' veya 'Bad' gibi bir puan vererek yanıtını gönderdiğinde gerçekleşir. Puan ve varsa ilgili yorum ticket'a kaydedilir. | ||
|
Neden önemli?
Doğrudan müşteri geri bildirimi, hizmet kalitesini ve müşteri algısını ölçmek için çok değerlidir. Bu puanları süreç akışı bağlamında analiz etmek, belirli etkinlikleri veya temsilcileri sonuçlarla ilişkilendirmenize yardımcı olur.
Nereden alınır?
Ticket Audits API'de 'satisfaction_rating' alanı müşterinin puanı ve yorumuyla doldurulduğunda 'Change' olayı olarak kaydedilir.
Yakalayın
Ticket Audits günlüklerini 'satisfaction_rating' alanındaki değişiklikler için filtreleyin.
Olay türü
explicit
|
|||
|
Müşteri yanıt verdi
|
Müşteri, genellikle 'pending' durumundaki bir ticket'a yanıt verdiğinde tetiklenir. Zendesk, temsilcinin çalışmaya devam edebileceğini göstermek için ticket durumunu otomatik olarak 'pending' durumundan 'open' durumuna geçirir. | ||
|
Neden önemli?
Bu etkinlik, bekleme süresinin sona erdiğini ve sürecin devam etmesi için tetikleyici oluştuğunu gösterir. Müşterilerin yanıt vermesinin ne kadar sürdüğünü analiz etmek, temsilci taleplerinin ne kadar açık olduğunu anlamanıza yardımcı olabilir.
Nereden alınır?
Bu olay, son kullanıcıdan gelen yeni bir herkese açık yoruma karşılık gelir ve Ticket Audits API'de 'pending' durumundan 'open' durumuna açık bir durum değişikliğini tetikler.
Yakalayın
'pending' durumundan 'open' durumuna gerçekleşen 'Change' olaylarını izleyin veya son kullanıcıdan gelen yeni herkese açık yorumları belirleyin.
Olay türü
explicit
|
|||
|
SLA ihlali gerçekleşti
|
Bu etkinlik, bir hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi önceden belirlenmiş bir Service Level Agreement koşulunu karşılayamadığı anı gösterir. Olay, ticket etkinliklerinin zaman damgaları SLA politikalarıyla karşılaştırılarak hesaplanır. | ||
|
Neden önemli?
SLA ihlalleri müşteri memnuniyetini ve sözleşme uyumluluğunu doğrudan etkiler. Ne zaman ve neden gerçekleştiğini analiz etmek, sistemik gecikmeleri, kaynak yetersizliklerini veya gerçekçi olmayan performans hedeflerini belirlemek için önemlidir.
Nereden alınır?
Bu bilgi, SLA ihlali zaman damgalarını ('breached_at') saklayan Zendesk Ticket Metrics API'den alınabilir. Alternatif olarak ticket olaylarının zaman damgaları tanımlanan SLA kurallarıyla karşılaştırılarak hesaplanabilir.
Yakalayın
Ticket Metrics API'deki 'breached_at' zaman damgasını kullanın veya çözüm süresini SLA politika süresiyle karşılaştırarak hesaplayın.
Olay türü
calculated
|
|||
|
Talep kategorilere ayrıldı ve önceliklendirildi
|
Bu etkinlik, bir temsilci veya otomasyon type, category ve priority gibi ticket alanlarını belirlediğinde ya da güncellediğinde gerçekleşir. Bu adım, ticket geçmişinde bir değişiklik olayı olarak kaydedilir. | ||
|
Neden önemli?
Doğru kategorilendirme ve önceliklendirme, verimli yönlendirme ve kaynak tahsisi için büyük önem taşır. Bu etkinliği analiz etmek, ilk triyajın doğruluğunu ve çözüm sürelerine etkisini belirlemenize yardımcı olur.
Nereden alınır?
Zendesk Ticket Audits API'de 'Change' olayları olarak kaydedilir. 'priority', 'type' veya kategorilendirmeyle ilgili özel alanlarda yapılan ilk güncelleme aranarak belirlenebilir.
Yakalayın
Ticket Audits günlüklerini, oluşturma sonrasında temel kategorilendirme alanlarında gerçekleşen ilk 'Change' olayı için filtreleyin.
Olay türü
explicit
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Template ile verilerinizi hazırlayarak müşteri hizmetlerinizi bugün iyileştirmeye başlayın. Değerli içgörüleri keşfedin ve Zendesk Support operasyonlarınızda verimliliği artırın.
Müşteri hizmetlerindeki darboğazları ortadan kaldırın, CSAT'ı şimdi artırın
Tekrarlanan iletişimleri durdurun. %80 FCR'ye ulaşın ve müşteri memnuniyetini artırın.
Kredi kartı gerekmez