Müşteri Hizmetleri Veri Şablonunuz

Zendesk Support
Müşteri Hizmetleri Veri Şablonunuz

Müşteri Hizmetleri Veri Şablonunuz

Bu Template, müşteri hizmetleri sürecinizi analiz etmek için doğru verileri toplamanıza yardımcı olur. Toplanması gereken temel veri özniteliklerini ve izlenecek önemli etkinlikleri açıklar, ayrıca bu bilgileri nasıl çıkaracağınıza ilişkin pratik yönlendirme sunar. Bu rehberi kullanarak içgörüleri ortaya çıkarmak ve hizmet operasyonlarınızı iyileştirmek için güvenilir bir Event Log oluşturabilirsiniz.
  • Toplanması önerilen öznitelikler
  • Müşteri hizmetleri sürecinizde izlenecek önemli etkinlikler
  • Zendesk Support için veri çıkarma rehberi
Event Loglarına yeni misiniz? Öğrenin Process Mining Event Logu oluşturmayı öğrenin.

Müşteri hizmetleri öznitelikleri

Kapsamlı müşteri hizmetleri analizi için Event Logunuza eklemeniz önerilen veri alanları bunlardır.
5 Gerekli 6 Önerilen 7 İsteğe bağlı
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 created_at alanı.

Ö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, id alanı.

Ö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, assignee_id alanı. Kullanıcı ayrıntıları Users API'den alınabilir.

Ö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, type alanı.

Ö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, via.channel alanı.

Ö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, priority alanı.

Ö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, satisfaction_rating.score alanı.

Ö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, group_id alanı. Grup ayrıntıları Groups API'den alınabilir.

Ö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
Gerekli Önerilen İsteğe bağlı

Müşteri hizmetleri aktiviteleri

Müşteri hizmetleri sürecini doğru şekilde keşfetmek için Event Logunuzda yakalamanız gereken temel süreç adımları ve kilometre taşları bunlardır.
6 Önerilen 8 İsteğe bağlı
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
Önerilen İsteğe bağlı

Veri çıkarma rehberleri

Verilerinizi Zendesk Support'tan nasıl alırsınız

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.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez