Olay yönetimi Veri Templateiniz
Olay yönetimi Veri Templateiniz
- Toplanması önerilen öznitelikler
- Süreç haritalama için izlenecek temel etkinlikler
- Veri çıkarma için pratik bilgiler
Olay yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Olay kimliği
TicketId
|
Her olay kaydı için sistem tarafından oluşturulan benzersiz tanımlayıcı. | ||
|
Açıklama
Olay kimliği, Zendesk Support’taki her olay vakasını benzersiz biçimde tanımlayan birincil anahtardır. Process Mining için CaseId olarak kullanılır ve olay oluşturulduğu andan kapatılana kadar ilgili tüm etkinlikleri, durum değişikliklerini ve iletişimleri birbirine bağlar. Analizde bu kimlik, her olayın baştan sona izlediği yolu yeniden oluşturmak için önemlidir. Olay verilerinin bir araya getirilmesini sağlayarak her vaka için toplam çözüm süresi, devir teslim sayısı ve hizmet seviyesi anlaşmalarına uyum gibi metriklerin izlenmesine imkân verir. Analistler olayları bu kimliğe göre gruplandırarak süreç akışlarını görselleştirebilir, yaygın yolları belirleyebilir ve standart prosedürden sapmaları tespit edebilir.
Neden önemli?
Tüm olayları tek bir vakaya bağlayan bu temel tanımlayıcı, yaşam döngüsünün tamamını izlemeyi ve süreç performansını doğru biçimde analiz etmeyi sağlar.
Nereden alınır?
Zendesk Tickets API (/api/v2/tickets/{id}), id alanı.
Örnekler
19428230113521941055
|
|||
|
Olay zaman damgası
EventTimestamp
|
Etkinliğin gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Bu zaman damgası, yorum eklenmesi veya durumun değişmesi gibi bir olayın olay yaşam döngüsünde tam olarak ne zaman gerçekleştiğini kaydeder. Bir vaka içindeki tüm etkinliklerin kronolojik sırasını gösterir. Bu öznitelik, zamana dayalı Process Mining analizlerinin temelidir. Etkinlikler arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini belirlemek, toplam vaka süresini ölçmek ve farklı dönemlerdeki süreç performansını incelemek için kullanılır. Vakaların zaman içindeki akışını gösteren animasyonlu bir süreç haritası oluşturmak ve ortalama çözüm süresi gibi KPI’ları izleyen performans Dashboardları hazırlamak için zaman damgalarının doğru olması gerekir.
Neden önemli?
Zaman damgaları tüm etkinliklerin kronolojik bağlamını sunar. Böylece süreler hesaplanabilir, darboğazlar belirlenebilir ve süreç performansı zaman içinde analiz edilebilir.
Nereden alınır?
Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), her denetim olayı için created_at alanı.
Örnekler
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
|
|||
|
Etkinlik
ActivityName
|
Olay yaşam döngüsünün belirli bir noktasında gerçekleşen iş etkinliğinin veya olayın adı. | ||
|
Açıklama
Bu öznitelik, olay yönetimi sürecinde gerçekleştirilen belirli bir adımı veya eylemi açıklar. Örneğin 'Olay oluşturuldu', 'Kayıt temsilciye atandı' veya 'Olay çözüldü'. Bu etkinlikler, sistem değişikliklerinin kaydedildiği Zendesk olay günlüğü veya denetim izi verilerinden elde edilir. Process Mining’de bu etkinliklerin sıralaması, tüm analizlerin temelini oluşturan süreç haritasını meydana getirir. Kuruluşlar etkinlik akışını analiz ederek olayların gerçekte izlediği yolları keşfedebilir, adımlar arasındaki darboğazları belirleyebilir, yeniden çalışma döngülerini (ör. çözülmüş bir kaydın yeniden açılması) ölçebilir ve tanımlı standart sürece uyumu kontrol edebilir.
Neden önemli?
Etkinliklerin sıralaması süreç akışını belirler. Verimsizlikleri ve sapmaları tespit etmek, iyileştirme fırsatlarını bulmak için Process Mining analizinin temelini oluşturur.
Nereden alınır?
Zendesk Ticket Audits API’deki olaylardan elde edilir. Örneğin, status alanındaki bir Change olayı 'Durum değişti' olarak eşlenebilir.
Örnekler
Olay oluşturulduKayıt temsilciye atandıDurum beklemede olarak değiştiOlay çözüldüOlay kapatıldı
|
|||
|
Kaynak sistem
SourceSystem
|
Olay verilerinin çıkarıldığı sistem. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu görünümde değer sabit olur. Örneğin 'Zendesk Support' değeri, tüm olayların ve özniteliklerin bu sistemden alındığını gösterir. Birden fazla sistemden gelen verilerin birleştirildiği ortamlarda bu alan, farklı veri kaynaklarını ayırt etmek için önemlidir. Veri bütünlüğünü korumaya ve Zendesk’teki olay yönetimi sürecini başka bir ITSM aracıyla karşılaştırmak gibi kaynağa özel analizler yapmaya yardımcı olur.
Neden önemli?
Verinin kaynağını belirtir. Bu bilgi, veri yönetişimi ve birden fazla kaynak sistemden gelen verileri birleştiren analizler için önemlidir.
Nereden alınır?
Veri kaynağını belirtmek için veri dönüşümü sırasında ayarlanan sabit değer.
Örnekler
Zendesk SupportZendesk
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Bu sürecin verilerinin en son yenilendiği zamanı gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, kaynak sistemden en son veri çıkarma veya güncelleme işleminin tarih ve saatini kaydeder. Genellikle her yenileme döngüsündeki veri setinin tamamına uygulanan tek bir değerdir. Bu bilgi, veri yönetişimi ve Process Mining analizini kullanan kişiler için önemlidir. Verilerin ne kadar güncel olduğunu göstererek analistlerin mevcut en yeni bilgileri görüp görmediğini anlamasına yardımcı olur. Operasyonel performansı izlerken ve analiz sonuçlarına göre zamanında karar alırken özellikle önem taşır.
Neden önemli?
Verilerin güncelliği hakkında önemli bilgiler sunar; kullanıcıların analizin ne kadar güncel olduğunu ve verilerin en son ne zaman alındığını anlamasını sağlar.
Nereden alınır?
Veri yenileme işlemi tamamlandığında ETL/veri hattı süreci tarafından oluşturulan zaman damgası.
Örnekler
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Atanan grup
AssignedGroup
|
Olayla ilgilenmek üzere şu anda görevlendirilmiş destek ekibi veya grubu. | ||
|
Açıklama
Bu öznitelik, olaydan hangi ekibin sorumlu olduğunu gösterir. Olaylar genellikle farklı destek kademeleri veya uzman gruplar arasında aktarılır; örneğin L1 Destek ekibinden Ağ Ekibine. Bu bilgi, süreçteki devir teslimleri analiz etmek ve darboğazları belirlemek için önemlidir. Analistler, olayların gruplar arasında nasıl ilerlediğini izleyerek ekipler arası bağımlılıkları ölçebilir, belirli ekiplerin kuyrukta bekleme sürelerini hesaplayabilir ve yönlendirme kurallarını iyileştirebilir. Bu öznitelik, Devir teslim ve yeniden çalışma analizi Dashboardunu doğrudan destekler.
Neden önemli?
Ekip sorumluluğunu izleyerek ekipler arası devir teslimleri analiz etmeye, ekiplere özgü darboğazları belirlemeye ve kuyrukta bekleme sürelerini ölçmeye yardımcı olur.
Nereden alınır?
Zendesk Tickets API, group_id alanı. Değişiklikler Ticket Audits API’de kaydedilir.
Örnekler
L1 DestekL2 Ağ EkibiL3 AltyapıFaturalandırma
|
|||
|
Atanan temsilci
Assignee
|
Olayı ele almakla şu anda görevlendirilmiş destek temsilcisi. | ||
|
Açıklama
Bu öznitelik, belirli bir zamanda olaydan sorumlu olan temsilciyi gösterir. Atanan kişideki değişiklikler, işin bir kişiden diğerine devredildiğini gösteren önemli olaylardır. Atanan temsilciyi analiz etmek; iş yükünün dağılımını, bireysel performansı ve iş birliği örüntülerini anlamaya yardımcı olur. Bu alandaki değişiklikleri izlemek, olay başına ortalama devir teslim sayısı KPI’ını hesaplamak ve olayların sık sık farklı kişilere aktarıldığı durumları belirlemek için gereklidir. Bu durumlar, bilgi eksikliğine veya verimsiz yönlendirmeye işaret edebilir.
Neden önemli?
Sorumlu temsilciyi belirleyerek iş yükü analizine ve devir teslimlerin izlenmesine olanak tanır; süreç verimsizliklerini belirlemeye yardımcı olur.
Nereden alınır?
Zendesk Tickets API, assignee_id alanı. Değişiklikler Ticket Audits API’de kaydedilir.
Örnekler
John SmithJane DoeHizmet Masası Otomasyonu
|
|||
|
Bildirim kanalı
Channel
|
Olayın ilk bildirildiği kanal; örneğin E-posta, Web veya API. | ||
|
Açıklama
Bu öznitelik, son kullanıcının veya sistemin olay kaydı oluşturmak için kullandığı yöntemi gösterir. Olayların kaynağını analiz etmek ve destek sürecini buna göre düzenlemek için kanal bilgisini anlamak önemlidir. Olayları kanala göre analiz etmek farklı örüntüleri ortaya çıkarabilir. Örneğin telefonla bildirilen olayların çözüm süresi, e-postayla bildirilenlerden daha kısa olabilir. Bu bilgi, Olay işlem hacmi Dashboardunu destekler; kaynak planlamasına ve kanalların iyileştirilmesine yardımcı olur.
Neden önemli?
Olay hacmini ve süreç performansını kaynağa göre analiz etmeye yardımcı olur; kanala özel süreç iyileştirmelerini ve kaynak dağılımını destekler.
Nereden alınır?
Zendesk Tickets API, via.channel alanı.
Örnekler
webe-postaapitelefon
|
|||
|
Kayıt durumu
TicketStatus
|
Olay anındaki kayıt durumu; örneğin 'Açık', 'Beklemede' veya 'Çözüldü'. | ||
|
Açıklama
Bu öznitelik, olay kaydının yaşam döngüsünün farklı noktalarındaki durumunu gösterir. Zendesk’in standart durumları new, open, pending, on-hold, solved ve closed değerlerini içerir. Bu alandaki değişiklikleri izlemek, Process Mining için etkinlik oluşturmanın temel yollarından biridir. Süreci anlamak için kayıt durumunu analiz etmek önemlidir. Olayların, genellikle müşteri yanıtının beklendiğini gösteren 'Beklemede' gibi belirli durumlarda ne kadar kaldığını belirlemeye yardımcı olur. Ayrıca vakanın ne zaman tamamlandığını tanımlamak ve çözüm sürelerini hesaplamak için kullanılır.
Neden önemli?
Durum değişikliklerini izlemek, sürecin nasıl ilerlediğini anlamak, bekleme sürelerini belirlemek ve olay yaşam döngüsünün başlangıç ve bitiş noktalarını tanımlamak için önemlidir.
Nereden alınır?
Zendesk Tickets API, status alanı. Değişiklikler Ticket Audits API’de kaydedilir.
Örnekler
yeniaçıkbeklemedeçözüldükapatıldı
|
|||
|
Olay bitiş zamanı
EventEndTime
|
Bir etkinliğin tamamlandığı zamanı gösteren zaman damgası. | ||
|
Açıklama
Olay bitiş zamanı, bir etkinliğin sona erdiği anı gösterir. Olay günlüğü verilerinde, bir etkinliğin bitiş zamanı genellikle aynı vakadaki sıradaki etkinliğin başlangıç zamanından çıkarılır. Vakadaki son etkinliğin bitiş zamanı, başlangıç zamanıyla aynı olabilir. Bu öznitelik, tek tek etkinliklerin süresini (ProcessingTime) ve etkinlikler arasındaki bekleme süresini hesaplamak için gereklidir. Darboğaz analizinin temelini oluşturur; analistlerin yalnızca bir adımın ne kadar sürdüğünü değil, başlamadan önce vakanın ne kadar süre beklediğini de görmesini sağlar.
Neden önemli?
Etkinlik sürelerinin ve bekleme sürelerinin hesaplanmasını sağlar; ayrıntılı darboğaz analizi yapmak ve süreç gecikmelerini belirlemek için temel oluşturur.
Nereden alınır?
Aynı vakadaki sonraki olayın başlangıç zamanı olarak hesaplanır. Son olayın bitiş zamanı, başlangıç zamanı veya vakanın kapanış zamanı olabilir.
Örnekler
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
|
|||
|
Öncelik
TicketPriority
|
Olaya atanan öncelik düzeyi; örneğin Düşük, Normal, Yüksek veya Acil. | ||
|
Açıklama
Olayın önceliği, yanıt ve çözüm için gereken aciliyeti belirler. Destek ekibinde işlerin önceliklendirilmesini ve kaynakların dağıtılmasını etkileyen temel bir faktördür. Süreç analizinde öncelik, olayları gruplandırıp süreç akışlarını ve performanslarını karşılaştırmak için kullanılır. Örneğin analistler, Acil öncelikli olayların gerçekten Düşük öncelikli olaylardan daha hızlı çözülüp çözülmediğini inceleyebilir. SLA’lar genellikle öncelik düzeylerine göre belirlendiğinden, bu öznitelik SLA uyumluluğunu izlemek için de kullanılır. Öncelik değişim oranı KPI’ı, bu alandaki değişikliklerin izlenmesine dayanır.
Neden önemli?
Bu öznitelik, analizleri gruplandırmak, önceliklendirme etkinliğini değerlendirmek ve farklı aciliyet düzeylerinde SLA uyumluluğunu izlemek için önemlidir.
Nereden alınır?
Zendesk Tickets API, priority alanı. Değişiklikler Ticket Audits API’de kaydedilir.
Örnekler
düşüknormalyüksekacil
|
|||
|
SLA durumu
SlaStatus
|
Olay için Hizmet Seviyesi Anlaşmasının (SLA) mevcut durumu. | ||
|
Açıklama
Bu öznitelik, olayın belirlenen SLA hedeflerini karşılayıp karşılayamayacağını, hedeflerin aşılıp aşılmadığını veya SLA sayaçlarının duraklatılıp duraklatılmadığını gösterir. Zendesk, yapılandırılan politikalara göre SLA metriklerini otomatik olarak izler. Bu öznitelik, SLA uyumluluğu izleme Dashboardu için önemlidir. Hizmet taahhütlerine göre performansı doğrudan ölçer. Kuruluşlar, SLA’ların ne zaman ve neden aşıldığını analiz ederek süreçlerdeki zayıf noktaları belirleyebilir ve hizmet güvenilirliğini artırabilir. Olay SLA’sına uyum oranı KPI’ını doğrudan destekler.
Neden önemli?
Hizmet taahhütlerine göre performansı doğrudan ölçer; SLA ihlallerinin analiz edilmesini ve uyumluluğu artırmak için proaktif izleme yapılmasını sağlar.
Nereden alınır?
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), sla_policy, breached_at gibi alanlardan türetilir.
Örnekler
EtkinDuraklatıldıİhlal edildiYerine getirildi
|
|||
|
Bildirimi yapan
Submitter
|
Olayı ilk bildiren son kullanıcı veya sistem. | ||
|
Açıklama
Bu öznitelik, kaydı oluşturan kişiyi veya varlığı gösterir. Talep sahibinden farklıdır; bir temsilci başka biri adına kayıt oluşturabilir. Analizde, sorunları kimin bildirdiğini anlamak için bildirimi yapan bilgisi kullanılabilir. Kuruluş verileriyle birlikte değerlendirildiğinde, belirli müşterilerin veya kullanıcı gruplarının çok sayıda olay yaşayıp yaşamadığını belirlemeye yardımcı olur. Bu bilgi, proaktif destek çalışmalarına veya eğitim girişimlerine yön verebilir.
Neden önemli?
Olay bildiriminin kaynağını gösterir. Belirli kullanıcılar, departmanlar veya otomatik sistemlerle ilgili örüntüleri bulmak için analiz edilebilir.
Nereden alınır?
Zendesk Tickets API, submitter_id alanı.
Örnekler
alice.jones@example.combob.williams@example.comSistem İzleyicisi
|
|||
|
Devir teslim sayısı
HandoffCount
|
Bir olayın farklı bir temsilciye veya gruba yeniden atandığı toplam sayı. | ||
|
Açıklama
Bu hesaplanan metrik, bir olayın sorumluluğunun kaç kez devredildiğini ölçer. Atanan kişi veya Atanan grup alanındaki her değişiklik, vaka için bu sayıyı artırır. Devir teslimler, olay yönetiminde verimsizlik ve gecikmenin yaygın nedenlerindendir. Devir teslim sayısının yüksek olması; yönlendirme kurallarının belirsizliğine, destek ekiplerindeki bilgi eksikliklerine veya süreçlerin gereğinden fazla karmaşık olmasına işaret edebilir. Bu metrik, olay başına ortalama devir teslim sayısı KPI’ının temelidir ve Devir teslim ve yeniden çalışma analizi Dashboardu için önemlidir.
Neden önemli?
Aktarımlardan kaynaklanan süreçteki aksaklıkları ölçer; çözüm sürelerini uzatan yönlendirme verimsizliklerini ve bilgi eksikliklerini belirlemeye yardımcı olur.
Nereden alınır?
Bir olay için Atanan grup veya Atanan kişi alanlarının kaç kez değiştiği sayılarak hesaplanır.
Örnekler
0135
|
|||
|
Etiketler
Tags
|
Olayı sınıflandırmak ve bağlam sağlamak için eklenen etiketlerin listesi. | ||
|
Açıklama
Etiketler, ek bağlam sağlamak veya sınıflandırma ve yönlendirmeye yardımcı olmak için kayıtlara eklenebilen esnek tanımlayıcılardır. Temsilciler bunları elle ekleyebilir veya tetikleyiciler ve otomasyonlar aracılığıyla otomatik olarak atayabilir. Etiketler, Process Mining analizleri için zengin bir veri kaynağıdır. Belirli bir ürün lansmanıyla (launch_q4) veya bilinen bir kesintiyle (outage_20231027) ilgili olayları filtrelemek gibi ayrıntılı analiz grupları oluşturmak için kullanılabilir. Bu esneklik, standart kayıt alanlarının ötesine geçen derinlemesine incelemeler yapılmasını sağlar.
Neden önemli?
Olayları sınıflandırmak ve filtrelemek için esnek bir yöntem sunar; yalnızca standart alanlarla yapılamayabilecek ayrıntılı ve bağlama özel analizlere olanak tanır.
Nereden alınır?
Zendesk Tickets API, tags alanı.
Örnekler
vip_usernetwork_issueoutage_20231027billing_related
|
|||
|
İlk temasta çözüldü mü
IsFirstContactResolution
|
Olayın, herhangi bir devir teslim olmadan ilk atanan temsilci veya grup tarafından çözülüp çözülmediğini belirten mantıksal değer. | ||
|
Açıklama
İlk temasta çözüm (FCR), destek merkezi verimliliği ve müşteri memnuniyeti için temel bir metriktir. Bu hesaplanan öznitelik, başka bir temsilciye veya ekibe yeniden atanmadan çözülen olayları işaretler. Mantık genellikle kaydın, ilk atanan temsilci ve grupta kalırken Çözüldü durumuna ulaşıp ulaşmadığını kontrol eder. Process Mining analizinde bu bilgi, FCR oranını doğrudan hesaplamayı ve FCR ile çözülen olayların süreç yollarını üst kademeye aktarılanlarla karşılaştırmayı sağlar. Böylece ilk temas noktasındaki destek hizmetini iyileştirme fırsatları belirlenebilir.
Neden önemli?
İlk destek temasının verimliliğini doğrudan ölçer ve çözümün sürecin daha erken aşamalarında sağlanabileceği fırsatları belirlemeye yardımcı olur.
Nereden alınır?
Hesaplanan mantıksal değer. Olay yaşam döngüsü boyunca kayıt durumu çözüldü veya kapatıldıysa ve yalnızca tek bir farklı atanmış kişi ya da grup varsa doğru değerini alır.
Örnekler
truefalse
|
|||
|
Kayıt türü
TicketType
|
Kaydın sınıflandırması; örneğin Olay, Problem, Soru veya Görev. | ||
|
Açıklama
Bu alan, talebin niteliğine göre kaydı sınıflandırır. Olay yönetimi süreci, özellikle türü Olay olan kayıtları ele alır. Bu kayıtlar, bir BT hizmetinin planlanmamış kesintiye uğramasını veya hizmet kalitesinin düşmesini ifade eder. Analizde bu öznitelik, süreç görünümüne yalnızca olayların dahil edilmesini sağlamak için çoğunlukla filtre olarak kullanılır. Ayrıca olayların, problemlerin veya hizmet taleplerinin ele alınma süreçlerini karşılaştıran daha geniş kapsamlı ITSM analizlerinde de kullanılabilir.
Neden önemli?
Verileri yalnızca olaylara odaklanacak şekilde filtrelemeyi sağlar ve süreç analizinin olay yönetimi yaşam döngüsünü yansıtmasına yardımcı olur.
Nereden alınır?
Zendesk Tickets API, type alanı.
Örnekler
olayproblemsorugörev
|
|||
|
Kök neden kategorisi
RootCauseCategory
|
Olayın altında yatan kök nedenin üst düzey kategorisi. | ||
|
Açıklama
Bu öznitelik, olayın temel nedenini sınıflandırmak için kullanılır. Genellikle olay yaşam döngüsünün sonuna doğru, olay sonrası değerlendirme veya problem yönetimi sürecinde kaydedilir ve özel bir alanda saklanır. Bu veri, Kök neden belirleme doğruluğu Dashboardu ve RCA kapsamı KPI’ı için gereklidir. Olayları kök nedene göre analiz etmek, yinelenen sorunları belirlemeye yardımcı olur; kalıcı çözümler geliştirme ve gelecekteki olay hacmini azaltma çalışmalarına yön verir. Böylece odak, sorunlara anlık müdahaleden proaktif önlemeye kayar.
Neden önemli?
Olay nedenlerini sınıflandırarak proaktif problem yönetimini destekler; eğilimlerin belirlenmesine ve benzer olayların tekrarlanmasının önlenmesine yardımcı olur.
Nereden alınır?
Bu genellikle özel bir kayıt alanıdır. Zendesk Admin Center’daki Ticket Fields yapılandırmasını kontrol edin.
Örnekler
Yazılım hatasıDonanım arızasıKullanıcı hatasıAğ kesintisi
|
|||
|
Memnuniyet puanı
SatisfactionRating
|
Olay çözüldükten sonra son kullanıcının verdiği memnuniyet puanı. | ||
|
Açıklama
Bu öznitelik, genellikle kayıt çözüldükten sonra yapılan bir anketle toplanan müşteri geri bildirimini gösterir. Zendesk’te yaygın puanlar İyi veya Kötü şeklindedir. Memnuniyet puanları süreç verimliliğini doğrudan ölçmese de sonuçları değerlendirmek için önemli bir metriktir. Process Mining analizinde bu puanlar süreç varyantlarıyla karşılaştırılarak hangi çözüm yollarının müşteri memnuniyetini artırdığı anlaşılabilir. Örneğin, daha fazla devir teslim içeren olaylara verilen puanlar daha mı düşüktür?
Neden önemli?
Süreç özellikleriyle karşılaştırılabilecek temel bir sonuç metriği sunar ve süreç performansının kullanıcı memnuniyetini nasıl etkilediğini anlamaya yardımcı olur.
Nereden alınır?
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), satisfaction_rating.score alanı.
Örnekler
iyikötüsunuldusunulmadı
|
|||
|
Müşteri kuruluşu
Organization
|
Olayı talep eden kişinin bağlı olduğu kuruluş veya şirket. | ||
|
Açıklama
Bu öznitelik, olayı müşterinin kuruluşuyla ilişkilendirir. Hizmet düzeylerinin ve destek süreçlerinin müşteriye göre değişebildiği B2B destek ortamlarında önemlidir. Olayları kuruluşa göre analiz etmek, destek ekiplerinin müşteri durumunu izlemesine, belirli müşterileri etkileyen yinelenen sorunları belirlemesine ve sözleşme yükümlülüklerinin yerine getirilmesini sağlamasına yardımcı olur. Dashboardları ve raporları filtreleyerek performansı müşteri odaklı bir bakışla incelemek için temel bir boyuttur.
Neden önemli?
Müşteriye özel analiz yapılmasını sağlar; hizmet düzeylerini izlemeye, önemli müşterilerle ilgili eğilimleri belirlemeye ve müşteri ilişkilerini etkili biçimde yönetmeye yardımcı olur.
Nereden alınır?
Zendesk Tickets API, organization_id alanı.
Örnekler
Global Tech Inc.Innovate SolutionsData Corp
|
|||
|
Önem derecesi
Severity
|
Olayın iş üzerindeki etkisinin düzeyi. | ||
|
Açıklama
Önem derecesi, genellikle genel aciliyeti belirlemek için öncelikle birlikte değerlendirilerek olayın iş üzerindeki etkisini tanımlar. Zendesk’te genellikle özel bir alan olarak yapılandırılır. Önem derecesini analiz etmek, ele alınan olayların ne kadar kritik olduğunu anlamaya yardımcı olur. SLA uyumluluğu izleme ve Önceliklendirme etkinliği metrikleri gibi Dashboardlarda verileri gruplandırmak için temel bir boyuttur. Farklı önem düzeylerindeki süreç akışlarını karşılaştırmak, yüksek önem dereceli olayların uygun hız ve kaynaklarla ele alınıp alınmadığını gösterebilir.
Neden önemli?
Olayın iş üzerindeki etkisini gösterir; en önemli sorunlara odaklanan analizler yapılmasını ve bu sorunların verimli biçimde çözülmesini sağlar.
Nereden alınır?
Bu genellikle özel bir alandır. Zendesk Admin Center’daki Ticket Fields yapılandırmasını kontrol edin.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
Otomatik mi
IsAutomated
|
Bir etkinliğin otomatik bir sistem veya insan temsilci tarafından gerçekleştirilip gerçekleştirilmediğini belirten mantıksal değer. | ||
|
Açıklama
Bu türetilmiş öznitelik, insan kullanıcıların gerçekleştirdiği olaylarla sistem otomasyonlarının, tetikleyicilerin veya API entegrasyonlarının gerçekleştirdiklerini ayırt etmeye yardımcı olur. Genellikle olayın yazarının bilinen bir sistem kullanıcısı olup olmadığı kontrol edilerek belirlenir. Otomasyon düzeyini anlamak, günümüz süreç analizleri için önemlidir. Otomasyon kurallarının etkinliğini değerlendirmeye, otomatikleştirilebilecek manuel görevleri belirlemeye ve otomasyonun verimlilik ile çözüm süreleri üzerindeki etkisini ölçmeye yardımcı olur. Bu öznitelik, otomatik ve manuel etkinliklerin süreç akışlarını karşılaştırmak için kullanılabilir.
Neden önemli?
İnsanların gerçekleştirdiği işlemlerle sistem işlemlerini ayırt eder; otomasyonun süreç verimliliğine etkisini analiz etmeye ve yeni otomasyon fırsatlarını belirlemeye yardımcı olur.
Nereden alınır?
Olayı oluşturan kişinin (Ticket Audits API’deki author_id) bilinen bir sistem veya otomasyon kullanıcısı olup olmadığı kontrol edilerek türetilir.
Örnekler
truefalse
|
|||
|
Vaka süresi
CaseDuration
|
Olayın oluşturulmasından tamamen kapatılmasına kadar geçen toplam süre. | ||
|
Açıklama
Bu hesaplanan metrik, tek bir olayın baştan sona çevrim süresini gösterir. İlk olayın (ör. Olay oluşturuldu) zaman damgasıyla son olayın (ör. Olay kapatıldı) zaman damgası arasındaki fark alınarak hesaplanır. Vaka süresi, genel süreç verimliliğini ölçen temel bir performans göstergesidir (KPI). Ortalama çevrim sürelerini göstermek, uzun süren vakaları belirlemek ve zaman içindeki eğilimleri analiz etmek için Dashboardlarda sıkça kullanılır. Sürecin olayları ne kadar hızlı ele alıp çözebildiğini genel olarak gösterir.
Neden önemli?
Genel süreç hızını ölçmek ve uzun çözüm sürelerine yol açan etkenleri belirlemek için temel bir KPI’dır.
Nereden alınır?
Her olay kimliği için son olayın zaman damgasıyla ilk olayın zaman damgası arasındaki fark alınarak hesaplanır.
Örnekler
25920060480086400
|
|||
Olay yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Durum açık olarak değişti
|
Bir temsilcinin olay üzerinde çalışmaya başladığını gösterir. Genellikle kaydın 'status' alanının 'new' değerinden 'open' değerine değişmesiyle anlaşılır; bu da inceleme ve tanılama aşamasının başladığını belirtir. | ||
|
Neden önemli?
Bu olay, sırada bekleme aşamasından etkin çalışmaya geçişi gösterir. İlk yanıt süresini ölçmek için kayıtların 'new' durumunda kalıp 'open' durumuna geçene kadar beklediği süre önemli bir metriktir.
Nereden alınır?
Kayıt denetim günlüğünde, 'status' alanının yeni değerinin 'open', önceki değerinin ise 'new' olduğu bir 'Change' olayı belirlenerek anlaşılır.
Kaydedin
Durum alanının 'new' değerinden 'open' değerine değişmesiyle anlaşılır.
Olay türü
inferred
|
|||
|
Kayıt temsilciye atandı
|
Kayıt, ilgilenmesi için belirli bir temsilciye atandığında bu etkinlik gerçekleşir. Kayıt denetim geçmişinde açıkça yer alır ve bir kişinin sorumluluğu üstlendiğini gösterir. | ||
|
Neden önemli?
Bu kilometre taşı, ilk atamaya kadar geçen süreyi ölçmek için gereklidir. Devir teslimleri, yeniden çalışmayı ve ilk temasta çözüm oranlarını analiz etmenin temelini oluşturur.
Nereden alınır?
'assignee_id' alanı doldurulduğunda veya değiştirildiğinde kayıt denetim günlüğünden alınır. İlk atama, KPI hesaplamasında önemli bir kilometre taşıdır.
Kaydedin
Kayıt denetim günlüğündeki 'assignee_id' alanına ait bir 'Change' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Kayıt yeniden atandı
|
İlk atamadan sonra kaydın sorumluluğu bir temsilciden veya gruptan diğerine aktarıldığında gerçekleşir. Kayıt denetim geçmişinde açık bir olay olarak izlenir. | ||
|
Neden önemli?
Yeniden atamalar, devir teslimleri ve yeniden çalışmayı analiz etmek açısından önemlidir. Sık yeniden atama, genellikle yanlış ilk yönlendirmeye, karmaşık sorunlara veya süreç darboğazlarına işaret eder.
Nereden alınır?
İlk atama yapıldıktan sonra 'assignee_id' veya 'group_id' alanında gerçekleşen bir 'Change' olayı, kayıt denetim günlüğünden belirlenerek alınır.
Kaydedin
'assignee_id' veya 'group_id' alanına ait sonraki bir 'Change' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Olay çözüldü
|
Bir temsilcinin çözüm uygulayıp kaydı 'solved' olarak işaretlemesiyle bu önemli kilometre taşına ulaşılır. Kayıt denetim günlüğünde durum değişikliği olarak açıkça kaydedilir. | ||
|
Neden önemli?
Bu, temel çözüm etkinliğidir ve çözüm süresini ölçmek için önemli bir noktadır. Bu olayla 'Olay kapatıldı' arasındaki süre, kullanıcı onayına veya otomatik kapatmaya kadar geçen dönemi gösterir.
Nereden alınır?
Kayıt denetim günlüğündeki, 'status' alanının yeni değerinin 'solved' olduğu bir 'Change' olayıyla alınır.
Kaydedin
'status' alanının 'solved' değerine değiştiğini gösteren bir 'Change' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Olay kapatıldı
|
Kayıt kalıcı olarak kapatıldığında olay yaşam döngüsünün sona erdiğini gösterir. Zendesk’te bu işlem, kayıt çözüldükten belirli bir süre sonra genellikle otomatik olarak gerçekleşir ve son durum değişikliği olarak kaydedilir. | ||
|
Neden önemli?
Bu, sürecin kesin bitiş etkinliğidir. Toplam süreç süresi, 'Olay oluşturuldu' ile bu olay arasındaki süre hesaplanarak belirlenir ve çevrim sürecinin baştan sona görünümünü sunar.
Nereden alınır?
Kayıt denetim günlüğündeki, 'status' alanının yeni değerinin 'closed' olduğu bir 'Change' olayıyla alınır.
Kaydedin
'status' alanının 'closed' değerine değiştiğini gösteren bir 'Change' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Olay oluşturuldu
|
Zendesk’te yeni bir kayıt oluşturulduğunda olay yaşam döngüsü başlar. Bu olay, Zendesk kayıt oluşturma denetim günlüğünde açıkça kaydedilir ve her vaka için başlangıç noktası olur. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç etkinliğidir. Genel kayıt yaşam döngüsünün süresini ve ilk yanıt süresini ölçmek için bu olaydan diğer olaylara kadar geçen süreyi analiz etmek önemlidir.
Nereden alınır?
Zendesk kayıt denetim günlüklerinde açıkça yer alan bir olaydır. Her yeni kayıt, ilgili zaman damgasıyla birlikte bir 'Create' olayı oluşturur.
Kaydedin
Doğrudan denetim günlüğündeki kayıt oluşturma olayından alınır.
Olay türü
explicit
|
|||
|
Dahili not eklendi
|
Bu etkinlik, bir temsilcinin diğer ekip üyeleri için kayda özel bir not eklediği dahili iş birliğini gösterir. Yorumun herkese açık olarak işaretlenmemesiyle açıkça kaydedilir. | ||
|
Neden önemli?
Dahili notları analiz etmek, iş birliği gerektiren karmaşık sorunlar hakkında bilgi sağlayabilir. Ancak not sayısının fazla olması, bilgi eksikliklerine veya süreç verimsizliklerine işaret edebilir.
Nereden alınır?
Kayıt yorumları verilerinden alınır. Bir yorumun dahili not olduğu, 'public' özniteliğinin false olmasıyla belirlenir.
Kaydedin
Kayda 'public: false' değerine sahip yeni bir yorum eklendiğinde olay kaydedilir.
Olay türü
explicit
|
|||
|
Durum beklemede olarak değişti
|
Talep sahibinden yanıt beklenirken sürecin duraklatıldığını gösterir. Kayıt 'status' alanının 'pending' değerine değişmesiyle anlaşılır. | ||
|
Neden önemli?
Bu etkinlik, kullanıcı onayını bekleme süresini hesaplamak için önemlidir. Bu durumda uzun süre beklenmesi, toplam çözüm süresini önemli ölçüde uzatabilir ve iletişimdeki gecikmeleri ortaya çıkarabilir.
Nereden alınır?
Kayıt denetim günlüğünde, 'status' alanının yeni değerinin 'pending' olduğu bir 'Change' olayı belirlenerek anlaşılır.
Kaydedin
Durum alanının 'pending' değerine değişmesiyle anlaşılır.
Olay türü
inferred
|
|||
|
Herkese açık yanıt gönderildi
|
Bir destek temsilcisinin son kullanıcıya gönderdiği iletiyi ifade eder. Zendesk’te, kayda herkese açık bir yorum eklendiğinde açık bir olay olarak kaydedilir. | ||
|
Neden önemli?
Herkese açık yanıtları izlemek, iletişim sıklığını anlamak açısından önemlidir. Kullanıcı onayındaki gecikmeleri analiz ederken zaman çizelgesinin önemli bir parçası olabilir.
Nereden alınır?
Kayıt yorumları verilerinden alınır. Bir yorumun herkese açık olduğu, 'public' özniteliğinin true olmasıyla belirlenir.
Kaydedin
Kayda 'public: true' değerine sahip yeni bir yorum eklendiğinde olay kaydedilir.
Olay türü
explicit
|
|||
|
Kayıt gruba atandı
|
Olayın ilk yönlendirilmesini veya ön değerlendirmesini belirli bir destek grubuna ifade eder. Genellikle sorumluluğun atanmasındaki ilk adımdır ve kaydın denetim geçmişinde açık bir değişiklik olayı olarak tutulur. | ||
|
Neden önemli?
Grup atamalarını izlemek, ilk değerlendirme sürecinin verimliliğini incelemeye ve kaydın doğru ekibe yönlendirilmesinden önceki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır?
'group_id' alanı ayarlandığında veya değiştirildiğinde kayıt denetim günlüğünden alınır. Oluşturma işleminden sonraki ilk değişiklik, ilk atamayı gösterir.
Kaydedin
Kayıt denetim günlüğündeki 'group_id' alanına ait bir 'Change' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
Kullanıcı memnuniyeti puanlandı
|
Son kullanıcının aldığı destek için memnuniyet puanı verdiği noktayı ifade eder. Zendesk’te kayıt çözüldükten sonra açık bir olay olarak kaydedilir. | ||
|
Neden önemli?
Memnuniyet puanlarını analiz etmek, temsilci performansı ve süreç etkinliği hakkında önemli geri bildirimler sağlar; süreç metriklerini müşteri sonuçlarıyla ilişkilendirir.
Nereden alınır?
Kayıtla ilişkili memnuniyet puanı verilerinden alınır. Bu veriler genellikle bir puan ('iyi' veya 'kötü') ve isteğe bağlı bir yorum içerir.
Kaydedin
Kayıt için memnuniyet puanı gönderildiğinde olay kaydedilir.
Olay türü
explicit
|
|||
|
Öncelik belirlendi
|
Olayın öncelik düzeyi (ör. Düşük, Normal, Yüksek veya Acil) belirlenir. Bu, açık bir değişiklik olayı olarak kaydedilir ve kaydın aciliyetini ve gereken yanıt süresini belirler. | ||
|
Neden önemli?
Önceliğin ne zaman ve nasıl belirlendiğini izlemek, Kritik sorunların hızla ele alınmasını sağlayan 'Önceliklendirme etkinliği metrikleri' Dashboardı için önemlidir.
Nereden alınır?
Kayıt denetim günlüğündeki 'priority' alanına ait bir 'Change' olayından alınır. Öncelik değişim oranı KPI’ını ölçmek için sonraki değişiklikler de izlenebilir.
Kaydedin
Kayıt denetim günlüğündeki 'priority' alanına ait bir 'Change' olayıyla belirlenir.
Olay türü
explicit
|
|||
|
SLA hedefi aşıldı
|
Bir kaydın ilk yanıt süresi veya çözüm süresi gibi tanımlı bir Hizmet Seviyesi Anlaşmasını karşılayamadığı anı gösterir. Bu olay, SLA politikası tanımlarına ve kayıt güncelleme zaman damgalarına göre hesaplanır. | ||
|
Neden önemli?
Bu olay, SLA uyumluluğunun izlenmesini doğrudan destekler. İhlallerin ne zaman ve neden yaşandığını belirlemek, hizmet güvenilirliğini ve müşteri güvenini artırmanın temelidir.
Nereden alınır?
Bu, hesaplanan bir olaydır. Her SLA hedefi için 'breached_at' zaman damgası kullanılarak kayıtla ilişkili 'sla_policy_metrics' verileri analiz edilip elde edilebilir.
Kaydedin
Kaydın SLA metriği verilerindeki 'breached_at' zaman damgasından elde edilir.
Olay türü
calculated
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Veri hazırlığını kolaylaştırmak ve olay yönetimi performansınıza dair anlamlı içgörüler elde etmek için bu Templateten yararlanın. Sürecinizi iyileştirmeye bugün başlayın.
Olay yönetimini iyileştirin, olayları daha hızlı çözün
Ortalama çözüm süresini (MTTR) %35 azaltın, tekrarlayan olayları ortadan kaldırın ve memnuniyeti artırın.
Kredi kartı gerekmez, iyileştirmeye dakikalar içinde başlayın