Müşteri hizmetleri veri Templateiniz
Müşteri hizmetleri veri Templateiniz
- Toplanması önerilen öznitelikler
- Müşteri hizmetleri sürecinizde izlenecek temel 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üşterinin yorum eklediği, temsilcinin atandığı veya talep durumunun 'Resolved' olarak değiştiği zamanı gösterir. Bu zaman damgası, olayların kronolojik sırasını belirlediği için Process Mining açısından temel önemdedir. Etkinlikler arasındaki süreleri hesaplamak, çevrim sürelerini ölçmek, SLA hedeflerine göre performansı analiz etmek ve hizmet sürecinin zaman içindeki işleyişini anlamak için kullanılır.
Neden önemli?
Olayları sıralamak, süreleri hesaplamak ve hizmet talebi sürecinin zaman çizelgesini analiz etmek için bu zaman damgası gereklidir.
Nereden alınır?
Zendesk Ticket Audits API, denetim izindeki her olayın
Örnekler
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
|
|||
|
Hizmet talebi
ServiceRequest
|
Her müşteri hizmetleri talebinin, yani talep veya vakanın benzersiz tanımlayıcısı. | ||
|
Açıklama
Hizmet Talebi, tek bir müşteri sorunu veya sorusuyla ilgili tüm etkinlikleri, oluşturulma anından nihai çözüme kadar birbirine bağlayan temel vaka tanımlayıcısıdır. Her etkileşim, güncelleme veya kurum içi işlem bu benzersiz kimlikle ilişkilendirilir. Process Mining’de etkinlikleri Hizmet Talebi bazında gruplandırarak müşteri hizmetleri yolculuğunu baştan sona görebilirsiniz. Bu, 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 temel Vaka kimliği, sürecin tüm adımlarını birbirine bağlayarak her müşteri hizmetleri yolculuğunun yeniden oluşturulmasını ve analiz edilmesini sağlar.
Nereden alınır?
Zendesk Tickets API,
Örnekler
102451287415332
|
|||
|
Etkinlik adı
ActivityName
|
Hizmet talebinin yaşam döngüsünde gerçekleşen belirli olayın veya görevin adı. | ||
|
Açıklama
Etkinlik adı, müşteri hizmetleri sürecindeki tek bir adımı veya kilometre taşını 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ştururlar. Bu öznitelik, süreç akışını görselleştirmek, süreç çeşitlerini keşfetmek ve olayların sıklığını ve sırasını analiz etmek için önemlidir. Analistlerin hangi işlemlerin yapıldığını anlamasına, yaygın yolları, darboğazları ve standart prosedürden sapmaları belirlemesine yardımcı olur.
Neden önemli?
Bu öznitelik, süreç adımlarını tanımlar; süreç haritasını görselleştirmenizi, süreç akışlarını ve farklılıklarını analiz etmenizi sağlar.
Nereden alınır?
Değişiklikleri ve işlemleri kaydeden Zendesk talep denetim günlüklerinden veya olay akışlarından elde edilir.
Örnekler
Hizmet talebi oluşturulduTalep temsilciye atandıTemsilciden ilk 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 geldiği sistemi belirtir. Bu örnekte kaynak Zendesk Support’tur. Özellikle birden fazla sistemden gelen veriler birleştirildiğinde veri yönetişimi ve veri soy ağacının izlenmesine yardımcı olur. Analiz sırasında verilerin doğru kaynağa bağlanmasını sağlar. Bu, veri bütünlüğünü korumak ve özellikle birden fazla sistemin kullanıldığı ortamlarda sürecin bağlamını anlamak açısından önemlidir.
Neden önemli?
Verinin kaynağını belirterek veri yönetişimine ve entegre ortamlardaki süreç verilerinin birbirinden ayrılmasına yardımcı olur.
Nereden alınır?
Veri çıkarma sırasında verinin kaynağını belirtmek için eklenen sabit 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 ne kadar güncel olduğu hakkında bilgi verir. 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ına yardımcı olur. Verilerin güncelliğine ilişkin beklentileri yönetmeyi kolaylaştırır ve raporlama ile izleme için önemlidir.
Neden önemli?
Verilerin ne kadar güncel olduğunu göstererek kullanıcıların süreç analizinin güncelliğini anlamasına yardımcı olur.
Nereden alınır?
Veri çıkarma sırasında oluşturulup saklanan ve çıkarma işleminin zaman damgasını kaydeden bir meta veri alanıdır.
Örnekler
2023-10-27T02:00:00Z
|
|||
|
Atanan temsilci
AssignedAgent
|
Hizmet talebini işlemekle görevlendirilen müşteri hizmetleri temsilcisinin adı veya kimliği. | ||
|
Açıklama
Bu öznitelik, belirli bir zamanda bir etkinlikten veya hizmet talebinden sorumlu temsilciyi gösterir. Talep yeniden atandığında yaşam döngüsü boyunca değişebilir. Atanan temsilciye göre analiz yapmak, temsilcilerin iş yükünü, performansını ve verimliliğini anlamak açısından önemlidir. 'Temsilci iş yükü ve verimliliği' Dashboardunda farklı temsilcilerin işlem sürelerini ve vaka hacimlerini karşılaştırmayı sağlar. Böylece koçluk fırsatlarını belirleyebilir ve iş yükünün dengeli dağıtılmasına yardımcı olabilirsiniz.
Neden önemli?
İşlemi hangi temsilcinin yaptığını izleyerek bireysel performansın, iş yükü dağılımının ve kaynak tahsisinin analiz edilmesini sağlar.
Nereden alınır?
Zendesk Tickets API,
Örnekler
John SmithJane DoeSupportBot
|
|||
|
Hizmet talebi türü
ServiceRequestType
|
'Question', 'Incident', 'Problem' veya 'Task' gibi hizmet talebinin sınıflandırması. | ||
|
Açıklama
Bu öznitelik, hizmet talebini niteliğine göre sınıflandırır. Sınıflandırma genellikle talep oluşturulurken veya ilk değerlendirme sırasında belirlenir ve uygun iş akışının ve önceliğin seçilmesine yardımcı olur. Analizde, Hizmet Talebi Türüne göre segmentlere ayırmak temel önem taşır. 'Hizmet talebi çözüm süresi analizi' ve 'Kurum içi üst kademeye aktarma oranı ve nedenleri' gibi Dashboardlarda farklı sorun türlerinin çözüm sürelerini, üst kademeye aktarma oranlarını ve süreç akışlarını karşılaştırabilirsiniz. Böylece belirli talep türlerinin çözümünün daha zor veya verimsiz olup olmadığını belirleyebilirsiniz.
Neden önemli?
Talepleri sınıflandırarak farklı sorun türlerinin performansını karşılaştırıp analiz etmenizi sağlar. Bu, süreç iyileştirmelerini hedeflemek açısından önemlidir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
SoruOlaySorunGörev
|
|||
|
İletişim kanalı
CommunicationChannel
|
Hizmet talebinin iletildiğ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 belirtir. Müşterilerin hizmet masasıyla nasıl iletişim kurduğunu gösterir. Kaynak planlaması yapmak ve müşteri deneyimini iyileştirmek için kanalların nasıl kullanıldığını anlamak önemlidir. 'İletişim kanalı kullanımına genel bakış' Dashboardu, en çok kullanılan kanalları ve belirli kanalların daha uzun çözüm süreleriyle ya da farklı süreç akışlarıyla ilişkili olup olmadığını inceler. Hizmet iyileştirmelerine veya otomasyona hangi alanlarda yatırım yapılacağına karar vermenize yardımcı olabilir.
Neden önemli?
Müşterilerle temsilciler arasındaki etkileşimi göstererek kanal verimliliğini ve kanalların süreç ile müşteri deneyimi üzerindeki etkisini analiz etmenizi sağlar.
Nereden alınır?
Zendesk Tickets API,
Örnekler
webe-postaapisohbet
|
|||
|
Öncelik
Priority
|
'Low', 'Normal', 'High' veya 'Urgent' gibi hizmet talebine atanan öncelik düzeyi. | ||
|
Açıklama
Öncelik, hizmet talebinin ne kadar acil olduğunu gösterir ve genellikle kuyruktaki sırasını ve hedef çözüm süresini etkiler. Temsilcilerin önce en acil sorunlara odaklanmasına yardımcı olur. Bu öznitelik, performans ve SLA analizleri için önemlidir. 'Hizmet talebi çözüm süresi analizi' Dashboardu, verileri önceliğe göre gruplandırır. Böylece yüksek öncelikli taleplerin daha düşük öncelikli taleplerden hızlı işlenip işlenmediğini ve kaynakların iş ihtiyaçlarına göre etkili biçimde dağıtılıp dağıtılmadığını görebilirsiniz.
Neden önemli?
Bir talebin aciliyetini belirtir. SLA uyumluluğunu analiz etmek ve kritik sorunların hızla ele alınmasını sağlamak için önemlidir.
Nereden alınır?
Zendesk Tickets API,
Örnekler
DüşükNormalYüksekAcil
|
|||
|
SLA aşıldı mı
IsSlaBreached
|
Hizmet talebinin çözüm süresinin SLA hedefini aşıp aşmadığını belirten mantıksal değer. | ||
|
Açıklama
Hesaplanan bu öznitelik, bir hizmet talebinin tanımlı çözüm süresi SLA’sını karşılayıp karşılamadığını doğru veya yanlış olarak gösterir. Gerçek çözüm süresiyle planlanan SLA hedefi karşılaştırılarak hesaplanır. Bu gösterge, SLA uyumluluğu analizini kolaylaştırır. 'SLA uyumluluk performansı' Dashboardu ve 'SLA uyumluluk oranı' KPI’ı için temel veri noktasıdır. Hizmet hedeflerini karşılayan ve karşılayamayan talepleri hızla toplamanıza ve görselleştirmenize olanak tanır.
Neden önemli?
Her talep için SLA performansını net biçimde, iki olası sonuçla gösterir; uyumluluk takibini ve raporlamayı kolaylaştırır.
Nereden alınır?
Veri dönüştürme sırasında toplam çözüm süresi SlaTargetResolutionTime ile karşılaştırılarak hesaplanır.
Örnekler
truefalse
|
|||
|
SLA hedef çözüm süresi
SlaTargetResolutionTime
|
SLA politikasına göre bir hizmet talebinin çözülmesinin beklendiği hedef süre. | ||
|
Açıklama
Bu öznitelik, bir talebin çözümü için geçerli olan Hizmet Seviyesi Anlaşması (SLA) hedefini tanımlar. Bu hedef genellikle dinamiktir; talebin önceliği, türü veya müşterinin hizmet planı gibi etkenlere bağlıdır. 'SLA uyumluluk performansı' Dashboardu için temel bir özniteliktir. Gerçek çözüm süresini ölçmek için karşılaştırma ölçütü olarak kullanılır. Bu hedefe göre performansı incelemek, hizmet sunumunun kalitesini ölçmenize ve müşterilere verilen sözleşme taahhütlerinin yerine getirilip getirilmediğini görmenize yardımcı olur.
Neden önemli?
Müşteriye verilen hizmet sözünü tanımlar; zamanında hizmet sunumunu ve SLA uyumluluğunu ölçmek için karşılaştırma ölçütü sağlar.
Nereden alınır?
Bir talebe uygulanan SLA politikalarından elde edilir. Bu bilgiye Zendesk Ticket Metrics API üzerinden ulaşabilirsiniz.
Örnekler
144002880086400
|
|||
|
Bilgi talebi sayısı
InformationRequestCount
|
Tek bir hizmet talebi için müşteriden toplam kaç kez bilgi istendiği. | ||
|
Açıklama
Bu hesaplanan metrik, her hizmet talebi için 'Müşteriden bilgi istendi' etkinliğinin kaç kez gerçekleştiğini sayar. Sayının yüksek olması, temsilcilerin gerekli tüm bilgileri başlangıçta toplamadığını gösterebilir. Bu öznitelik, 'Tekrarlanan bilgi talepleri analizi' Dashboardunda kullanılır. Talep sayısını izlemek, süreç verimsizliklerini ve temsilci eğitimi gerektiren alanları belirlemenize yardımcı olur. Bilgi isteme sayısını azaltmak, çözüm sürelerini kısaltabilir ve müşteri deneyimini iyileştirebilir.
Neden önemli?
Müşteriyle yapılan karşılıklı yazışma sayısını ölçer; çözüm süresini uzatan ve müşteri deneyimini olumsuz etkileyen verimsizlikleri ortaya çıkarır.
Nereden alınır?
Her hizmet talebi için ActivityName değeri 'Müşteriden bilgi istendi' olan olaylar sayılarak hesaplanır.
Ö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 ise ilgili durumun sona erdiği anı gösterir. Bu öznitelik, performans analizinin temel bileşenlerinden biri olan etkinlik sürelerini doğru hesaplamak için gereklidir. En çok zaman alan adımları belirlemeye, ayrıntılı darboğaz analizi yapmaya ve kaynak verimliliğini hesaplamaya yardımcı olur.
Neden önemli?
Etkinlik sürelerini hesaplamayı sağlar. Bu hesaplama, darboğazları belirlemek ve performansı ölçmek için önemlidir.
Nereden alınır?
Genellikle belirli bir Hizmet Talebi için sıradaki olayın başlangıç zamanı kullanılarak elde edilir.
Örnekler
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
|
|||
|
Çözüm kodu
ResolutionCode
|
Talebin nasıl çözüldüğünü veya kapatıldığını belirten kod ya da kategori. | ||
|
Açıklama
Çözüm kodu, hizmet talebinin sonucu hakkında yapılandırılmış bilgi sunar. Örnekler arasında 'Temsilci tarafından çözüldü', 'Yinelenen talep', 'İşlem gerekmiyor' ve 'Bilinen sorun' yer alır. Bu kod, basit bir 'Kapalı' durumundan daha fazla bağlam sağlar. Bu öznitelik, temel neden analizinde özellikle yararlıdır. 'Yeniden açılan hizmet taleplerindeki eğilimler' Dashboardunda, yeniden açılma oranlarını çözüm koduna göre incelemek, bazı çözüm türlerinin daha az etkili olduğunu ve müşterilerin destek ekibiyle yeniden iletişime geçmek zorunda kaldığını ortaya çıkarabilir.
Neden önemli?
Hizmet talebinin sonucunu anlamanızı sağlar. Temel neden analizi ve taleplerin neden yeniden açıldığını belirlemek için önemlidir.
Nereden alınır?
Bu genellikle Zendesk’te özel olarak tanımlanmış bir talep alanıdır. Alanın tam adı, Zendesk yapılandırmanıza bağlıdır.
Örnekler
İlk temasta çözüm2. düzey desteğe aktarıldıMüşteriden yanıt bekleniyorÜrün hatası
|
|||
|
Memnuniyet puanı
SatisfactionRating
|
Hizmet talebi çözüldükten sonra müşterinin verdiği memnuniyet puanı. | ||
|
Açıklama
Bu öznitelik, genellikle talep çözüldükten sonra yapılan bir anketle toplanan müşteri geri bildirimini kaydeder. Yaygın yanıtlar arasında 'İyi', 'Kötü' veya sayısal bir puan bulunur. Müşteri algısını doğrudan ölçer ve süreç sonuçlarını değerlendirmek için kullanılır. 'Müşteri algısı skoru' KPI’ını hesaplamaya yardımcı olur. Memnuniyet puanlarını çözüm süresi veya temsilci etkileşimi sayısı gibi süreç verileriyle birlikte inceleyerek hangi süreç adımlarının müşteriler için daha iyi sonuçlar sağladığını görebilirsiniz.
Neden önemli?
Sunulan hizmetle ilgili 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 temsilci ekibini belirtir. Talepler genellikle uzmanlık alanına, ürün grubuna veya dile göre belirli ekiplere yönlendirilir. Temsilci grubuna göre analiz yapmak; ekip performansını, iş yükü dağılımını ve ekipler arasındaki üst düzeye aktarma örüntülerini anlamanıza yardımcı olur. Tek tek temsilcileri incelemekten daha geniş bir bakış sunar ve belirli departmanlardaki ya da işlevlerdeki sistemik sorunları belirlemeyi kolaylaştırır.
Neden önemli?
Ekip sorumluluğunu izleyerek grup performansını, ekipler arasındaki devir teslimleri ve farklı destek düzeyleri ya da uzmanlık alanlarındaki kaynak dağılımını analiz etmenizi sağlar.
Nereden alınır?
Zendesk Tickets API,
Örnekler
1. düzey destekTeknik destekFaturalandırma
|
|||
|
Ürün ve hizmet kategorisi
ProductServiceCategory
|
Müşterinin talebinin ilgili olduğu ürün, hizmet veya özellik. | ||
|
Açıklama
Bu öznitelik, hizmet talebini ürün veya hizmet alanına göre sınıflandırarak ayrıntılı bağlam sunar. Sınıflandırmayı genellikle bir temsilci elle yapar veya talep içeriğine göre sistem otomatik olarak belirler. Bu sınıflandırma, 'Talep sınıflandırma doğruluğu' ve 'İnceleme çevrim süresi dağılımı' Dashboardları için önemlidir. Hangi ürünlerin en çok destek talebi oluşturduğunu, hangilerinin çözümünün daha karmaşık olduğunu ve ilk sınıflandırmanın nihai çözümle örtüşüp örtüşmediğini ayrıntılı biçimde incelemenizi sağlar. Böylece talepleri doğru ekiplere yönlendirebilir ve temsilci eğitimlerini iyileştirebilirsiniz.
Neden önemli?
Talepleri belirli iş alanları, ürünler veya hizmetlerle ilişkilendirerek sorunlu alanları ve bunların süreç üzerindeki etkisini hedefli biçimde analiz etmenizi sağlar.
Nereden alınır?
Bu genellikle Zendesk’te özel olarak tanımlanmış bir talep alanıdır. Alanın tam adı, Zendesk yapılandırmanıza bağlıdır.
Örnekler
Mobil uygulamaAbonelik yönetimiAPI entegrasyonuDonanım
|
|||
|
Yeniden açıldı mı
IsReopened
|
Hizmet talebinin çözüldü olarak işaretlendikten sonra yeniden açılıp açılmadığını belirten mantıksal değer. | ||
|
Açıklama
Bu gösterge, bir hizmet talebi çözüldü veya kapatıldıktan sonra yeniden açık duruma geçtiğinde doğru değerini alır. İlk çözümün yeterli olmadığını gösterir. 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' Dashboardunu ve 'Hizmet talebinin yeniden açılma oranı' KPI’ını destekler. Ek inceleme gerektiren talepleri kolayca sayıp analiz etmenizi sağlar. Bu talepler ç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üştürme sırasında, talep durumu 'çözüldü' veya 'kapalı' değerinden yeniden 'açık' değerine geçtiğinde hesaplanır.
Örnekler
truefalse
|
|||
Müşteri hizmetleri etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet talebi çözüldü
|
Temsilci, müşteriye çözüm sunduktan sonra hizmet talebini 'solved' olarak işaretler. Bu geçici bir durumdur; talep, kalıcı olarak kapatılmadan önce müşterinin yanıtıyla yeniden açılabilir. | ||
|
Neden önemli?
Bu, çözüm süresini ve temsilci verimliliğini ölçmek için temel kilometre taşıdır. Temsilcinin işi tamamladığını düşündüğü anı gösterir. Talep yeniden açılırsa yeniden çalışma ihtiyacını analiz etmek için de başlangıç noktası sağlar.
Nereden alınır?
Zendesk Ticket Audits API’de 'status' alanı 'solved' olarak ayarlandığında kaydedilen açık bir durum değişikliğidir.
Kaydedin
Talep durumunun 'solved' olarak ayarlandığı 'Change' olaylarını Ticket Audits içinde belirleyin.
Olay türü
explicit
|
|||
|
Hizmet talebi kapatıldı
|
Bu, hizmet talebinin kalıcı olarak kapatıldığını gösteren son etkinliktir. Genellikle talep '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 talep yaşam döngüsünü tamamlar. 'solved' durumundan 'closed' durumuna kadar geçen süre, talebin yeniden açılabileceği 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.
Kaydedin
Talep durumunun 'closed' olarak ayarlandığı 'Change' olaylarını Ticket Audits içinde 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 talep kaydı oluşturulduğunda müşteri hizmetleri sürecinin başladığını gösterir. Sistem, kayıt oluşturulurken bu olayı benzersiz bir talep kimliği ve zaman damgasıyla açıkça kaydeder. | ||
|
Neden önemli?
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 açıkça kaydedilen bir olaydır. Bir talep için 'Create' olayına karşılık gelir ve ilk oluşturulma zaman damgasını sağlar.
Kaydedin
Ticket Audits günlüğündeki talep oluşturma olayından alınır.
Olay türü
explicit
|
|||
|
Hizmet talebi yeniden açıldı
|
Müşteri, 'solved' durumundaki bir talebe yanıt verdiğinde bu etkinlik 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çılma, İlk Temasta Çözüm başarısızlığının ve çözüm kalitesinin düşük olduğunun önemli bir göstergesidir. Yeniden açılan taleplerin sıklığını ve nedenlerini analiz etmek, temsilci eğitimlerinin ve çözüm prosedürlerinin iyileştirilmesi gereken alanları belirlemeye 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.
Kaydedin
Durumun 'solved' durumundan 'open' durumuna geçtiği 'Change' olaylarını izleyin.
Olay türü
explicit
|
|||
|
Müşteriden bilgi istendi
|
Temsilcinin ilerlemek için müşteriden ek bilgi istemesi ve talep durumunu 'pending' olarak değiştirmesiyle gerçekleşir. Bu durum değişikliği, sürecin artık dışarıdan yanıt beklediğini açıkça gösterir. | ||
|
Neden önemli?
Bu etkinlik, müşteriye bağlı bekleme süresini gösterir ve kurum içi SLA sayaçlarını duraklatır. Tek bir talepte sık sık veya tekrar tekrar gerçekleşmesi, ilk bilgi toplama sürecinin eksik kaldığına işaret edebilir ve çözüm süresini uzatabilir.
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ştiğinde kayda geçer.
Kaydedin
Talep durumunun 'pending' olarak ayarlandığı 'Change' olaylarını Ticket Audits içinde belirleyin.
Olay türü
explicit
|
|||
|
Talep temsilciye atandı
|
Bu olay, hizmet talebinin işleme alınmak ü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, sorumlulukların belirlenmesi ve iş yükünün yönetilmesi açısından önemli bir aşamadır. Atamaya kadar geçen süreyi ve yeniden atama örüntülerini analiz ederek ilk değerlendirme ve dağıtım sürecindeki darboğazları görebilirsiniz.
Nereden alınır?
Zendesk Ticket Audits API’de açıkça kaydedilen bir 'Change' olayıdır. 'assignee_id' alanı doldurulduğunda veya değiştirildiğinde kayda geçer.
Kaydedin
Ticket Audits günlüğünde 'assignee_id' alanındaki değişiklikleri izleyin.
Olay türü
explicit
|
|||
|
İlk bilgilendirme gönderildi
|
Müşteriye talebinin alındığını bildiren otomatik ilk yanıtı ifade eder. Bu yanıt genellikle, talep oluşturulduktan hemen sonra şablonlu bir e-posta bildirimi gönderen bir Zendesk tetikleyicisi tarafından iletilir. | ||
|
Neden önemli?
Bu etkinliği izlemek, ilk yanıt hızını ölçmek ve müşteri beklentilerini yönetmek açısından önemlidir. Talebin oluşturulmasıyla bu bilgilendirme arasındaki süre, müşteri memnuniyetini etkileyen temel bir metriktir.
Nereden alınır?
Talep üzerindeki ilk herkese açık yorumun yazarı otomatik bir kullanıcıysa veya yorum talep oluşturulduktan birkaç saniye içinde geldiyse bu etkinlik çıkarımla belirlenir. Ticket Comments akışı analiz edilerek tespit edilebilir.
Kaydedin
Talep oluşturulduktan hemen sonra otomasyon veya tetikleyici tarafından eklenen ilk herkese açık yorumu belirleyin.
Olay türü
inferred
|
|||
|
Kurum içi üst kademeye aktarma başlatıldı
|
Hizmet talebinin başka bir kurum içi ekibe veya daha üst düzey bir destek ekibine aktarılmasını ifade eder. Bu durum genellikle talebin atandığı grup değiştiğinde çıkarımla belirlenir. | ||
|
Neden önemli?
Üst kademeye aktarmaları izlemek; süreçteki aksaklıkları, ilk destek ekibindeki bilgi eksiklerini ve karmaşık talep türlerini belirlemeye yardımcı olur. Aktarma oranlarının yüksek olması, daha iyi eğitim veya süreç dokümantasyonu ihtiyacına işaret edebilir.
Nereden alınır?
Ticket Audits API’de 'group_id' alanının değiştirildiği bir 'Change' olayından çıkarımla belirlenir. Grup değişikliği, ekipler arasında devir teslim yapıldığını gösterir.
Kaydedin
Ticket Audits günlüğünde 'group_id' alanındaki değişiklikleri izleyin.
Olay türü
inferred
|
|||
|
Memnuniyet anketi gönderildi
|
Müşteriye memnuniyet anketinin (CSAT) otomatik olarak gönderildiği anı ifade eder. Bu genellikle talep 'solved' olarak işaretlendikten kısa süre sonra gerçekleşir. | ||
|
Neden önemli?
Bu etkinlik, müşteri geri bildirim sürecini başlatır. Anketlerin ne zaman ve gönderilip gönderilmediğini anlamak, memnuniyet puanlarını doğru bağlamda değerlendirmek ve geri bildirim programının etkisini ölçmek açısından önemlidir.
Nereden alınır?
Otomasyon günlüğünden veya talebe eklenen belirli bir etiketten çıkarımla belirlenebilir. Ticket Audits API’deki 'satisfaction_rating' bölümü de anketin müşteriye sunulduğu zamanı kaydeder.
Kaydedin
'csat_sent' gibi etiketleri arayın veya memnuniyet değerlendirmesinin sunulduğu zaman damgasını kullanın.
Olay türü
inferred
|
|||
|
Memnuniyet puanı alındı
|
Müşteri, 'Good' veya 'Bad' gibi bir puan vererek memnuniyet anketini yanıtladığında bu olay gerçekleşir. Puan ve varsa yorum, talep kaydına işlenir. | ||
|
Neden önemli?
Müşterilerden doğrudan alınan geri bildirim, 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şkilendirmeye yardımcı olur.
Nereden alınır?
Ticket Audits API’de 'satisfaction_rating' alanına müşterinin puanı ve yorumu eklendiğinde 'Change' olayı olarak kaydedilir.
Kaydedin
'satisfaction_rating' alanındaki değişiklikleri bulmak için Ticket Audit günlüklerini filtreleyin.
Olay türü
explicit
|
|||
|
Müşteri yanıt verdi
|
Bu olay, genellikle 'pending' durumundaki bir talebe müşteri yanıt verdiğinde tetiklenir. Zendesk, temsilcinin çalışmaya devam edebileceğini belirtmek için talep durumunu otomatik olarak 'pending' durumundan 'open' durumuna geçirir. | ||
|
Neden önemli?
Bu etkinlik, bekleme süresinin sona erdiğini ve sürecin devam edebileceğini gösterir. Müşterilerin yanıt vermesinin ne kadar sürdüğünü analiz etmek, temsilcilerin bilgi taleplerinin ne kadar açık olduğunu anlamaya yardımcı olabilir.
Nereden alınır?
Bu olay, son kullanıcıdan gelen yeni bir herkese açık yoruma karşılık gelir. Ticket Audits API’de durumun 'pending' durumundan 'open' durumuna açıkça değiştirilmesini tetikler.
Kaydedin
Durumun 'pending' durumundan 'open' durumuna geçtiği 'Change' olaylarını izleyin veya son kullanıcıların yeni herkese açık yorumlarını belirleyin.
Olay türü
explicit
|
|||
|
SLA ihlali gerçekleşti
|
Bu etkinlik, hizmet talebinin ilk yanıt süresi veya çözüm süresi gibi önceden belirlenmiş bir Hizmet Seviyesi Anlaşmasını karşılayamadığı anı gösterir. Olay, talep etkinliklerinin zaman damgaları SLA politikalarıyla karşılaştırılarak hesaplanır. | ||
|
Neden önemli?
SLA ihlalleri müşteri memnuniyetini ve sözleşme koşullarına uyumu doğrudan etkiler. Ne zaman ve neden gerçekleştiğini analiz etmek; sistem genelindeki gecikmeleri, kaynak eksikliklerini veya gerçekçi olmayan performans hedeflerini belirlemek açısından önemlidir.
Nereden alınır?
Bu bilgi, SLA ihlali zaman damgalarını ('breached_at') saklayan Zendesk Ticket Metrics API’den alınabilir. Alternatif olarak talep olaylarının zaman damgaları, tanımlı SLA kurallarıyla karşılaştırılarak hesaplanabilir.
Kaydedin
Ticket Metrics API’deki 'breached_at' zaman damgasını kullanın veya çözüm süresini SLA politikasındaki süreyle karşılaştırarak hesaplayın.
Olay türü
calculated
|
|||
|
Talep sınıflandırıldı ve önceliklendirildi
|
Bir temsilci veya otomasyon, tür, kategori ve öncelik gibi talep alanlarını ayarladığında ya da güncellediğinde bu etkinlik gerçekleşir. Bu adım, talep geçmişine değişiklik olayı olarak kaydedilir. | ||
|
Neden önemli?
Doğru sınıflandırma ve önceliklendirme, taleplerin uygun ekiplere yönlendirilmesi ve kaynakların verimli dağıtılması için önemlidir. Bu etkinliği analiz ederek ilk değerlendirmenin doğruluğunu ve çözüm süreleri üzerindeki etkisini ölçebilirsiniz.
Nereden alınır?
Zendesk Ticket Audits API’den 'Change' olayları olarak alınır. 'priority', 'type' veya sınıflandırmayla ilgili özel alanlardaki ilk güncelleme bulunarak belirlenebilir.
Kaydedin
Oluşturma işleminden sonra sınıflandırma alanlarında gerçekleşen ilk 'Change' olayını bulmak için Ticket Audit günlüklerini filtreleyin.
Olay türü
explicit
|
|||
|
Temsilciden ilk 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. Temsilcinin müşteri sorunuyla ilk kez doğrudan ilgilendiğini gösteren önemli bir olaydır. | ||
|
Neden önemli?
Bu aşama, hizmete yanıt hızını gösteren önemli bir ölçüt olan 'First Reply Time' SLA’sını ölçmek için temel bir kilometre taşıdır. Otomatik iletişimi, temsilcinin inceleme ve destek sürecini başlatmasından ayırır.
Nereden alınır?
Ticket Comments akışında, yazarı otomatik sistem kullanıcısı değil gerçek bir temsilci olan ilk herkese açık yorum bulunarak belirlenir.
Kaydedin
Talep yorumlarını tarayın, temsilcilerin herkese açık yorumlarını filtreleyin ve zaman damgası en eski olanı seçin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Template ile verilerinizi hazırlayın ve müşteri hizmetlerinizi bugün iyileştirmeye başlayın. Zendesk Support operasyonlarınızla ilgili değerli içgörüler edinin ve verimliliği artırın.
Müşteri hizmetlerindeki darboğazları giderin, CSAT puanını hemen yükseltin
Tekrarlanan başvuruları azaltın. İlk temasta çözüm oranını (FCR) %80'e çıkarın ve müşteri memnuniyetini artırın.
Kredi kartı gerekmez